high vertical resolution crashes (high priority)

[JulioTBacmeister]

In CLUBB, but no useful diagnostic messages from CLUBB.

This happens when we increase PBL vertical resolution. Changing firing level of ZM from 1 to 2 does not prevent crash. However turning ZM off altogether prevents crash.

In SE dycore, location and time of crash: NH warm season (first June) near 0.5 degree and 1N.

Details can be found in Cecile's case directory:
/glade/p/cesmdata/cseg/runs/cesm2_0/f.e21.FWscHIST.ne30_L48_BL10_v1_tag20201111.001_debug_native2

Note that FV one-degree using same vertical grids runs longer but crashes at nearby gridpoint.

[swrneale]

Just to be clear. Does the model actually crash, or does it exit in an orderly fashion after CLUBB triggers one of its error criteria?

[swrneale]

And from some TOGA-COARE SCAM expts. I see that CLUBB is producing a MEAN temp. tendency in the lowest level of a L256 run of +32K/day. Seems a lot. Compared to +8K/day in L32.

[adamrher]

Since Julio just said the model does not crash when ZM is off (this is unrelated to rich's q's above) ... Thomas Toniazzo found that "Changing the base mass layer definition is necessary and has the largest effect, but results in large RMSE" ... he sets the sub-cloud layer to match the PBL. See more here: https://www.cesm.ucar.edu/events/wg-meetings/2019/presentations/AMWGChemWAWG/toniazzo.pdf

[adamrher]

Changing firing level of ZM from 1 to 2 does not prevent crash

Maybe try setting the level to the equivalent of first level in 32 level model? If this controls the subcloud layer thickness, I believe Thomas told me that too small a subcloud layer could lead to instabilities.

[swrneale]

It's definitely the case with a thin lowest level I see a massive push/pull between ZM and CLUBB with a +/- 57 K/day tendency for some timesteps.

[JulioTBacmeister]

Yes I totally agree with where this seems to be heading. I think we should try "strapping" the bottom N-levels to provide the plume base properties as well to receive the ZM tendencies

[adamrher]

I've been looking through Thomas' zm code mods and I think I see where he matched the base mass layer to the pbl depth. I sent him an email asking to confirm, and will provide those code mods in this thread when/if he does. I agree with Julio's idea of "strapping" the bottom levels to create the launcing parcel, but I think its worth just trying the noresm mods as well to see if that doesn't alleviate the issue.

[cecilehannay]

About "strapping" the bottom levels: Is this something Rich is going to provide? +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Cecile Hannay National Center for Atmospheric Research email: hannay@ucar.edu webpage: http://www.cgd.ucar.edu/staff/hannay/ "Live as if you were to die tomorrow. Dream as if you were to live forever." +++++++++++++++++++++++++++++++++++++++++++++++++++++++++

…

On Wed, Dec 9, 2020 at 11:57 AM Adam Herrington ***@***.***> wrote: I've been looking through Thomas' zm code mods and I think I see where he matched the base mass layer to the pbl depth. I sent him an email asking to confirm, and will provide those code mods in this thread when/if he does. I agree with Julio's idea of "strapping" the bottom levels to create the launcing parcel, but I think its worth just trying the noresm mods as well to see if that doesn't alleviate the issue. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#288 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACKF2VCJLZ2FMB7J2FUVIBLST7CBZANCNFSM4USH4BMA> .

[swrneale]

We should do the NORESM version, otherwise it's easy just to say that the initial parcel properties have the moist static energy of the pressure weighted lowest n layers.
Actually I think we should the pressure weighting over the same dp as the lowest model level thickness in L32 CAM6.

[adamrher]

I'm attaching my email and his response here. Basically his mod is similar to mine where I omit certain layers at the bottom. In his case, he omits just about all layers in the PBL. It's a one liner in buoyan_dilute.

Hi Adam

no, that's about it really.
The "+2", i.e. start down two PBL layers anyway (if available), was
tuning really, and not so elegant since it reintroduces an explicit
dependence on the discrete sigma-p layers. But the impact was too large
otherwise, and perhaps partly unphysical because it would ignore
cloud-base inversions (decoupling).

You're stirring my conscience for not having got round to writing this
(and the other ZM tweaks I've done) up yet...

Since it has indeed been a while, and I'm not sure how long, can I ask
what version of the code you have there? best to just send my your
source, and also zm_conv_intr.F90, please. If you would like I can give
you an updated version, where several bugs, one of which serious, have
been caught.

Best regards
Thomas

---

From: Adam Herrington aherring@ucar.edu
Sent: 09 December 2020 19:46
To: Thomas Toniazzo
Subject: changes to zm base mass layer in noresm2

Hi Thomas,

It's been a while, I hope all is well with you. I am revisiting some of
the changes you've made to the zm scheme in noresm2. I am particularly
interested in changing the base mass layer to match the pbl height.
Searching through your code mods in noresm2/components/cam/src/NorESM, I
think you do this in the buoyan_dilute subroutine, by initializing the
launching level to be just below the pbl.
!+tht: variable LON initialised here (to PVER).
! This hard-wires lowest level where conv. initiation is permitted
!lon(i) = pver
! try something different, e.g. limit PBL ovverride:
lon(i) = min(pver,nint(pblt(i))+2)
!-tht

That is, it will set the launch level to the level of minimum moist
static energy of the two levels below the pbl, or the pbl level itself.

Do I have this right or did you adjust another part of the code to
change the base mass layert?

Thanks,
Adam