The new crm_bulk module will be invoked by the "SP_CRM_BULK" preprocessor variable. This new module is still a work in progress, but the goal is to provide a framework that is similar to ECPP, but a much simpler implementation that can be used with both 1 and 2 moment configurations. The initial idea follows from the "crmclouds_camaerosols" module created by Minghuai Wang, which is to create wrappers around existing GCM routines and drive them with CRM data. Minghuai never got his version fully working, and instead focused on ECPP. In light of the difficulty we've had with ECPP, I think it would be good to have an alternative.
Currently, the only working component is the vertical convective transport part, but I have other parts of the framework in place for aerosol scavenging, diffusion, and droplet nucleation. These other components will take awhile to develop. There is an additional issue to work out with the transport scheme because the mass flux magnitudes coming out of the CRM are unrealistically small (~10^-25), so there is a problem somewhere in how these are calculated that I have not identified yet.
I also took Minghuai's appraoch a step further by essentially recoding the ZM bulk transport scheme as the new "crm_bulk_transport_tend" sunroutine, which is contained in the crm_bulk module. Offline tests verified that the new code gives the same bit-for-bit answers as the ZM code. Eventually, it will be nice to improve the algorithm a bit, by adding downdraft detrainment for example, but at least the variable names are more sensible and there are many more comments so altering the algorithm will be much easier and less like deciphering hieroglyphics.
Additionally, I made several changes that are mostly cosmetic, but also reorganize the code in a more sensible way. Most of these changes should not affect the regression testing. The one exception is the SP2 case, because I added a check for ECPP such that when ECPP is not used, the conventional GCM routines are used how they are used in the SP1 case. I think this makes more sense for now, so if there are diffs there, we can safely ignore them.
The new crm_bulk module will be invoked by the "SP_CRM_BULK" preprocessor variable. This new module is still a work in progress, but the goal is to provide a framework that is similar to ECPP, but a much simpler implementation that can be used with both 1 and 2 moment configurations. The initial idea follows from the "crmclouds_camaerosols" module created by Minghuai Wang, which is to create wrappers around existing GCM routines and drive them with CRM data. Minghuai never got his version fully working, and instead focused on ECPP. In light of the difficulty we've had with ECPP, I think it would be good to have an alternative.
Currently, the only working component is the vertical convective transport part, but I have other parts of the framework in place for aerosol scavenging, diffusion, and droplet nucleation. These other components will take awhile to develop. There is an additional issue to work out with the transport scheme because the mass flux magnitudes coming out of the CRM are unrealistically small (~10^-25), so there is a problem somewhere in how these are calculated that I have not identified yet.
I also took Minghuai's appraoch a step further by essentially recoding the ZM bulk transport scheme as the new "crm_bulk_transport_tend" sunroutine, which is contained in the crm_bulk module. Offline tests verified that the new code gives the same bit-for-bit answers as the ZM code. Eventually, it will be nice to improve the algorithm a bit, by adding downdraft detrainment for example, but at least the variable names are more sensible and there are many more comments so altering the algorithm will be much easier and less like deciphering hieroglyphics.
Additionally, I made several changes that are mostly cosmetic, but also reorganize the code in a more sensible way. Most of these changes should not affect the regression testing. The one exception is the SP2 case, because I added a check for ECPP such that when ECPP is not used, the conventional GCM routines are used how they are used in the SP1 case. I think this makes more sense for now, so if there are diffs there, we can safely ignore them.