Closed adamrher closed 4 years ago
Yes, you cannot put a use statement for phys_control in micro_mg3_0.F90
Add the namelist variable to micro_mg_init instead, and then put the use statement where micro_mg_init is called in micro_mg_cam.
Hope that makes sense.
Also: is this generic? I.e., you might want to do this with any mass flux scheme? I.e. should it be specific to CLUBB? I would prefer if it was not named 'clubb_mf' but rather for what it is doing (I think it is shutting off precip right?).
Thanks!
Andrew
@andrewgettelman as it is currently formulated, it is specific to clubb. This is because the mass fluxes are added to the RHS of the clubb solver. Down the road, I may be able to pull it out of clubb's code entirely, but for this initial implementation, I am keeping it as is.
This PR should be viewed as a preliminary implementation so that we can start testing and improving it on the cam trunk. As soon as it's on the trunk, we had discussed having a mtg with you, Mikael, Kay ... to discuss how we can move forward with the microphysics ... at that point the do_clubb_mf will either no longer be needed in PUMAS or it will be used to flag PUMAS to do microphysics for the mass fluxes.
Ok, so this is not a lot of code updates, and we can bring it in with just a couple of changes. As Andrew suggested, please change this to go through micro_mg_cam.F90 as a passed-in parameter to the micro_mg_tend function, rather than using cam-specific code in micro_mg3_0.F90. Also, you somehow managed to have a conflict with only like 4 code changes. I think that's super impressive! You'll need to resolve that conflict before I can merge this PR. Thanks!
@Katetc Working on passing through in micro_mg_cam.F90 right now.
Re: conflicts. When I was doing the PR, I noticed the conflicts. But when I switched from comparing the head of the cam/release branch with the older tag cam-release_v1.3, there were no conflicts. This is because this is what I forked/branch off of ... So I presume to resolve the conflicts by fork/branching off of the head of cam/release? BUT isn't that a problem because the cam externals on the cam trunk are pointing to the old puma tag cam-release_v1.3?
Adam, I have a PR that will be a cam trunk tag... maybe next week that updates to the next PUMAS tag. You can either update to the most recent PUMAS code, or just put those two lines in the file like a little bit further down. Working off the head of the release/cam branch shouldn't hurt your trunk tag, though.
Committed changes bringing the namelist through micro_mg_cam and micro_mg_init.
Here is my forked/branch off of cam that contains the new namelist variable do_clubb_mf that is used in this PUMAS PR: https://github.com/adamrher/CAM/tree/cam6_2_039.clubb-mf
fixes https://github.com/ESCOMP/PUMAS/issues/4