Hi,
I processed WRF outputs from 3 nested domains, 36-12-4km using MCIPv5.3.3. All variables in MCIP outputs for 36km and 12km domain look fine, however, the RC value (convective precipitation) in all MCIP output files is -9e+20 in all grid cells of 4km domain. I checked 4km WRF outputs and saw nothing wrong with all variables related to precipitation as below, they all have reasonable values,
RAINC:description = "ACCUMULATED TOTAL CUMULUS PRECIPITATION" ;
RAINSH:description = "ACCUMULATED SHALLOW CUMULUS PRECIPITATION" ;
RAINNC:description = "ACCUMULATED TOTAL GRID SCALE PRECIPITATION" ;
SR:description = "fraction of frozen precipitation" ;
PREC_ACC_C:description = "ACCUMULATED CUMULUS PRECIPITATION OVER prec_acc_dt PERIODS OF TIME" ;
PREC_ACC_NC:description = "ACCUMULATED GRID SCALE PRECIPITATION OVER prec_acc_dt PERIODS OF TIME" ;
I am wondering if this problem is associated with cumulus scheme used in WRF.
If anyone was confronted with the same or similar problem. I really appreciate if you can share your ideas how to fix it.
Thanks.
Feng
This likely is due to the fact that you switched off cumulus parameterization for the 4 km grid, relying instead on convection to be resolved through grid-scale processes. Do you have non-zero RAINC values for the 4 km grid in your wrfout files?
As documented in the MCIP change log, in cases where cumulus parameterization was not used for a given WRF grid, starting with version 5.0 MCIP uses a large negative fill value (set to -9.0e20) for the convective rainfall variable RC (prior versions of MCIP used -1).
CMAQ then screens for such negative RC values to set an internal logical variable CONVECTIVE_SCHEME that controls some of the behavior in convcld_acm.F because that behavior depends on whether or not cumulus parameterization was used in WRF. Put differently, these negative fill values are a way for MCIP to communicate to CMAQ that no cumulus parameterization was used in WRF.
Hello Christian,
Thank you very much for the detail information and explanation. Now I know why I got the large negative fill value for the RC.
Yes, I turned off cumulus scheme for the 4 km grid when I ran WRF4.3 for 2-way nested 36-12-4 km domains because cumulus scheme is better to set for dx >10km grids according to NCAR and physically reasonable. But I can try to switch on cumulus parameterization for the 4 km grids later on.
I noticed that RC and RN in MCIP output are read from PREC_ACC_C and PREC_ACC_NC in WRF output, respectively. I am wondering which variable(s) in MCIP output is based on RAINC and RIANNC from WRF. You can see the RAINC and RIANNC are dealt with by rdwrfem.f90 in MCIP package (I am sorry for not diving in the code for details).
My understand is RAINNC cumulates all hourly PREC_ACC_NC as daily total precipitation for that day.
Thanks.
Hi Feng,
unless you want to test whether you are getting better 4 km cloud and precipitation fields with cumulus parameterization switched on compared to the run you already performed, there isn’t any need to do so from an MCIP/CMAQ perspective. The negative RC values in the 4 km MCIP files you already generated are the intended behavior and are handled properly by the cloud and deposition routines in CMAQ. They are also handled by the species definition files for ‘combine’ when defining total precipitation variable ‘precip’ as the sum of MCIP RN and RC if RC is greater than 0 and as only RN otherwise.
As for the hourly incremental (PREC_ACC_##) vs. accumulated-since-the-simulation-start “bucket” (RAIN##) wrfout precipitation variables, my understanding is that starting with version 4.2 MCIP will try to directly read the hourly incremental variables if they are available from WRF since they directly correspond to what MCIP variables RC and RN represent (i.e. rainfall for that hour). However, these hourly incremental rainfall variables are not always available from WRF, so as a fallback MCIP will use the difference in the “bucket” values RAIN## between the current hour and the previous hour to calculate the hourly RN and RC values. The MCIP change log indicates that for MCIPv5.0 there was a change in how MCIP determines whether incremental precipitation is available from WRF. @tlspero , please jump in if my understanding is wrong or incomplete.
Hi Christian,
Thank you so much for your quick response and the updates. I see now I do not need to worry about negative RC precipitation, which is considered as a logical mark for CMAQ. I took a quick look at mcip/src/metvars2ctm.f90 and several CMAQ routines like cloud, phot, beis3 etc. and understand how those modules process and use precipitations from MCIP. Thanks for your guidance.
Your discussion on hourly incremental PREC_ACC_## and bucket values make me crystal clear about the different definitions of precipitation. Thank you.
According to the latest version of WRF and MCIP, I see that bucket may be outdated and not necessary to apply to MCIP/CMAQ.
I review the update logs of MCIP and the latest MCIP programs, I noticed that MCIP processes only few cumulus schemes (1, 5, and 11) used by WRF that now actually includes 18 cumulus options. May I miss something from MCIP if I use met_cumulus = 16, which is a newer Tiedtke scheme in WRF and not cited in MCIP?
Thanks.
Hi Feng,
unfortunately, I do not have an answer for your last question and will have to defer to @tlspero or others to answer it.
@FengLiu –
There is currently no restriction in MCIP (and, thus, CMAQ) on the cumulus scheme used in WRF. There are different flags in MCIP that can control the additional types of input expected from WRF and/or its treatment in the output fields. I have not explicitly tested with the Tiedtke scheme, so I cannot guarantee that all of the subgrid cloud information is handled fully and appropriately. But you are welcome to try it. I am not aware of any showstoppers.
To your point about RAIN(N)C vs. PREC_ACC_xx…I added the option to deal with the PREC_ACC arrays late (as pointed out by @hogrefe.christian), as these arrays are not always (and have not always been) available in the standard WRF output. The PREC_ACC arrays are the more straightforward presentation of the rainfall over the time period (usually one hour) without backing out the total from the bucket.
Hope this helps.
–Tanya