E3SM
E3SM copied to clipboard
Add FATES land use change module to pass LUH2 data to FATES
This pull request adds a new module, the structure of which is adopted from the dyn_subgrid code, to enable e3sm to ingest minimally processed luh2 data to be passed to FATES. A new namelist variable is introduced use_fates_luh
, to engage the module functionality, which is off by default. The luh2 dataset to be ingested is a minimally processed concatenation of the luh2 state, transition and management datasets.
These changes also include a minor bug fix discovered in the process of developing the code, in which if the number of FATES patches being defined by the user in the fates parameter file is greater than the max_patch_per_col
elm variable, would result in a BalanceCheck error.
To be coordinated with https://github.com/NGEET/fates/pull/1040
[nonBFB] for FATES
@glemieux Can we add a new test for this PR?
Status update: there is a forthcoming update to the fates luh2 data pipeline https://github.com/NGEET/fates/pull/1032 that will result in an update to the default fates landuse data set. As such I've added "WIP" to this PR.
status: probably another month waiting on FATES refactor.
Need #5849 and also still WIP.
#5849 was merged. Status now?
@glemieux is this ready?
@glemieux is this ready?
@rljacob This is still WIP and waiting on https://github.com/NGEET/fates/pull/1040 updates. I'm actively working on this.
update: still waiting on fates PR. Another couple of weeks.
update: still WIP. 2 others will need to be merged before this.
@glemieux can you list in a comment the PRs this is waiting on?
@rljacob it needs to be staged after #6018 and #6027, both which need review and are undergoing some testing. Ultimately, it's also waiting on https://github.com/NGEET/fates/pull/1040, but this should be integrated within the next week.
This PR needs to have some updates brought in, but is close to not being "WIP".
FYI: The next FATES API (33) is fairly simple, but I will hold on making that until this branch is re-based, since I have to build it on top of this one.
- [x] update fates tag
- [x] add landuse testmod to
fates
test suite - [x] remove
use_cn
return check from landusemod - [x] add
fluh_timeseries
tosetup_cmdl_fates_mode
@peterdschwartz @rgknox I've taken care of the suggested changes and rebased this onto master
now that #6027 is in. I'm going to start regression testing on this today and I've removed the '[WIP]'.
@peterdschwartz regression testing on perlmutter with the e3sm_land_developer
suite is complete and all expected non-fates tests are B4B. The qian
smoke test from #6192 is failing, but that's because I hadn't rebased since last week. I've got a local rebased branch with #6219 included to make sure its not failing for a different reason. All fates test pass with expected DIFFs in non-landuse run modes since the tag update also includes a couple fates scientific bug fixes since sci.1.68.2_api.31.0.0
.
@rgknox @bishtgautam This is ready to review then.
Edit: Needs to be re-approved after rebase.
Just a quick update to note that rebasing against the latest master
resulted in SMS.r05_r05.I1850ELMCN.pm-cpu_....elm-qian_1948
passing.
Tested on chrysalis and everything came back as expected. This can go in once it's got one approval
However, a major comment is: Shouldn't there be a new compset (say I20TRELMFATES) in which the transient LU data is used by FATES?
@bishtgautam Eventually we should have a compset for this, but with this PR I don't think its ideal as we're going to be bringing in a fates landuse v2 change in the next month or so. I think with the v2 update we will want to facilitate easier use of the option through the compset.
On a related note and by comparison, I think its definitely worth creating a fates SP mode compset with a future PR since that run mode is more mature.
Still waiting for the repo to be open.
merged to next