Update to CRU-JRA as default datm inputs for CTSM development

[wwieder]

Should we consider updating to CRUJRA as our default forcing for CTSM development?

Brief +/- here:

• Positive here are that these are the input data used for TRENDY simulations and updated annually (and currently available through 2021, vs. GSWP3, which ends in 2014).
• Negatives are that each year it seems like the dataset is slightly modified. We may not what to update our input data this often.

Considerations:

• We need some assessment of what results look like with these simulations, but @djk2120 has CLM50 runs for TRENDY;
• We should update to CTSM5.1 / 5.2 branch and spin up new initial conditions, which would be helpful to discuss with @olyson and the rest of the LMWG/CLM team.
• This also will require developing some infrastructure / storage to support a new input dataset that @ekluzek can inform.
• @swensosc also noted CRU-JRA is 6 hourly data, whereas GSWP3 is 3 hr resolution.
• @olyson noted there's not data for Antarctica with CRU-JRA, complicating evaluation.

There have been a number of conversations on this related to:

• TRENDY simulations Example, user_nl_datm_streams for TRENDY.2020 simulation for NUOPC coupler #1701,
• Roughness calculation Surface roughness modifications #1596, and
• Mesh creation Modify mesh mask with new mesh_mask_modifier tool #1677

We can have discussion on this thread, but I also suggest we discuss at an upcoming Thursday science meeting (maybe next week)?

---

Updated Nov 20, 2024

In the absence of other options of datm data to bring us through present day, we're calibrating CLM6 with CRU-JRA forcing. A few notes related to outstanding tasks

Definition of done

• Share @adrifoster and @swensosc's script that takes raw CRUJRA data to make three stream datm files. Initial thoughts from @wwieder and @slevis-lmwg that this can go in /tools/contrib/.
• Fill data over Antarctica with GSPW3-forcing
  • Data available at /glade/derecho/scratch/wwieder/TRENDY2024/inputs/three_stream
