Test run with CFORCE DATM

[wwieder]

Members of the Ocean group (Rita, Gokhan and Fred) are bias correcting ERA5 for running G-cases as part of the CFORCE project. It would be good to see if we can leverage some of this work for CLM simulations so we can develop our own 'in house' DATM pipeline that can be updated more regularly.

Rita has done global bias correcting for incoming solar and has methods for correcting other biases over oceans (temperature, humidity, & winds). This may be challenging over land, as the higher resolution of the dataset (quarter degree) introduces greater topographic heterogeneity than many of our datasets. CFORCE is not changing precip over the ocean, but acknowledges there are precip biases over land (rain bombs in Africa).

@olyson, to start with I wonder if you can take a stab at doing a relatively short SP run on with the current CFORCE data? @swensosc may have some experience here that's helpful (see also #3010) @megandevlan is interested in helping to evaluate the forcing (and eventually simulations), as ESPAT is interested in using this.

There are some interesting questions to consider here, especially related to:

• Performance (hourly data at quarter degree).
• Potentially removing multiple streams in the DATM field, as temporal interpolation may not be needed)
• Ability to get direct and diffuse incoming shortwave radiation?
• Mesh file generation (#3010 mentions challenges running at the poles)?
• Methods for bias correcting this higher spatial resolution fields.

Rita stressed this is a work in progress, but her current files are here /glade/campaign/cgd/oce/people/rita/ERA5/ and said she'd help navigate what files to use

[dlawrenncar]

Note that as we start to consider how to update the CFORCE dataset to be improved over land, here is a paper that describes the WFDEI dataset, which is a bias-corrected ERA-Interim dataset produced a few years ago. https://agupubs.onlinelibrary.wiley.com/doi/full/10.1002/2014WR015638

[olyson]

I've incorporated the CFORCE dataset into the datm for testing. And done a one month SP test run. The forcing fields look provisionally ok in a gross sense, except for surface pressure (PBOT in the history file), which has spatial patterns that aren't consistent with the forcing files (SP in the forcing file). I think it is because the "lat" variable in the SP_*.nc forcing files is oriented north to south, which isn't consistent with the mesh file, which is oriented south to north.

[ekluzek]

I've incorporated the CFORCE dataset into the datm for testing. And done a one month SP test run. The forcing fields look provisionally ok in a gross sense, except for surface pressure (PBOT in the history file), which has spatial patterns that aren't consistent with the forcing files (SP in the forcing file). I think it is because the "lat" variable in the SP_*.nc forcing files is oriented north to south, which isn't consistent with the mesh file, which is oriented south to north.

@olyson we could either have a mesh file that reverses latitudes, or reverse the dataset. It seems to me that we should reverse the dataset as S to N is the standard in CESM. Isn't this also a problem for the Ocean people as well?

[olyson]

I'm using the same mesh for other streams, solar and precip for example, so I think it would be best to reverse the dataset. We think the Ocean people use SLP.

[dlawrenncar]

I expect that the ocean folks use SLP. It's probably worth flagging to them that we saw an issue with SP so that they can double check that there isn't a problem.

On Tue, Nov 11, 2025 at 12:05 PM Keith Oleson @.***> wrote:

olyson left a comment (ESCOMP/CTSM#3588) https://github.com/ESCOMP/CTSM/issues/3588#issuecomment-3518374812

I'm using the same mesh for other streams, solar and precip for example, so I think it would be best to reverse the dataset. I'm not sure if the Ocean people use SP or if they use SLP, I haven't checked SLP.

— Reply to this email directly, view it on GitHub https://github.com/ESCOMP/CTSM/issues/3588#issuecomment-3518374812, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFABYVDMGB5UFW765RRIVLL34IXQBAVCNFSM6AAAAACLMKZ4I6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTKMJYGM3TIOBRGI . You are receiving this because you commented.Message ID: @.***>

[olyson]

@margarita-markina has processed the SP files, thanks. PBOT now looks like I would expect. I'm continuing the 1-month run for several years (1980-1989) to compare to a CRUJRA2024 control.

[olyson]

Land diagnostics for a SP CFORCE run compared to CRUJRA2024 are here. Maybe most useful to look at the set2 contour plots for these forcing variables:

PREC, RAIN, SNOW, TBOT, WIND, THBOT, QBOT, PBOT, ZBOT, FLDS, FSDS (and the partitioning into visible, near-infrared, direct, and diffuse). Some interesting model responses in LHEAT, FSH, and FPSN (annual mean). Significant increases in LHEAT (and decreases in FSH) almost everywhere, particularly in the tropics. Some of this increase in LHEAT in the tropics seems to be due to increased canopy evaporation due to more precip. The Amazon also has higher transpiration. Lower photosynthesis in the tropics.

A note about the streams. The forcing data is hourly and the model time-step is 1/2 hourly. I've left the time interpolation for solar, precip, and the rest of the variables at "coszen", "nearest", and "linear", respectively. I think those are still the right choices for precip and the "linear" variables. I'm not sure how well "coszen" works for hourly data interpolated to 1/2 hourly. Needs to be investigated. And probably the diurnal cycle of all these variables needs to be looked at in more detail also.

[dlawrenncar]

If it would be easy, an ILAMB comparison would be interesting to see, not so much necessarily to look at the model output, but to see what the climate forcing scores look like. Even better would be a three way comparison between a CRUJRA run, a GSWP3 run, and a CFORCE run. I think we had previously seen a degradation in the forcing scores for CRUJRA.

On Thu, Nov 13, 2025 at 12:21 PM Keith Oleson @.***> wrote:

olyson left a comment (ESCOMP/CTSM#3588) https://github.com/ESCOMP/CTSM/issues/3588#issuecomment-3529350510

Land diagnostics for a SP CFORCE run compared to CRUJRA2024 are here https://webext.cgd.ucar.edu/I2000/Clm60SP_ctsm53084_1deg_ERA5CFORCE_2000/lnd/Clm60SP_ctsm53084_1deg_ERA5CFORCE_2000_1981_1989-Clm60SP_ctsm53084_1deg_CRUJRA2024_2000_1981_1989/setsIndex.html . Maybe most useful to look at the set2 contour plots for these forcing variables:

PREC, RAIN, SNOW, TBOT, WIND, THBOT, QBOT, PBOT, ZBOT, FLDS, FSDS (and the partitioning into visible, near-infrared, direct, and diffuse). Some interesting model responses in LHEAT, FSH, and FPSN (annual mean). Significant increases in LHEAT (and decreases in FSH) almost everywhere, particularly in the tropics. Some of this increase in LHEAT in the tropics seems to be due to increased canopy evaporation due to more precip. The Amazon also has higher transpiration. Lower photosynthesis in the tropics.

A note about the streams. The forcing data is hourly and the model time-step is 1/2 hourly. I've left the time interpolation for solar, precip, and the rest of the variables at "coszen", "nearest", and "linear", respectively. I think those are still the right choices for precip and the "linear" variables. I'm not sure how well "coszen" works for hourly data interpolated to 1/2 hourly. Needs to be investigated. And probably the diurnal cycle of all these variables needs to be looked at in more detail also.

— Reply to this email directly, view it on GitHub https://github.com/ESCOMP/CTSM/issues/3588#issuecomment-3529350510, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFABYVHBO5GOB67QG7EJLB334TK37AVCNFSM6AAAAACLMKZ4I6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTKMRZGM2TANJRGA . You are receiving this because you commented.Message ID: @.***>

[olyson]

I like that idea. Currently, the CFORCE data is only available for 1980-1989. I think it would be desirable to extend that through 2014, which is when the GSWP3 data ends. The ILAMB datasets that evaluate forcing extend out that far as well. @margarita-markina , would it be possible to process data out through 2014? I see some directories corresponding to those years, but don't have permissions to look at them to see if they have what we would need. In the meantime though, I could do a GSWP3 run for 1980-1989 and run ILAMB on the three simulations for that time period...if we want to proceed quickly.

[margarita-markina]

Will do! One more note: in my A-compset runs I set tintalgo = linear and offset = 0 for SWDN, because the coszen option was giving weird results (not sure yet if that’s related to the hourly forcing or something else). So you might want to double-check this on your side as well.

[olyson]

Ok, thanks, I'll do that.

[margarita-markina]

All files for 1980–2019 should now be available - please let me know if you can’t access any of them. For the wind components, some years have despiked files and others don’t. If despiked files are available for a given year, please use those; otherwise, use u_10.${year}.nc and v_10.${year}.nc.

[olyson]

I don't seem to have read access to the new directories (1990 - 2019).

[margarita-markina]

try now

[olyson]

Thanks, I can look in the directories now and can see that I seem to have read permission for the files.

[olyson]

Actually, sorry, I can't read anything beyond the 1999 directory. E.g., cd /glade/campaign/cgd/oce/people/rita/ERA5/2000 /glade/campaign/cgd/oce/people/rita/ERA5/2000: Permission denied.

[margarita-markina]

that’s odd - the permissions looked the same to me for all these directories. I’ve made another change - can you try accessing them now?

[olyson]

Yes, that is working, thanks.

[olyson]

I ran into a problem extending the CFORCE simulation past 1989. The check_for_errors subroutine in src/cpl/utils/lnd_import_export_utils.F90 is catching some negative downward solar radiation (swdn) in the /glade/campaign/cgd/oce/people/rita/ERA5/1990/swdn.1990.corrected_2000_2024_base_period.nc forcing file. They are small negative but maybe they can/should be zeroed out in the processing?

[margarita-markina]

let me look into it - are other years ok?

[olyson]

It looks like the following years also have some small negative values: 1999, 2004, 2005, 2011, 2016

[megandevlan]

A bit of a tangent, but related - are files available for DATM using the default ERA5 versus the CFORCE dataset? I'm worried about the implications of https://github.com/ESCOMP/CTSM/issues/3010, but ideally we'd like to start some ESPAT runs with ERA5 forcing first before we figure out if CFORCE is needed.

[margarita-markina]

yes, the raw ERA5 data are also in the same directories. For the ocean runs, I use the following fields: prec.${year}.nc, slp.${year}.nc, lwdn.${year}.nc, swdn.${year}.nc, q_10.${year}.nc, t_10.${year}.nc, u_10.${year}.nc, v_10.${year}.nc

I've also processed surface pressure from ERA5 so it can be used in CESM (SP_${year}_processed.nc)

For the grid setup, I’m using the following mesh files and settings: ./xmlchange OCN_DOMAIN_MESH=/glade/work/altuntas/scripts/mesh/ESMF_mesh_era5_241218_ocean.nc ./xmlchange MASK_MESH=/glade/work/altuntas/scripts/mesh/ESMF_mesh_era5_241218_ocean.nc ./xmlchange OCN_NX=1280 ./xmlchange OCN_NY=640 ./xmlchange ICE_DOMAIN_MESH=/glade/work/altuntas/scripts/mesh/ESMF_mesh_era5_241218_ocean.nc ./xmlchange ICE_NX=1280 ./xmlchange ICE_NY=640 ./xmlchange ATM_DOMAIN_MESH=/glade/work/altuntas/scripts/mesh/ESMF_mesh_era5_241218_atm.nc ./xmlchange ATM_NX=1280 ./xmlchange ATM_NY=640

And I use the daily SST/ice file (update the year range if you run a different period): ./xmlchange SSTICE_DATA_FILENAME=/glade/campaign/cgd/oce/people/rita/ERA5/sst_ice_daily.1980_1989.nc ./xmlchange SSTICE_MESH_FILENAME=/glade/work/altuntas/scripts/mesh/ESMF_mesh_era5_241218_ocean.nc

[margarita-markina]

@olyson I’ve fixed the SWDN files (both corrected and uncorrected) - the issue was due to small negative values in the original ERA5. Let me know if you spot anything else!

[olyson]

Thanks for fixing those! I'll try running again with the bias-corrected data. For the raw data, I'm having trouble reading a few files. For example,

-rw-rw----+ 1 mmarkina cgdoce 28704869798 Nov 19 17:53 1990/swdn.1990.nc -rw-rw----+ 1 mmarkina cgdoce 28704869798 Nov 19 18:14 1999/swdn.1999.nc -rw-rw----+ 1 mmarkina cgdoce 28704869798 Nov 19 18:20 2004/swdn.2004.nc ....

There are others, so maybe you could just make everything readable by "all", e.g., like this one:

-rw-r-r--+ 1 mmarkina cgdoce 28704874917 Jan 23 2025 2003/swdn.2003.nc

[margarita-markina]

done

[olyson]

An update before I leave for my normal times off + PTO (back Dec 2). My plan evolved to running 4 simulations for the overlapping available data 1980-2014 (35 years). GSWP3V1: Complete CRUJRA2024: Complete CFORCE ERA5: In queue (stuck there for a day already) Raw ERA5: In queue (ditto)

And then compare and evaluate these in ILAMB. Pending a satisfactory evaluation in ILAMB and perhaps any other Raw ERA5 evaluation @megandevlan would like to do, @megandevlan could use the Raw ERA5 for spinup. Some questions though:

1. What type of spinup is being done, do you need years other than 1980-2014? If so, are those years available @margarita-markina ?
2. I've implemented two new DATM modes so that either CFORCE ERA5 or Raw ERA5 can be requested out of the box using a compset spec. What code will be used for the Raw ERA5 spinup? My code would need to be integrated with that.

[margarita-markina]

the data for 1940-2024 is there, let me know if you need it!

[megandevlan]

Huge thanks for adding raw ERA5, @olyson! Happy to touch base in December if helpful, and really excited to look at these results. Tagging in @sglanvil as well for more info if needed!

• We're ideally looking for 1999-2022 for spinup/analysis in ESPAT, so an extension would be helpful if it's not a major lift!
• The plan is to use an older version of the model - CESM2.2.2 (easy regionally refined options). Not sure how hard it is to integrate your code with that?

[olyson]

The CFORCE ERA5 simulation is complete. I stopped the Raw ERA5 simulation because I could see it was going to run out of wall clock time. For some reason, it is about 4 times slower than the CFORCE simulation. Not sure why. The two simulations are configured the same. The datm files are the same type and appear to be the same size with the same lat/lon coordinates. The number of streams are the same also. I tried cleaning the build and rebuilt, but no effect. Need to look at the timing files. For now, I've restarted this to run in two segments.

In the meantime, I've run ILAMB on the GSWP3V1, CRUJRA2024, and CFORCE ERA5 simulations, posted below. I'll add the Raw ERA5 when it is complete.

https://webext.cgd.ucar.edu/I2000/Clm60SP_ctsm53084_1deg_ERA5CFORCE_2000/lnd/_build_CFORCE/

Sounds like files are available through 2022, so should be no problem to do that spinup. It should be fairly straightforward to implement my code in CESM2.2.2...