Cloud Water

Submitted by hertneky on Wed, 09/15/2021 - 11:35
Forum: CCPP User Support | CCPP Single Column Model

For v5.0 there are 2 variables 'qc' and 'qc_conv'. I view 'qc_conv' to be the SGS partition from the convective parameterization and therefore included in 'qc', which is total. Is that correct?

Permalink

Submitted by hertneky on Thu, 09/16/2021 - 15:13

Hi Dom - Ah sorry, yes CCPP-SCM. Actually it was the v5.0.0-tutorial that I had played with and earlier versions (eg. v4). I have not run CCPP-SCM for v5.0.0 release (Note: I myself am currently using branch 'main' which does not have qc_conv in the SCM output.) However, I am still curious about the earlier v4 release since I am looking at/transitioning scripts that used output from that version.

Permalink

Submitted by grantf on Tue, 09/21/2021 - 14:09

Tracy,

Looking at the v4 SCM code, it looks like qc_conv is the amount of cloud water diagnosed by the deep convection scheme. This variable looks to be reset to zero at the beginning of each physics time step, so it is not persistent, nor is it advected around. The qc variable is the sum of the cloud liquid and ice mixing ratios that occur in the tracer concentration array. In the UFS, this variable is advected, but it is not in the SCM (since there is no dycore). It is modified by the microphysics scheme that can add to it due to grid-scale condensation or subtract due to precipitation processes or evaporation. It looks like the output code was also modified to include the SGS cloud water diagnosed by the MYNN PBL scheme, however. That cloud water is radiatively active, but does NOT get added to the cloud liquid and ice mixing ratios in the tracer array either (is instantaneously diagnosed in the physics and not advected in the UFS).

What gets written out in the scm output routine doesn't necessarily have to correspond to one particular variable in the physics. It can be modified by the user. For the purposes of the v4 code, though, what is described above was the way it was.

Permalink

Submitted by hertneky on Tue, 09/21/2021 - 16:34

Thanks Grant for the thorough response. I have some follow-up questions, now related to CCPP-SCM branch 'main' as I am working with this branch for a project.

I looked at the ccpp-scm/scm/src/scm_output.F90 and it looks like what is output is the same as in v4 (assuming I am looking in the right place):

 if (physics%model%do_mynnedmf) then
   call NetCDF_put_var(ncid, "qc",    scm_state%state_tracer(:,:,scm_state%cloud_water_index,1) + &
                                      scm_state%state_tracer(:,:,scm_state%cloud_ice_index,1)   + &
                                      physics%Tbd%QC_BL(:,:), scm_state%itt_out)
 else
   call NetCDF_put_var(ncid, "qc",    scm_state%state_tracer(:,:,scm_state%cloud_water_index,1) + &
                                      scm_state%state_tracer(:,:,scm_state%cloud_ice_index,1),    &
                                      scm_state%itt_out)
 endif

So, what you described for v4 also applies to branch 'main' for the output of 'qc'? 

New question: I am comparing two runs:

1. SCM v4.1 with CCPP GFSv16beta

2. SCM main with CCPP GFSv16

Run #1 has the variable qc_conv, but #2 doesn't - is it as simple as adding that to the scm_output.F90 to get that in the output?

Run #1 has non-zero values of cloud ice (qi), while run #2 is zero-filled for qi. The clouds for this case are shallow and non-precipitating, and during the summer, so perhaps no cloud ice is correct, but I thought I would get your take on the difference in qi between the two runs.

 

 

 

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.