Question about converting between dry and moist mixing ratios #959
Replies: 2 comments 4 replies
-
Hi @hannahcbarnes. I think that you're correct that it should be converted to a dry mixing ratio at the beginning of the driver and back to wet mixing ratio at the end of the driver, assuming that the code in lines 944-976 assumes dry ratios. Your reasoning for why is the same reason that I'm seeing; that the clw array feeds back into the state variables and it is not just diagnostic or ignored. I would say that cliw should get the same treatment. I wonder if this code was written when we used to be under the impression that only the water vapor tracer variable was a wet mixing ratio (specific humidity)? We now know that all of them assume that the denominators of the mixing ratios contain masses of dry air + water vapor (but not hydrometeors). Sorry for taking so long to respond; I've been out sick for a while. @dustinswales Is this what you're seeing too? |
Beta Was this translation helpful? Give feedback.
-
@hannahcbarnes I think you're correct and there may be an error with how the GF convection is coupled to the radiation. For documentation purposes: The liquid and ice convective cloud mixing are computed within cu_gf_driver.F90, starting at line 972. These are defined with intent(inout), but as far as I can tell they are not computed anywhere else within the RAP suite. Then in GFS_suite_interstitial_4.F90 these convective (scaled) mixing-ratios are added to qg0, which as you point out as being incorrect. The cloud-to-radiation coupling is different for RRTMG and RRTMGP, so this manifests slightly different in each. |
Beta Was this translation helpful? Give feedback.
-
I am working with cu_gf_driver.F90. I know that many of the hydrometeor mixing ratios used in the physic portion of the code needs to be converted back and forth between dry and moist mixing ratios.
Towards the end of cu_gf_driver I found this comment,
! Scale dry mixing ratios for water vapor and cloud water to specific humidity / moist mixing ratios
At the start of cu_gf_driver, qv, qv2di, and forceqv are all converted. This makes sense; they are water vapor variables. Towards the end of cu_gf_driver, qv and cnvw are converted. cnvw contains cloud water. So my question is, why don't we have to scale clcw, which is the cloud water variable at the start and end of cu_gf_driver?
I asked someone I work with this question and he said clcw is an interstitial variable , so it is only used in physics and does not need to be scaled. This is true, clcw is part of the clw array, and is an interstitial variable. However, clw is filled from and feeds back into gq0 and gq0 ultimately goes in qgrs, which is used in radiation. These are stateout and statein variables, respectively. Does the fact that clw is connected to gq0 and qgrs impact whether it should be converted? I tried looking through other portions of the physics code that are related to clw and have not been able to find an instance where the clw array is converted.
If clcw should be converted, should cliw be converted as well? cliw is the ice mixing ratio, comes from clw, and is also connected to the gq0 and qgrs arrays.
Beta Was this translation helpful? Give feedback.
All reactions