CTSM
CTSM copied to clipboard
ESCOMP
Set and use zetamaxstable for BHS cases
There is special code in CanopyFluxes and FrictionVelocity to essentially hardcode zetamaxstable when Biomass Heat Storage (BHS) is on to 100. What should be done is the namelist value should always be used, but set to 100 when BHS is on. That value of zetamaxstable should be used by all instances including: bare-ground, veg, lake, and urban.
This is blocked by #1689
Some discussion on this is in: #1596
We talked about this today. Potentially this could become an entire research project to get right. We want to talk about this at a future CTSM science meeting. @wwieder could you schedule that? @olyson is also going to work with @swensosc to talk about what could be done simply. @olyson on has done some testing changing it from 100 to 20 for #1596 so we might settle on a smaller value than 100.
In principle I think it's bad design to have a zetamaxstable used for some landunits and then have a different hardcoded value for vegetated landunits that's hidden in the code. Hidden hardcoded constants that override namelist behavior is bad design. But, if it becomes too much of a research project to get this right we may need to leave it in place as is.
@dlawrenncar also pointed out that the reason we needed a small value for vegetation was that there was no heat capacity in vegetation so it allowed bad behavior for high values of zeta (things like allowing excessively low temperatures even in the Summer). Adding BHS allowed better behavior under stable conditions with higher zeta values, so we could increase the limit. Presumably bare soil, and lake (and urban?) will have enough heat capacity to eliminate this kind of bad behavior.
@ekluzek happy to schedule time. Is this a 15, 30, or 60 minute conversation? Also, how timely does this need to be- our CLM science meetings are getting scheduled way out at the moment, but I can see where we may be able to adjust the schedule, especially if this is critical.
Seems like it would be good to have a discussion on this relatively soon while it is fresh in our minds. If necessary, we could schedule for outside CLM meeting. I think this could be a roughly 20 min discussion. Alternative is to invite some people to a CTSM software meeting (Sean, Gordon?, Ronnie Meier?) and discuss there.
On Mon, Mar 28, 2022 at 7:01 AM will wieder @.***> wrote:
@ekluzek https://github.com/ekluzek happy to schedule time. Is this a 15, 30, or 60 minute conversation? Also, how timely does this need to be- our CLM science meetings are getting scheduled way out at the moment, but I can see where we may be able to adjust the schedule, especially if this is critical.
— Reply to this email directly, view it on GitHub https://github.com/ESCOMP/CTSM/issues/1690#issuecomment-1080620034, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFABYVB6EKKLMY7ANU3SRF3VCGUSPANCNFSM5RJCNOBA . You are receiving this because you were mentioned.Message ID: @.***>
@olyson can you briefly introduce this topic / issue at the CLM meeting this Thursday at 2? Most of our hour will be spent on the SIF GPP work, but it would be good to at least start a conversation on this too while it's more fresh in everyone's mind. I'll invite Ronnie to the meeting too
I'm on PTO Wed-Mon. But we had a preliminary meeting on this last week with myself, Erik, Sean, and Gordon (see #1596 ). So you could probably continue the discussion without me. The relevant slides are here:
https://docs.google.com/presentation/d/1u6ycr7F97QYYRcRfEdD9yIxH75diUx2r/edit#slide=id.p10
In particular, the last slide summarizes the current situation.
We've decided to go forward with this and that the value to be used will be 2. Talked about in the CLM science business meeting on Jun 9th.