ESCOMP
Update dataset read code (for FATES and non-FATES?) to be compatible with the CMIP7 datasets
The FATES CLM6 task-force identified that CMIP7 land-use datasets will have different fields and format. The code that reads in these datasets must be updated to accomodate for this format. This could be renaming expected field names or their position in an array.
@ckoven @lawrencepj1
@ckoven do we need FATES-side code changes for this, or is this all handled through host-side code?
FWIW, the preprocessed data from Peter that are going into our surface datasets and landuse time series can be found here /glade/campaign/cesm/development/lmwg/landuse_source_data/CTSM53CMIP7RawData/
Yes this will require adding the new state and transition field names in both CTSM and FATES:
I'm currently downloading the CMIP7 files, I will update here or in https://github.com/NGEET/fates/issues/1272 with the new fields that need to be added once I have them.
FWIW, the preprocessed data from Peter that are going into our surface datasets and landuse time series can be found here
/glade/campaign/cesm/development/lmwg/landuse_source_data/CTSM53CMIP7RawData/
I don't have access to that directory (I do to the directory one level up), could one of you change the permissions to give read access?
derecho2 lmwg/landuse_source_data> ls CTSM53CMIP7RawData
ls: cannot open directory 'CTSM53CMIP7RawData': Permission denied
@lawrencepj1 we'll need you to give Read/execute access to the CMIP7 directories and files for "Other" under the directory above.
We could also give @ckoven access to the cesm group, or change the group it's under. But, we'd have to think about that a bit.
OK I just took a look at the luh3 files. I had downloaded the 3.0 version, and assuming the 3.1 isn't too different (i.e. that it also has all zeros for plantation forest areas and transitions), I think this should actually just work as-is. The FATES land use tool will regrid all fields, so they will be in the FATES land use forcing file. We'll have to eventually add the new plantation forest pltns state and the following set of new transitions:
primf_to_pltns
primn_to_pltns
pltns_to_secdf
secdf_to_pltns
pltns_to_secdn
secdn_to_pltns
pltns_to_c3ann
c3ann_to_pltns
pltns_to_c4ann
c4ann_to_pltns
pltns_to_c3per
c3per_to_pltns
pltns_to_c4per
c4per_to_pltns
pltns_to_c3nfx
c3nfx_to_pltns
pltns_to_pastr
pastr_to_pltns
pltns_to_range
range_to_pltns
pltns_to_urban
urban_to_pltns
And then we'll also have to add the following set of harvest rates, and the additional logic to handle them:
pltns_bioh
pltns_harv
One thing that sort of surprises me are the transitions primf_to_pltns and primn_to_pltns. I was planning to lump plantation forests into secondary lands, but if we do that, then it sort of breaks the rule that only harvest of primary land results in secondary land, since those are technically transitions rather than harvests. If we do area-based harvesting, they are equivalent, but not so if we use mass-based harvesting. So some thought may be required of those transitions are ever nonzero. Or we could actually make them their own land use type.
But since all of these are all zeros at this point, I don't think we need to prioritize for the code freeze, since the scientifically supported FATES case will only be historical transients.
From discussion this will require changes in: CTSM as well as FATES and the FATES tools. This is a high priority for the FATES code freeze. But, being able to use the LUH2 data is a OK as a backup.
cross-posting https://github.com/NGEET/fates/issues/1272#issuecomment-2920805032 here.