Implement CLUBB-MF functionality on trunk: PUMAS externals #4
Comments
adamrher
changed the title
|
I'm okay with this in principle. It needs a line of explanation about what it does in the code and why. I'm not sure why this is exactly needed. I think you are saying that CLUBB is doing precip now. That might be an issue going forward. I wonder if the model that Song and Zhang 2011 used for applying MG to a mass flux scheme could be employed? Happy to discuss further, and glad to see this moving along. |
|
Sounds good to me. You are forked and branching off the correct spot. The release/cam branch will be updated with the code going into the cam_development branch. Our master branch is used for more experimental work. |
|
It would be good for the 3 of us to talk. I think what Adam is doing first
is simply re-implementing what Mikael Witte did in his initial stab at
CLUBB-MF. The more I think about it, though, the more unsure I am about
Mikael's approach (or at least my understanding of it).
It seems to me that microphysics is being disabled to avoid autoconversion
of cloud-condensates from the MF part of CLUBB-MF. Why is it easier to
shut-off microphysics altogether than to intercept the condensates in the
MF scheme from being added to the total CLUBB condensates?
…On Fri, Aug 7, 2020 at 6:31 AM Andrew Gettelman ***@***.***> wrote:
I'm okay with this in principle. It needs a line of explanation about what
it does in the code and why. I'm not sure why this is exactly needed. I
think you are saying that CLUBB is doing precip now. That might be an issue
going forward. I wonder if the model that Song and Zhang 2011 used for
applying MG to a mass flux scheme could be employed? Happy to discuss
further, and glad to see this moving along.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#4 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACGLMTUENIWMRNGK7VPYBH3R7PX3ZANCNFSM4PXCNYVA>
.
|
|
The original intent of disabling microphysics was to make it easier to compare with LES output. SCAM was producing precipitation for the "non-precipitating" BOMEX shallow cumulus case (I suspect because of the use of climatological aerosol) and it was impacting my ability to understand the dynamical response of coupling CLUBB and MF. It will also be helpful to turn off "large-scale" precip as we begin working on microphysics in the plumes. Julio, I agree that we should have a more detailed discussion about the handling of MF condensate - I was planning to deal with MF microphysics separately from CLUBB because the microphysical evolution of a plume impacts its thermodynamical state. The current method of adding MF cloud fraction and condensate amount to CLOUD and CLDLIQ was really just a lazy diagnostic choice. Kay Suselj has been working on plume microphysics in the JPL SCM for a couple years now (separate from the Song and Zhang approach - he's close to finishing a paper on our work) and I don't think his method will be terribly difficult to merge with PUMAS (at least for warm rain), so I'd prefer to start there. |
|
I'm not a big fan of having multiple microphysics or tweaked microphysics for different condensate: this is the problem we have now of course between the ZM MF scheme and CLUBB+MG. I'm worried you are headed down the same path with the Suselj plume microphysics. If the problem was that it was raining when it should not be raining, this is a model bias, not a code bug. You could fix the number concentration in the microphysics (micro_nccons) to be high enough to not precipitate perhaps in SCAM? With CLUBB we are able to pass the condensate to MG. Is there a way to deal with the microphysics in the plumes? One option is to re-code the precipitation in MG as a subroutine and call it (or not) and other microphysical utilities from the plumes...this would keep the code consistent? |
|
@andrewgettelman - I 100% agree that we should avoid having different microphysics for different condensate. I'm open to pursuing something like the Song and Zhang approach, but let me give you a little more detail on how we do things in the JPL SCM first. We iterate over the dynamics+macrophysics integration (upward) and microphysics (integrated downward) a few times to reach convergence. This is required because we assume the mass flux plumes are at steady state (since the plumes are diagnostic) and it addresses one of the main weaknesses that Song and Zhang discuss in their approach, i.e. that integrating microphysics upward leads to underprediction of accretion. At present, we use KK2000 for autoconversion and accretion and Grabowski (1998) for evaporation so it should be relatively straightforward to adapt to MG2. The main limitation is that our current formulation of the microphysical source terms assumes power law-type process rates so it will take a new, more generalized derivation of the source term equations to adapt to Seifert-Beheng since SB's "universal functions" for autoconversion and accretion have a complicated dependence on q_c and q_r (assuming SB is indeed what you intend to be the default for PUMAS). That's the most significant obstacle I see at present. Your idea of (re-)coding subroutines that can then be called from within the plume integration subroutine seems ideal. We just need the process rate coefficients since all the microphysical variables (q_c, q_r, etc.) are computed internally, so it may be as simple as constructing something to pull those coefficients. I think this is a promising framework to start with. Lastly, fair point about hiking up micro_nccons to shut off precip. I will be the first to say my "turn it all off" approach came from not knowing the code and namelist options super well when I was getting started working on this. I'm fine jettisoning my modifications if there are simple methods of accomplishing the same outcome (e.g. no precip when an LES comparison case shows no precip). |
|
After reviewing namelists / configure options, I don't believe there is an ability to turn off MG while keeping CLUBB on (e.g., ./xmlchange --append CAM_CONFIG_OPTS=" -microphys none" errors out in the build namelists). I personally feel that this flexibility should be an available option for developers for debugging purposes ... and so I think sneaking this in as a hard coded logical in the microphysics is the most incognito / exclusive means to provide that flexibility. |
|
To Mikael: If you want to use KK2000 instead of SB2001, that's fine. I'm now testing a different machine learning emulator of the stochastic collection kernel from a bin model, so it's evolving. My point is just to make it consistent if you can. to Adam: micro = none and turning off precip in MG are two entirely different things. If you want to add a micro = none, just do that around the interface for the microphysics in physpkg if that is what you want. Then you wont call stratiform microphysics and won't update tendencies. |
|
My PUMAS branch is ready for a PR, but I'm confused on how to do this because I added a dependency on a namelist variable that I added to phys_control.F90 in the CAM source code. Specifically, I call the new namelist var like this in micro_mg3_0.F90: use phys_control, only: phys_getopts Do I need to do a PR for CAM first that includes this new namelist variable, that is part of the phys_ctl_nl group? |
|
So, CAM points to a tag of our release branch. You can do the PUMAS PR first, and we'll make a new tag. Include that new tag in your CAM PR. All good. |
|
Adam, please include a link to your CAM development branch in your PUMAS PR as well. Did you put the namelist variable in Phys_control because it is used in multiple places throughout the physics? I'd like to take a peek at how you implemented this. :) |
|
yes, the namelist var is used in clubb_intr.F90 as well. Ill attempt at a PR now. |
|
Sorry, not on github right now, but you cannot put use statements in the micro_mg3 module. That is portable code. It needs to come in via namelist in the init methods. The use statement for physopts can only be in micro_mg_cam
Cheers,
Andrew
o__ __ Dr. Andrew Gettelman andrew@ucar.edu
_,>/'_ -- http://www.cgd.ucar.edu/cms/andrew/ +1.303.497.1887
(_) \(_)-- National Center For Atmospheric Research
1850 Table Mesa Dr, Boulder, CO, USA 80305
… On Aug 21, 2020, at 12:39, Adam Herrington ***@***.***> wrote:
yes, the namelist var is used in clubb_intr.F90 as well. Ill attempt at a PR now.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
got it. making those mods when done with this mtg. |
|
This issue is addressed in PR #5 , which is now merged in! |
This issue is associated with the CPT to test / implement CLUBB-MF (MF = mass fluxes) into CAM, in coordination with JPL / UCLA & NCAR (@mikaelwitte, @JulioTBacmeister). For more information, please refer to the main issue at the cam repo here: ESCOMP/CAM#181.
The purpose of this issue is to get a primitive working version of CLUBB-MF onto the cam trunk ASAP. The mass fluxes as they are currently implemented do compute in-plume condensation, but adding this to the condensation from CLUBB macrophysics and passing this on to MG2 is not an appropriate treatment for microphysics associated with the plumes. So as a starting point for developing CLUBB-MF, we are turning off the MG microphysics, and are focusing on non-precipitating cases.
The current way that we switch off microphysics is by adding a do_rain=.false. logical to skip the main loop in subroutine micro_mg_ten. You can view this implementation by searching for "ARH" in micro_mg3_0.F90 in my forked / branch pumas_cam-release_v1.3.clubb-mf. This forked / branch is still being tested and is not ready to be merged as of now. I will respond to this thread when the code is ready.
So the specific goal of this issue is to introduce code mods to turn off MG3 microphysics while keeping CLUBB on. @andrewgettelman does introducing this do_rain logical seem like the best / easiest way to do this?
In the future, we plan to open PUMAS issues to cater the microphysics to be physically consistent with the mass fluxes in CLUBB-MF.
The text was updated successfully, but these errors were encountered: