PIO for MOM6

[jedwards4b]

Alper and Jim,

As we look into various optimization / speed-up opportunities for MOM6, I am reminded that Alper was looking into PIO approaches in MOM6 / FMS. Alper: Could you please provide an update on this?

Best,
Gokhan

[jedwards4b]

Not sure if Gokhan has a GitHub account to receive notifications from that GitHub issue, so I am responding here.

Previously, MOM6 had explicit FMS calls throughout the source code. But recently, a layer of abstraction between FMS and MOM6 has been introduced into MOM6. The main motivation is to support multiple versions of different infrastructure libraries, and not just FMS. As a result, for instance, we can now run with either FMS1 or FMS2, without making any changes in the MOM6 source code. We can utilize this abstract infrastructure layer to introduce PIO. A couple of paths I can think of:

(1) bypassing FMS IO calls and instead calling an in-house IO module (to be developed), and still using FMS for all other infrastructure operations. This should allow us to introduce PIO in MOM6 without having to touch the FMS code. But I am not sure if this path is viable. Interdependencies between other FMS modules and IO need to be identified.
(2) start maintaining our own fork of FMS and freely make changes in our own version as we need, and in an incremental fashion. Because the interface between MOM6 and FMS is an abstract layer, we don't need to push our FMS changes back to GFDL to keep our MOM6 versions in sync. Initially, this path seems more viable, but we need to make sure that we have the resources and commitment to maintaining an in-house FMS version in the longer term. We also need to make sure that this path is viable for CESM FV3 folks who also rely on FMS.

So, I suggest we first explore option (1) and if that doesn't seem to be viable, we may discuss whether we have resources for option (2).

Thanks,

Alper