search

ESCOMP / CTSM

Community Terrestrial Systems Model (includes the Community Land Model of CESM)
http://www.cesm.ucar.edu/models/cesm2.0/land/
Other
308 stars 312 forks source link

RH_LEAF not specifically designated as corresponding to sunlit or shaded canopy #1322

Open djk2120 opened 3 years ago

djk2120 commented 3 years ago

RH_LEAF is identified as 'fractional humidity at leaf surface' https://github.com/ESCOMP/CTSM/blob/6fad071dce82ab4cbf42f6cd47399bd463bd126a/src/biogeophys/PhotosynthesisMod.F90#L377

But in the SMS (use_hydrstress=.false.) Ball-Berry code, it looks like RH_LEAF is first set as the sunlit rh_leaf, but then will be rewritten by shaded rh_leaf if there is a shaded leaf phase of the canopy. This seems like a bug. RH_LEAF is not populated with SMS-Medlyn or PHS.

I would suggest addressing this issue when unifying the PHS and SMS code and checking for any other leaf-level variables that may be inconsistently populated.

In the mean time, I wanted to document the issue for users who may be looking at RH_LEAF.

wwieder commented 3 years ago

Thanks for noting this, @djk2120. A few followup questions:

djk2120 commented 3 years ago

The variable is used correctly within the code. During the sunlit call to Photosynthesis it is correctly the sunlit leaf relative humidity and is used within the ball-berry model for computing sunlit stomatal conductance. Then in the shaded call it is recalculated as the correct shaded leaf relative humidity and used within the ball-berry model for computing shaded stomatal conductance. Because leaf temperature can vary between the sunlit and shaded leaves we would not expect RH_LEAF to necessarily be the same for sunlit/shaded. So the bug is only in the history/diagnostic aspect of RH_LEAF.

Most of the time the history field will end up populated with the shaded leaf relative humidity. But in the case where LAISHA=0, it could instead end up populated with the sunlit leaf relative humidity, which is a bug. The fact that this is usually shaded leaf relative humidity is a bit of a misnomer, compared to its current long_name. It is never populated with PHS. Nor is it populated with SMS-Medlyn. The bug exists within SMS-BallBerry. So overall it is never 'accurate'.

The relevant code is here: https://github.com/ESCOMP/CTSM/blob/master/src/biogeophys/PhotosynthesisMod.F90#L1764

This should be wrapped within a phase=='sun / phase=='sha' conditional.

I would suggest removing RH_LEAF from the history output. We could replace it with RH_LEAF_SUN and RH_LEAF_SHA, but these probably should be optional output. Then we would make sure they are populated for both stomatal conductance models and both water stress schemes.

On Tue, Apr 6, 2021 at 5:21 AM will wieder @.***> wrote:

