Welcome to the new DiscussCESM forum!
We are still working on the website migration, so you may experience downtime during this process.

Existing users, please reset your password before logging in here: https://xenforo.cgd.ucar.edu/cesm/index.php?lost-password/

CLM5-BGC: 3 kilometer Europe: Curvilinear Grid? Restart file not compatible?

ChrisPp

Christian Poppe
New Member
I am using CTSM (Version ctsm1.0.dev084-306-gb146c62) to model Europe on a 3km grid with CLM5-BGC. I had regrid the domain and surface files created by the supplied gen_domain and mksurfdata.pl to fit the required 3 km grid. Because i read in some posts that it is not possible for CLM to model on both sides of the prime meridian in one domain, i had to split the case in two (west & east). This and the nature of my curvilinear grid made it impossible to keep the 'real' coordinates, so i am using 'false', 'invented' coordinates in my domain file for the grid cell centers xc and yc. The edge variables xv and yv in the domainfile remained untouched.
  • Are the coordinates used for calculations within the model? I know the coordinates are used to calculate the zenith angle for the tintalgo algorithm of datm if tintalgo=coszen; but not when set to linear. Do the coordinates play a role somewhere else?
  • Same question for the grid cell edges: Do the coordinates from the grid cell edges play a particular role in the model calculations?
To do the BGC Spinup, i increased the timestep, but here, depending on the timestep value, i get ENDRUN Errors indicating: that the Carbon Balance is critically negative after a certain simulation time. The western case is able to run at a 3 hourly time-step, while the easten part is not fuctioning on any other time step than 0.5 hourly.
  • Could it have something to do with the changes in the domain / surface file? Why does it work with the half hourly time-step then?

I would be glad if i would get some insight here! Thanks in advance :)
Best
Christian
 

oleson

Keith Oleson
CSEG and Liaisons
Staff member
The lat/lon are used to determine the solar zenith angle in the model itself, and thus affect the radiation calculations in the model (not just the tintalgo algorithm).
I don't think the cell edges are used in the model calculations.
It's possible that you've run into this issue:


But since you are not running with a 20-second time step, I wouldn't think that is the problem. However, you may have hit another issue involved with time steps that are different from the standard 1/2 hourly, although I don't know why that would be confined to just the eastern part.
Does the eastern part run with a cold start (no finidat) for time steps other than 1/2 hourly?
Can you attach the lnd and cesm log files that have the carbon balance error?
 

ChrisPp

Christian Poppe
New Member
Thanks Mister Oleson for your fast reply.
The radiation calculations - are they also used if the swdn solar downward radiation is explicitly given in the atmospheric forcing? I should mention i am using my own atmospheric forcing derived from a renalysis data set. I am quite confident that there is no problem there though.
The issue you suggested is not really related - i am using the default initfiles (so not starting from cold) when the error occurs (i dont get to the point to have my own restart files) and usually try to use a 3 hourly time step.

I am attaching cesm and lnd log files for that issue here: Files
(the cesm file is too large to attach in this post)

Dont mind it is now clm5 and not the ctsm version i mentioned before. I am in the processing to migrate my case there, but i get the same mentioned error. Excuse the confusing title of my thread too. The part 'Restart file not compatible?' Refers to that migration process. I am not able to use the restart files generated in the ctsm in the clm5 version i am using now. I get:
ERROR: ERROR:: pot_f_nit_vr is required on an initialization dataset
I wonder: is there a possibility to tell the ctsm to add those variables to the restart files so i have a restart file for the last ctsm run that i can use on clm5 standalone too?

Thank you again for you help. Greetings from Jülich, Germany.
Regards
Christian
 

oleson

Keith Oleson
CSEG and Liaisons
Staff member
By radiation calculations, I mean the calculations for absorbed, reflected, and transmitted solar radiation which are a function of solar zenith angle, and thus the grid cell lat/lons. However, I doubt your adjusted lat/lons are the problem.
From the log files, the negative carbon error appears to be associated with leaf carbon.
I don't know of a way to tell ctsm to add variables to the restart file, other than doing it manually (i.e., using a netcdf utility).
 

ChrisPp

