Scheduled Downtime
On Tuesday 24 October 2023 @ 5pm MT the forums will be in read only mode in preparation for the downtime. On Wednesday 25 October 2023 @ 5am MT, this website will be down for maintenance and expected to return online later in the morning.
Normal Operations
The forums are back online with normal operations. If you notice any issues or errors related to the forums, please reach out to help@ucar.edu

Atm forcing data during 2015-2019

KeerZ

Member
Dear All,

I know that the atm forcing data for the present climate is from 1990-2014, but I am wondering whether the atm forcing data from 2015-2019 are available somewhere? (or has anyone tried to construct the forcing data for the latest years?)

Thank you!
 

oleson

Keith Oleson
CSEG and Liaisons
Staff member
It's not clear when or if the GSWP3 atm forcing data will be updated for more recent years. You could check with the dataset creator: Hyungjun Kim, hjkim@iis.u-tokyo.ac.jp

An alternative forcing dataset is CRUJRA, which is through 2017:

/glade/p/cgd/tss/CTSM_datm_forcing_data/atm_forcing.datm7.CRUJRA.0.5d.v1.c190604
 

KeerZ

Member
It's not clear when or if the GSWP3 atm forcing data will be updated for more recent years. You could check with the dataset creator: Hyungjun Kim, hjkim@iis.u-tokyo.ac.jp

An alternative forcing dataset is CRUJRA, which is through 2017:

/glade/p/cgd/tss/CTSM_datm_forcing_data/atm_forcing.datm7.CRUJRA.0.5d.v1.c190604
OK. Thanks for the information!
 

oleson

Keith Oleson
CSEG and Liaisons
Staff member
The CRUJRA dataset has been updated through 2019 and is here:

/glade/p/cgd/tss/people/dll/TRENDY2020_Forcing/three_stream_files
 

KeerZ

Member
The CRUJRA dataset has been updated through 2019 and is here:

/glade/p/cgd/tss/people/dll/TRENDY2020_Forcing/three_stream_files
Hi, Keith! I configured a Case using I2000Clm50BgcCruGs compset. For this case, I changed the datam stream file by creating user_datm.streams.txt.CLMCRUNCEPv7.Precip/ Solar/ TPQW in my Case directory. In the user_ stream files, I pointed to /glade/p/cgd/tss/people/dll/TRENDY2020_Forcing/three_stream_files.

Then I specified DATM_CLMNCEP_YR_ALIGN=2000, DATM_CLMNCEP_YR_START=2000, DATM_CLMNCEP_YR_END=2019 since I want the forcing data to loop through 2000 to 2019. However, after I run the case for 3 months, I found that the atm forcing uses 2010 forcing data instead of 2000 forcing data.

It seems that I successfully used the TRENDY2020_Forcing as my atm forcing but failed to change the start year of the forcing data. My case can be found at /glade/u/home/keerzhang/cases/i.e20.I2000.f02_g16.URBAN_CRUtest. Can you tell me what's wrong here? Thank you!
 

oleson

Keith Oleson
CSEG and Liaisons
Staff member
Your "RUN_STARTDATE" is 0001. If you want the model start year to line up with the first year of atmospheric forcing, then you would need to set DATM_CLMNCEP_YR_ALIGN=1, not 2000.
Let us know if that doesn't work.
 

KeerZ

Member
Your "RUN_STARTDATE" is 0001. If you want the model start year to line up with the first year of atmospheric forcing, then you would need to set DATM_CLMNCEP_YR_ALIGN=1, not 2000.
Let us know if that doesn't work.
Thanks for pointing that out. I am running a branch simulation with RUN_REFDATE=0090-01-01, and the RUN_STARTDATE was ignored. So I guess I should use DATM_CLMNCEP_YR_ALIGN=90 in this case. And it works! Now the first year atmospheric forcing is the 2000 forcing data.

I am a little bit confused about how to specify DATM_CLMNCEP_YR_ALIGN. In CLM5 user's guide, DATM_CLMNCEP_YR_START and DATM_CLMNCEP_YR_END determine the range of years to cycle the atmospheric data over, and DATM_CLMNCEP_YR_ALIGN determines which year in that range of years the simulation will start with. However, it seems that sometimes DATM_CLMNCEP_YR_ALIGN=certain year after simulation starting (e.g. 90 in my case) and sometimes DATM_CLMNCEP_YR_ALIGN= the 'real' year (e.g. 2009).

Is it correct to say DATM_CLMNCEP_YR_ALIGN should always be consistent with the RUN_STARTDATE (for a startup simulation) or RUN_REFDATE (for a branch simulation) of my case?
 

oleson

Keith Oleson
CSEG and Liaisons
Staff member
Well not necessarily always.
The datm guide here explains two common cases (this is for CPLHIST but CLMNCEP operates the same way):


DATM_CPLHIST_YR_ALIGN-999integerrun_component_datmenv_run.xml
  • Valid Values []
  • Description Simulation year corresponding to DATM_CPLHIST_YR_START (only used
    when DATM_MODE is CPLHIST). A common usage is to set this to
    RUN_STARTDATE. With this setting, the forcing in the first year of
    the run will be the forcing of year DATM_CPLHIST_YR_START. Another
    use case is to align the calendar of transient forcing with the
    model calendar. For example, setting
    DATM_CPLHIST_YR_ALIGN=DATM_CPLHIST_YR_START will lead to the
    forcing calendar being the same as the model calendar. The forcing
    for a given model year would be the forcing of the same year. This
    would be appropriate in transient runs where the model calendar is
    setup to span the same year range as the forcing data.


