dlawrenncar
commented
3 years ago For one, organic_frac_squared should not have changed from CLM5 to CLM5.1.
On Tue, Sep 29, 2020 at 8:41 PM Bill Sacks notifications@github.com wrote:
Brief summary of bug
I am reviewing the changes in ctsm5.0.dev001. I noticed a few possible problems with the namelist defaults in that tag. I'm not sure if all of these are actually bugs, but I wanted to bring this to the attention of @ekluzek https://github.com/ekluzek and others in case some should be fixed. One of these issues, organic_frac_squared, appears to lead to incorrect results in out-of-the-box clm51 configurations (unless this change was intentional). The other issues would just affect runs in non-standard configurations, or are cleanup issues. General bug information
CTSM version you are using: ctsm5.1.dev001
Does this bug cause significantly incorrect results in the model's science? Yes, I think so, for clm51 cases, because of incorrect value for organic_frac_squared.
Configurations affected: clm51 cases, and non-standard configurations Details of bug
These are really a few somewhat unrelated issues. I'm grouping them together here for ease of review:
- organic_frac_squared for clm5_1 uses the same setting as clm4_5; I'm guessing this is wrong:
- Some fire-related namelist variables depend on the physics version directly, whereas my intuition is that they should depend on the fire method. As a thought experiment: if someone sets up a clm51 case but reverts to the li2016crufrc fire method, or conversely sets up a clm50 case but changes to li2021gswpfrc, what defaults should be used for these? Specifically, this is the case for the lightning and popdens streams: the light_res variable and the three popdens variables that depend on phys version – though it looks like the popdens variables don't actually differ with different phys versions, so the duplication in xml is irrelevant and could probably be removed:
- It looks like some fire-related namelist variables would be undefined for certain values of lnd_tuning_mode, when using li2016crufrc: rh_low and pot_hmn_ign_counts_alpha. I think these should be given default values for li2016crufrc without a lnd_tuning_mode attribute, so that they are given some reasonable value for other lnd_tuning_modes (I think that's the right way to fix this problem). This could arise in practice if someone sets up a clm51 case but reverts to the li2016crufrc fire method, or conversely sets up a clm50 case but changes to li2021gswpfrc (and probably other ways, too):
- Cleanup that shouldn't have any impact: spinup_state has some duplicated lines for fates: there are 2 unique lines here, each doubled:
-
Cleanup that shouldn't have any impact: the 2010 control use case has some unnecessary clm4_0 settings
Cleanup that shouldn't have any impact: the 2010 control use case has a duplicated line:
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/ESCOMP/CTSM/issues/1166, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFABYVCZ6K76S7F62WKPU23SIKLHDANCNFSM4R6Q6SJA .
billsacks
ekluzek
Brief summary of bug
I am reviewing the changes in ctsm5.0.dev001. I noticed a few possible problems with the namelist defaults in that tag. I'm not sure if all of these are actually bugs, but I wanted to bring this to the attention of @ekluzek and others in case some should be fixed. One of these issues, organic_frac_squared, appears to lead to incorrect results in out-of-the-box clm51 configurations (unless this change was intentional). The other issues would just affect runs in non-standard configurations, or are cleanup issues.
General bug information
CTSM version you are using: ctsm5.1.dev001
Does this bug cause significantly incorrect results in the model's science? Yes, I think so, for clm51 cases, because of incorrect value for organic_frac_squared.
Configurations affected: clm51 cases, and non-standard configurations
Details of bug
These are really a few somewhat unrelated issues. I'm grouping them together here for ease of review:
organic_frac_squaredforclm5_1uses the same setting asclm4_5; I'm guessing this is wrong:https://github.com/ESCOMP/CTSM/blob/08bc0ade130b23a67a9366120f8033897505c74b/bld/namelist_files/namelist_defaults_ctsm.xml#L163-L165
[x] Default finidat files for sim-year 2000 are incorrect (fixed in ctsm5.1.dev008)
[ ] Some fire-related namelist variables depend on the physics version directly, whereas my intuition is that they should depend on the fire method. As a thought experiment: if someone sets up a clm51 case but reverts to the li2016crufrc fire method, or conversely sets up a clm50 case but changes to li2021gswpfrc, what defaults should be used for these? Specifically, this is the case for the lightning and popdens streams: the
light_resvariable and the threepopdensvariables that depend on phys version – though it looks like thepopdensvariables don't actually differ with different phys versions, so the duplication in xml is irrelevant and could probably be removed:https://github.com/ESCOMP/CTSM/blob/08bc0ade130b23a67a9366120f8033897505c74b/bld/namelist_files/namelist_defaults_ctsm.xml#L1569-L1573
https://github.com/ESCOMP/CTSM/blob/08bc0ade130b23a67a9366120f8033897505c74b/bld/namelist_files/namelist_defaults_ctsm.xml#L1592-L1602
rh_lowandpot_hmn_ign_counts_alpha. I think these should be given default values for li2016crufrc without alnd_tuning_modeattribute, so that they are given some reasonable value for other lnd_tuning_modes (I think that's the right way to fix this problem). This could arise in practice if someone sets up a clm51 case but reverts to the li2016crufrc fire method, or conversely sets up a clm50 case but changes to li2021gswpfrc (and probably other ways, too):https://github.com/ESCOMP/CTSM/blob/08bc0ade130b23a67a9366120f8033897505c74b/bld/namelist_files/namelist_defaults_ctsm.xml#L265-L270
https://github.com/ESCOMP/CTSM/blob/08bc0ade130b23a67a9366120f8033897505c74b/bld/namelist_files/namelist_defaults_ctsm.xml#L276-L281
https://github.com/ESCOMP/CTSM/blob/08bc0ade130b23a67a9366120f8033897505c74b/bld/namelist_files/namelist_defaults_ctsm.xml#L53-L56
[ ] Cleanup that shouldn't have any impact: the 2010 control use case has some unnecessary
clm4_0settings[ ] Cleanup that shouldn't have any impact: the 2010 control use case has a duplicated line:
https://github.com/ESCOMP/CTSM/blob/08bc0ade130b23a67a9366120f8033897505c74b/bld/namelist_files/use_cases/2010_control.xml#L11-L12