Comply with MAPL "positive" standards in export definitions

[sdeastham]

Currently GCHP does not obey MAPL conventions regarding which way is "up" in exported data. It appears that - when writing out - data acquired through the GEOS-Chem diagnostic arrays are produced "inverted" (level 1 = surface, even though HISTORY is meant to output with level 1 = TOA) but all other data are produced "right way up" (level 1 = TOA). I've opened a request in the GEOS-ESM/MAPL repo to make the "positive" attribute of vertical data be something that is communicated explicitly in imports and exports (GEOS-ESM/MAPL#284), which would resolve this issue. However, this will require that we modify GCHP to comply with MAPL's standards.

[lizziel]

Currently non-HEMCO diagnostics are the only GIGCchem grid comp HISTORY output that are inverted to be opposite the MAPL standard of level 1 = TOA. HEMCO diagnostics and checkpoints comply with the MAPL standard. Is this feature request to make ALL outputs have level 1 = TOA or level = surface?

[sdeastham]

ALL level 1 = TOA (i.e. comply with MAPL standards). My understanding is that the HEMCO diagnostics are a small minority of the ones we output, so most of our outputs don't comply with MAPL (but then I'm biased as I rarely use the HEMCO diagnostics). The hope is that changes resulting from GEOS-ESM/MAPL#284 would then allow us to be more flexible in HISTORY by simply specifying positive=up.

[lizziel]

My preference is to change HEMCO diagnostics so that level 1 = surface in the output so that ALL diagnostics set in HISTORY.rc are consistent with GEOS-Chem Classic conventions. Then once MAPL is updated to allow specifying positive=up in HISTORY.rc we could remove the level inversion during the copy phase and continue to have level 1 = surface in output files. Is this in line with what you have in mind?

[sdeastham]

Not really. I defer to MAPL over GCC, simply because it's MAPL that's doing the data processing and handling; any outcome where we are "lying" to MAPL seems non-optimal. Plus (if I understand it correctly) NetCDF files produced by MAPL currently all have "positive=down" as an attribute. That means our files can be easily misinterpreted. But certainly I'd prefer any consistency over what we have now.

[lizziel]

Yes, MAPL currently assigns the "positive=down" attribute to the lev dimension by default for all HISTORY outputs, which means close inspection of the file will give an incorrect interpretation of the content. My hope is there would be flexibility to choose positive up or down in the future. Then we could decide whether to output positive up or down based on what is easiest and least confusing for users without having to "lie" to MAPL.

[sdeastham]

Based on today's discussion (documented also in GEOS-ESM/MAPL#284) my hope is that we can robustly assume all imports to be "positive=down", and accordingly should (once the HISTORY option is available of course!) modify GCHP to write all export data using the MAPL convention (with all our default HISTORY output collections including the "positive=up" tag). Does that seem reasonable?

[lizziel]

Yes, assuming you mean MAPL will store all imports at "positive=down" and transform them to that as needed based on information in the input file. I would love it if all input data had that positive attribute. The question is is that too much of a burden on users to change all their files.

[lizziel]

Related to issue #115 which addresses exports only.

[lizziel]

Also related to GEOS-ESM/MAPL#942 which addresses "positive" standards in writing checkpoints and reading restarts.

[lizziel]

This is being moved to the 14.1 release.

[lizziel]

This is not currently a priority for 14.1.