Another case would be where one doesn't have forcing data for the full duration of a desired transient run.
For example, our land-only transient simulations run 1850-2014, but we only have forcing data for 1901-2014.
So, we've decided we want to use the first 20 years of our forcing data (1901-1920) for simulation years 1850-1900. Then we want to use our 1901-2014 forcing data for simulation years 1901-2014.
For the first part of the simulation we set:

RUN_STARTDATE=1850-01-01
DATM_CLMNCEP_YR_ALIGN=1901
DATM_CLMNCEP_YR_START=1901
DATM_CLMNCEP_YR_END=1920

So here we are telling the datm that we want model year 1901 to (eventually) line up with year 1901 of the forcing data.
The datm will actually figure out that it needs to start with 1910 forcing data for the first year of simulation (1850), eg.,

Model year 1850 1859 1860 1861 1881 1901
Atm year 1910 1919 1920 1901 1901 1901

We run the simulation through the end of 1900 with this setup, then we switch to using atm years that correspond to model years for simulation years 1901-2014. RUN_STARTDATE stays the same because we are doing a restart (CONTINUE_RUN - True).

DATM_CLMNCEP_YR_ALIGN=1901
DATM_CLMNCEP_YR_START=1901
DATM_CLMNCEP_YR_END=2014
 

KeerZ

Member
Well not necessarily always.
The datm guide here explains two common cases (this is for CPLHIST but CLMNCEP operates the same way):


DATM_CPLHIST_YR_ALIGN-999integerrun_component_datmenv_run.xml
  • Valid Values []
  • Description Simulation year corresponding to DATM_CPLHIST_YR_START (only used
    when DATM_MODE is CPLHIST). A common usage is to set this to
    RUN_STARTDATE. With this setting, the forcing in the first year of
    the run will be the forcing of year DATM_CPLHIST_YR_START. Another
    use case is to align the calendar of transient forcing with the
    model calendar. For example, setting
    DATM_CPLHIST_YR_ALIGN=DATM_CPLHIST_YR_START will lead to the
    forcing calendar being the same as the model calendar. The forcing
    for a given model year would be the forcing of the same year. This
    would be appropriate in transient runs where the model calendar is
    setup to span the same year range as the forcing data.


Another case would be where one doesn't have forcing data for the full duration of a desired transient run.
For example, our land-only transient simulations run 1850-2014, but we only have forcing data for 1901-2014.
So, we've decided we want to use the first 20 years of our forcing data (1901-1920) for simulation years 1850-1900. Then we want to use our 1901-2014 forcing data for simulation years 1901-2014.
For the first part of the simulation we set:

RUN_STARTDATE=1850-01-01
DATM_CLMNCEP_YR_ALIGN=1901
DATM_CLMNCEP_YR_START=1901
DATM_CLMNCEP_YR_END=1920

So here we are telling the datm that we want model year 1901 to (eventually) line up with year 1901 of the forcing data.
The datm will actually figure out that it needs to start with 1910 forcing data for the first year of simulation (1850), eg.,

Model year 1850 1859 1860 1861 1881 1901
Atm year 1910 1919 1920 1901 1901 1901

We run the simulation through the end of 1900 with this setup, then we switch to using atm years that correspond to model years for simulation years 1901-2014. RUN_STARTDATE stays the same because we are doing a restart (CONTINUE_RUN - True).

DATM_CLMNCEP_YR_ALIGN=1901
DATM_CLMNCEP_YR_START=1901
DATM_CLMNCEP_YR_END=2014
Thanks a lot. It is much easier for me to understand now.
 

KeerZ

Member
The CRUJRA dataset has been updated through 2019 and is here:

/glade/p/cgd/tss/people/dll/TRENDY2020_Forcing/three_stream_files
Hello Keith. I have a small follow up question about using this forcing data.

As I checked the TRENDY2020_Forcing, I found that it excluded atm forcing in Antarctica (QBOT graph attached). Therefore, in a simulation using I2000Clm50SpGs compset driven by TRENDY2020_Forcing, I observed 'erroneous' results (e.g. the TSA graph attached) in the Antarctica continent.

Since I don't need to use any results from the polar regions, is it correct to say the absence of Antarctica atm forcings will have no impact on the results of other non-polar regions? Moreover, I wonder if there is any way to turn off model calculation on Antarctica so that we can get rid of the problem? Thank you :)
 

Attachments

  • QBOT_in_clmforc.TRENDY.c2020.0.5x0.5.TPQWL.2010.png
    QBOT_in_clmforc.TRENDY.c2020.0.5x0.5.TPQWL.2010.png
    261.7 KB · Views: 4
  • TSA_in_i.e20.I2000.f02_g16.URBAN_CRU09_15.clm2.h0.png
    TSA_in_i.e20.I2000.f02_g16.URBAN_CRU09_15.clm2.h0.png
    256.9 KB · Views: 4

oleson

Keith Oleson
CSEG and Liaisons
Staff member
Yes to your first question.
I think you can avoid the calculations over Antarctica by modifying the domain file pointed to by fatmlndfrc in your lnd_in.
You'd have to set the mask and probably frac fields in that file to zero over Antarctica.
 
Top