ESCOMP
Update to CRU-JRA as default datm inputs for CTSM development
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 #1701,
- Roughness calculation #1596, and
- Mesh creation #1677
We can have discussion on this thread, but I also suggest we discuss at an upcoming Thursday science meeting (maybe next week)?
@djk2120 noted that the forcing is available here: /glade/campaign/asp/djk2120/TRENDY2022/forcing
latest TRENDY from GCB-2021: /glade/campaign/asp/djk2120/TRENDY2022/S3/lnd
based on: branch_tags/TRENDY-2019.n05_ctsm1.0.dev056
@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?
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
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
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
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.
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.
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.
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 https://github.com/ESCOMP/CTSM/issues/1895#issuecomment-1405445843, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFABYVDFX7HTRTO43SZTQC3WULBA5ANCNFSM6AAAAAAR43R2VE . You are receiving this because you are subscribed to this thread.Message ID: @.***>
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 https://github.com/ESCOMP/CTSM/issues/1895#issuecomment-1405445843, 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 https://github.com/ESCOMP/CTSM/issues/1895#issuecomment-1405472717, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGRN57APGD6SBXQLBTWVRXTWULDPRANCNFSM6AAAAAAR43R2VE . You are receiving this because you were mentioned.Message ID: @.***>
@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 🫤
Also we should soon (before /glade's scrubber gets us) move the datm files and corresponding mesh file to /glade/campaign/.../atm/datm7/...
I'm adding a checkbox in issue #2675.
