BGC -cn or -fates spinup problem

[umair@skku_edu]

Hy all,

I am working on CLM 5.0 using CESM2.1.1. I am trying to run a single point case for forest and grassland sites in California and Texas. I am having a problem with the spinning up of carbon-nitrogen (-bgc cn) and fates model. I want to know what is the exact way of spinning up the biogeochemical process (cn or fates model).

1- I tried to follow the sequence of spinup_state (2 - 1 - 0, that is accelerated spinup to exit mode and then normal run). but could not succeed.
2- I also tried the sequence of spinup (2 - 0, and 1 - 0), that is switching directly from spinup mode to normal mode, as I also read in a guidebook, that in CLM5 case it automatically exit from accelerated spinup mode to normal mode on its first time step.

I have used the below-mentioned compset and resolution:
./create_newcase --case P301CA8 --res CLM_USRDAT --compset I1PtClm50SpGs --mach wrrsl

I have also tried this thread (Logic for initializing C isotopes and maybe other variables incorrect when using init_interp · Issue #67 · ESCOMP/CTSM) subroutines and customization but could get any luck.

I have attached the error log files below.

Will be very thankful for any nice suggestion.

Regards
Umair

 

[oleson]

The correct sequence for CLM5 is "2 - 0". The initial/restart file you are using as shown in log_2_1_0_case log files has a spinup state = 1. And the model is being initialized in spinup_state = 1. So I think the problem is that the model doesn't know what to do with that. You should generate a spunup initial/restart file in accelerated model (spinup_state=2) and then go into normal mode (spinup_state = 0).

 

[umair@skku_edu]

Thank you for your quick feedback.
I tried the spinup (2 - 0), as you mentioned, but it is giving error on the second time step. I have attached the error log files, and also the restart files from the case having spinup_state = 2.

can't find rootfr in restart (or initial) file...
Initialize rootfr to default
exit_spinup F restart_file_spinup_state 2
CNRest: taking Dead wood C pools out of AD spinup mode
Multiplying stemc and crootc by 10 for exit spinup
CNRest: taking Dead wood N pools out of AD spinup mode
Multiplying stemn and crootn by 10 for exit spinup
NitrogenStateType Restart: taking SOM pools out of AD spinup mode
ENDRUN:
ERROR:
Error in entering/exiting spinup - should occur only when nstep = 1ERROR in So
ilBiogeochemNitrogenStateType.F90 at line 611

Please review this again, and give your recommendation for this issue.

Regards

 

[oleson]

Based on the log files you sent, I think you are doing a restart run (CONTINUE_RUN = True). This should not be a restart run, but rather a startup run, using the initial file you are specifying.

 

[umair@skku_edu]

Thank you so much for your help. I got it. I was running a branch case and using spinuup_state = 0. I changed to startup run with the finidat file from Accelerated spinup case(spinup_state = 2) as you mentioned, and it works.

I have one more question if you don't mind.
I am running a single point case, after spinning up in accelerated mode for 600 years for cn, I did 60 years spinup in the normal mode. But still, I am getting very low values for GPP and NPP, almost closer to zero. (0.00xe-11 or less).

Do I need to spinup for a longer period? or there could be any other problem. I have attached the history files as well if that gives you any clue.

Thanks

 

[oleson]

I don't think you need to spinup longer. I would start by looking at your atmospheric forcing, e.g., temperature, wind, humidity, precipitation, solar and longwave radiation. There may be something about the forcing that is preventing the plant functional type from growing (I see ELAI (leaf area index) of zero all year). For example, I see peak values of solar radiation in summer at 400 W/m2. For sites in California and Texas I would expect peak incoming solar to be twice that. Or maybe the precipitation is inadequate or incorrect.

 

[oleson]

Another possible reason why your plants are not growing is if you initialized your accelerated mode run using an initial file in which the plant was dead at that location. In that case, you would need to give the plant some carbon/nitrogen to get it growing again. To do this, you would set reseed_dead_plants = .true. in your user_nl_clm. If you ran a cold start for your accelerated mode run (finidat = ' '), then this not likely to be the problem.

 

[umair@skku_edu]

Thank you for looking into the history files I shared in the previous message.

Based on the thoughts you shared, I went back into the forcing data. I was using daily forcing data before, and solar radiation was daily average, it was around 400, then I changed to hourly which is maximum reaching 800 to 1000 W/m2. Repeat the spun-up and normal running again. but getting the same results.

I also observed that GPP and TLAI were continuously decreased in each spin-up cycle. Is it logical?

I have shared the first few runs from the case which is running and showing the same kind of decreasing GPP and TLAI trend.

I used the PFT index 2 (for needleleaf evergreen tree) in surface data creation, as the first index is for barren land. Am I right?

Thanks

 

[umair@skku_edu]

Another possible reason why your plants are not growing is if you initialized your accelerated mode run using an initial file in which the plant was dead at that location. In that case, you would need to give the plant some carbon/nitrogen to get it growing again. To do this, you would set reseed_dead_plants = .true. in your user_nl_clm. If you ran a cold start for your accelerated mode run (finidat = ' '), then this not likely to be the problem.

I ran a coldstart for the accelarated run mode, I think that could not be the issue then.

 

[oleson]

Bare ground is index 0 in the surface dataset. Temperate needleleaf evergreen tree is index 1.

 

[umair@skku_edu]

Yes, you are right. This is the surface data file I have used. I have used PFT index 1. I wrote index 2, just to mention the row name.

 

[zpc]

I ran a coldstart for the accelarated run mode, I think that could not be the issue then.

May I ask if you have solved this problem? I have been troubled by this problem recently. I have the same parameter as you, but TLAI gradually becomes 0

 

[CGL]

Based on the log files you sent, I think you are doing a restart run (CONTINUE_RUN = True). This should not be a restart run, but rather a startup run, using the initial file you are specifying.

Hi! oleson,
I create a case want to rerun after spinup. It's RUN_TYPE = branch and the CONTINUE_RUN=FALSE. When I submit the case.I got the erro:
Error in entering/exiting spinup - should occur only when nstep = 1ERROR in So
ilBiogeochemNitrogenStateType.F90 at line 622
I check the spinup_state for the lnd_in and the initial file,and they are 0 and 2, respectively. The attach files is lnd_in and cesm log.

 

[CGL]

Hi! oleson,
I create a case want to rerun after spinup. It's RUN_TYPE = branch and the CONTINUE_RUN=FALSE. When I submit the case.I got the erro:
Error in entering/exiting spinup - should occur only when nstep = 1ERROR in So
ilBiogeochemNitrogenStateType.F90 at line 622
I check the spinup_state for the lnd_in and the initial file,and they are 0 and 2, respectively. The attach files is lnd_in and cesm log.

I change the RUN_TYPE to hybrid. The model working,now. Though, i don't konw why...

 

[oleson]

A branch is essentially a continuation run so nstep is not going to be 1 and that's why you are getting that error. As you've found, a hybrid run should work. As noted in env_run.xml in your case directory:

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.

 

[CGL]

A branch is essentially a continuation run so nstep is not going to be 1 and that's why you are getting that error. As you've found, a hybrid run should work. As noted in env_run.xml in your case directory:

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.

I consider hybrid to be a less conditional version of branch. Can hybrid run also be considered as a mode of operation for continuation run( no source code or component namelist inputs are modified.) ？
I see the timestamp of output files(using hybrid run) is 0001-01-01. But the timestamps for branch run are continued from the previous case

 

[CGL]

I consider hybrid to be a less conditional version of branch. Can hybrid run also be considered as a mode of operation for continuation run( no source code or component namelist inputs are modified.) ？
I see the timestamp of output files(using hybrid run) is 0001-01-01. But the timestamps for branch run are continued from the previous case

And I set the RUN_REFDATE=0156-01-01. Is the timestamp generated by Hybrid run normal?

 

[CGL]

And I set the RUN_REFDATE=0156-01-01. Is the timestamp generated by Hybrid run normal?

I think maybe the CONTINUE_RUN should be TRUE, then the timestamp would be right. But I found someone's post that his CONTINUE_RUN is FASLE.

 

[slevis]

Here's a link to a section in the documentation that discusses hybrid and branch simulations:

1.2.2. Customizing CLM’s Configuration — ctsm release-clm5.0 documentation

Think of these (startup, hybrid, branch, continue) as tools for using the model. Users decide which tool works best for their application. In some cases, users may need to design custom tools to accomplish what they want.

 

[CGL]

The correct sequence for CLM5 is "2 - 0". The initial/restart file you are using as shown in log_2_1_0_case log files has a spinup state = 1. And the model is being initialized in spinup_state = 1. So I think the problem is that the model doesn't know what to do with that. You should generate a spunup initial/restart file in accelerated model (spinup_state=2) and then go into normal mode (spinup_state = 0).

Hi,@oleson! I want to ask how can I generate or know the spinup restart file(spinup_state=2)? I use the 'CLM_ACCELERATED_SPINUP=on' to spinup for 50 years.