Question about using CLM1PT mode with my regional atmospheric forcing?

[mengqi]

Hi,

I am conducting a regional-scale simulation using CLM5 with custom atmospheric forcing. Specifically, I have employed the CLM1PT mode to incorporate my own atmospheric forcing data. However, the simulated crop yield results appear to be inaccurate, leading me to suspect an issue with the atmospheric forcing.

Upon comparing several atmospheric input variables (e.g., precipitation and temperature) with the corresponding atmospheric output, I observed differences between them (they are supposed to be the same!) This indicates that the atmospheric forcing may not have been correctly specified.

I attached my datm.streams.xml. Could anyone please offer me some insights? Thank you so much!!

 

[oleson]

It seems like you have daily average data? I see 31 time samples in 2015-01.nc

netcdf \2015-01 {
dimensions:
time = 31 ;
scalar = 1 ;
lat = 26 ;
lon = 50 ;

You have tintalgo in your datm.streams.txt file set to "nearest". So I would expect that the daily values would be repeated for every time step for each day. You could use "linear". So each time step would be an interpolated value between adjacent days. But I don't think that would work very well for solar radiation, for example, as your daily value is probably an average of day and night (zero solar radiation) values. I think you will need to impart some kind of a diurnal cycle to your data. Our forcing data is generally 3-hourly or 6-hourly or half-hourly or hourly (for flux tower sites).

 

[mengqi]

Hi @oleson

Thank you for your insights! Much appreciated!

I modified tintalgo from "nearest" to "linear"; however, the issue persists. Please refer to the attached plot. As shown, there are significant discrepancies between the precipitation and temperature patterns, which suggests that CLM5 may not have correctly processed the atmospheric forcing data. I observed that the datm.streams.xml does not include a meshfile. However, I believe the CLMGSWP3v1 mode requires a meshfile in the datm.streams.xml. So I am unsure if this raises the possibility that this omission could be the source of the issue. If not, could you please offer some insights here? Thanks!

 

[oleson]

Where is the case that was used to produce the maps shown above? Thanks.

 

[mengqi]

Where is the case that was used to produce the maps shown above? Thanks.

Case: u/home/mengqij/B_simulation_region_pv_c/I2000_CTSM_singlept_region_pv_f1
Simulation results: derecho/scratch/mengqij/archive/I2000_CTSM_singlept_region_pv_f1/lnd/hist
Thank you, @oleson! Thanks for your help!

 

[oleson]

The atm log file indicates that the data is being read once each day which is what I would expect. Not sure why the averages from the history files don't agree with the averages from the datm forcing files. You could output the forcing every time step for a day or a month to see what's going on. I'd go back to "nearest" for that test.
I don't think there is necessarily a problem with a missing mesh file. Your forcing data appears to be valid over all grid cells in your domain. If it wasn't then I would expect there might be a problem because you'd need a mesh file to indicate where data is valid or invalid.
Again, I don't think providing only daily average data is going to result in a decent simulation. For example, if the daily value of precipitation is non-zero, then you'll have precipitation every time step during that day, which would be unrealistic in most cases. Another example is that the daily value of solar radiation that is being provided is probably averaging in zero solar radiation at night which would mean lower solar radiation that would be realistic. You would also have the same solar radiation at each time step of the day, which wouldn't be realistic either.

 

[mengqi]

Thank you, @oleson! Thanks for your insights!

I remain uncertain about the question; therefore, I employed an alternative approach, specifically utilizing anomaly forcing. In particular, I conducted and SSP126 scenario.

./create_newcase --case ~/B_simulation_region_pv_c/I2000_CTSM_singlept_region_pv_g1 --res CLM_USRDAT --compset SSP126_DATM%GSWP3v1_CLM50%BGC_SICE_SOCN_SROF_SGLC_SWAV --project UIUC0025 --run-unsupported

Besides, I revised some parameters in user_nl_clm below:

fsurdat = '/glade/u/home/mengqij/B_simulation_region_pv_b/surface_datasets/surfdata_CO_region_78pfts_simyr2000_c231005_a.nc'
paramfile = '/glade/u/home/mengqij/B_simulation_region_pv_c/parameters/ctsm51_params.c240105_b.nc'
hist_fincl2 = 'GRAINC', 'FSQ', 'H2OSOI'
hist_fincl3 = 'FSA', 'FSR', 'TV', 'QFLX_EVAP_TOT', 'VPD_CAN', 'GPP', 'GSSHA', 'GSSUN', 'LAISHA', 'LAISUN', 'TLAI', 'GRAINC'
hist_dov2xy = .true., .false., .false.
hist_type1d_pertape = ' ', 'GRID', 'PFTS'
hist_nhtfrq = 0, -24, -24
hist_mfilt = 1, 3650, 3650

When I build the case, there is an issue:
ERROR: Command /glade/u/home/mengqij/ctsm_MYBRANCH/bld/build-namelist failed rc=255
out=
err=ERROR : CLM build-namelist::CLMBuildNamelist::add_default() : No default value found for flanduse_timeseries.
Are defaults provided for this resolution and land mask?

I do not believe I specified a transient simulation; however, I am uncertain how to resolve the issue. Could you please give me some insights? Thanks!
@oleson

 

[oleson]

The SSP126 compset (and all SSP compsets in general) is a compset that has transient landcover. I think setting 'flanduse_timeseries' to a blank string, e.g., flanduse_timeseries = ' ', in your user_nl_clm, will turn off the transient landuse part of the compset.

 

[mengqi]

Hi @oleson,

Thanks for your insights! We implemented the "anomaly forcing" method for land-only simulations in CLM5, aligned with future climate projections (SSP-126, SSP-245, and SSP-585), which allowed us to generate climate data to drive the model. As far as I know, these SSP scenarios were specifically based on projections from a single Earth system model (CESM).

However, I have observed that, in general, SSP-126, SSP-245, and SSP-585 are generated using more than five Earth system models. This leads me to question whether the "anomaly forcing" method remains effective or robust when exploring future climate impacts on relevant variables.

Thank you! @oleson

 

[mengqi]

I noticed a few high-profile papers are using the "anomaly forcing" method, such as Potential decoupling of CO2 and Hg uptake process by global vegetation in the 21st century - Nature Communications

This suggests that this method seems to be justified. But for my previous question, could you please give me some insights? Thank you, @oleson!