[WIP] Move hillslope variables off surface dataset
Work in progress! Do not review!
Subject to force pushes!
Description of changes
This PR moves the variables required for hillslope runs off the surface dataset and onto the new hillslope_file. This makes it so we don't have to maintain a hillslope-specific surface dataset for testing purposes. If/when running with hillslopes becomes the default, we can move these variables back onto the surface dataset.
Specific notes
Contributors other than yourself, if any: None
CTSM Issues Fixed (include github issue #): None
Are answers expected to change (and if so in what way)? No
Any User Interface Changes (namelist or namelist defaults changes)? No
Testing performed, if any:
- [x] Derecho hillslope tests are b4b-identical with ctsm5.1.dev174
- [ ] Izumi hillslope tests are b4b-identical with ctsm5.1.dev174
- [ ] Other Derecho and Izumi aux_clm tests are b4b-identical with ctsm5.1.dev174
Remaining work
- [ ] Merge in 5.2 tag
- [ ] Update surface dataset specified in Hillslope testmod: Use default 10x15 fsurdat
- [ ] Update synthetic hillslope dataset specified in Hillslope testmod, if needed
Blocked: Waiting on 5.2.
5.2 is in, so this is no longer blocked.
I have to change the 5x5_amazon hillslope tests from I1850 to I2000 because there's no default 2000 surface dataset for that resolution. I've thus retargeted this branch at master instead of b4b-dev.
@swensosc Would you mind having a look over this? Happy to walk you through it if you prefer.
I think most of it looks straightforward (changing input file). You may wish to add a phrase to this warning "This means all hillslope columns in a gridcell will read identical values" to indicate that this will occur even if the finidat file has hillslope data on it. Also, is there a check to ensure that hillslope_file is of the same spatial resolution as fsurdat? If not, is that possible?
Thanks, @swensosc!
- [x] Add check that
fsurdatandhillslope_fileare the same resolution. - [x] Add text to warning message.