Implement "no aerosol" option in scream v1

[hassanbeydoun]

v0 had an option of turning off aerosols by setting do_aerosol_rad and micro_aerosolactivation to false. The former bypasses aerosol calculations in radiation.F90 and sets aerosol optical properties to zeros while the latter sets nc to a constant value saved in p3_utils. Having this option in v1 will allow comparisons with v0 without SPA.

The v1 p3 code still uses do_prescribed_CCN and do_predict_nc so we can set those to false and have our constant drop number option going. The radiation however does not seem to have a "do_aerosol_rad" equivalent so more work might be needed there.

@AaronDonahue @brhillman @PeterCaldwell let me know if you have any thoughts. I'll post updates as I have them.

[PeterCaldwell]

Additional context - I see this innocuous issue as the path forward for getting ne512 and ne1024 working in the short term (by bypassing the memory bottleneck in SPA init). So I think it is high priority. In my mind, this should be easy but requires changes to our user interface that I don't know how to do - basically, we need to create an option that bundles a couple of user interface options: do_prescribed_CCN=False, do_predict_nc=False, and aerosol optical properties should all be initialized to zero. We also need to specify the prescribed nc value we want to use... I'm not sure if that is possible yet.

Do you have comments on how this could be done, @jgfouca , @bartgol , @AaronDonahue ?

[AaronDonahue]

I've been chatting with @hassanbeydoun on Slack about this... Some thoughts so far:

1. Adding do_prescribed_CCN and do_predict_nc as runtime options should be fairly straightforward. They can just be added to the parameter list in the namelist_defaults.xml file for SCREAM.
2. We will need to put some checks into rrtmgp to essentially grab 0 valued arrays when aerosol is turned off. Note, P3 already has some infrastructure for handling cases when aero is turned off so we just need to pass the correct logical there.
3. I think, that in cases where all of the aero_blah_sw/lw variables are going to be unused, we shouldn't even add them to the field manager. Probably the same with nccn. I think we will just need to add conditionals in the p3 and rrtmgp interfaces to either get those fields when active, or later on assign those fields (as they are used) to some zero array.

[jgfouca]

@PeterCaldwell , you mentioned on the telecon that you wanted me to help with this. I can definitely help with point 1 from @AaronDonahue 's list. I can potentially help with 2,3 too but I would need just a bit of guidance as far as what files to look at.

[AaronDonahue]

@jgfouca , I've started a branch which addresses (1) above, I'm testing now. We can go from there. We will need to do something similar for the rrtmgp variables. For the moment I'm just focusing on p3.

[AaronDonahue]

I've started the branch aaron_hassan/set_do_prescribed_aero (https://github.com/E3SM-Project/scream/tree/aaron_hassan/set_do_prescribed_aero) to add this option.

[bartgol]

@jgfouca random idea for our XML handling (which might require some python work).

This option is an example (there may be more in the future) of 2+ parameters scattered across the XML file that need to be "synced". Not necessarily with the same value, but be "consistent". We could introduce XML-wide config knobs, which can be used at yaml-generation time to get the correct value of a parameter. E.g, we could have something like

<global_parameters>
  <use_spa>false</use_spa>
</global_parameters>
...
<atmosphere_processes>
  ...
   <mac_aero_mic inherit="atm_proc_group">
      <atm_procs_list use_spa="true">(shoc,cld,spa,p3)</atm_proc_list>
      <atm_procs_list use_spa="false">(shoc,cld,p3)</atm_proc_list>
      ...
      <p3 inherit="physics_proc_base">
         <do_prescribed_ccn>@use_spa@</do_prescribed_ccn>
         ...
      </p3>
   </mac_aero_mic>
   <rrtmgp>
     <use_spa_fields>@use_spa@<use_spa_fields>
     ...
   </rrtmgp>
</atmosphere_processes>

The idea is to have some parameters in the XML synced by tying their value to a single parameter, which we declare in a common section. The parameter value must not be resolved in the intermediate XML file, since the user could do atmchange global_parameters::use_spa=false. In a way, these global parameters could be used to switch N parameters with one atmchange call, ensuring that they are all consistent. Otherwise, the user would have to atmchange them all manually, with a non-negligible risk of forgetting one of them...

Taking this to the extreme, one could use the value of any XML parameter inside the @param_name@ syntax, but limiting us to a hard coded section like global_parameters might make the python code a bit less messy.

[bartgol]

Actually, using global_parameter entries as selectors complicates things (you'd have to keep both lines in the XML file, in case the user atmchanges the global parameter). But using them inside the parameter value is prob ok. Perhaps if we could have a "ternary" operator inside the XML entry, like

  <atm_procs_list>(shoc,cld,$(@use_spa@ ? spa, : ), p3)</atm_procs_list>

which evaluates to either (shoc,cld,spa,p3) or (shoc,cld,p3), depending on the value of use_spa at yaml generation time.

[AaronDonahue]

@bartgol , I like this suggestion. For example in the case of this issue. If we turn off SPA it would be good to automatically set do_prescribed_ccn to FALSE, otherwise we will get some strange behavior. Although, whatever system we set up should be robust enough to work for future prescribed aerosol models too. Presumably, SPA won't be the one and only in the future. I can think of other runtime arrangements where multiple parameters would need to be tweaked and having some dependency might be nice.

[AaronDonahue]

Closing, solved by #1715