Atmospheric physics time-step impact on CNBalance?

[jbladant@umich_edu]

Hi, I am wondering if (and how) the atmospheric physics time-stepping impacts the CN module in CLM4.0.I use the slab ocean model (SOM) version of cesm1_2_2_1, modified for deep-time paleo applications (pcesm0.2_cesm1_2_2_1). I have set up 2 experiments using Cretaceous boundary conditions which have already been used to run an isotope-enabled deep-time version of CESM1.2 (iCESM1_2_0_1_geotrace_n02c) for a total of more than 1200 years. The prescribed atm CO2 concentration is 1708.2 ppm (6x modern levels) and the atmospheric physics time-step was set to 900 s instead of 1800 s for stability. Following investigations with the SOM demonstrating that the atm time-stepping significantly affect global mean surface temperatures, I would like to continue the iCESM simulation with a standard time-step (ie 1800 s). However, the tests I have made with the SOM crash in the CN module of CLM4.0 when I prescribe the standard time-step, as explained below.Please note that both the SOM and iCESM use CAM5 and CLM4.0. I created 2 SOM test cases using the startup mode and a CLM restart file from the iCESM coupled simulation as the finidat file in user_nl_clm.The 2 simulations have identical boundary conditions and differ by the following:- one simulation is run with an atm physics time-step of 1800 s and a dynamics time-step of 450 s.- one simulation is run with an atm physics time-step of 900 s and a dynamics time-step of 450 s. The simulation with the same physics time-step as the fully coupled simulation (ie dt=900 s) does not crash. But the other simulation with the standard time-step (dt = 1800 s) crashes after 5 model years. More details follow but it is important to note here that I performed another SOM simulation with dt=1800 s where the model start from scratch for CLM instead of prescribing a restart file as finidat, and this simulation does not crash. The model fails in CNBalanceCheckMode.F90 when there is a check on the error on the carbon balance. The absolute value of the variable col_errcb in one grid point gets larger than 1.e-8 so the run is aborted.I have made a few plots attached where it can be seen that the total carbon content of this grid point exponentially increases whereas leaf carbon content gets negative. Instead, with the reduced atm time-step, it does not. In the plots, the black lines represent the simulation which crashes (ie with dt = 1800 s) and the red lines represent the simulation which does not (with dt = 900 s). I have attached the logs of the two simulations (note that the log file of the crashing simulation is heavy because I added some prints in the CNBalanceCheckMode.F90 routine to output information on the crashing grid points, and on other grid points nearby for comparison). Following an earlier post on this forum, I have also tried to increase the acceptable error (to 1e-7) in CNBalanceCheckMod.F90 and the precision on ncrit and ccrit but the problem still occurs a few years later. I would very much appreciate some help as I am not familiar with vegetation models and thus feel a bit lost. To me it seems to be somehow related to the change in atm physics time-step although I do not understand how, all the more so as it does not fail (at least over 50 years) with the standard 1800 s time-step if the CLM model is initialized from scratch instead of using a finidat from the coupled 900 s iCESM simulation. Best,Jean-Baptiste Ladant

 

[jbladant@umich_edu]

With the files attached.Thank you

 

[jbladant@umich_edu]

With the files attached.Thank you

 

[jbladant@umich_edu]

With the files attached.Thank you

 

[oleson]

Thanks for the detailed description of the problem.  I'm not personally aware of any issues with CN related to time-stepping.  You mentioned that you changed the precision control  thresholds in accordance with the previous post on this subject.  This seemed to work for the previous problem because the carbon value was still small enough to trigger the precision control using the new threshold.  So I'm wondering if you could try starting with an finidat file from further back in the original simulation than the one you are using?

 

[oleson]

Thanks for the detailed description of the problem.  I'm not personally aware of any issues with CN related to time-stepping.  You mentioned that you changed the precision control  thresholds in accordance with the previous post on this subject.  This seemed to work for the previous problem because the carbon value was still small enough to trigger the precision control using the new threshold.  So I'm wondering if you could try starting with an finidat file from further back in the original simulation than the one you are using?

 

[oleson]

Thanks for the detailed description of the problem.  I'm not personally aware of any issues with CN related to time-stepping.  You mentioned that you changed the precision control  thresholds in accordance with the previous post on this subject.  This seemed to work for the previous problem because the carbon value was still small enough to trigger the precision control using the new threshold.  So I'm wondering if you could try starting with an finidat file from further back in the original simulation than the one you are using?

 

[jbladant@umich_edu]

Hi,Thank you for your quick feedback.I have run the simulation starting from an earlier restart (~ 100 years earlier). The issue repeats itself although not on the same grid point.In fact when the simulation crashes, there are actually a few problematic grid points with an exponentially increasing totcolc. The figures attached show the totcolc variable at the last valid month in the crashing simulation vs the totcolc variable at the exact same month in the simulation that works. The points in black in the crashing simulations (Fig. 1) have totcolc > 50 000 gC/m2 (the maximum being > 1.e7 gC/m2) whereas in the working simulation (Fig. 2), the maximum totcolc is ~ 45 000 gC/m2.Note that the displayed simulations are the same as those used to create the figures in my previous post; I did not used the re-run simulation from another restart to make the figure.Thank you,Jean-Baptiste

 

[jbladant@umich_edu]

Hi,Thank you for your quick feedback.I have run the simulation starting from an earlier restart (~ 100 years earlier). The issue repeats itself although not on the same grid point.In fact when the simulation crashes, there are actually a few problematic grid points with an exponentially increasing totcolc. The figures attached show the totcolc variable at the last valid month in the crashing simulation vs the totcolc variable at the exact same month in the simulation that works. The points in black in the crashing simulations (Fig. 1) have totcolc > 50 000 gC/m2 (the maximum being > 1.e7 gC/m2) whereas in the working simulation (Fig. 2), the maximum totcolc is ~ 45 000 gC/m2.Note that the displayed simulations are the same as those used to create the figures in my previous post; I did not used the re-run simulation from another restart to make the figure.Thank you,Jean-Baptiste

 

[jbladant@umich_edu]

Hi,Thank you for your quick feedback.I have run the simulation starting from an earlier restart (~ 100 years earlier). The issue repeats itself although not on the same grid point.In fact when the simulation crashes, there are actually a few problematic grid points with an exponentially increasing totcolc. The figures attached show the totcolc variable at the last valid month in the crashing simulation vs the totcolc variable at the exact same month in the simulation that works. The points in black in the crashing simulations (Fig. 1) have totcolc > 50 000 gC/m2 (the maximum being > 1.e7 gC/m2) whereas in the working simulation (Fig. 2), the maximum totcolc is ~ 45 000 gC/m2.Note that the displayed simulations are the same as those used to create the figures in my previous post; I did not used the re-run simulation from another restart to make the figure.Thank you,Jean-Baptiste

 

[oleson]

Ok thanks. Not sure where to go from here.  You could check your atmospheric forcing prior to the crash to make sure the atmosphere is not going unstable and causing the land to crash. Or maybe try 1200s time step?

 

[oleson]

Ok thanks. Not sure where to go from here.  You could check your atmospheric forcing prior to the crash to make sure the atmosphere is not going unstable and causing the land to crash. Or maybe try 1200s time step?

 

[oleson]

Ok thanks. Not sure where to go from here.  You could check your atmospheric forcing prior to the crash to make sure the atmosphere is not going unstable and causing the land to crash. Or maybe try 1200s time step?