Can the dependencies on GMAO_hermes be eliminated?

[tclune]

We’re still waiting on Larry/Scott to approve the changes that pull FVdycoreCubed_GridComp and fvdycore into separate repos, but yesterday I went ahead and created a this fixture (GEOSfvdycore) for building and running just FV. (NOTE: it is not too late if you prefer a different name for this.)

Ideally the full package would only involve the following repos:

@env
@cmake
@MAPL
@GFDL_fms
@FVdycoreCubed_GridComp
@fvdycore (GFDL_atmos …)

Unfortunately though, there is a dependency on GMAO_hermes, which itself has a dependency at least on GMAO_gfio, and probably mpeu as well. At the very least the Harvard CTM people would like to avoid including these dependencies, but you may also see value in keeping this dependency chain as small as practically possible.

Looking into the details, the FV dependencies on hermes are on m_set_eta and m_topo_remap

The dependencies on hermes are pretty minor: m_set_eta and m_topo_remap. The latter in turn depends on m_dyn. (I'm ignoring trivial dependencies on constants that define Fortran KIND's.)

Now, we have already planned an improved set_eta module that would live in MAPL that uses config files rather than hardcoded values. This would greatly improve the ability of external groups to use GEOS for their own grid choices.

But m_topo_remap (and m_dyn) are a bit more insidious. They cannot be moved, because other things in hermes need them. And I don't want to duplicate them. One possibility is to split hermes into two parts, say FVhermes and hermes (the rest). But maybe this dependency is already unnecessary and existing functionality already exists inside FV itself? m_dyn appears to be an attemp to duplicate FV state, which then seems odd for FV to depend on it.

Let me know how you would prefer to proceed.

[mathomp4]

It looks like m_topo_remap is only needed by FV3 when Intermittent Replay is enabled?