Open adamrher opened 1 year ago
FYI: Related discussion in E3SM: https://github.com/E3SM-Project/E3SM/issues/2680
Here is summary of my findings:
The variable state%exner is computed in dp_coupling.F90 as
This quantity would have been the inverse Exner function had it been using P0=1000hPa instead of surface pressure (pint(i,pver+1)). Hence calling this quantity state%exner seems confusing!
In CAM7 state%exner is used (as far as I can tell) in two places in the code (as well as for some diagnostics in CLUBB interface and in CTEM):
Note that only th values in level k=pver are used!
which is passed to the surface components.
In turns out that th in 1. and thbot in 2. are correct with the definition of theta_atm in CLM scientific documentation:
p.44 in https://www2.cesm.ucar.edu/models/cesm2/land/CLM50_Tech_Note.pdf
In other words, the quantities computed are what the surface components expect and what is expected for computing Obukhov length according to the documentation. Hence not a bug!
Recommendation:
Other:
In the turbulent mountain stress parameterization (not used in CAM7), state%exner is used to compute potential temperature that, in turn, is used to compute Richardson number (trb_mtn_stress.F90). This might be scientifically correct because only vertical gradients are computed @JulioTBacmeister .
phys_grid_ctem.F90 diagnostics are using state%exner to compute potential temperature. This is likely a bug @islasimpson. Likely not significant!
In clubb_intr.F90 state%exner is used to compute diagnostic variables. Advice needed @adamrher @zarzycki @vlarson
Please note that the dp_coupling.F90 version for MPAS uses inverse Exner function so th and thbot used for Obukhov length and surface coupling, respectively, are incorrect!
What happened?
state%exner is currently computed as pressure over surface pressure, raised to kappa. That is not the definition of exner; it should be with respect to the reference pressure = 1000e2 Pa. @brian-eaton - When you are ready to implement this, talk to @PeterHjortLauritzen and he will explain what is to be done.
What are the steps to reproduce the bug?
fix it in dp_coupling.F90 in all dycores.
What CAM tag were you using?
all of em
What machine were you running CAM on?
CISL machine (e.g. cheyenne)
What compiler were you using?
Intel
Path to a case directory, if applicable
No response
Will you be addressing this bug yourself?
Yes, but I will need some help
Extra info
No response