Newest raw datasets for pft, lai, soilcolor#1946
Merged
slevis-lmwg merged 461 commits intoMay 17, 2023
Merged
Conversation
compatabiilty with FATES v2 nutrient API
This set of changes allows CTSM to continue API compatability with changes to the FATES API. FATES has updated its nutrient dynamics routine, and required a modification to the test environment, some minor updates to variable dimensions in the history, and a call to a new FATES history routine. Implicitly, the updating of the FATES tag introduces new content in the FATES model since the last API update (mostly bug fixes).
…fsurdat_in/fsurdat_out files it fails
…fig file so that it will work
This set of changes allows CTSM to continue API compatability with changes to the FATES API. FATES has updated its nutrient dynamics routine, and required a modification to the test environment, some minor updates to variable dimensions in the history, and a call to a new FATES history routine. Implicitly, the updating of the FATES tag introduces new content in the FATES model since the last API update (mostly bug fixes). Resolved conflicts: cime_config/SystemTests/fsurdatmodifyctsm.py test/tools/test_driver.sh
FSURDATMODIFYCTSM_D_Mmpi-serial_Ld1.5x5_amazon.I2000Clm50SpRs.cheyenne_intel
run_sys_tests (which starts ctsm's test-suites) builds cases on cheyenne's compute nodes. Running py_env_create on cheyenne's compute nodes fails, so we will leave it up to users to run py_env_create when necessary, manually.
New msg explains that user's ctsm_pylib environmt may be out-of_date and what to do. As written, the code lumps getting the conda environmt and running the tool in one subprocess. I will separate these to enable more informative error messages.
I haven't found a way to separate the single subprocess that currently (1) loads conda and activates the ctsm_pylib environment and (2) runs the fsurdat_modifier tool into two or more subprocesses without losing access to the ctsm_pylib environment. So instead I have written a more elaborate error message with the various possible scenarios leading to an error in the subprocess. I have tested it by commenting out the "conda activate" line and confirming that I see my error message in TestStatus.log.
… can be tested, fix some lint and black issues
…nd the other to set an existing output file
…sts working, fix pylint issues, run in black
…-line and config file, stest fails
change soil moisture initialization logic for FATES configurations
Occasionally, h2osoi_ice was going significantly negative in UpdateState_TopLayerFluxes - see ESCOMP#1979. As noted in that issue, this seems to be due to h2osoi_ice having a very different magnitude from h2osoi_liq, leading to greater-than-roundoff-level differences from zero final state in a relative sense (i.e., relative to the magnitude of h2osoi_ice) - I think because of the appearance of the sum (h2osoi_ice + h2osoi_liq) in the equations that limit fluxes. To try to deal with this, I have reworked the handling of the evaporation constraint to directly limit both the liqevap and solidevap, so that both of them should result in the equivalent liq or ice states going to 0 within roundoff. To do that, I needed to move the partitioning of the total flux into liquid and solid to earlier in the subroutine and then recalculate those partitioning fluxes in conditions where we're applying an evaporation constraint. Note that the deleted lines in this commit have just been moved as-is to earlier in this subroutine.
These could sometimes be roundoff-level negative due to h2osoi_liq starting out roundoff-level negative.
A few specific notes: - Needed to increase tolerances a bit in the matrix test to make tests pass on my Mac (with gfortran). - Needed to remove some assertions in an expected-failure test for quadratic (it seems like the new pFUnit hits these assertions whereas the old did not).
Use versions of externals from latest CESM tag
Rework handling of evaporation constraint in SoilFluxes Occasionally, h2osoi_ice was going significantly negative in UpdateState_TopLayerFluxes - see ESCOMP#1979. As noted in that issue, this seems to be due to h2osoi_ice having a very different magnitude from h2osoi_liq, leading to greater-than-roundoff-level differences from zero final state in a relative sense (i.e., relative to the magnitude of h2osoi_ice) - I think because of the appearance of the sum (h2osoi_ice + h2osoi_liq) in the equations that limit fluxes. To try to deal with this, I have reworked the handling of the evaporation constraint to directly limit both the liqevap and solidevap, so that both of them should result in the equivalent liq or ice states going to 0 within roundoff. To do that, I needed to move the partitioning of the total flux into liquid and solid to earlier in the subroutine and then recalculate those partitioning fluxes in conditions where we're applying an evaporation constraint. Note that I applied a max of 0 to the new fluxes because many initial conditions files have roundoff-level negative H2OSOI_LIQ, so without this limit, we were getting roundoff-level negative fluxes. Resolves ESCOMP#1979
This just updates the nag compiler setup to remove the recently-added NaN flag, which is causing test failures.
Updates needed for pFUnit 4 and other externals updates
(1) Lots of small changes needed for the update to pFUnit4. Note that
this is a backwards-incompatible update, so we will require pFUnit 4
moving forward.
(2) Externals updates: some of these are needed for the update to pFUnit
4; others are included to update externals to those in a recent CESM
alpha tag.
Updates needed for pFUnit 4 and other externals updates
(1) Lots of small changes needed for the update to pFUnit4. Note that
this is a backwards-incompatible update, so we will require pFUnit 4
moving forward.
(2) Externals updates: some of these are needed for the update to pFUnit
4; others are included to update externals to those in a recent CESM
alpha tag.
Resolved conflicts:
Externals.cfg
test/tools/input_tests_master
test/tools/tests_posttag_hobart_nompi
test/tools/tests_posttag_izumi_nompi
test/tools/tests_posttag_nompi_regression
test/tools/tests_pretag_cheyenne_nompi
ADDED, then MOVED these to mksurfdata_map...
tools/mksurfdata_esmf/default_data_1850.cfg
tools/mksurfdata_esmf/modify_1x1_mexicocityMEX.cfg
tools/mksurfdata_esmf/modify_1x1_urbanc_alpha.cfg
tools/mksurfdata_esmf/modify_1x1_vancouverCAN.cfg
ADDED these back to be removed later...
tools/mksurfdata_map/Makefile.data
tools/mksurfdata_map/src/test/mkdomain_test/test_mkdomain.pf
tools/mksurfdata_map/src/test/mkgridmap_test/test_mkgridmap.pf
tools/mksurfdata_map/src/test/mkindexmap_test/test_mkindexmap.pf
tools/mksurfdata_map/src/test/mkpctPftType_test/test_mkpctPftType.pf
tools/mksurfdata_map/src/test/mkpftUtils_test/test_adjust_total_veg_area.pf
tools/mksurfdata_map/src/test/mkpftUtils_test/test_convert_from_p2g.pf
tools/mksurfdata_map/src/test/mkpftmod_test/test_pftInit.pf
tools/mksurfdata_map/src/test/mkpftmod_test/test_pft_oride.pf
tools/mksurfdata_map/src/test/mkpftmod_test/test_pftrun.pf
tools/mksurfdata_map/src/test/mksoilUtils_test/test_dominant_soil_color.pf
tools/mksurfdata_map/src/unit_test_stubs/abort.F90
… new_rawpftlai This branch (see PR ESCOMP#1873) has necessary changes for ctsm5.2
Same handling of lakes & urban as pfts. Also added a comment to gen_mksurfdata_namelist.py to address later.
Contributor
Author
|
To generate a 2000 fsurdat file for @Ivanderkelen on the 360x720cru grid, I had to update two things:
|
Contributor
Author
|
I completed this test to confirm that the Gross Unrepresented Land Use (GULU) code addition works: @lawrencepj1 (in a meeting yesterday) suggested what to look for in the new variables prefixed with GRU. As far as I can tell the simulation worked correctly, so I will go ahead with next steps:
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
11 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description of changes
Mainly I'm updating file paths/names in
gen_mksurfdata_namelist.xml.While testing, I'm also updating codes and README with necessary corrections or updates.
Specific notes
Contributors other than yourself, if any:
@ekluzek @lawrencepj1
CTSM Issues Fixed (include github issue #):
Fixes #1873
Are answers expected to change (and if so in what way)?
Yes: new raw datasets; eventually all new fsurdat files.
Any User Interface Changes (namelist or namelist defaults changes)?
New raw datasets. Eventually all new fsurdat files.
Testing performed, if any:
This far I have used mksurfdata_esmf to generate 2-degree fsurdat (and landuse when applicable) files for
@samsrabin is using (2) with ctsm5.1 code. He had to address the following ctsm5.1 vs. ctsm5.2 inconsistencies: