This page summarizes discussions during the speed-dating sessions with the ocean-ice team (where particular to-do items were requested, the relevant persons name has been flagged with an @).
Coupler-SE
- discussion regarding CIME5 integration and how to organize the timing of that with other bug fixes ocean-ice team needs to get in
- life after Doug ... how are we doing?
- SE side is doing ok (Jim F. filling in for Git expertise)
- Jon W. filling in integrator role for ocean-ice team; Mark P. coming up to speed
- discussion of use of slack more widely (e.g., project-wide vs. just within SE team)
- Rob J. says there is already a "channel" per group, but discussion that is at level of "help ticket" should still go through triage hub still
- Robert Jacob will send out ACME-all email regarding wider use of slack
- Andy S. brings up trying to move MPAS builds over to Cmake; we are trying it out, it has been discussed on MPAS telecons (lost some note here due to crap internet connection)
- Rob J. demoed use of slack for the rest of the group
...
- Todd R. to perf. team – where are the opportunities to make our models faster?
- Phil J. – what are we targeting for hi-res ... 15to5km or 18to6km?; Pat. W. has no experience with 18to6km
- Pat W. – atmos. and ice are the bottleneck, not the ocean ... so ice perf. will decide (?)
- Pat W. – Titan is currently the only machine where ocean-ice perf. on each node can be optimized (by allocating procs. differently for each?)
- Mat M. – says that recent discussions indicate that we'll probably be using the 18to6km for hi-res rather than the 15to5km
- Oz has been using diff. coupling freq. than Pat W. (to what end?)
- Phil J. – perf. team needs to know the final configuration (resolution, coupling freq. ASAP) so they can work on benchmark / improve perf. for that
- Adrian T. – thought we already decided on the coupling freq. ; don't change from what we previously decided
- Phil J. – Matt N. has been starting work on gpu port (for MPAS-O); this will lead to multiple versions of MPAS-O ... how does MPAS team want to handle this?
- Todd R. response – doesn't matter too much as long as you aren't touching framework
- Matt N. – we will not be touching framework, but probably need two sources codes for CPU vs. GPU ... how do we avoid him having to do the port to GPUs multiple times?
- wider discussion – what is process for merging changes if we have multiple code bases for GPUs, CPUs, MICs, etc.?
- Todd R. / others – can we have multiple F90 files in repo (on master) for use on diff. arch? Then MPAS team is responsible for making / controlling changes in multiple versions of a single F90 file (?)
- Phil J. – pushing loops down in code may requiring refactoring of CVMIX
- Mark P. – requests clearer updating / posting of existing perf. on various machines to Confluence
- Philip Jones, Patrick Worley (Unlicensed) to tidy this up and point us to it? E.g., we add a "quick link" to this that is easy to find from the perf. home page
- Phil J. – MPAS team should anticipate possibly significant changes to code structure for GPU port
- questions on why threading perf. improvements seen in stand-alone testing are not translating through to perf. improvements in the fully coupled system (e.g. CVMIX), with particular reference to work of Abhinav; Pat W. notes this is consistent with past work as well