• Share script that appends Antartica data (currently on wwieder's repo). Initial thoughts from @wwieder and @slevis-lmwg that this can go in /tools/contrib/.
• load CRUJRA datm and mesh files appropriately onto input data (also a check box in Ability to run TRENDY type simulations on mainline CTSM  #2675).
• @slevis-lmwg set up CLM5 and CLM6 compset so that users get datm.streams set up correctly out of the box
  • Include necessary mods to cdeps and/or other submodules.
• @slevis-lmwg ./rimport the files
• modify subset_data for CRUJRA (currently hardcoded for GSWP3 and rather brittle).
  • @wwieder has done this in a hacky way, just replacing GSWP3 with CRUJRA in the same brittle way on the mimics_AAtest_ctsm5.2.028 branch I have on derecho.

[wwieder]

@djk2120 noted that the forcing is available here:
/glade/campaign/asp/djk2120/TRENDY2022/forcing

[djk2120]

latest TRENDY from GCB-2021:
/glade/campaign/asp/djk2120/TRENDY2022/S3/lnd

based on:
branch_tags/TRENDY-2019.n05_ctsm1.0.dev056

[wwieder]

@olyson can you run diagnostics (and ILAMB) on these results? Does it make the most sense to compare them with results from the CLM5.0-GWSP3 runs that were done for the CLM5 release?

[olyson]

Either that or the more recent CLM5 simulation I did with the PPE tag: cesm2_3_alpha02c_PPE.n08_ctsm5.1.dev030

for our comparison with "CTSM5.1":

https://github.com/ESCOMP/CTSM/wiki/CLM5-CTSM5.1-Simulations

[olyson]

Either way, I'll need permissions set on Daniel's directory to at least be able to read/copy the files on campaign store. Currently they are set to "asp" group which I don't have permissions for.

drwxr-s---+ 11 djk2120 asp 4096 Oct 12 11:33 TRENDY2022

[wwieder]

Yep the CTSM5.1.dev030 tag is also a good candidate, Keith. Dealers choice. Again, our main goal here will be to start learning big difference in the forcing data and what differences we may expect at initialization and in historical trajectories. Down the road we'll do a clean run with a modern tag and both forcing datasets assuming there's no obvious flaws in CRU-JRA

[olyson]

There are standard diagnostics here.
And ILAMB results here.
Having run those and looking at some plots I realize now that this comparison isn't going to be very useful. Mainly because CRUJRA doesn't have data over Antarctica (consequently the datm interpolates data from more northern latitudes), so CRUJRA has much poorer scores than GSWP3V1 in ILAMB, and the contour plots in the standard diagnostics have color bar scalings that wash out differences that are not over Antarctica.
Maybe some of the northern hemisphere trend plots are useful.

[wwieder]

I've learned that JRA is no longer going to be continue / supported, which makes me think that CRU-JRA, as used in TRENDY will be of limited utility moving forward. The need for updated datm data is going to be a need for multiple CESM communities (ocean and atm use JRA for initialization in the ESPWG). At this point I suggest we wait to see what the TRENDY migrates to or consider a larger effort to generate these input data. @billsacks mentioned that Kevin R in DART suggested they may be a data product that could serve this need.

[klindsay28]

FYI, with the upcoming stoppage in JRA support, the ocean community is also faced with deciding how to move forward. My understanding, based on conversations w/ Gokhan Danabasoglu, is that the ocean community is leaning towards using ERA5 from ECMWF. The forcing spans 1940 to present day, and ECMWF seems committed to updating it. I don't know if this forcing meets the needs for CTSM/CLM. It seems prudent for conversations within CESM on moving forward to include folks from both the LMWG and OMWG, to ensure coordination, where it is possible.

[dlawrenncar]

I was going to suggest the same thing. It would be great if we could create something that would be applicable for both ocean and land groups. 1940 is not as early as we would like, but I wonder if that limitation might be offset by having a routinely updatable dataset to use.

…

On Thu, Jan 26, 2023 at 11:46 AM Keith Lindsay ***@***.***> wrote: FYI, with the upcoming stoppage in JRA support, the ocean community is also faced with deciding how to move forward. My understanding, based on conversations w/ Gokhan Danabasoglu, is that the ocean community is leaning towards using ERA5 from ECMWF. The forcing spans 1940 to present day, and ECMWF seems committed to updating it. I don't know if this forcing meets the needs for CTSM/CLM. It seems prudent for conversations within CESM on moving forward to include folks from both the LMWG and OMWG, to ensure coordination, where it is possible. — Reply to this email directly, view it on GitHub <#1895 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFABYVDFX7HTRTO43SZTQC3WULBA5ANCNFSM6AAAAAAR43R2VE> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[swensosc]

ecmwf also has a few products that go back to 1900: https://www.ecmwf.int/en/forecasts/datasets/browse-reanalysis-datasets It seems like we could splice together one of those with the newer updated data. Or maybe dart could be used to assimilate one into the other to synthesize them. On Thu, Jan 26, 2023 at 12:07 PM David Lawrence ***@***.***> wrote:

…

I was going to suggest the same thing. It would be great if we could create something that would be applicable for both ocean and land groups. 1940 is not as early as we would like, but I wonder if that limitation might be offset by having a routinely updatable dataset to use. On Thu, Jan 26, 2023 at 11:46 AM Keith Lindsay ***@***.***> wrote: > FYI, with the upcoming stoppage in JRA support, the ocean community is > also faced with deciding how to move forward. My understanding, based on > conversations w/ Gokhan Danabasoglu, is that the ocean community is leaning > towards using ERA5 from ECMWF. The forcing spans 1940 to present day, and > ECMWF seems committed to updating it. I don't know if this forcing meets > the needs for CTSM/CLM. It seems prudent for conversations within CESM on > moving forward to include folks from both the LMWG and OMWG, to ensure > coordination, where it is possible. > > — > Reply to this email directly, view it on GitHub > <#1895 (comment)>, or > unsubscribe > < https://github.com/notifications/unsubscribe-auth/AFABYVDFX7HTRTO43SZTQC3WULBA5ANCNFSM6AAAAAAR43R2VE > > . > You are receiving this because you are subscribed to this thread.Message > ID: ***@***.***> > — Reply to this email directly, view it on GitHub <#1895 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGRN57APGD6SBXQLBTWVRXTWULDPRANCNFSM6AAAAAAR43R2VE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[wwieder]

@adrifoster created CRUJRAv2.5 data for use in the TRENDY 2024 simulations.
/glade/campaign/cgd/tss/projects/TRENDY2024/inputs/three_stream/

These annual files, 1901-2023, are at 0.5 degree, 6 hr resolution but are still missing data over Antarctica. This is OK for running I cases, but it is suboptimal for generating initial conditions for use in B and F cases (#2403).

I updated these files pasting in data south of 60S from GSWP3 (also 0.5 resolution, but every 3 hours). For now I've only made 20 years of data (1901-1920). New data are here /glade/derecho/scratch/wwieder/TRENDY2024/inputs/three_stream/, and I'll also put them on the CGD machines in
/project/tss/TRENDY2024/inputs/three_stream

Code is on github.
At some point it would be helpful for someone to have a look at the script and files to see if this is working correctly. We can also start generating new 5.3 initial conditions files (with Li2024 fire turned on with the f09 and ne30 grids).

If these look OK we can extend the approach for all CRUJRAv2.5 data, although my script is kind of slow (and worse wit Dask), it also overloads memory on the TPQWL files 🫤

[slevis-lmwg]

Also we should soon (before /glade's scrubber gets us) move the datm and mesh files from /glade/derecho/scratch/wwieder/TRENDY2024 to /glade/campaign/cesm/cesmdata/inputdata/atm/datm7/atm_forcing.datm7.CRUJRA.0.5d.c2024/TRENDY2024

I'm adding a checkbox in issue #2675.

UPDATE: done

[slevis-lmwg]

In the context of
NCAR/cesm_dev#26 and NCAR/LMWG_dev#75
@wwieder @linniahawkins @dlawrenncar @slevis-lmwg
discussed (on 2024/12/16) whether it still makes sense to make CRU-JRA the default due to its high humidity values.

[slevis-lmwg]

Note to self:
Using git grep -i gswp and git grep -i cruv7 to find all the references to current defaults.

[slevis-lmwg]

Seeking feedback
I will name the new default "CRUJRA" but do we want a version associated with the name? In the past we have included version numbers, such as CRUv7 and GSWP3v1. For the new default I see two version label options:

• v2.5 (listed on the files)
• 2024 (listed on the atm_forcing directory)

[ekluzek]

@slevis-lmwg I think we should call it CRUJRA2024 for the long name. You could add dashes or periods or something in there to make it easier to read.

[wwieder]

I agree we need something for the version of this dataset. @ekluzek's suggestion makes sense, especially if it's effectively a new dataset for each TRENDY edition. Do they ever just append the version number with an additional year? Maybe @adrifoster or @djk2120 can weigh in here?