Problems with namelist defaults starting in ctsm5.0.dev001
- Dominant language
- Fortran
- Stars
- 352
- Forks
- 361
- Avg merge
- 6d 6h
- Merged PRs (30d)
- 8
Description
### 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:
- [x] `organic_frac_squared` for `clm5_1` uses the same setting as `clm4_5`; I'm guessing this is wrong:
- (2020-10-01) Fixed in e8327910a
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_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:
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
- [ ] 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):
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
- [ ] Cleanup that shouldn't have any impact: spinup_state has some duplicated lines for fates: there are 2 unique lines here, each doubled:
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_0` settings
- [ ] 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
Contributor guide
Assessment
This issue has not been assessed yet.