/
Transitioning from MPAS-O and to OMEGA

Transitioning from MPAS-O and to OMEGA

  • The E3SM project will place MPAS-O into maintenance only following the finalization of v3.1 (roughly August 2025).

  • 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

    • Once Omega is coupled and validated in E3SM, all new ecosystem features must develop new features in C++

  • 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.

  • The E3SM project may decide to support new ecosystem features if they are of clear benefit to current or planned project goals.

    • In this case, the E3SM project will take charge of maintenance of the feature

    • In the rare cases where the feature is in fortran, the E3SM project will lead the porting of the feature to C++ with the assistance of the feature POC from the ecosystem project.

  • Ecosystem features written in C++, not supported by the E3SM project must follow the coding style and standard of Omega and must again follow the code review process outlined above for the fortran code.