Transitioning from MPAS-O and to OMEGA
The E3SM project will place MPAS-O into maintenance only following the finalization of v3.1 (roughly January 2024).
Bandwidth of the E3SM project is limited and it is not possible to be responsible for the support of new features developed by ecosystem projects.
Proposed plan
Planned ocean developments must be communicated to the Omega group leadership
Ecosystem projects must designate a point of contact on the ecosystem project for every feature. If that person leaves a new POC must be designated.
Ecosystem projects that need features before the delivery of Omega should develop in fortran and utilize MPAS-Ocean
All ecosystem features must be developed as ‘stealth features’, which means they go into the code as off and the model must be shown as BFB with the current code.
Ecosystem project teams must follow full procedure for stealth features defined hereE3SM Code Review and New Feature Process (documentation and testing)
Design doc required
For all features a 10-year fully coupled simulation is required
For features that change the climate when enabled, a 100-year coupled (standard resolution) run is required.
The E3SM project will be responsible for the final merge to E3SM master
All new features must have a corresponding feature test for regular testing.
When the testing fails it will be the responsibility of the ecosystem project to provide a fix.
Longer term developments should move to C++
Possibility to develop ecosystem wide hackathons to train up staff in C++/YAKL
The same comment about being a stealth feature applies to C++ developments
The E3SM project is not obligated to fully test, validate, and maintain all new ecosystem developments.
This means that there will be no guarantee from the E3SM project that new code developments will be maintained with the evolving E3SM code.
The E3SM project may decided to fully support new features at its discretion.
Only features fully tested, validated, and maintained by the E3SM project will be ported to Omega