geoschem / GCHP

The "superproject" wrapper repository for GCHP, the high-performance instance of the GEOS-Chem chemical-transport model.
https://gchp.readthedocs.io
Other
22 stars 25 forks source link

Comply with MAPL "positive" standards in export definitions #21

Open sdeastham opened 4 years ago

sdeastham commented 4 years ago

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 (https://github.com/GEOS-ESM/MAPL/issues/284), which would resolve this issue. However, this will require that we modify GCHP to comply with MAPL's standards.

lizziel commented 4 years ago

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 commented 4 years ago

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 https://github.com/GEOS-ESM/MAPL/issues/284 would then allow us to be more flexible in HISTORY by simply specifying positive=up.

lizziel commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

Based on today's discussion (documented also in https://github.com/GEOS-ESM/MAPL/issues/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 commented 4 years ago

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 commented 3 years ago

Related to issue https://github.com/geoschem/GCHP/issues/115 which addresses exports only.

lizziel commented 3 years ago

Also related to https://github.com/GEOS-ESM/MAPL/issues/942 which addresses "positive" standards in writing checkpoints and reading restarts.

lizziel commented 2 years ago

This is being moved to the 14.1 release.

lizziel commented 1 year ago

This is not currently a priority for 14.1.