Time evolving parameterization for leaf properties

[wwieder]

I've been in several discussions with groups asking about the feasibility of implementing time evolving parameterizations for CTSM that can be used for sensitivity tests in the model. For example, there seems to be good evidence that SLA and tissue stoichiometry changes under elevated CO2, but these are effectively fixed by values in the parameter file. Is this something that can be modified (e.g. as a function of CO2) at one place in the code, or would it have to be modified in individual modules where a parameter is used?

e.g. cn_now = pftcon%leafcn + max(cn_slope*ln(CO2_now/CO2_base),0._r8)

The plot below shows what the cn_now would be under elevated CO2, relative to a 350 ppm CO2 baseline with leafcn=25, for equations having cn_slope of 10, 15, 20

Interested to hear ideas about how this may be possible to explore.

[wwieder]

@ekluzek suggested this could be something in pftconMod.f90 in a hacky way (which is fine with me for now)

[wwieder]

The parameter would also have to be updated in clm_driver.f90 (and maybe added to history, e.g. leafcn_target which can be compared to leafc/leafn). These will be grid cell averages, reflecting changes in pft weights and changes in CO2

[slevis-lmwg]

clm_driver would call a new subroutine that's located in pftconMod.f90 and the new subroutine would contain the function that makes the parameter(s) time-varying.

[slevis-lmwg]

CO2_base for now will be hardwired in the new subroutine.

[slevis-lmwg]

Initially test with single-pt with and without time-varying leafcn.

Later will follow up with global runs.

[slevis-lmwg]

Met with @ekluzek Motivated by errors that I'm getting when I place the new subroutine in pftconMod, we agreed that I should place it in CanopyStateMod instead.

[ekluzek]

@wwieder I've got some thoughts on the philosophy of this and how to organize it that we should perhaps discuss. The specific solution that @slevisconsulting is pursing makes sense for this specific case. And if it's impactful and interesting and we want to bring it into the main code, we'll go over the implementation details, and may make some changes.

The philosophical part though is what does it mean for "parameters" to change in time? It seems like in general parameters should be constants that aren't going to change in time, and if they do the parameterization itself should change to have additional parameters that define the change in time. So like in this example you have new parameters that define how something changes relative to CO2 (or something else that may change in time).

Now since parameters are set with experiments like the PPE where parameters are tuned to give good behavior that compares well to observations over some period. Does that same kind of PPE work need to be done anytime you are modeling a different period or scenario? The PPE work handles this by doing spinup, 1850, and transient historical. But, would you need to redo the PPE work for Paleo studies or future scenarios? Ideally that wouldn't be the case, and if it is required it seems to me that means we are missing a parameterization of something that changes in time (like in this case). Our confidence in being able to use the model for future or past scenarios goes up if we don't have to have parameters that change in time. The problem of course is that we've got to realize that for every instance which is hard to do.

Anyway, a few thoughts that maybe would be best to do in a discussion...

[wwieder]

Yes, this would be good to discuss. Broadly, I like the language of having time invariant parameters that can be use to in a parameterization that handles a change in foliar properties over time (e.g. chemistry, sla, etc). I'll try to be more careful with my language. This seems like a good topic to discuss at an upcoming CLM meeting. I'll change the title of this issue to be more accurate.