Define Supported FATES Compsets for CLM6 Release

[rgknox]

CLM FATES calibrations for SP and possibly no-comp will be conducted along with the CLM6 release. The namelist configurations and any other relevant configurations for these runs will define what is "supported". Thus, we need compset(s) for these supported configurations.

This was defined as a "required" milestone for CLM6 release.

@adrifoster @rosiealice

---

Decisions

Compsets to support (all scientific): FatesSp and FatesNoComp for:

• I1850Clm60
• I2000Clm60
• IHistClm60

Definition of done:

• [ ] Scientific and functional tests evaluated and approved
• [ ] Aliases defined in XML files etc.
• [ ] Make sure every alias is used in at least one aux_clm test

[ekluzek]

We need FatesSp and FatesNoComp for:

I1850Clm60 I2000Clm60

scientifically supported

And then

IHistClm60

for both as functionally supported

[ckoven]

For the supported compsets, I agree with those for FatesNoComp but I don't think we need a transient case for FatesSP mode?

[samsrabin]

From CTSM SE meeting today: Adrianna got transient FatesSP mode working with an adjustment. Continued a case with new DATM after deleting restart files. Might have been easier if she knew the steps from the beginning.

[mvdebolskiy]

Related issues: NorESMhub/CTSM#111 and NorESMhub/CTSM#142.

[adrifoster]

From CTSM SE meeting today: Adrianna got transient FatesSP mode working with an adjustment. Continued a case with new DATM after deleting restart files. Might have been easier if she knew the steps from the beginning.

What I had done:

I ran a spinup case with GSWP3 climate, cycling 2005-2014 data for 60 years.

I made all the updates to user_nl_datm and user_nl_datm_streams:

user_nl_datm: !------------------------------------------------------------------------ ! Users should ONLY USE user_nl_datm to change namelists variables ! Users should add all user specific namelist changes below in the form of ! namelist_var = new_namelist_value ! Note that any namelist variable from shr_strdata_nml and datm_nml can ! be modified below using the above syntax ! User preview_namelists to view (not modify) the output namelist in the ! directory $CASEROOT/CaseDocs ! To modify the contents of a stream txt file, first use preview_namelists ! to obtain the contents of the stream txt files in CaseDocs, and then ! place a copy of the modified stream txt file in $CASEROOT with the string ! user_ prepended. !------------------------------------------------------------------------

anomaly_forcing = 'Anomaly.Forcing.Temperature'

user_nl_datm_streams: !------------------------------------------------------------------------ ! This file is used to modify datm.streams.xml generated in $RUNDIR ! Entries should have the form ! :<stream_variable>= (NO Quotes!!!) ! The following are accepted values for a stream named foo ! foo:meshfile = character string ! foo:datafiles = comma separated string of full pathnames (e.g. file1,file2,file3...) ! foo:datavars = comma separated string of field pairs (e.g. foo foobar,foo2 foobar2...) ! foo:taxmode = one of [cycle, extend, limit] ! foo:tintalgo = one of [lower,upper,nearest,linear,coszen] ! foo:readmode = single (only suported mode right now) ! foo:mapalgo = one of [bilinear,redist,nn,consf,consd,none] ! foo:dtlimit = real (1.5 is default) ! foo:year_first = integer ! foo:year_last = integer ! foo:year_align = integer ! foo:vectors = null or the names of the vector fields in the model (i.e. Sa_u:Sa_v) ! foo:lev_dimname: = one of [null,name of level dimenion name] ! foo:offset = integer ! As an example: ! foo:year_first = 1950 ! would change the stream year_first stream_entry to 1950 for the foo stream block ! NOTE: multi-line inputs are enabled by adding a \ at the end of the line ! As an emaple: ! foo:datafiles=foo1,foo2,
! foo3 ! Will yield the following new entry for datafiles in stream foo ! ! foo1 ! foo2 ! foo3 ! !------------------------------------------------------------------------ Anomaly.Forcing.Temperature:year_first=2015 Anomaly.Forcing.Temperature:year_last=2100 Anomaly.Forcing.Temperature:year_align=61 Anomaly.Forcing.Temperature:meshfile =$DIN_LOC_ROOT/share/meshes/fv0.9x1.25_141008_polemod_ESMFmesh.nc ! List of Data types to use ! Remove the variables you do NOT want to include in the Anomaly forcing: ! pr is preciptiation ! tas is temperature ! huss is humidity ! uas and vas are U and V winds ! rsds is solare ! rlds is LW down Anomaly.Forcing.Temperature:datavars = pr Faxa_prec_af,
tas Sa_tbot_af,
ps Sa_pbot_af,
huss Sa_shum_af,
uas Sa_u_af,
vas Sa_v_af,
rsds Faxa_swdn_af,
rlds Faxa_lwdn_af Anomaly.Forcing.Temperature:datafiles =$DIN_LOC_ROOT/atm/datm7/anomaly_forcing/CMIP6-SSP3-7.0/af.allvars.CESM.SSP3-7.0.2015-2100_c20220628.nc

