ESCOMP / ESCOMP/CTSM

Problems with namelist defaults starting in ctsm5.0.dev001

Open
#1,166 6 comments 0 reactions 1 assignee Claimed by @ekluzek View on GitHub
b4b bug good first issue
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

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.