Merge ctsm1.0.dev105 tag into fates_main_api #1137
Conversation
I think it's really ESCOMP#203 that's causing this failure, not ESCOMP#158.
I'm hopeful that this will address ESCOMP#203
Update cime and cmeps externals; rework initialization of CNFire object Main change is to update cime and cmeps externals. cime is now essentially at the version used in cesm2_2_beta05 (but with one change backed out); cmeps is at latest master. Also, reworks initialization of CNFire object to avoid occasional segmentation faults.
Generated from this branch by running: make -f Makefile.data crop-smallville after first building mksurfdata_map using an environment loaded from a recent cheyenne_intel case.
It was identical to coldStart
This was the intent when I first created the test: The point of this test is to test crop restart shortly after cold start. It later accidentally turned into a test that used spun-up initial conditions (when we changed just about everything to use spun-up initial conditions); this commit restores it to being cold start.
I particularly want isotopes to be on for this test
Although gindex_ocn could be intent(out), intel18.0.3 generates a runtime segmentation fault in runs that don't have this argument present when this is declared intent(out). (It works fine on intel 19.0.2 when declared as intent(out).) Resolves ESCOMP#930
BFB according to the following tests: ERS_Ly5_P144x1.f10_f10_musgs.IHistClm50BgcCrop.cheyenne_intel.clm-cropMonthOutput ERP_D_Ld5.f10_f10_musgs.IHistClm50BgcCrop.cheyenne_intel.clm-allActive ERS_D_Ld6.f10_f10_musgs.I1850Clm45BgcCrop.cheyenne_intel.clm-clm50CMIP6frc clm_short test suite Parameters moved: prh30 (was hardcoded as 0.7 in CNFireLi2016Mod) ignition_efficiency (was hardcoded as 0.22 in CNFireLi2016Mod) tpu25ratio (was hardcoded as 0.167 in PhotosynthesisMod) kp25ratio (was hardcoded as 20000 in PhotosynthesisMod) bsw_adjustfactor (set to 1.0, did not previously exist in SoilStateInitTimeConstMod) hksat_adjustfactor (set to 1.0, did not previously exist in SoilStateInitTimeConstMod) sucsat_adjustfactor (set to 1.0, did not previously exist in SoilStateInitTimeConstMod) watsat_adjustfactor (set to 1.0, did not previously exist in SoilStateInitTimeConstMod)
Gridcell-level balance checks for carbon and nitrogen Bracket the model's time-step loop to calculate balance checks at the gridcell level because there are terms in the carbon and nitrogen cycles not accounted for at the column level. Balance checks at the column level remain unchanged for now. Resolves ESCOMP#314
Resolved Conflicts: src/biogeochem/CNProductsMod.F90
Resolves ESCOMP#1021 (at least, I think it will: I'm about to test it)
Add two bioenergy crops (switchgrass and miscanthus) Main change is from Yanyan Cheng: adding parameters and code for two bioenergy crops, switchgrass and miscanthus. Along with this, there is a new potential flux from crop leaves and stems to the crop product pool at harvest, representing biofuel products; a new pft-specific parameter controls this flux (biofuel_harvfrac). Currently, the out-of-the-box surface datasets do not specify any area for these crops, but the new parameter file will allow them to be present if specified on the surface dataset or landuse_timeseries file. Note that this is only an option for CLM5.0, NOT for CLM4.5. (See ESCOMP#884 for details.) Also, some minor fixes from Bill Sacks: - Resolves ESCOMP#203 - Fixes creation of harvest-related variables on surface datasets created with the all_veg option - smallville, PTCLM, etc. (documented in ESCOMP#1019) - Resolves ESCOMP#930 - Makes gindex_ocn intent(inout) rather than intent(out) - Resolves ESCOMP#1021 - Changes SSP test to only do symlink if needed
Gridcell-level balance checks for carbon and nitrogen Bracket the model's time-step loop to calculate balance checks at the gridcell level because there are terms in the carbon and nitrogen cycles not accounted for at the column level. Balance checks at the column level remain unchanged for now.
At this point, it parses arguments and fills out the machine template files, then stops.
…l for C24 and C96, also just use a generic decStart test and remove the special C96 test for running a Sp case fo rC96
This will be helpful for the lilac build script. I have not yet tested this thoroughly!
Add two bioenergy crops (switchgrass and miscanthus) Main change is from Yanyan Cheng: adding parameters and code for two bioenergy crops, switchgrass and miscanthus. Along with this, there is a new potential flux from crop leaves and stems to the crop product pool at harvest, representing biofuel products; a new pft-specific parameter controls this flux (biofuel_harvfrac). Currently, the out-of-the-box surface datasets do not specify any area for these crops, but the new parameter file will allow them to be present if specified on the surface dataset or landuse_timeseries file. Note that this is only an option for CLM5.0, NOT for CLM4.5. (See ESCOMP#884 for details.) Also, some minor fixes from Bill Sacks: - Resolves ESCOMP#203 - Fixes creation of harvest-related variables on surface datasets created with the all_veg option - smallville, PTCLM, etc. (documented in ESCOMP#1019) - Resolves ESCOMP#930 - Makes gindex_ocn intent(inout) rather than intent(out) - Resolves ESCOMP#1021 - Changes SSP test to only do symlink if needed
This isn't yet fully working, but it's close
Resolved Conflicts: src/main/clm_initializeMod.F90
This was giving an error because ESMFMKFILE is no longer defined in the environment on bishorn. Rather than fixing it, I'm stopping writing this for now. My plan is to rework how this is written, writing it from the top-level build_ctsm script instead of from within buildlib.
|
For the
For the |
|
Looking in the |
|
The arcticGris test hit the walltime limit. I tell this by looking at the TestStatus file, which shows I wouldn't worry about that test for the sake of testing your integration. For the LILAC test, I think you uncovered a real issue that I will fix ASAP. (Thank you!) Again, you don't need to worry about that for the sake of the FATES testing. |
|
Thanks @billsacks. I see that the |
ekluzek
left a comment
ekluzek
left a comment
There was a problem hiding this comment.
It's hard to go through these long list of changes. But, it does look like the update to ctsm1.0.dev105. A lot of the changes that come in aren't ones that FATES would care about (new SE, and FV3 grids, and LILAC). But, there are also some important bug fixes that come in ctsm1.0.dev102. The CNFire change was good to bring in as it required some work on the FATES interface side. It was good to get that into FATES.
|
@billsacks I manually added in the diff that you pointed to and the MODEL_BUILD get started, but it's failing elsewhere in the build now. Here's a partial copy from the atm_driver.bldlog: I currently have The test case was run via UPDATE: loading to |
|
@glemieux sorry for the continued issues. I'm glad you were able to work around this issue. I think I have also fixed it robustly in #1149 . I'll be interested to know if that fix works for you, too... though I suspect it will, since I was able to reproduce your issue by changing my environment to look like yours, and then #1149 got things working for me with your environment. |
In LILACSMOKE test: Call case.load_env() before building the atm driver. This is needed for the atm driver build to use the correct module environment. Things were working for me, and apparently for @ekluzek and @negin513 , without this change. But this is probably because our default module environment was similar to cime's cheyenne_intel environment. @glemieux was running into trouble because he has intel17 loaded in his default environment (whereas the environment loaded by cime uses intel19). This should fix that issue. Are answers expected to change (and if so in what way)? Answers *may* change for the LILACSMOKE test, if baselines were generated with a slightly different compiler version than the one loaded by cime. However, I do not expect answer changes. Testing performed, if any: - I first reproduced the error reported in #1137 (comment) by changing my environment to match @glemieux 's. Specifically, I replaced my `.profile` with his, and replaced the contents of my `.lmod.d` directory with his. So this used intel17. This led to the same issue with the LILACSMOKE test that he reported. - I then reran the LILACSMOKE test using @glemieux 's environment but with the fix in this PR; now it passed. - I also ran the LILACSMOKE test using my environment (which uses intel 19.0.5) with this fix; it also passed.
|
@billsacks the addition in #1149 did the trick. I was able to get the LILAC test to pass b4b using my default environment. Thanks again! |
Fixes missing clm2 output data for baseline generation
|
Quick note that the Most diffs against baseline are for |
|
@rgknox the f10 test comparing the fates_main_api baseline and used acre to compare as suggested. The Note I got the Weirdly when I ran the test on it's own, it passes the run but fails the exact restart (which is the expected failure): That said, I think we probably can go ahead and integrate this. I'll try and address the |
8 participants
Description of changes
This PR brings the fates_main_api branch up to date with ctsm1.0.dev105 tag to incorporate fixes to address #1125.
Specific notes
Contributors other than yourself, if any:
CTSM Issues Fixed (include github issue #): #1125
Are answers expected to change (and if so in what way)? Only fates outputs expected to change relative to ctsm1.0dev.105 tag
Any User Interface Changes (namelist or namelist defaults changes)? No
Testing performed, if any:
aux_clmsuite outputs:/glade/u/home/glemieux/scratch/ctsm-tests/tests_ctsmdev105-aux_clmfatessuite outputs:/glade/u/home/glemieux/scratch/ctsm-tests/tests_ctsmdev105-mergeNOTE: 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).