GEOS-ESM / MAPL

MAPL is a foundation layer of the GEOS architecture, whose original purpose is to supplement the Earth System Modeling Framework (ESMF)
https://geos-esm.github.io/MAPL/
Apache License 2.0
27 stars 18 forks source link

Can MAPL3 create 1D variables not mapped to gridded dims #2955

Open bena-nasa opened 1 month ago

bena-nasa commented 1 month ago

The title says it all. When I was thinking about vertical regridding we are going to want to start putting AK and BK in addition to PS in our output files potentially so that any file could be regridded to a different resolution. This is fine because AK and BK are exports of the dynamics in the current model.

But, those are a bit special because they have no geometry associated so the array does not map to any gridded dimensions of any ESMF geometry. MAPL2 handles this just fine and can create such fields, but does MAPL3? Can I specify a VarSpec that's a 1D field that has no mapping to any gridded dims?

If so, what is the syntax in the field spec, i.e. what the MAPL3 way to specify MAPL_DimsVertOnly in the spec?

If not it needs to at some point or find an alternative way for History to access this information.

tclune commented 1 month ago

At the moment, no. But this need was at least anticipated, and several of the hooks are there in HORIZONTAL_DIMS_NONE. (I'm very open to a better name to capture this case.)

A bit of logic needs to be added to FieldSpec.F90 to add a gridToFieldMap argument to the call to ESMF_FieldEmptyComplete() which will indicate "replicated" dimensions. (ESMF terminology for this case.)

tclune commented 1 month ago

Note - in ESMF parlance my plan is that these fields are associated with a geometry; albeit just for consistency. (And Fields must have some geom object.)

But this probably raises an issue that I had not anticiptated. If we have say DYN export ak, bk. And those are then imported into a History collection on a different geom, I'm not sure what happens when we try to use the Routehandle object created to regrid between the two geoms. Probably bad things, but possibly ESMF anticipated this. If not, then the make_extension() method in FieldSpec will need a conditional for the degenerate case. (And we might want it anyway for performance reasons.)