Thanks for noting this, @djk2120 https://github.com/djk2120. A few followup questions:

  • Can you post the part of the code where RH_LEAF should be updated (I'm assuming in PhotosynthesisMod)?
  • Is this simply a diagnostic output, or is the variable subsequently used (incorrectly) later in the code?
  • In the short term should we clarify the long_name or RH_LEAF to clarify it's only accurate for PHS?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ESCOMP/CTSM/issues/1322#issuecomment-814075566, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADNHR5U5OTPSXELCJGIYM23THL4EFANCNFSM42NLORUA .

heroldn commented 3 years ago

Yes thanks @djk2120, I was literally writing a forum post then thought to look here.

You said that leaf temperature can vary between sunlit and shaded but I'm having trouble seeing it in the code (looking at PHS=off). Line 1711 references esat_tv which doesn't look like it varies for sun/shade. I'm interested in this because I'm trying to figure out which variables have sun/shade versions and which don't.

And actually, when I look at the two calls to Photosynthesis in CanopyFluxesMod.F90 it looks like esat_tv (which should be the 4th variable passed) is svpts - which does not look like temperature at all(???). I assume I'm reading the code incorrectly!

heroldn commented 3 years ago

It also looks like from line 1763 that rh_leaf (or its sun/shade equivalents to be) should have unique values for each canopy level and thus be two dimensional - referenced as e.g. rh_leaf_sun(p,iv). Would you agree?

djk2120 commented 3 years ago

In terms of getting the correct gs, etc I don't think it matters, because it will be rewritten within each step of the canopy layer for loop. But if you wanted to look at multilayer rh_leaf, that would not be possible as written. I will also note that the multilayer canopy capability is not scientifically supported, and is not being used at this time.

On Mon, Apr 19, 2021 at 9:27 PM Nicholas Herold @.***> wrote:

It also looks like from line 1763 https://github.com/ESCOMP/CTSM/blob/c877c225c91796fabe82a9c954cccb51b15ced17/src/biogeophys/PhotosynthesisMod.F90#L1764 that rh_leaf (or its sun/shade equivalents to be) should have unique values for each canopy level and thus be two dimensional - referenced as e.g. rh_leaf_sun(p,iv). Would you agree?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ESCOMP/CTSM/issues/1322#issuecomment-822945863, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADNHR5RKC4P3C7IRW6GS64TTJTYC5ANCNFSM42NLORUA .

heroldn commented 3 years ago

So to confirm, if I wanted to write out canopy-averaged sun or shade rh_leaf would I need to correct this to properly record each canopy layer, then send it to the appropriate hist_addfld function? I think that's what I would have to do, that's how other canopy level variables are treated.

And do you have an opinion on my previous comment or should I post those as new potential issues/questions?

djk2120 commented 3 years ago

That is technically correct, but I want to point out that the canopy really only ever has 1 layer. The extra dimension of canopy layer is not used within any supported version of CLM.

Separately, RH_LEAF is subject to a bug (detailed at the top of this issue), which would need a workaround. If you anticipate looking at it, I could add a fix to the Medlyn-SMS pull request.

On Tue, Apr 20, 2021 at 4:39 PM Nicholas Herold @.***> wrote:

So to confirm, if I wanted to write out canopy-averaged sun or shade rh_leaf would I need to correct this to properly record each canopy layer, then send it to the appropriate hist_addfld function? I think that's what I would have to do, that's how other canopy level variables are treated.

And do you have an opinion on my previous comment or should I post those as new potential issues/questions?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ESCOMP/CTSM/issues/1322#issuecomment-823643422, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADNHR5RETV5AQEPQOZJDAR3TJX7BPANCNFSM42NLORUA .

heroldn commented 3 years ago

Ah I didn't know that only one layer gets used, thanks. And re the bug in this issue, thanks but I've set up rh_leaf_sun_ln and rh_leaf_sha_ln to store local noon versions of rh_leaf, essentially mimicking how gs_mol_sun_ln gets recorded. And so in that vein, for the sake of consistency, I'll also make my rh_leaf variables 2D (p,iv).

djk2120 commented 3 years ago

Replying to

You said that leaf temperature can vary between sunlit and shaded but I'm having trouble seeing it in the code (looking at PHS=off).

Thanks for checking this. It looks like I misspoke, and that rh_can (L1661) should be identical for sunlit and shaded leaves. In that case the functional input to ball-berry would be the same for shaded/sunlit.

Later rh_leaf is calculated (L1764) which accounts for the differing sunlit vs shaded stomatal conductances.

So I would say it might make sense to add rh_can to the history file. And then consider adding rh_leaf_sun and rh_leaf_sha. However as rh_leaf has no impact on the calculation of g_s, maybe it's better to write out only rh_can.

Replying to:

And actually, when I look at the two calls to Photosynthesis in CanopyFluxesMod.F90 ...

These look fine to me. CanopyFluxes is passing in saturation vapor pressure, and Photosynthesis is expecting saturation vapor pressure. They are just using different names for the same variable (svpts/esat_tv)

heroldn commented 3 years ago

These look fine to me. CanopyFluxes is passing in saturation vapor pressure, and Photosynthesis is expecting saturation vapor pressure. They are just using different names for the same variable (svpts/esat_tv)

Ah yes I completely misread esat_tv.

Later rh_leaf is calculated (L1764) which accounts for the differing sunlit vs shaded stomatal conductances.

So I would say it might make sense to add rh_can to the history file. And then consider adding rh_leaf_sun and rh_leaf_sha. However as rh_leaf has no impact on the calculation of g_s, maybe it's better to write out only rh_can.

Yes looks like rh_leaf is only used as a diagnostic check near the end of the routine. But that's good advice, I'll actually write out the vapor pressures which will let me back out rh_can in post processing.

wwieder commented 3 years ago

@djk2120 is this issue being corrected? Should we correct it for a CTSM5.1 release?