CAM
CAM copied to clipboard
clean up preexisting_ice logic in ice nucleation code
Issue Type
Code Clean-up
Issue Description
The preexisting ice logic is very confusing and I've consulted with @andrewgettelman about cleaning it up. Here's our convo:
Adam:
Hi Andrew,
I think I can tell from your code mods that you're no longer adding pre existing ice to heterogeneous nucleation, via these lines in nucleate_ice_cam:
if (cam_physpkg_is("cam_dev")) then call nucleati( & wsubi(i,k), t(i,k), pmid(i,k), relhum(i,k), icldm(i,k), & qc(i,k), qi(i,k), ni(i,k), rho(i,k), & so4_num, dst_num, soot_num, subgrid(i,k), & naai(i,k), nihf(i,k), niimm(i,k), nidep(i,k), nimey(i,k), & wice(i,k), weff(i,k), fhom(i,k), regm(i,k), & oso4_num, odst_num, osoot_num, & call_frm_zm_in = .false., add_preexisting_ice_in = .false.) else
However, the "use_preexisting_ice" namelist is still set to true for cam_dev. Are you retaining parts of this preexisting ice elsewhere in the code?
Andrew:
Bottom line: this should be cleaned up. I think it got put in this way because I was asked to be minimally invasive and we were trying to maintain multiple codes.
use_preexisting_ice is used for several things and is supposed to be left as true. I’m thinking it is a flag for CAM6 ice nucleation (partially).
add_preexisting_ice is different. In nucleate_ice (nucleati subroutine), ‘add preexisiting ice’ is only used to stop adding the existing ice number (as it says). In this routine, use_preexisting_ice is a conditional for calculating the amount of preexisting ice to add. It could also be switched off if add_prexisting_ice is false.
Places where preexisting ice is used:
- In microp_aero.F90 a minimum on the subgrid vertical velocity for ice (WSUBI) is set if false.
- In the initialization for nucleate_ice_cam.F90 prexisting ice = true is used as a conditional to add some history fields (This conditional probably should NOT be there: it may cause the code to fail if you select preexisting_ice = false and cam_dev = true)
- Nucleate_ice.F90 (see above)
I don’t think that #1 and #2 should be controlled by use_preexisting_ice, and #3 could be made more elegant.
Adam:
Thanks for taking a look at this. I just encountered #1 yesterday for the first time. I think we should just turn that into a namelist for the minimum wsubi, and set it to 0.2 for both cam6 and cam_dev. All the limiters on wsub/wsubi are nauseating, and I partially cleaned them up a few months ago but this needs to be simplified to 4 namelists IMO, a floor and a ceiling for wsub, wsubi. What I cleaned up earlier was an additional limiter applied to wsub after it's passed into dropmixnuc (look for "wsub_min_asf" in microp_aero, where asf stand for "after scale factor" since by the time wsub is passed into dropmixnuc it has already been scaled by wsub_scale). In hindsight I should've just ditched this asf limiter altogether. Maybe Ill do that this time around.
In terms of science it's just #1 and #3. And you're saying #2 is just diagnostics but may be very brittle. That's very good to know.
Will this change answers?
I Don't Know
Will you be implementing this yourself?
Yes, but I will need some help
Thanks Adam! FYI: I do not think it should change answers for cam_dev or cam if done correctly.
It would be great to loop @cmcclus on this also.