SCM/CCPP: suite vs. namelist imp_physics

Submitted by ted.mansell on Mon, 10/19/2020 - 18:50
Forum: CCPP User Support | CCPP Single Column Model

Hi!

I seem to have the NSSL microphysics working with SCM/CCPP (at least tested for TWPICE), so my next question is about adding/removing predicted variables from the tracer array. Following Grant's advice, I have moved to the master branch of SCM (and CCPP) to get up to the revamped SCM code that uses the tracer.txt files. That was as of a few weeks ago, so they are a few commits behind

https://github.com/MicroTed/ccpp-physics/master-ted-nssl2m
https://github.com/MicroTed/gmtb-scm.git/master-ted-nssl2m

I have set up separate tracer.txt files for NSSL to either include or exclude the hail hydrometeor category (corresponding to separate suite names with either "NSSL" or "NSSLg" for graupel-only). I ended up making an internal flag (nssl_hail_on) that is set based on the value model%nthl that comes from the get_tracer_index subroutine. That tells the microphysics interface whether the hail variables actually exist or not, so that a separate interface isn't needed. I hope that's an appropriate strategy. (It seems that one has to be careful to set namelist imp_physics to match the suite selection, as I don't see a way to check this at runtime.)

In each case, there are two imp_physics options to predict CCN (imp_physics_nssl2mccn or 18) or not predict (imp_physics_nssl2m or 17). Both tracers.txt files include the CCN tracer. In GFS_typedefs.F90, can I turn this off at will by setting Model%ntccn = -99 if I want CCN to be "off"? Or is it easier to just let it exist and always be zero?

I still need to run SCM tests for the other cases, and I have a further question about my sensible heat flux results. (It's not clear why it is low, nor why it would increase if I subdivide the time step for the microphysics.)

-- Ted M.

Permalink

Submitted by grantf on Mon, 10/26/2020 - 11:33

Hi Ted,

I think that your strategy for setting the internal hail flag based on whether the hail tracer is read from the tracer file is OK. You're right that it is important to make sure that imp_physics matches what is in the SDF. This is a redundancy that will hopefully be removed soon. In fact, while the SCM moved to setting tracers externally to match FV3, there has been some talk within the CCPP framework group to change how this is done in all CCPP models (including FV3 and SCM). The idea is that the physics should control which tracers are being used and to have the CCPP framework generate the code to handle tracers based on what physics exist in the SDF one is trying to run. I don't have many details or a timetable for when this change will be implemented though.

Regarding the CCN tracer, I'm a little confused as to why this is different then what was done with hail -- e.g, why there wouldn't be separate tracer files for hail + ccn, hail only, ccn only, no hail or ccn. At first blush, I suppose I don't see a problem with setting ntccn = -99 based on the value of imp_physics, but the SCM isn't really doing anything with tracers other than water vapor outside of the physics (although there probably should be a flag to control whether prescribed vertical velocities should "advect" tracers other than water vapor). In the FV3, there definitely is a computational penalty for carrying a zero-valued tracer, so I would definitely avoid it in that case. It's probably fine for research purposes, but carrying additional non-functional advected quantities will definitely slow it down and would likely not be acceptable in operations.

As far as sensible heat flux with the TWPICE case, it is definitely "muted" (less variability) than the observations with ALL suites. IIRC, the TWPICE field campaign domain was mostly over ocean, but had a station or two over land. I think that the surface flux observations are averaged over all points (both water and land), so that the variability of the land point(s) is swamping the variability from the ocean points. I think this is silly, but that is how the data was shared with me.

As far as the flux increasing if the microphysics timestep is subdivided, that definitely sounds like a bug somewhere.

 

 

Permalink

Submitted by ted.mansell on Mon, 10/26/2020 - 18:02

Thanks for the reply!

For the CCN, I was really trying to avoid a proliferation of tracer.txt files. Maybe there would be a way to build a tracer file "on the fly"? It seems the GSD/Thompson micro are set up to always have the two aerosol arrays (tracers_gsd.txt), but there is a separate namelist flag to use those or not.

I'm puzzled by the sensible heat thing. The precip rates seem to be fine with sub-stepping the microphysics. Those are the only arrays that looked like they needed to be accumulated on each sub step, but maybe there is another that I missed? (And in any case would seem backwards to expectation.)

Sitemap

Contact

303.497.8921
dtcenter@ucar.edu

Addresses

mailing:
PO Box 3000
Boulder, CO 80307-3000

Shipping:
3090 Center Green Dr.
Boulder, CO 80301

Follow Us

YouTube Icon
Twitter Icon

Copyright © 2024. All rights reserved.