Complete the FATES-CLM nitrogen coupling#3409
Complete the FATES-CLM nitrogen coupling#3409slevis-lmwg wants to merge 46 commits intoESCOMP:masterfrom
Conversation
PASS ERS_D_Ld30.1x1_brazil.I2000Clm60FatesCrujraRs.derecho_intel.clm-FatesColdPRT2 FAIL ERS_D_Ld30.1x1_brazil.I2000Clm60FatesCrujraRs.derecho_intel.clm-FatesColdPRT2--clm-mimicsFatesCold--clm-nofireemis The latter needs "nofireemis" to work with Fates, but it then dumps core in line 1180 SoilBiogeochemDecompCascadeMIMICSMod.F90
...calculating these variables: nf_soil%decomp_npools_sourcesink_col nf_soil%fates_litter_flux
|
With the latest commit, I repeated the two earlier tests and added another to check whether answers have changed from the baseline: The latter fails in case2, after reading the restart file, with a N balance error. UPDATE
|
|
Enabled fixation and ran the same tests: PRT2 still b4b with the baseline. PASS The same tests with the code change for harvest (same results relative to the baseline). |
|
Worked on the next checkbox in the issue (#3378), submitted the same tests, and after some troubleshooting: |
These variables originate in fates, so this renaming requires the same renaming in fates; I will open the corresponding PR very soon
Notes:
|
|
Updated the fates paramfile (see next commit) and submitted these two again The first (LUH2) same as before (DIFF from baseline) since nothing changed for it.
|
|
Thanks @slevis-lmwg & @rgknox , that's good to know. We will circle back to this once Shelby is spun up on life in general after Easter (she only just arrived about a week ago...) |
|
I'm investigating the ERS restart test failure and tried two tests. In the first test, I forced litter flux from FATES to CLM to be zero. This did not have any impact on restarts, suggesting that the bug is either not related to restarting litter fluxes, or simply is not relegated to restarting litter fluxes. I also forced the fine-root profile that fates sends to the nitrogen allocation scheme to zero, and this did generate b4b restarts. My next test will be to go into the allocation code, and set the fates-side boundary conditions to constants, and see if that works. That will tell us if the problem is restarting clm-side allocation/decomposition variables, of if its fates-side restarting of boundary conditions.. cc @slevis-lmwg |
restarting uptake fluxes
|
After the latest updates, I started by submitting
FAIL PRT2_synthN RUN FAIL LUH2 RUN turns out to expected as per #3789 PASS PRT2, just no baseline to compare
|
|
@rgknox two tests failed (PRT2_synthN and LUH2) and three passed. See error msgs in the previous post. Looking into the first of these. I think we set My first inclination is to move FAIL PRT2_synthN RUN so my first intuition was wrong, and I will restore FatesRestartInterfaceMod.F90 and try changing the allocate statement in FatesInterfaceMod.F90. PASS PRT2_synthN RUN Fixed! |
|
Starting aux_clm on derecho + izumi: RUN failures to investigate (none on izumi) in /glade/derecho/scratch/slevis/tests_0408-165737de
Also, should we expect the DIFFs from baseline in the following tests (some also on izumi, but I did not list them) due to the diff between |
Simplify messaging during docs build slevis resolved conflicts: bld/namelist_files/namelist_defaults_ctsm.xml
|
Testing on derecho after the latest updates:
Before I try
|
|
Now repeat
Known issue #3840 |
|
@rgknox testing seems satisfactory to me, so this PR and its fates counterpart are ready for your final review, unless you think of anything else that we need to work on here. |
Description of changes
For now see the issue #3378
Corresponding mods on the FATES side:
NGEET/fates#1472
Nutrient enabled FATES handbook
FATES CLM N coupling
Specific notes
Contributors other than yourself, if any:
@rgknox @adrifoster @wwieder
CTSM Issues Fixed (include github issue #):
#3378
Are answers expected to change (and if so in what way)?
For non-fates tests expect roundoff diffs due to a change in the order of operations in CNNDynamicsMod.F90 as documented below.
Any User Interface Changes (namelist or namelist defaults changes)?
Yes, see changes to CLMBuildNamelist and namelistdefaults.
Does this create a need to change or add documentation? Did you do so?
Yes, no.
Initial testing performed
...with the first two commits in this PR:
Later comments point out that these two tests were inadequate at catching problems, and that I switched to two other tests.