Christian Poppe
New Member
From the log files, the negative carbon error appears to be associated with leaf carbon.
Okay thanks. I looked into the specific line of code "CNPrecisionControl Mod.F90 at line 207" but its hard to figure out what exactly i can do to prevent this. Can this still be associated with my input data (although the model runs nicely with 0.5h timestep?

Be safe
Chris
 

oleson

Keith Oleson
CSEG and Liaisons
Staff member
If the model is running fine with a 0.5h timestep, then I doubt there is anything wrong with the input data.
As I mentioned before, there could be an undiscovered problem in the model associated with a difference in the time step used to create the restart file you are using to initialize the model and the time step being used in your model run. The model is not commonly run with time steps other than 0.5h or 1.0h. There are some counters in the restart file that are a function of the time step and that are reset periodically according to phenology. However, the counters that caused the problem in the issue I noted were associated with the crop model and it doesn't look like you are running with crops on.

Does the model run with, e.g., a 3h time step using a cold start initialization?

You could try setting cnegcrit in your user_nl_clm to something more negative, e.g., -70. That would allow the model to run past the point at which it is crashing now. However, I suspect that leafc will continue to become more negative and the new limit will eventually be triggered.
 

ChrisPp

Christian Poppe
New Member
Hello Oleson.
Yes, i am just running the BGC module without crops.
When doing 3h with CLM_FORCE_COLDSTART="on", the model crashes after the second time step, without any clear error message in the log files, although i think it is also related to the CN Balance, as it is stated in the lnd log file that this is "skipped for the first timesteps after startup". And probably it crashes the first time this is due.
See attached log files.

You were again right, when i changed cnegcrit to -90 it also crashed slighty later. By the way also when declaring an 1h timestep, i get the CN critical negative ENDRUN error. Just this time explicitelly in the lnd log file and cesm log file instead of just in the cesm log file as it was with 3h. Maybe this is of importance. You can see them here.

I also created the missing variables in the restart file with an ncl script. I will see if that works.

In your opinion, there is no better possibility than just run the model in the 0.5h time-step? My only issue here is that for a 3km Europe grid, the BGC Spinup would take a lot of computation time and life time until it reaches stability.

Best Regards.
Chris
 

Attachments

  • cesm.log.3133244.201201-105843.txt
    700.4 KB · Views: 2
  • lnd.log.3133244.201201-105843.txt
    118.3 KB · Views: 1

oleson

Keith Oleson
CSEG and Liaisons
Staff member
For the coldstart simulation, the error is pointing to a divide by zero in this line in accumulMod.F90:

if ((mod(nstep,this%period) == 1 .or. this%period == 1) .and. (nstep /= 0))then

I assume that this means that this%period is zero. This variable description is "field accumulation period (in model time steps)".
That subroutine is being called by this line in TemperatureMod.F90:

call update_accum_field ('TREFAV', this%t_ref2m_patch, nstep)

where TREFAV is the hourly average 2m air temperature.
Since you are trying to run 3-hourly, this hourly accumulation function may not work correctly in a cold start configuration. The time step would have to be an hour or less. I need to confirm that here with a simulation.

In a non-coldstart configuration, the accumulator variables would be on the restart file and so the model would probably run (for a bit).
Your western simulation in non-coldstart configuration may be running with a 3-hourly time step, but I'm not sure it's running properly.

One more thing to try is a coldstart with a 1-hour time step in your eastern simulation.

In the end, we've only ever run with 1/2 or 1 hour time steps and it appears the model may not run or may run incorrectly for other timesteps.
 

ChrisPp

Christian Poppe
New Member
Dear Oleson,
Thanks for your illuminating reply.
Indeed, if i run the eastern part as coldstart simulation it works with an hourly time-step. A continuation with the created restart file also finished successfully. I would run the spinup for the eastern part at one hourly resolution from coldstart, and the same for the western domain too, to assure the model works the way it should.

Do you have other suggestions to speed up the spin-up? I was thinking of run the spinup at different resolutions, e.g. 12 km for 500 years, 6km for 300 years, and 3km in the end until equilibrium is reached. In between i would regrid / interpolate the restart files in the resolution transitions.

Allow me me one small inquiry on top: I see in the CLM5 BGC Spinup tutorial (and elsewhere) the RUN_TYPE variable being set to startup and the copying of rpointer files. I have not found a description what exactly this does / how it affects the simulation. I would be glad to have some insight there.

Best
Chris
 

oleson

Keith Oleson
CSEG and Liaisons
Staff member
Sorry, I don't have any other suggestions for the spinup.

The documentation seems to be a bit out of date. The RUN_TYPE variable for the case should already be set to startup and it's not necessary to copy over the rpointer files. All that is needed really is to set finidat.
 
Top