CTSM
CTSM copied to clipboard
ESCOMP
reseeding on a branch
Run 156 had the variable reseed_dead_plants = .true. Run 156.budget is a branch run of that case. It also had this variable set and it appears that it was used when starting the branch. This caused these runs to diverge, is there a way to prevent this from happening?
@jedwards4b thanks for pointing this out. We are going to have to think about how to do this one.
One solution I can think of is to NOT allow it to be true for anything, but the initial segment of a simulation. And maybe we disallow it for branch, and only allow for hybrid or startup?
@slevis-lmwg and @olyson can you comment on this one? Do you do things to make sure reseeding isn't set when it shouldn't be in CTSM simulations?
I also realized this is similar to why we keep finidat files on the namelists -- so that you can see what IC file was used to start the simulation. In the same way it's good to know if a simulation had reseeding turned on at it's beginning.
In general it's also relatively harmless, it only affects anything at the beginning of a simulation. And it only allow dead plants to reseed and start from scratch. So it only impacts vegetation that's dead in the IC file being used. So it can be viewed as doing a positive thing, and something that could be argued that you always want. But, if you are doing a branch simulation and you expect answers to be replicated this is exactly what you do NOT want.
Another thing that could be done, would be to disallow it in a branch simulation, but have a way to override it maybe? And since branch simulations are sometimes done to replicate answers exactly, this should maybe be done for any namelist settings that would change answers.
My opinion is that setting it to be true should be disallowed in a branch simulation. The problem arose when Cecile created a branch case by cloning a case with it set to true, and was expecting those two cases to be bfb.
I ran an ERI.ne30pg3_t232_wg37.B1850C_LTso.derecho_intel.allactive-defaultio to verify this and the test passes. What am I missing?
We discussed this in 2018: see https://github.com/ESCOMP/CTSM/wiki/Meeting-Notes-2018-Software (search for "reseed" in there)
Good memory @billsacks ! I did a simple test in which I ran a control for two months, and then two branches beginning at the end of the first month, one with reseed_dead_plants = .true. and one with reseed_dead_plants = .false. The one with .true. was not bfb with the control for the second month, while the one with .false. was.
I thought that it might be associated with a longer run and am trying that now.
We discussed this in 2018: see https://github.com/ESCOMP/CTSM/wiki/Meeting-Notes-2018-Software (search for "reseed" in there)
Here's the direct header to the section for the discussion:
https://github.com/ESCOMP/CTSM/wiki/Meeting-Notes-2018-Software#reseed_dead_plants-on-a-branch-run
From that we intended to NOT allow this for a branch -- but didn't implement that restriction in the code.
So I think we should implement this so that turning it on for a branch so that preview_namelist dies with a warning, that you have to allow with the ignore_warnings option.
From the meeting today, we decided that this should just be something that's disallowed and the code will abort with an error. At least in the build-namelist, but also potentially in the Fortran code?
From this morning's Stand-up: @slevis-lmwg to open a b4b-dev PR and merge this change before proceeding to the next b4b-dev merge to master.
@billsacks it looks like we should do the same thing with reset_snow and reset_snow_glc so that they can't be true on a branch. Does that sound right to you?
I don't think this is as necessary for reset_snow: my recollection and understanding from the logic is that it already won't be active on a branch run. The difference from reseed_dead_plants is that reset_snow happens in the run loop for some initial number of time steps (if get_nstep() <= reset_snow_timesteps) (it doesn't work to do this resetting in initialization). Since (I think) nstep keeps counting in a branch run rather than being reset to 0, reset_snow won't have any effect in a branch run.
That said, if you think it would be better to raise an error in this case, then that's fine with me.
Ahhh, OK thanks for that clarification. I do think it's still important to have a fail on namelist settings that don't do anything. The assumption that users will have is that namelist settings are going to do something, so should be told if it won't. Technically, also if your branch started within reset_snow_timesteps, it will apply. Normally since that number will be small -- you wouldn't be doing that. And actually for that matter this is a case -- where you would need it to be set as it was for your initial case.
In any case, thanks for clarifying that it's not as critical as the reseed option. I'll open this as a new issue that we can make a lower priority.