Megan CTSM #96
Megan CTSM #96
Conversation
FATES API update to facilitate fates refactor This updates a number of FATES type names and module use statements which correspond with a refactoring effort that moves FATES patches and cohorts into their own respective modules. With the FATES update is a minor science update, so there are changes to answers for FATES. This also incorporates a minor update to a more recent version of the ccs config external.
Bring b4b-dev branch to main CTSM development. - PLUMBER2 for ctsm5.2 datasets - Last bit of PPE changes for namelist and parameter file settings - Update run_sys_tests on Derecho for compiler jobs to run using 16 tasks - Bring in a fix for dust emissions for coupling with CAM Update cs.status parsing script to make expected BASELINE fails more obvious Fix some issues with finding IC files for certain lnd_tuning_modes: all for cam7, clm5_0_cam6.0, and clm6_0_cam6.0
Merge master 20240828
hs-uii: Merge in latest b4b-dev
Add a namelist warning when hillslope hydrology is used with initial interpolation.
Fix comments on urban thermal variables (no testing done)
Also makes it accessible from table of contents. Not actually changing file contents at this point.
* The experience of making a mesh from an input with 1d vs. 2d coordinates is identical, so only provide one example. * In example, use as input file the 5x5_amazon surface dataset included with CTSM. * Various wording and typo fixes.
Avoids requiring new fsurdat.
|
Thanks @rosiealice. It also looks like the latest version of CIME does not permit you to do any tests with month bounds (i.e. _LmXX in the test name). We are using close to latest version of CIME in noresm2_5_alpha07 - whereas CTSM is using a version that is 6 months old. So I will change our tests for aux_clm_noresm to make sure we have no month specification in the test names. |
|
So, the model is trying to find the 'fates_turnover_leaf_canopy' variable in the parameter file. This is a quite recently introduced parameter, and so I would not be surprised if the cause was that we were using the wrong default fates_paramfile.
** In addition** to this parameter, the MEGAN code also introduces new parameters.
The solution to both of these is broadly to run with the parameter file that goes with this code which is here: How to integrate the parameter file in the tests is not clear to me. How does that normally work when you test a branch that needs a new parameter file? I guess this is something to do with the rest of the errors: |
|
I guess I was going to add, is it worth 'testing' the default version of the code first to troubleshoot these types of things? |
|
I agree. I can try to fire off a test with the default version. Are you referring to the latest version on master? |
|
The version I used is the one linked from the alpha07 tag. So probably best to use that? It was this CTSM and this FATES |
|
@rosiealice - the problem seems to be that in lnd_in we are trying to read in Since |
|
Sounds about right @mvertens. Hopefully changing the setting will work. I wonder how we normally test things that need new parameter defaults? |
If I understand the question, when we have non-default parameter file values that need to be routinely tested, we use the on-the-fly netcdf generation scheme that you mentioned above. There is a PR that is 'stuck' to try and make this a little more robust, but we need to get back to it now that some upstream issues have been addressed: ESCOMP#2336. I should note that alternate ways of generating and storing the files for testing has also been discussed over on the elm side of things: E3SM-Project/E3SM#6639 (comment) |
…an_cherrypick_ctsm_mvertens
Fix handling of finidat with cold starts
|
@glemieux - thanks for the clarification. That is super helpful. Just to clarify - this is a parameter file that will need to accompany this PR - and not one that just needs to be routinely tested. So my understanding would be that we actually need to do the following:
|
|
@rosiealice - what I have done is
|
|
@mvdebolskiy - I cannot create a case with a stand-alone checkout of ctsm-noresm. I get the following error: |
Gotcha, thanks for the clarification. What you've laid out is equivalent to what we do as well. |
|
@rosiealice - it turns out that we need this PR for noresm2_5_alpha08. What I found out today is the following:
|
…rtens updates for testing of megan/fates
|
@rosiealice - it turns out that it will be much easier for me to close this PR and issue a new one with my changes on top of yours as well (which had some more relative to what you merged last week). I'll copy the PR summary exactly as you have it here. First I need to do some additional testing then I'll issue the PR again and have both you and @mvdebolskiy review it. |
|
OK thanks @mvertens Let me know if I can help out at all... |
|
Closing in favor of #99 |
|
closing in favor of #99 |
Description of changes
Megan changes without the fire emissions commits.
Specific notes
Same notes as the previous now closed PR
#74
Contributors other than yourself, if any:
CTSM Issues Fixed (include github issue #):
#36
Are answers expected to change (and if so in what way)?
Yes, all the MEG_* fields will change, but nothing else.
Any User Interface Changes (namelist or namelist defaults changes)?
No
Does this create a need to change or add documentation? Did you do so?
Yes, but haven;'t changed yet pending further coupled model testing.
Testing performed, if any:
(List what testing you did to show your changes worked as expected)
(This can be manual testing or running of the different test suites)
(Documentation on system testing is here: https://github.com/ESCOMP/ctsm/wiki/System-Testing-Guide)
(aux_clm on derecho for intel/gnu and izumi for intel/gnu/nag/nvhpc is the standard for tags on master)
NOTE: Be sure to check your coding style against the standard
(https://github.com/ESCOMP/ctsm/wiki/CTSM-coding-guidelines) and review
the list of common problems to watch out for
(https://github.com/ESCOMP/CTSM/wiki/List-of-common-problems).