BGC -cn or -fates spinup problem
- Thread starter umair@skku_edu
- Start date
Yes, I found spinup_state=0 in lnd.log. this is confusing me. I thought restarting the file would hold the CONTINUE_RUN of the branch, but I can't do it.
Thanks for reply. I got the spinup_state = 2,too. But I use this restart file to CONTINUE_RUN, I got the same erro like
"
Error in entering/exiting spinup - should occur only when nstep = 1ERROR in So
ilBiogeochemNitrogenStateType.F90 at line 622
"
I checked the CONTINUE_RUN and is FASLE. I read the answer that you reply to umair@skku_edu. I check the setting for the CONTINUE_RUN as you mentioned in the post. It doesn't work...
But I change the RUN_TYPE=hybrid. The model run, now. So,I would also like to know if there is a difference in the output between RUN_TYPE=branch and RUN_TYPE=hybrid.
There is a description in the env_run.xml in your case directory:
<group id="run_begin_stop_restart">
<entry id="RUN_TYPE" value="startup">
<type>char</type>
<valid_values>startup,hybrid,branch</valid_values>
<desc>
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.
</desc>
</entry>
<group id="run_begin_stop_restart">
<entry id="RUN_TYPE" value="startup">
<type>char</type>
<valid_values>startup,hybrid,branch</valid_values>
<desc>
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.
</desc>
</entry>
It see lik the output of hybrid and the output of branch will get same result.
Now, I got some trouble. I used the hybrid to CONTINUE_RUN and I change the CONTINUE_RUN=TRUE. But I got the message from the cesm.log.
I guessing the hybrid to start model that may cause the modle can't CONTINUE_RUN? If I want to continue calculate my case, how can I set the model when I use the RUN_TYPE=hybrid.
I guessing the hybrid to start model that may cause the modle can't CONTINUE_RUN? If I want to continue calculate my case, how can I set the model when I use the RUN_TYPE=hybrid.
I found my restart files always keep spinup_state =2 in this case. I guess that's the problem. The spinup_state=2 maybe means the spinup isn't over yet(I checked other case's restart files and can't find this variable.Maybe when the spinup done,the variable will be removed). So, how can I continue run my spinup task? or just rerun spinup task?
Dear oleson
I found my restart files always keep spinup_state =2 in this case. I guess that's the problem. The spinup_state=2 maybe means the spinup isn't over yet(I checked other case's restart files and can't find this variable.Maybe when the spinup done,the variable will be removed). So, how can I continue run my spinup task and make the spinup_state to be corrected? or just rerun spinup task?
PLUS: My spinup task interrupted for a while, I set the CONTINUE_RUN=TRUE for the spinup task. Does this behavior make spinu_state wrong and always keep 2? Could you tell me the meaning of number of spinup_state ?
Thanks a lot for your kindness help!
I found my restart files always keep spinup_state =2 in this case. I guess that's the problem. The spinup_state=2 maybe means the spinup isn't over yet(I checked other case's restart files and can't find this variable.Maybe when the spinup done,the variable will be removed). So, how can I continue run my spinup task and make the spinup_state to be corrected? or just rerun spinup task?
PLUS: My spinup task interrupted for a while, I set the CONTINUE_RUN=TRUE for the spinup task. Does this behavior make spinu_state wrong and always keep 2? Could you tell me the meaning of number of spinup_state ?
Thanks a lot for your kindness help!
If you want to transition from an AD case to a post-AD case, then you will start your post-AD case with a restart file from the end of the AD case. That restart file will have spinup_state=2 encoded on it. That indicates that the restart file is from an AD case. This is fine. Your post-AD case should be setup with CONTINUE_RUN=FALSE and RUN_TYPE=startup or hybrid, and with CLM_ACCELERATED_SPINUP=FALSE. That case will have spinup_state=0 in the lnd_in file indicating that the run will be in "normal" mode.
The model will read in the restart file and take the model out of AD spinup mode and run in normal mode. Restarts generated by the model in this run will have spinup_state=0 encoded in it.
The model will read in the restart file and take the model out of AD spinup mode and run in normal mode. Restarts generated by the model in this run will have spinup_state=0 encoded in it.
Thank you!@oleson. Here is my question. I setup two cases by using the RUN_TYPE=startup or hybrid.(you can see my action in this post).
I output the TSA for RUN_TYPE=startup or hybrid. I get a very big swing and I find this very strange.
Below is a comparison of temperatures at the same location between my case with the surfdat modification and the case without any modification, and you can see that there is a lot of volatility between them.(Note:In this case,I use RUN_TYPE=hybrid）
But, I setup other case by set RUN_TYPE=branch. I got a comparative change of very little difference in temperature, this is what we expected.
Both cases are modifications of the surfdat for parts of the region. it is clear that it is difficult for land use changes alone to lead to large temperature oscillations. My guess is that it could be due to differences in RUN_TYPE settings. This is also reflected in the fact that I set the RUN_TYPE to startup, which also has a large temperature change.
I checked the lnd_in and lnd.log. The fsurdat modification files got used in each case. I think the fsurdat modification can't change the temperature so huge. The result of RUN_TYPE=brach is reasonable.
This model should also not fluctuate so much between -1.5 and 1. 5.
Another thing to check would be the atmospheric forcing streams and atm logs in the two hybrid cases (which are the one with the surfdat modification and the case without any modification, if I understand correctly) to make sure they are the same. Also, examine the differences in landcover between the two cases for that particular location you've plotted and post the results here.