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

question related to hist_type1d_pertape

yangx2

xinyi yang
Member
Hi everyone,
If I want to get one variable (e.g. H2OSOI; monthly ) from CLM4.0 output in vector format (column, levtot), I assume that I need to add those lines in usr_namelist_clm:
++++++++++++++++++++++++++++++
hist_fincl2 = 'H2OSOI'
hist_dov2xy = .true., .false.
hist_type1d_pertape = ' ', 'COLS'
hist_nhtfrq = 0, 0
++++++++++++++++++++++++++++++
Am I understanding right? Thanks in advance!
Best,
Skyler
 

yangx2

xinyi yang
Member
That should work.
Hi Keith,
Thanks for the help! It did work for transiting "message" to $RUNID/lnd_in. But I got other errors. I am running CESM1_2_2 on Cheyenne. Here is my case:
I successfully run a case (compset='B1850C5CN', res='f19_g16',) for 24 months without changing any variables on namelist. Then I wan to output some variables (e.g. H2OSOI, SOILLIQ and so or) monthly and daily in vector format (column, levtot) rather than grid format (lat,lon), therefore I add those lines shown below on ussr_namelist_clm:
=======================
hist_fincl2 = 'H2OSOI', 'SOILLIQ', 'SOILICE','SOILWATER_10CM'
hist_fincl3 = 'H2OSOI', 'SOILLIQ', 'SOILICE'
hist_dov2xy = .true., .false., .false.
hist_type1d_pertape = ' ', 'COLS', 'COLS'
hist_mfilt = 1,30,365
hist_nhtfrq = 0,-24,-24
=======================
Then I executed ./preview_namelists to update $RUNID/lnd_in. It worked.
Below shows the commands I used:
=======================
./xmlchange -file env_run.xml -id STOP_OPTION -val 'nmonths'
./xmlchange -file env_run.xml -id STOP_N -val '12'
./xmlchange -file env_run.xml -id REST_N -val '12'
./xmlchange CONTINUE_RUN=TRUE
./${CASE}.submit
=======================
I got errors shown in cesm.log:
----------------------------------------------------------------------------
1: Opened existing file
1: /glade/p/cesmdata/cseg/inputdata/lnd/clm2/snicardata/snicar_drdt_bst_fit_60_c07
1: 0416.nc 1441792
1: Opened existing file PI-control.clm2.r.0003-01-01-00000.nc 1441792
1: Opened existing file PI-control.clm2.r.0003-01-01-00000.nc 1441792
1: ntapes = 3 ntapes_onfile = 1
1: ENDRUN:
1: hist_restart_ncd ERROR: number of ntapes different than on restart file!, you
1: can NOT change history options on restart!
9: ntapes = 3 ntapes_onfile = 1
9: ENDRUN:
...
105: hist_restart_ncd ERROR: number of ntapes different than on restart file!, you
105: can NOT change history options on restart!
----------------------------------------------------------------------------

Any idea which step I did was wrong? Thanks in advance!
Best,
Skylar
 

oleson

Keith Oleson
CSEG and Liaisons
Staff member
As the error message notes, you can't change history options on a restart. You would need to do a branch run instead by setting the RUN_TYPE variable in env_run.xml. And by setting CONTINUE_RUN to FALSE.
There is an explanation of RUN_TYPE in env_run.xml in newer versions of CESM:

Determines the model run initialization type.
This setting is only important for the initial run of a production run when the
CONTINUE_RUN variable is set to FALSE. After the initial run, the CONTINUE_RUN
variable is set to TRUE, and the model restarts exactly using input
files in a case, date, and bit-for-bit continuous fashion.
Default: startup.
-- In a startup run (the default), all components are initialized
using baseline states. These baseline states are set independently by
each component and can include the use of restart files, initial
files, external observed data files, or internal initialization (i.e.,
a cold start). In a startup run, the coupler sends the start date to
the components at initialization. In addition, the coupler does not
need an input data file. In a startup initialization, the ocean model
does not start until the second ocean coupling (normally the second
day).
-- In a branch run, all components are initialized using a consistent
set of restart files from a previous run (determined by the
RUN_REFCASE and RUN_REFDATE variables in env_run.xml). The case name
is generally changed for a branch run, although it does not have to
be. In a branch run, setting RUN_STARTDATE is ignored because the
model components obtain the start date from their restart datasets.
Therefore, the start date cannot be changed for a branch run. This is
the same mechanism that is used for performing a restart run (where
CONTINUE_RUN is set to TRUE in the env_run.xml) Branch runs are
typically used when sensitivity or parameter studies are required, or
when settings for history file output streams need to be modified
while still maintaining bit-for-bit reproducibility. Under this
scenario, the new case is able to produce an exact bit-for-bit restart
in the same manner as a continuation run IF no source code or
component namelist inputs are modified. All models use restart files
to perform this type of run. RUN_REFCASE and RUN_REFDATE are required
for branch runs.
To set up a branch run, locate the restart tar file or restart
directory for RUN_REFCASE and RUN_REFDATE from a previous run, then
place those files in the RUNDIR directory.
--- In a hybrid run the model is initialized as a startup, BUT uses
initialization datasets FROM A PREVIOUS case. This
is somewhat analogous to a branch run with relaxed restart
constraints. A hybrid run allows users to bring together combinations
of initial/restart files from a previous case (specified by
RUN_REFCASE) at a given model output date (specified by
RUN_REFDATE). Unlike a branch run, the starting date of a hybrid run
(specified by RUN_STARTDATE) can be modified relative to the reference
case. In a hybrid run, the model does not continue in a bit-for-bit
fashion with respect to the reference case. The resulting climate,
however, should be continuous provided that no model source code or
namelists are changed in the hybrid run. In a hybrid initialization,
the ocean model does not start until the second ocean coupling
(normally the second day), and the coupler does a cold start without
a restart file.
 
Top