Agenda Notes Monday May 22nd 2017 11:00 AM

MPAS-Developer Telecon:

Date: 22 May 2017
Time: 11:00 MDT / 19:00 CET

Call-in number: 1-866-740-1260
Access Code: 4978161

---

---

Agenda Topics:

1. Framework modifications:
   • Open framework PRs
2. Standing topics:
   • MPAS-Atmosphere has renewed interest in generalized variable attributes
   • Subset I/O capability
   • Periodic meshes
   • https://github.com/MPAS-Dev/MPAS/issues/1307 "reference time" for output_interval in streams
3. Code cleanup (Dom, not attending the telecon because on the plane to Burkina Faso): is routine mpas_block_creator_reindex_block_fields in src/framework/mpas_block_creator.F used in any of the cores? It is not used in release v5.1 and also not in develop
4. Alternative solution to forcing timestamps: https://github.com/MPAS-Dev/MPAS/pull/1332
5. Using the forcing module correctly.

---

---

Notes:

Participants: Adrian, Matt, Mark

Framework PRs

• #1332
  • this option is favored over #1318 for handling restart times of forcing groups
  • since ocean core is using forcing, Mark's opinion on core-specific changes would be valuable
  • see other notes below for notes on correct usage of the forcing module
• #1331
  • unanimous agreement that we all write so few messages during model runs that flushing after each write by default should have almost unnoticeable performance impact
  • is it worth adding flushNow=.false. to only a select set of log writes, or should we not bother changing any code to avoid flushing unless specific performance issues are identified?
• #1300
  • we should wait until thorough testing in ACME has been completed before merging this PR

Standing topics

• Issue #1307
  • Intuitively, reference_time should control the filenames in a stream as well as the read/write times
  • What about streams that have different reference times?
  • Can the timekeeping module handle different reference times for each alarm?

Code cleanup

• Investigate whether the currently unused routine mpas_block_creator_reindex_block_fields has any potential use, e.g., when reordering mesh elements "online" after the original creation of blocks
  • Also see whether this routine has applicability to the building of halos for periodic meshes or other use cases

Forcing module

• As noted above in discussion of PR #1332, it seems preferable to save forcing clock times in restart files themselves
  • Some uses of the forcing module were incorrect in their order of operation concerning the reading of forcing data and restart data
  • Other uses were creating separate linked lists for different forcing groups, though the cleanest and preferred way to use forcing groups involves storing all groups in a single linked list
  • Adrian is willing to provide guidance in the "best practices" when using the forcing module for any future uses by cores