Introduce prognostic updraft velocity to saSAS and C3 cumulus convection schemes #246
Conversation
lisa-bengtsson
requested review from
grantfirl,
rhaesung,
Qingfu-Liu,
dustinswales,
JongilHan66 and
mzhangw
as code owners
… into updraft_velocity
…vertical advection of updraft velocity
… into updraft_velocity
|
Hi @JongilHan66, thank you for reviewing the PR so carefully. I do have the CCPP_typedefs update that you are referring to included. But it is not under ccpp/physics, but rather under the FV3/ccpp/data directory, so you can see those file changes in my PR to FV: NOAA-EMC/fv3atm#914 |
|
@lisa-bengtsson I appreciate the work and your PR description. In the document you link to, you compare the prognostic omega to the diagnostic omega and the prognostic code was "tuned" to achieve the same results as the diagnostic code. If they are basically giving the same results, is there some other advantage of having convective omega by prognostic? I thought that if a diagnostic approach is good enough (and it must be if it was used for tuning?) then the KISS principle sides with sticking with the diagnostic approach. I.e. Why is an (arguably) more complicated prognostic algorithm preferred in this case? Back in my PBL scheme development days there was a prevailing thought that if computational speed is important, adding prognostic variables that are advected by the dycore is a big penalty. This resulted in keeping prognostic variables to a minimum. Maybe this just isn't actually the case anymore (or ever was)? |
|
@lisa-bengtsson Reading my own comment, it comes across as snarky. That wasn't my intent -- just trying to learn. |
| omegaout(i,k) = omega(i,k) | ||
| endif | ||
|
|
||
| omegaout(i,k) = MAX(MIN(omegaout(i,k), -1.2), -80.0) |
There was a problem hiding this comment.
I've seen these limits (-1.2,-80) in a couple of places in this PR. It may make sense at some point to have these be constants defined in this module for clarity and in case they need to be adjusted in the future. Not that big of a deal though. You're already loading this module in samfdeepcnv and samfshalcnv, so it would be easy enough to import these limits to those files where they're used too.
| real(kind=kind_phys), intent(in) :: tmf(:,:,:),q(:,:) | ||
| real(kind=kind_phys), dimension (:), intent(in), optional :: maxMF | ||
| real(kind=kind_phys), intent(out) :: rainevap(:) | ||
| real(kind=kind_phys), intent(out), optional :: sigmaout(:,:) | ||
| real(kind=kind_phys), intent(out), optional :: sigmaout(:,:), & |
There was a problem hiding this comment.
sigmaout and omegaout are intent(out) but are not always give a value if present, which is a CCPP rule. The fact that they're optional maybe makes that rule cloudy, though. I'm thinking that it is probably best to add if present(sigmaout) sigmaout = 0.0_kind_phys (same for omegaout). @dustinswales You're more involved with optional arguments, do you think this is necessary?
| @@ -88,11 +90,11 @@ subroutine samfshalcnv_run(im,km,itc,ntc,cliq,cp,cvap, & | |||
| & cnvw(:,:), cnvc(:,:), dt_mf(:,:) | |||
| ! | |||
| real(kind=kind_phys), intent(out), optional :: ud_mf(:,:), & | |||
| & sigmaout(:,:) | |||
| & sigmaout(:,:), omegaout(:,:) | |||
There was a problem hiding this comment.
Same comment about initializing intent(out) variables.
| @@ -102,7 +102,26 @@ subroutine GFS_suite_interstitial_3_run (otsptflag, & | |||
| enddo | |||
| endif | |||
|
|
|||
|
|
|||
| ! In case of using prognostic updraft velocity, initialize updraft velocity here | |||
| ! since progomega_calc is called from both deep and shallow schemes. | |||
There was a problem hiding this comment.
Since sigmaout and omegaout are intent(out) in the deep and shallow convection schemes, this initialization is kinda "forgotten" as soon as those schemes are entered. Intent(out) variables become undefined when the subroutine is entered. If you want to initialize like this, I think that you may need to change sigmaout and omegaout to intent(inout) in samf[deep/shal]cnv. If you do this, you can disregard the comments about making sure that they're initialized within the scheme.
|
Looks good to me from a CCPP point-of-view other than the |
This development incorporates a new prognostic updraft velocity equation into the saSAS deep and shallow convection schemes. It is introduced as a module and will be easily added to the C3 scheme as well, once the modularized C3 code is in place.
The equation describes the time-evolution of convective updraft velocity, with buoyancy as a source term, and quadratic damping is due to aerodynamic drag and mixing/diffusion and linear damping from wind shear.
The equation is discretized using an implicit approach, and solved as a quadratic equation. For implementation details - please see: https://docs.google.com/document/d/13VH7DV4erJcuuF_-dUGpplk9uYHF6dalfx8l1fAIxe8/edit?tab=t.0
The prognostic updraft velocity is used in the prognostic closure if progsigma = true and progomega = true, it is also replacing the diagnostic updraft velocity in the adjustment time-scale computation if progomega = true (regardless of progsigma). I here implement the scheme using the default setting of progomega = false for further testing and evaluation, and thus no regression tests should fail and no new baselines are required.
The new variable is prognostic, and advected in the dycore like the other tracers. It needs to be added into the field_table to test.