Example, user_nl_datm_streams for TRENDY.2020 simulation for NUOPC coupler

[ekluzek]

The previous years TRENDY simulations were done using the MCT coupler and hence the user_datm.streams.txt.* files that were used no longer function for the NUOPC coupler. As such we need to develop new user_nl_datm_streams example files that can be used for this type of purpose.

[ekluzek]

I have a sample that creates the namelist and streams files.

It relies on the following setting of DIN_LOC_ROOT_CLMFORC

./xmlchange --force DIN_LOC_ROOT_CLMFORC="/glade/p/cgd/tss/people/dll/TRENDY2020_Forcing"

user_nl_datm_streams.txt

An example from the file for CO2 is like this:

   ! CO2 time series for TRENDY 1700 to 2020
   co2tseries.20tr:year_first = 1700
   co2tseries.20tr:year_align = 1700
   co2tseries.20tr:year_last  = 2020
   co2tseries.20tr:datafiles = $DIN_LOC_ROOT_CLMFORC/fco2_datm_global_simyr_1750-2014_CMIP6_c180929.nc

[ekluzek]

One issue with the above is that previously for TRENDY we used a domain file that had a land-mask. The mesh standard mesh file being used here is 1 everywhere.

The other issue I have with actually running the above case is that there are some NetCDF4 files somewhere in the list that the model can't read.

[ekluzek]

The CO2 file is fine, but it looks like the forcing files are in NetCDF-4 format and will need to be converted.

[wwieder]

thanks for starting this issue, @ekluzek . I wonder if we want to make these CRU-JRA55 data available as a compset for more regular model testing? It seems like the only reanalysis that's being updated.

[ekluzek]

Yes, let's talk more Thursday. When they update do they add the latest year to the end of the series, or do they redo the entire sequence? The first would be more sustainable for us. The second might mean we don't update every year, but maybe less often.

[dlawrenncar]

I think it varies. Sometimes they just add a year, but often, e.g., when they find a bug or some other limitation, they update the entire record.

…

On Mon, Apr 11, 2022 at 8:51 AM Erik Kluzek ***@***.***> wrote: Yes, let's talk more Thursday. When they update do they add the latest year to the end of the series, or do they redo the entire sequence? The first would be more sustainable for us. The second might mean we don't update every year, but maybe less often. — Reply to this email directly, view it on GitHub <#1701 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFABYVAQDVLVWY43MK3OMW3VEQ4ANANCNFSM5S7YPMUA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[dlawrenncar]

@olyson converted some files for testing. There are ten years here (1901-1910):
/glade/p/cgd/tss/people/oleson/TRENDY2020_Forcing/three_stream_files

These were converted from: /glade/p/cgd/tss/people/dll/TRENDY2020_Forcing/three_stream_files/

[dlawrenncar]

@ekluzek I tried to run using the user_datm_streams from above, and the converted files, but am getting the following error in the cesm log file.

26: ERROR:
26: (datm_init_pointers): ERROR: wind and tbot must be in streams for CLMNCEP

WIND and TBOT which point to wind and tbot are on the files that Keith converted, so I'm not sure where the error is coming from. My case is here, which is running from the most modern ctsm.

/glade/u/home/dlawren/cases/clm5sp_hd_crujra2020_createICs

[olyson]

@ekluzek can confirm but I think the stream variable names have changed:

swdndr -> Faxa_swdndr
swdndf -> Faxa_swdndf
precn -> Faxa_precn
tbot -> Sa_tbot
wind -> Sa_wind
shum -> Sa_shum
pbot -> Sa_pbot

[ekluzek]

@olyson is correct. Actually, I setup the names according to the previous example MCT for 2020. And there some of the names of the variables on the files were different as well as the stream variable names. The variable names and stream names are pairs in the "<datavars>" element. The names on the files are on the left, and the names within CDEPS:datm are on the right. From looking at both the default names and the names on the files, the default values for datavars looks correct. So actually what you should do is remove all of the settings for datavars in the user_nl_datm_streams file. It looks like that should work (at least get you to the next problem).

[dlawrenncar]

OK. Tried removing the datavars from user_nl_datm_streams and am now getting more standard errors on the first timestep.

g, newsum_lwrad_g, sum_wts_g, forc_lwrad_g: 4
3.970527130136304E+112 0.990000000000000 4.010633464784145E+112
iam = 0: local gridcell index = 4
iam = 0: global gridcell index = 5470
iam = 0: gridcell longitude = 214.7500000
iam = 0: gridcell latitude = -86.2500000
ENDRUN:
ERROR:
ERROR: Energy conservation error downscaling longwaveERROR in atm2lndMod.F90 a
t line 561

Note that I also tried running at the more standard f09 resolution, because I know that we have had problems with the 0.5degree resolution before (though using out of box CRUNCEP forcing, it ran fine at this resolution). With the f09 resolution, I got a column-level water balance error instead. Maybe the mesh file being 1 everywhere is a problem, especially if the actual realistic data coverage in the CRUJRA forcing is not complete, which I think it is not.