change the order of passing the "use_fates_luh" flag #2898
Conversation
…ce to allow memory allocation handling
rgknox
changed the title
rgknox
added
FATES
src/utils/clmfates_interfaceMod.F90
Outdated
| @@ -305,6 +305,7 @@ subroutine CLMFatesGlobals1(surf_numpft,surf_numcft,maxsoil_patches) | |||
| integer :: pass_nocomp | |||
| integer :: pass_sp | |||
| integer :: pass_masterproc | |||
| integer :: pass_luh | |||
There was a problem hiding this comment.
Could the existing pass_use_luh not be used for consistency in terms of naming (i.e., with pass_use_potentialveg)? If not, pass_use_luh seems to not be used anymore, so it should be deleted.
There was a problem hiding this comment.
Sure, i can change it. There are other flags in ClmFatesGlobals1 that dropped the "use" in the local variable, I can add those back in too.
There was a problem hiding this comment.
One concern I have is with the use of the term potentialveg in FATES code. FATES is using it with one specific meaning, but in CTSM we use PotentialVeg to mean a surface dataset that doesn't have anthropogenic changes. There are similarities, but I'm concerned this might create confusion in CTSM.
As such I'd prefer pass_use_luh for now...
Should we maybe talk about this tomorrow to make sure the use of potentialveg in FATES isn't conflicting with how CTSM uses it?
There was a problem hiding this comment.
@rgknox I would throw in for adding the "use" back in, because it's a convention we use in CTSM, so just looking at the variable name I know it's a logical variable. And I like that.
But, if we removed the "use" previously -- maybe there was a reason for it that we should look up?
There was a problem hiding this comment.
I previously removed the "use" just to be less verbose, nothing more. I'm fine with adding it back in.
@ekluzek, the pass_use_potentialveg is a separate flag from pass_use_luh, I think @samsrabin was pointing it out as an example of convention.
I'm happy to expand this PR though if you would like to update the name of that flag to something less "overlappy" with native ctsm. @ckoven, could you weigh in here on potential alternative names for use_fates_potentialveg.
There was a problem hiding this comment.
@glemieux suggested something like use_landuse_spinup.
There was a problem hiding this comment.
Hi All -- My preference is to use "Potential Veg" or similar, rather than "Spinup". The reason is that potential vegetation is a more accurate description of what the relevant code does. Spinup is more of a workflow concept; a user might use potential vegetation apart from spinup, and might do spinup without using potential vegetation mode. It also might make it sound to a user like potential veg has something to do with AD spinup, which it doesn't. In terms of the conceptual overlap of how the phrase is used in non-FATES CTSM, I think that it makes sense that both vegetation models might use the same vocabulary for something that is conceptually similar? I guess I don't see why that is a problem. It seems sort of analogous to how both models have stomatal conductance switches that share names. But I guess another possibility would be to call it something like "All Primary Land Mode"? But I feel like that is more verbose.
|
If tests reveal this to be b4b, then it should probably be merged into |
|
Absolutely merge to b4b if it is so. It's just that FATES updates almost always bring in answer changes. I don't remember the last one that was... |
|
|
|
Please disregard my last message. This PR does have useful content. |
Description of changes
The flag that specifies using LUH datasets is passed earlier in the call sequence so that it can be used to guide memory allocations. If landuse is turned on, particularly in fates nocomp mode, then the space required for patch allocations changes. Therefore this flag has to be passed earlier, before these allocations are decided on.
Specific notes
This PR does not need to be synchronized with, but does need to precede: NGEET/fates#1226
Contributors other than yourself, if any: @ckoven
CTSM Issues Fixed (include github issue #):
Are answers expected to change (and if so in what way)? none, b4b
Any User Interface Changes (namelist or namelist defaults changes)? no
Does this create a need to change or add documentation? Did you do so? no need
Testing performed, if any:
TBD, but some tests with the FATES test suite so far
(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).