presaero.SSP3-7.0:year_align=61 presndep.SSP3-7.0:year_align=61 preso3.SSP3-7.0:year_align=61 co2tseries.SSP3-7.0:year_align=61

but kept getting an error with the model reads the datm restart file.

reading data model restart ctsm51FATES_SP_sparsegrid_FATES_FIN_000.datm.r.0061-01-01-00000.nc
 ERROR: ERROR reading in nfiles

The solution was to delete the datm restart file:

rm -rf ctsm51FATES_SP_sparsegrid_FATES_FIN_000.datm.r.*

[wwieder]

I'd argue for making SP and noComp historical runs scientifically supported.

• both are needed so we can support users and developers that are migrating to FATES
• I also think a historical SP run is needed so we can understand water cycle and energy balance differences / similarities from CLM-FATES-SP and CLM-FATES simulations.

[ekluzek]

The total list is:

• I1PtClm60FatesSpRs
• I1850Clm60FatesSp
• I2000Clm60FatesSp
• IHistClm60FatesSp
• I1PtClm60FatesNoCompFbgRs
• I1850Clm60FatesNoCompFbg
• I2000Clm60FatesNoCompFbg
• IHistClm60FatesNoCompFbg

All of these will be scientifically supported. They will all have MOSART river's except the single point ones. In general we want the FATES compsets to have the same pattern as we have for the non-FATES cases.

We've had rivers off for FATES compsets, so this will be a change., But, it's bringing FATES forward as the model to be doing standard simulations with.

The FATES IHist compsets will do the normal IHist things in terms of cycling over 1850-2024 datasets, and will also turn on the FATES LUH transient changes as well.

We will NOT do SSP scenarios for FATES. @glemieux also points out that the CMIP7 (LUH3) future scenarios include plantation handling -- but this won't be required to be in until the cesm3.1 release. It's zeroed out for the historical period. So we won't need plantation handling in FATES for the cesm3.0 release.

[ckoven]

Hi All- For two of the globally-gridded compsets in @ekluzek's list in the above comment (I1850Clm60FatesNoCompFbg and I2000Clm60FatesNoCompFbg), they will require constant land-use files that give secondary-land age distributions that are in line with what would happen for the transient cases.

I just submitted a PR to the FATES land-use tools repo with the script to generate these.

The workflow for these is that, for any given grid resolution, you need to:

1. Generate the transient LUH file for a given scenario
2. Generate the PFT x Land Use dataset at that resolution (this is time and scenario-independent)
3. Generate the constant land use file for whatever year you plan to spin the model up in.

So, basically, for the three compsets listed above, in addition to different meteorology and CO2, there will be a different FATES land use file to use for each one:

• for the IHistClm60FatesNoCompFbg, you'll want the full transient land use file generated in step (1)
• for the I1850Clm60FatesNoCompFbg, you'll want the constant-land-use file generated in step (3) for the year 1850
• for the I2000Clm60FatesNoCompFbg, you'll also want the constant-land-use file generated in step (3), but for the year 2000

The pft x land use file generated in step 2 above will be the same for all three FatesNoCompFbg compsets.