New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[FEATURE REQUEST] Skip reading FLASH_DENS and CONV_DEPTH fields when lightning NOx extension is turned off #279
Comments
There are quite a few met fields that are never used by GEOS-Chem, e.g., the SEAICE{01..90} fields are only used by the Hg simulation, and some are just read in to be re-written as diagnostic output. It would be more generic if GEOS-Chem had the feature to ignore any met field specified in HEMCO_Config.rc with /dev/null, as I believe GCHP allows? Since the speciality simulations that do not use lightning NOx don't call the lightning NOx extension, it doesn't matter what is in the lightning flash State_Met field. This would facilitate coupling with met fields from other external GCMs/CCMs as well. |
@ltmurray You make a great point. I am planning on doing this work for the methane simulation (i.e. skipping reads of unnecessary met fields). I can think of a way to expand this to all simulations so that only the met fields needed by that simulation are read by HEMCO. |
This feature will be included in 12.9.0 because it will require changes in HEMCO_Config.rc files and therefore will require the creation of new run directories. |
…ng NOx extensionin HEMCO is off A shadow variable Input_Opt%DoLightNOx has been added and will be set to true or false depending on if the lightning NOx extension is turned on in HEMCO_Config.rc. When that option is off, the reading of FLASH_DENS and CONV_DEPTH in flexgrid_read_mod.F90 will be skipped (keeping those fields as all zeroes). This will avoid the requirement of having users download those data for simulations that do not require it. For more details, see #279. Signed-off-by: Melissa Sulprizio <mpayer@seas.harvard.edu>
…ng NOx extensionin HEMCO is off The FLASH_DENS and CONV_DEPTH entries in HEMCO_Config.rc have been removed from simulations that do not use the lightning NOx extension. In the code, a shadow variable Input_Opt%DoLightNOx has been added and will be set to true or false depending on if the lightning NOx extension is turned on in HEMCO_Config.rc. When that option is off, the reading of FLASH_DENS and CONV_DEPTH in flexgrid_read_mod.F90 will be skipped (keeping those fields as all zeroes). This will avoid the requirement of having users download those data for simulations that do not require it. For more details, see geoschem/geos-chem#279. Signed-off-by: Melissa Sulprizio <mpayer@seas.harvard.edu>
Hi @msulprizio |
Hi Jenny, changing the behavior flag to “C” should work. It will then read in 2019. |
Yes, Lee's suggestion is a quick an easy way to get past the error. The lightning fields for 2019 will be read in that case (and still not used as you point out). If you want to skip the read completely in GEOS-Chem 12.8.2 and earlier, you can comment out those lines in HEMCO_Config.rc:
and also comment out the corresponding lines in GeosCore/flexgrid_read_mod.F90:
You would then need to recompile the code. The fields won't be read and will remain all zeroes. |
Thanks both! |
Actually changing the flag to C (or CS) didn't work. |
Huh, that's weird. Any idea why, Melissa? Melissa's fix should definitely work, but as another quick offline alternative, you can just take one of the previous MERRA2 leap-year files (e.g., 2016), and change the time units with ncatted or ncap2 to be relative to 2020, e.g.,
or
|
Thanks Lee. We'll stick with Melissa's as a fake file will be an issue when we start to run full chem for that period (which is fairly imminent). On that note - what do you recommend we do for 2020 runs since there are no lightning fields yet? We're really mostly interested in what's happening near the surface, but it seems not ideal to have lightning turned off completely. Is there a climatology we can use, or some other option? What's the timeframe for 2020 fields? |
I'm not sure why using 'C' didn't work, but setting verbose and warnings to 3 would tell us why if we wanted to dig further. That would provide information in the HEMCO.log file about what the expected date/time is and what it finds. For what it's worth, we're planning on generating a lightning climatology file for the 13.0.0 release by running a 10-year HEMCO standalone simulation. The idea is that if a user wants to run for a time period for which lightning data isn't available, then HEMCO will crash with an error letting them know that they have the choice to use the climatology file. We'll do the same for volcanoes, which also does not have 2020 data at this time. |
Hi Melissa, Have seen in 12.8.1 and 12.8.2 out of the box code. So it may be a more pervasive problem with HEMCO... Thanks for the note about the climatology - that will be really useful!! Lee - any recommendation on what to do for 2020 lightning in the interim? Cheers, |
Hi Jenny, I have MERRA-2 lightning generated for Jan-Mar, 2020 so far — send me an offline message if you want me to send them to you. I am presently processing April 2020. Any user who sees this, please always feel free to contact me directly for the most recent available lightning. BTW, there is no need to use HEMCO to generate a lightning climatology; I generate this using CDO during the process of creating the scaling factors, so it already exists. Also, I've noticed an issue with dryrun failing to download fields newer in time if a subset of older fields have already been downloaded, including the surface files. E.g., if previously I used dryrun to download and run 2018, but then later use dryrun for a new 2019 simulation, any fields flagged with "C" do not show up as missing in the log file and the downloader skips them. But when the full model runs, it expects the field to exist based on the temporal specification (e.g., 1960-2100), and crashes when it can't find the file for that year, usually showing a random year in the error message. I haven't had time to put together a toy example to confirm that this is what is happening, but was going to probably put together a bug ticket. Just mentioning, in case you want to explore in the meantime, since it sounds potentially related to what Jenny is seeing. |
Thanks Lee, I'll follow up offline. Re dryrun, see #312 (in theory fixed, though I'm now having an issue where the dryrun thinks all my files are missing when they are there!). |
Thanks, Lee! Can you send us the climatology files you've generated? We'll be adding that as an option in 13.0.0. |
Hi Melissa, I put lightning.clim.tgz in my ~/share directory on Odyssey. If you untar that from within the OFFLINE_LIGHTNING root directory, it will place the climatologies alongside the time-varying data, including important README disclaimers about the use of lightning climatology versus time-varying fields on the photochemistry. Let me know if you have difficulty accessing! |
…r CH4 inversions (1) Update Get_Boundary_Conditions to apply background concentrations when BCs aren't found for a species To allow for nested grid simulations to proceed if a species isn't found in the boundary conditions file, we now apply the background species concentrations when the species cannot be found. The min, max, or background value applied for each species as boundary conditions will be printed to the log file. It is recommended that users check the log file to verify that the proper BCs are being read and applied. See also geoschem#268. (2) Add EFY time cycle flag to HEMCO The EFY time cycle flag has been added to hco_config_mod.F90. This option will be used for meteorology fields to ensure the exact date is used (E), the data is found (F), and the simulation year is used (Y). (3) Do not read FLASH_DENS and CONV_DEPTH fields in FlexGrid when lightning NOx extensionin HEMCO is off A shadow variable Input_Opt%DoLightNOx has been added and will be set to true or false depending on if the lightning NOx extension is turned on in HEMCO_Config.rc. When that option is off, the reading of FLASH_DENS and CONV_DEPTH in flexgrid_read_mod.F90 will be skipped (keeping those fields as all zeroes). This will avoid the requirement of having users download those data for simulations that do not require it. For more details, see geoschem#279. Signed-off-by: Melissa Sulprizio <mpayer@seas.harvard.edu>
Not all simulations require the lightning NOx extension, and therefore don't need to read in the fields
FLASH_DENS
andCONV_DEPTH
. Those fields are essentially treated as met fields -- they're read intoState_Met
inGeosCore/flexgrid_read_mod.F90
. As of now there is no easy way to turn off reading those fields if the lightning NOx extension is turned off. Instead users need to go into the source code as described on issue #277.The text was updated successfully, but these errors were encountered: