Feature/SatDiagnUpdates (netCDF Satellite Diagnostics) #1134
Conversation
|
Thanks for this @jdshutter. We will review this shortly and prioritize it for 14.0.0. We'll post any comments on this PR. |
|
This issue has been automatically marked as stale because it has not had recent activity. If there are no updates within 7 days it will be closed. You can add the "never stale" tag to prevent the Stale bot from closing this issue. |
yantosca
added
category: Feature Request
…geos-chem into dev+alpha.4 This merge brings the Satellite netCDF diagnostics of Joshua Shutter (cf geoschem/geos-chem PR #1134) into the 14.0.0 development branch of GEOS-Chem. Signed-off-by: Bob Yantosca <yantosca@seas.harvard.edu>
|
Hi @jdshutter @eamarais: I have pulled in these changes to a branch off of the 14.0.0 development stream but I have not been able to get the code to run successfully without throwing a seg fault. With IGC10 right around the corner, I might not be able to get this into our 14.0.0 release candidate that we plan to issue before IGC10 starts. With a little more time I can probably sort this out but it means that this might have to go into 14.1.0. Just letting you know. |
|
This PR has been superseded by PR #1478. We can close this now. |
Related GitHub Issue:
[FEATURE REQUEST] Output satellite diagnostic as NetCDF #770
Motivation and Context:
This pull request builds upon the work of @eamarais when she created a new netCDF satellite diagnostics patch for GCv13.0.2 that would eliminate the need to use the BPCH format for satellite diagnostics. For information on that patch and discussion, check out: [FEATURE REQUEST] Output satellite diagnostic as NetCDF #770
I have added more functionality to the SatDiagn Collection created by Eloise for GC13.3.3 to output additional diagnostics that were not done with the previous BPCH version. Specifically, additional outputs now include wet deposition, J-values, dry deposition, surface emission and surface flux of a given advected species, production and loss rates, OH reactivity, and individual reaction rates that can all be averaged between two time intervals (local time; LT) as specified by SatDiagn.hrrange.
Update Type:
New feature (GC 14.0.0 Milestone)
Update Impacts:
GEOS-Chem source code
Compiler Used in Testing:
Intel Fortran Compiler (aka ifort), version 2017/Update 4
Update Submitted By:
This update is a combination of code written by @eamarais and @jdshutter
Professor Eloise Marais: University College London (UCL) (e.marais@ucl.ac.uk)
Dr. Joshua Shutter: University of Minnesota (UMN) (shutt038@umn.edu)
Useful Notes for GCST:
(1) As I was reading the code, I noticed there was a missing factor of 1000 for OH in both the BPCH and SatDiagn satellite diagnostics. This pull request corrects both those diagnostics.
(2) When comparing between BPCH and the new SatDiagn Collection, they differed if the averaging period specified in the ND51 menu (located in input.geos) or the SatDiagn.hrrange (located in HISTORY.rc) were specified as INTEGERS. I noticed that the evaluation of the logic statement in diagnostics_mod.F90 (see code below) would sometimes return false when it should have been true (or vice-versa) if INTEGERS were used.
As a workaround, I simply specified an averaging range of 11.98 and 15.02 (corresponding closely to the desired 12 and 15 LT), which then caused the BPCH and netCDF satellite diagnostics to agree. I suppose an epsilon could also be added to the logic statement so that this isn’t a problem, but maybe there’s a better way when dealing with floating point numbers in evaluating logic statements.
The attached plot shows output of a few selected diagnostics from the new SatDiagn Collection that was generated using the code changes in this pull request. As Eloise showed before in Feature Request #770, the changes I made did not cause the BPCH and netCDF diagnostics to differ.
(3) Given how some of the satellite diagnostics are defined, some of the new satellite diagnostics that I’ve added need to have their corresponding collections activated (or else some diagnostics will be inadvertently undefined). Said another way, in order to output SatDiagnJval, you would also need to have output activated for the normal JValues Collection in HISTORY.rc. This holds true for the following satellite diagnostics: SatDiagnWetLossLS, SatDiagnWetLossConv, SatDiagnJval, SatDiagnDryDep, SatDiagnDryDepVel, SatDiagnOHReactivity (located in the ProdLoss Collection). For SatDiagnColEmis or SatDiagnSurfFlux, activate AdvFluxVert Collection since the advected species map will then be generated.
I realize this is non-ideal, but the workaround would have required even more modifications to the code that would just be specific to satellite diagnostics.
(4) Given the updates by @eamarais and myself, others can add additional satellite diagnostics that they might find useful for their research. As a starting place, folks will definitely need to modify GeosCore/diagnostics_mod.F90 and Headers/state_diag_mod.F90 if adding a new diagnostic. Folks may also need to modify other files as well depending on what is being defined.
(5) Currently, the HISTORY.rc file does not automatically include the SatDiagn Collection when creating a new run.
(6) I don’t know why this is an issue, but the SatDiagn Collection must be placed at the bottom of the HISTORY.rc file (which makes it the first file to have diagnostics generated when I’ve looked at the run logs). When it wasn’t placed at the bottom of HISTORY.rc, the satellite diagnostic would output NaNs and INFs.
Below are the SatDiagn fields that I’ve successfully used thus far and placed at the bottom of the HISTORY.rc file. Just like with the normal diagnostic collections, the SatDiagn diagnostics also allow for individual species to be named within a given diagnostic (i.e., SatDiagnJval_CH2O or SatDiagnJval_NO2).
I hope this makes some sense, but please don't hesitate to contact @jdshutter with questions about this pull request