ctsm5.4.051: Update Clm60 compsets to use dglc and Clm50/Clm60 Fates tests to be RsGs only for single-point/regional and Crujra forcing rather than Cru - #4110
Conversation
…lacier, if Gs isn't given then DGLC is used
…/regional cases, and without that for global tests, and change Clm60FatesCru tests to Clm60FatesCrujra
ekluzek
added
the
enhancement
ekluzek
added
priority: high
github-project-automation
Bot
moved this to Ready to start (or start again)
in CTSM: Upcoming tags
ekluzek
moved this from Ready to start (or start again)
to In progress - master
in CTSM: Upcoming tags
ekluzek
changed the title
…e-point/regional tests and not having just Rs, this fixes the lack of I2000Clm60FatesRsGs compset that was needed for a test on Izumi
…, now that distinction is done in the compset by either using CISM or DGLC, make a first pass at clarifying this in the tech-note
…es add the right one) and that the compsets for single point cases have stub ROF and stub Glacier
ekluzek
changed the title
wwieder
changed the title
… MOSART_MODE to null if so. Otherwise don't do anything so that tests with Stub ROF can be done
| In typical runs, CISM is not evolving; CLM computes the SMB and sends it to CISM, but CISM's ice sheet geometry remains fixed over the course of the run. In these runs, CISM serves two roles in the system: | ||
| In typical runs, DGLC is used and the ice sheet is not evolving; CLM computes the SMB and sends it to DGLC, but DGLC's ice sheet geometry remains fixed over the course of the run. In these runs, DGLC serves two roles in the system: | ||
|
|
||
| #. Over the CISM domain (typically Greenland in CESM2), CISM dictates glacier areas and topographic elevations, overriding the values on CLM's surface dataset. CISM also dictates the elevation of non-glacier land units in its domain, and only in this domain are atmospheric fields downscaled to non-glacier land units. (So if you run with a stub glacier model - SGLC - then glacier areas and elevations will be taken entirely from CLM's surface dataset, and no downscaling will be done over non-glacier land units.) |
There was a problem hiding this comment.
@billsacks I misinterpreted this line here that with SGLC no downscaling will be done. Reading it again it's saying that with CISM the elevation of non-glacier land units is determined and atmospheric fields within are downscaled, but with SGLC this downscaling over non-glacier land units is NOT done. But, since line 48 says that it's talking about CISM in NOEVOLVE mode it appears that this downscaling now refers to DGLC in NOEVOLVE mode. But, I don't think that's true either. I think this really applies only when running with CISM.
So I took it to mean that no downscaling over glacier land units will happen with SGLC, but it's really that this special downscaling over non-glacier land units happens when running with CISM over glacier regions (so in Greenland). So both SGLC and DGLC%NOEVOLVE work the same way in that regard there is no special downscaling over non-glacier land units. And also both SGLC and DGLC will downscale over glacier land-units, because that's dictated by the surface dataset.
This means some of the changes I made to the Tech Note about DGLC%NOEVOLVE need to change a bit. But, also line 50 shouldn't be listed as applying to NOEVOLVE mode, it should appear somewhere else as a general statement that applies when the ice sheet is evolving as you are running with CISM.
There was a problem hiding this comment.
@ekluzek - I think your current text is correct... I think your comments about needing to make adjustments are not right: from the perspective of CTSM, DGLC%NOEVOLVE should be the same as the old CISM%NOEVOLVE in these respects:
- I think DGLC%NOEVOLVE still provides topographic heights of non-glacier landunits within its domain. I'm not positive of this, though, and it should probably be confirmed somehow. (It could be confirmed by looking at the downscaled vs. non-downscaled atmospheric fields over a grid cell in Greenland that doesn't have any glacier cover.)
- DGLC does still provide the grid onto which SMB is downscaled.
If I remember correctly, there is one key difference between DGLC%NOEVOLVE and CISM%NOEVOLVE: DGLC%NOEVOLVE handles the fluxes, and so glc_dyn_runoff_routing is true for DGLC%NOEVOLVE, whereas it was false for CISM%NOEVOLVE. This could require some adjustment to the text in the "Computation of surface mass balance" section, if you haven't already adjusted it: I think it's now the case that glc_dyn_runoff_routing will typically be true for any run with either DGLC or CISM (given that CISM is now typically just used for EVOLVE runs).
It would be good to check all of this with @Katetc .
Thank you for your work on this!!!
There was a problem hiding this comment.
One thing I confirmed in looking at what's different between cases with DGLC%NOEVOLVE and SGLC is that gld_do_dynglacier==.true. because GLC_TWO_WAY_COUPLING==TRUE for DGLC and is FALSE for SGLC. This is something set in CMEPS.
I think the upshot with that is that DGLC is providing the topographic heights. Which goes along with one thing that @billsacks says above here
I think DGLC%NOEVOLVE still provides topographic heights of non-glacier landunits within its domain. I'm not positive of this, though, and it should probably be confirmed somehow. (It could be confirmed by looking at the downscaled vs. non-downscaled atmospheric fields over a grid cell in Greenland that doesn't have any glacier cover.)
I had trouble isolating a point over greenland that didn't have any glacier. But, in comparing TBOT (which is downscaled over greenland) I see differences in it over the Greenland coastline. So I think this sufficiently confirms that question.
There was a problem hiding this comment.
In terms of this:
If I remember correctly, there is one key difference between DGLC%NOEVOLVE and CISM%NOEVOLVE: DGLC%NOEVOLVE handles the fluxes, and so glc_dyn_runoff_routing is true for DGLC%NOEVOLVE, whereas it was false for CISM%NOEVOLVE. This could require some adjustment to the text in the "Computation of surface mass balance" section, if you haven't already adjusted it: I think it's now the case that glc_dyn_runoff_routing will typically be true for any run with either DGLC or CISM (given that CISM is now typically just used for EVOLVE runs).
Yes, I could confirm this by going through the code. glc_dyn_runoff_routing gets set by the glacier region, so over Greenland it'll be TRUE for either DGLC or CISM.
| In typical runs, DGLC is used and the ice sheet is not evolving; CLM computes the SMB and sends it to DGLC, but DGLC's ice sheet geometry remains fixed over the course of the run. In these runs, DGLC serves two roles in the system: | ||
|
|
||
| #. Over the CISM domain (typically Greenland in CESM2), CISM dictates glacier areas and topographic elevations, overriding the values on CLM's surface dataset. CISM also dictates the elevation of non-glacier land units in its domain, and only in this domain are atmospheric fields downscaled to non-glacier land units. (So if you run with a stub glacier model - SGLC - then glacier areas and elevations will be taken entirely from CLM's surface dataset, and no downscaling will be done over non-glacier land units.) | ||
| #. Over the DGLC domain (typically Greenland in CESM), DGLC dictates glacier areas and topographic elevations, overriding the values on CLM's surface dataset. DGLC also dictates the elevation of non-glacier land units in its domain, and only in this domain are atmospheric fields downscaled to non-glacier land units. (So if you run with a stub glacier model - SGLC - then glacier areas and elevations will be taken entirely from CLM's surface dataset, and no downscaling will be done over non-glacier land units.) |
There was a problem hiding this comment.
I think this needs some adjustment as well. The last part applies to both SGLC and DGLC.
Fix typo, 'expontential' --> 'exponential' in fates c starvation model PR ESCOMP#4093 Testing: aux_clm and fates test-suites OK on derecho and izumi
|
OK, I've sent off most of the testing that I need to send for this PR. |
slevis-lmwg
left a comment
slevis-lmwg
left a comment
There was a problem hiding this comment.
@ekluzek I approved preemptively to facilitate next steps; however:
- Please address my comments.
- Also I have this question regarding the PR's testing:
For tests expected to be b4b with the baseline despite having new test-names due to changes in their compset aliases, do you have a way to confirm b4b answers? If such tests were a small handful, I would not be concerned, but I think that this situation describes a fair number of tests.
| In this framework, mortality is represented as a first-order loss process, in which all vegetation carbon and nitrogen pools experience proportional losses over time. The equations presented in this section describe the pool-level mortality fluxes and their routing within the biogeochemical framework. | ||
|
|
||
| This section does not describe mechanistic mortality processes represented in the Functionally Assembled Terrestrial Ecosystem Simulator (FATES), where mortality emerges from explicit demographic, physiological, and disturbance processes (see Chapter :numref:`rst_Ecosystem Demography with FATES`). Readers interested in those formulations should refer to the `FATES documentation`_. Mortality associated with fire and land-use or harvest processes is treated separately in the Fire and Land Use Change sections (see Chapters :numref:`rst_Fire` and :numref:`rst_Transient Landcover Change`, respectively). Legacy dynamic vegetation configurations (CNDV) used related mortality formulations but are no longer actively supported; mechanistic dynamic vegetation and mortality processes in CTSM are now handled through FATES. | ||
| This section does not describe mechanistic mortality processes represented in the Functionally Assembled Terrestrial Ecosystem Simulator (FATES), where mortality emerges from explicit demographic, physiological, and disturbance processes (see Chapter :numref:`rst_Ecosystem Demography with FATES`). Readers interested in those formulations should refer to the `FATES documentation`_. Mortality associated with fire and land-use or harvest processes is treated separately in the Fire and Land Use Change sections (see Chapters :numref:`rst_Fire` and :numref:`rst_Transient Landcover Change`, respectively). Mechanistic dynamic vegetation and mortality processes in CTSM are now handled through FATES. |
There was a problem hiding this comment.
I have not built the documentation because there is a lot of other material to review in this PR; so I wonder whether the underbar/underscore here is a typo or intentional:
"... documentation`_. Mortality ..."
@ekluzek pls let me know if you would like me to also review the built documentation as part of this code review.
There was a problem hiding this comment.
That's a good question about the underscore. That predates this PR, but it might be good to see what it looks like. I think I should just plan to do that on my own. I don't think it's something needed for both of us to do.
code review update
code review clarification Co-authored-by: Samuel Levis <slevis@ucar.edu>
Remove repeated reference from code review. Co-authored-by: Samuel Levis <slevis@ucar.edu>
Removed math lines recommended in code review.
… into update_compsets_to_use_dglc
|
Here's a list of unexpected fails for aux_clm: |
|
The FATES testlist showed a difference for this single field FATES_C13DISC_SZPF for the AllVars test. So this is probably just a dignostic field that should be commented out for the time being. This same problem is seen in ctsm5.4.047 and ctsm5.4.049. This is issue #3660 |
|
The ctsm_sci test list has this list of unexpected fails: |
Remove sentence as noted in code review. Co-authored-by: Samuel Levis <slevis@ucar.edu>
…ed in the code review
… into update_compsets_to_use_dglc
|
One of the problems is due to an issue in CDEPS for DGLC. See: ESCOMP/CDEPS#426 |
|
Looking at the threaded tests that fail comparison of rest to base. It's the cpl history files that fail for 4 fields: so it's a roundoff difference somehow due to DGLC when threading is on. |
|
Shorter threaded ERP tests pass, so there must be something going on with tests that exceed a year. All of these PASS: |
|
Adding "next" to discuss: How did this get so big? Was it necessary? |
samsrabin
added
next
We talked about this in the CTSM SE meeting this morning. The main thing that happened was that I didn't want to make changes to compsets that would be removed. So I brought in those changes along with this here. What I didn't see, was that I could've done that as an initial smaller tag, and maybe even a few tags that could've come in quicker. I still had a list of things that will come in later PR's, and made sure I didn't do those, but I didn't see that I could've broken this tag up. There's still some things that came out of the DGLC update that required changes that I hadn't thought of before. And since it inheriently changed pretty much all of the compsets, and most of the tests it's pretty big in and of itself. I've been able to realize this sort of thing in the past, that I need to break something up. But, as @samsrabin pointed out when you have steps planned out, it can be hard to see that I really should have had a previous step to step "1". So it's a good reminder to think about that when you are in the middle of something that ended up being big. And the group discussion of this shows that sometimes it helps to bring it up in the group or even with one other person. Anyway, good thing to keep in mind for the future. |
samsrabin
changed the title
4 participants
Description of changes
Update most of the CLM60 compsets to use DGLC%NOEVOLVE rather than stub glacier. I1Pt single point compsets are left alone.
Make single point tests and compsets all have RsGs at the end of the alias to specify stub ROF and stub GLC, and do this consistently in all compsets and tests.
Change FATES CLM60 tests to use RsGs compsets for single-point/regional and without it for global. And change Clm60FatesCru tests to Clm60FatesCrujra. Make FATES tests (other than single-point) run with MOSART and DGLC.
Make single point tests all consistently use Qian forcing compsets for consistency and speed. Remove most of the Cru tests except for one with Clm50.
Also since I'm messing with compsets and tests, and removing compsets and tests for several things we've decided to deprecate: clm4_5, BGCDV, %BGC%NWP, and VIC.
Specific notes
Contributors other than yourself, if any:
CTSM issues resolved or otherwise addressed, if any:
If answers are expected to change, describe (delete this line otherwise): Yes
Definition of many Clm60 compsets change so that DGLC is used
Any user interface changes (namelist or namelist defaults changes)?
Change in compset definition for many Clm60 compsets
Testing planned or performed, if any:
Requirements before merge: