Proposed minor updates to canopy biogeophysics diagnostic variables

[mpaiao]

I was going through the code to incorporate a few additional output variables in ELM based on the CLM code (E3SM-Project/E3SM#7328), and in the process I found the following:

1. The units and description of variable USTAR are incorrect. I guess the description should be friction velocity, and the units should be m/s.

https://github.com/ESCOMP/CTSM/blob/e0104b91fef35b06aa1458b3023a7d83f568ad03/src/biogeophys/FrictionVelocityMod.F90#L286-L288

2. A few lines later, variable VPD seems to be reported in Pa:

https://github.com/ESCOMP/CTSM/blob/e0104b91fef35b06aa1458b3023a7d83f568ad03/src/biogeophys/FrictionVelocityMod.F90#L314-L316

But the actual calculation has a factor of 0.001_r8, which seems to be a conversion factor to kPa.

https://github.com/ESCOMP/CTSM/blob/e0104b91fef35b06aa1458b3023a7d83f568ad03/src/biogeophys/CanopyFluxesMod.F90#L1103-L1111

3. This one is just a very minor detail, but the term "Monin-Obukhov length" is incorrect, it should be "Obukhov length" according to the American Meteorological Society.

I have a commit ready for pull request that addresses all these points, but I am first opening an issue to see if there are any concerns with my suggested changes.

[olyson]

My 2 cents is that I agree with these changes. Thanks for finding these. Regarding 2, it seem like the units on the associate statement would also need to be changed from Pa to kPa:

vpd => frictionvel_inst%vpd_patch , & ! Output: [real(r8) (:) ] vapor pressure deficit [Pa]

Regarding 3, Gordon Bonan's Ecological Climatology book refers to L as the Obukhov length scale, but Obukhov length seems fine also...

[mpaiao]

Thanks for the feedback @olyson! For 2, I wasn't sure if it would be preferable to update the units to kPa, or to make the output in Pa (and drop the 0.001_r8 factor). I guess the latter would not be bit-for-bit.

For 3, "Obukhov length scale" is fine, I can update my branch and push it.

[olyson]

Yeah, it would probably be better to be bit-for-bit in my opinion. We have a (relatively) fast-track bfb branch that these changes could go on.