Print important version notes during run directory creation

[lizziel]

Your name

Lizzie Lundgren

Your affiliation

Harvard University

Please provide a clear and concise description of your question or discussion topic.

This issue is to start a discussion about how to highlight important version notes to users. This addresses a challenge brought up at last week's IGC meeting with regards to notifying users about settings such as offline emissions and discontinuities in GEOS-FP data.

One way we could do this is by including a list of important messages during run directory creation. Currently when you create a run directory messages are printed upon successful creation, such as this:

  -- Using default directory name gc_05x0625_geosit_TransportTracers
  -- See rundir_vars.txt for summary of default run directory settings
  -- This run directory has been set up to start on 20190101
  -- A restart file for this date has been copied to the Restarts subdirectory
  -- You may add more restart files using format GEOSChem.Restart.YYYYMMDD_HHmmz.nc4
  -- Change simulation start and end dates in configuration file geoschem_config.yml
  -- Default frequency and duration of diagnostics are set to monthly
  -- Modify diagnostic settings in HISTORY.rc and HEMCO_Config.rc

We could update this to include simulation and/or version-specific notes about things such as offline emissions.

@hmhorow, @cdholmes, @eamarais

[eamarais]

@lizziel, thanks for initiating this. Would these appear by default or only if a user has made a selection that could be affected? So, something like "discontinuity in GEOS-FP from January 2020 may affect your simulation. See URL" if user chooses GEOS-FP met fields when generating a run directory?

[lizziel]

We can put messages specific to what the user chooses during run directory creation. This includes simulation type, grid resolution (if using GC-Classic), and meteorology source. We can also add additional questions if needed but we do prefer to keep it simple.

[yantosca]

Thanks @lizziel. Maybe we could implement this by placing the messages into a configuration file (YAML?) so that we can easily update the messages..

[cdholmes]

This sounds like a very useful addition, @lizziel.

It became apparent to me at IGC11 that many (most?) users are not aware that they should avoid using GEOS-FP after 1 June 2020 (convection change), unless the user wants to study/improve transport in GC. While GEOS-FP has always been "user-beware", the surface concentrations of simple things like CO are so far below observational constraints that it should only be used by people who know this and are OK with it. I believe recent GEOS-IT data have the same issue, although I haven't used that MET data.

I would personally favor a halting error in GC, with a user option to override it. That should be done in consultation with the Transport WG chairs.

[luhu0]

I second all that has been said and it will be quite useful. I am one of the users who are not aware of the post-2020 GEOS-PF issue or forgot about it. Thank you all for the discussion. If the issue is so significant, I'd appreciate guidance and solutions for alternative ways of post-2020 simulations at higher resolution (likely MERRA2 running at 0.25 degrees as I learned at IGC11). I'd favor @cdholmes's proposed approach with a halting error and an option to override, like what we have with the lightning NOx. I am curious about what other users think.

[lizziel]

By halting error do you mean pause during run directory creation if the user chooses GEOS-FP to print warnings and then only proceed if the user manually acknowledges the warnings?

[yantosca]

@lizziel @luhu0 @cdholmes: The start date in the run directory is pegged to 2019/01/01 and the user has to manually change it. Maybe the halting error would be better in HEMCO. I'm not sure if there is a way to query starting date of simulation at run directory creation. We could certainly display a warning about GEOS-FP at rundir creation though. Thoughts?

[lizziel]

Tagging transport WG co-chairs: @aschuh, @ktravis213.

Are we now recommending that users not use met products at all created with post-2020 GEOS versions? Could someone from the community respond to the GEOS-Chem github issue detailing the problems with convection in post-2020 products: https://github.com/geoschem/geos-chem/issues/1409? We can link to this issue to give users more detail of the problem and recommendations moving forward.

[aschuh]

I think this deserves a closer look and maybe a short document explaining. Having compared CMFMC somewhat explicitly from MERRA2 against ERA-interim, I was a bit surprised that there wasn't more attention paid to noting the convection change in GEOS-FP. My original fear was poorly reviewed papers showing amazing science results that might be simply an artifact of this model change. My personal community, e.g. carbon/CO2/OCO2 inversions, all use MERRA products so this shouldn't be an issue. However, anybody using a more operational product, e.g. GEOS-FP ?, would probably need to be aware of it. I imagine it's only more important once you throw chemistry in the mix. There are a couple things that I can't answer but you guys probably can?

(1) What are the usable GMAO based transport field options being used now? MERRA1, MERRA2, GEOS-FP, GEOS-FPIT, etc? Which of those would include a time varying underlying GEOS model (w/ thought towards convection param) and possibly see step change kinds of issues after 2020? It would be good to document the answer to that question as well as maybe produce some simple plots of different met quantities, e.g. CMFMC, across the change. A warning or something where the user needs to "sign off" is probably a worthwhile safety feature of running across the time period, although for those doing automatic runs, you'd probably need a feature (not on by default) to also suppress this in ensemble runs.

(2) Then ...going WAY back, Andrea Molod also mentioned some kind of "bug" that occurred around the same time as the convection change but her recollection was "fuzzy" on the matter. I can't really comment on that and I imagine we'd need clarification from GMAO.

Again, I'd hope GC support might be able to document (1) and maybe we could get some feedback from GMAO on (2) ?

my 2 cents

andrew

[cdholmes]

I responded to #1409. The bug mentioned by Andrea Molod does not affect this discussion.

When I suggested a halting error, I meant that GEOS-Chem simulation should halt when used with GEOS-FP after 1 June 2020, unless the user explicitly allows it in geoschem_config.yml. If GCST or community doesn't want to go that route, then a warning message when creating a run directory with GEOS-FP is reasonable.

An email notice to all users would also be reasonable (perhaps in the newsletter), so that users of older model versions are aware.

[aschuh]

Maybe I'm confused then. The issue arises when using pre June 1, 2020 GEOS-FP and post Jun 1, 2020 GEOS-FP and assuming they are the same, right? If post uses GF scheme for example and pre uses RAS, who is to say one is right or wrong? The issue arises when you use BOTH and assume they should be similar, at least in my mind. Happy to hear others thoughts.

[cdholmes]

My understanding is that vertical transport is determined by the convective mass fluxes AND the algorithm for vertical transport. GEOS-Chem has retained the same transport algorithm while the mass fluxes and algorithm changed in the upstream GEOS model. It seems that the GC algorithm produced reasonable vertical distributions of many trace gases when using the older RAS mass fluxes, but not with the new GF fluxes. One salient difference seems to be that RAS and GC assume that compensating clear-air subsidence occur within the same grid cell as the upward convection, while GF allows subsidence to occur in neighboring grid cells. That could lead to GC diagnosing more subsidence and overturning in grid cells with convection than is happening in GEOS under the same conditions.