initial version of KPP Standalone in GEOS-Chem #19
Conversation
obin1
added
the
0 diff
There was a problem hiding this comment.
I am fine with the code, but I don't think this belongs within KPP/fullchem. This probably needs to be in a folder called something like KPP/kpp_standalone, since it is not part of the core model and you may want to generalize it to handle other GEOS-Chem mechanisms in the future. @lizziel, what do you think?
|
@viral211, good point. It would make sense for this to be generalized to any mechanism GC is running. Where would it go? Maybe GC wants an analysis/ folder or something. e.g. KPP/analysis wherein kpp_standaone and any other tools might live. Just for argument's sake, though, I'm generally wary of unnecessary complexity, and at this point kpp_standalone is meant for fullchem. |
|
I'm happy to restructure to a folder e.g. KPP/kpp_standalone. The use case that @christophkeller @msl3v and I were envisioning is that the KPP Standalone compiles at the same time as GEOS-Chem, with whichever mechanism is chosen. I'm not exactly sure how to do that and am hoping to check in with @lizziel and the GCST about the best way to structure this. This would be in addition to the current option that is enabled, which is drop in a mechanism, preprocess with KPP, and then compile with |
|
Sorry I missed seeing this until now. Tagging @yantosca on this since he will be using the box model and likely has some opinions on where it should go. I would prefer this PR to be on the upstream GEOS-Chem, do the full review and discussion there, bring it into the standard model, and then merge that into geos/develop. Does anyone object to bringing it into GEOS-Chem in this way? Since it will not impact GEOS-Chem benchmarks we can bring it into a Z version which means not waiting a long time for a new release. |
|
Hi Lizzie, would you mind making this a PR to the upstream branch similarly to how you made the PR for the 3D-to-standalone interface geoschem#2482? I don't have a code base for GEOS-Chem, so I probably shouldn't do it from my end. |
|
Yes, I just made the PR. See geoschem#2483. As with the other PR, @yantosca will be reviewing and testing. |
|
@obin1, whatever updates you make to the branch in this PR I can bring into the PR going into the standard model. |
This merge brings PR geoschem#2353 (Cloud-J error handling, by @lizziel) into the GEOS-Chem "no-diff-to-benchmark" development stream. This PR implements robust error handling for Cloud-J (i.e. error code passed all the way to the main program, for graceful shutdown). NOTE: Relies on Cloud-J PR #19, Signed-off-by: Bob Yantosca <yantosca@seas.harvard.edu>
We now run a 2x2.5 ModelE2.1 (aka GCAP 2.0) full-chemistry simulation in the GCClassic integration tests. Only one scenario (SSP2-4.5) is evaluated here simply to ensure these future scenario simulations compile and run for 1 hour successfully. I will defer to @ltmurray for guidance on whether additional simulations are needed. The GCAP 2.0 integration test is passing off of 14.4.1, confirming that the fixes in geoschem#2342 should have resolved the issues of GCAP 2.0 not working in 14.0.0 (as reported by Lee Murray at IGC11). Sample integration test output: ``` ============================================================================== GEOS-Chem Classic: Execution Test Results GCClassic #c49fcec Submod updates: Merge GEOS-Chem PR geoschem#2353 and Cloud-J PR #19 GEOS-Chem #7e4001658 Merge PR geoschem#2369 (Fix several issues with satellite diagnostics) HEMCO #2192e0e HEMCO 3.9.1 release Using 24 OpenMP threads Number of execution tests: 29 Submitted as SLURM job: 40462513 ============================================================================== Execution tests: ------------------------------------------------------------------------------ gc_05x0625_NA_47L_merra2_CH4........................Execute Simulation....PASS gc_05x0625_NA_47L_merra2_fullchem...................Execute Simulation....PASS gc_2x25_ModelE2.1_fullchem..........................Execute Simulation....PASS ``` Signed-off-by: Melissa Sulprizio <mpayer@seas.harvard.edu>
Name and Institution (Required)
Name: Obin Sturm
Institution: University of Southern California
Confirm you have reviewed the following documentation
Describe the update
The KPP Standalone replicates the chemistry operator when given the full chemical state of a grid cell. Documentation on how to set it up for any mechanism is in its home directory: https://github.com/KineticPreProcessor/KPP-Standalone/tree/kpp-standalone
It is used with the KPP Standalone Interface, a 3D-to-standalone interface used to obtain the full chemical state of specific grid cells during GEOS-Chem runs.
Currently, this code compiles with
makebut @christophkeller and I were discussing how it might be nice to have the option to compile the KPP Standalone when building GEOS-Chem.Expected changes
This will be zero diff to the GEOS-Chem model. This feature contributes a few files to the KPP/fullchem directory, and the standalone automatically updates with the KPP mechanism.
Reference(s)
More documentation on this is in a manuscript in prep, with application to twilight chemistry in GEOS-CF.
The KPP Standalone builds off a more specific autoreduce box model detailed in Lin et al. (2023):
Lin, H., Long, M. S., Sander, R., Sandu, A., Yantosca, R. M., Estrada, L. A., et al. (2023). An adaptive auto-reduction solver for speeding up integration of chemical kinetics in atmospheric chemistry models: Implementation and evaluation in the Kinetic Pre-Processor (KPP) version 3.0.0. Journal of Advances in Modeling Earth Systems, 15, e2022MS003293. https://doi.org/10.1029/2022MS003293
Related Github Issue(s)
Not an issue, but this is related to the KPP Standalone Interface, which sparsely samples grid cells during GEOS-Chem runs: the output from these 3D runs is fed as input to the KPP Standalone. The 3D to standalone interface pull request is here: #9