Provide aerosol initialization support for SCM runs

[bogensch]

Code employs the aerosol specification methods of Lebassi-Habtezion and Caldwell (2015) to allow for scientifically credible SCM simulations. Specifically, the user can specify the liquid/ice concentration via the namelist or specify observed aerosols provided they are included in the IOP file. Also included in this PR are optional switches to turn off longwave and shortwave radiation calculations to enable a match of GCSS idealizations for certain cases. acme_developer tests have been peformed and this tag is bit-4-bit, as expected.

[BFB]

[singhbalwinder]

@wlin7 : Would you please help me reviewing these changes. I am not so familiar with how SCM works in the model. Please feel free to add more reviewers.

[wlin7]

No problem, @singhbalwinder . I am going to review the changes and add others as needed.

[wlin7]

Hi @bogensch, This PR covers multiple issues. I have reviewed all except one file: tracer_data.F90, which I will do after an update from you. Suggestions and findings itemized below.

1. An soag_ext_file is set in namelist_default_cam.xml. While this is ok for most of the AV1C compsets, it would make other pre-existing compsets that do not use this particular soag file inconsistent. In the current structure, the spec for this soag_ext file is done thru use_case files. True the SCM for ACME V1 needs to use this soag_ext_file; to not break existing compsets, we may have to put it in use case as well, just like for the compset AV1C-04P2. (@singhbalwinder, your opinion appreciated).

2. New compsets added in this PR, FSCM5 and F_SCAM5 are not fully ready. No companion use_case available. Cases created using these compsets would fail during buildnml, complaining scmlat and scmlon not set. More works needed for new compsets or a generic compset.

3. Between scamMod.F90 and iop.F90:

   i) "scm_diam" at line iop.F90 line 317 looks like typo error, and should be "scm_dgnum"?

   ii) "dsps" in iop.F90 declared and allocated but never used, while scm_div used but not allocated. Should "scm_div" be in place of "dsps"; similarly "aitken" allocated but not used. The codes appear to use scm_div for all modes.

iii) scm_dgnum, scm_std, scm_num, and scm_div are delcared as public allocatable arrays to be used by other modules (such as iop.F90). Don't know if it is safe to use public module variables like these. Just seem unusual to me. But please ignore this comment if you are confident with that.

iv) Those public allocatable arrays are used in tracer_data.F90; but in the declaration block of tracer_data.F90, it has
use scamMod, only : scm_observed_aero, single_column.

 Please update this file and I will review it later altogether.

4. micro_mg_cam.F90: no initialization for micro_nccons and micro_nicons. They are assigned to nccons and nicons, which are then passed to micro_mg_init_20 and assigned to ncnst and ninst. The current model has ncnst=100e6 and ninst=0.1e6, which would be disabled by this PR. This would break the model unless the values are always set via use case.

5. rrtmg/radiation.F90: not essential, but to be consistent, should the swrad_off block be moved before the call to output_rad_data, and the lwrad_off block before the LWCF calculation? BTW, I assume turning swrad or lwrad off must be used with prescribed surface fluxes. If yes, should it be enforced? Just curious.

Thanks.

[rljacob]

Please remove the changes to config_machines.xml from this branch and use a different PR for that (if needed).

[bogensch]

Thanks @wlin7 for your careful review. I have pushed changes to my branch to reflect your comments. Responses to some of your points below:

1. The soag_ext_file has been added to the SCM use_case

2. A use_case as been added for the F_SCAM5 compset. Note that this is fairly empty and would still fail during buildnml, provided the user doesn't provide the relevant information in their namelist. @PeterCaldwell and I prefer to keep it this way as we feel providing default settings (scmlat, scmlon, for instance) could result in unintended error. In other words, our goal is for the user to provide all information for the particular case they want to run at the script level rather than buried in the code with use_case's ect.

3. i) kept as is because "scm_diam" is the name of the variable in the the netcdf aerosol forcing files
   ii) This has been cleaned up according to your comments
   iii) investigated and kept as is
   iv) cleaned up. This was actually redundant as "use scamMod" is declared lower down in the relevant subroutine.

4. Defaults are added to the namelist for these values

5. Fixed the first part of your comment on this to deal with output_rad_data and LWCF calculation. I guess I'm a bit confused why turning off swrad and lwrad when only prescribed surface fluxes are used should be enforced. Would you mind elaborating on why this should be so?

[wlin7]

Thanks @bogensch for the quick work. I am comfortable with all your updates.

For 2) I agreed with you and @PeterCaldwell to let user be fully aware of doing what are intended with the SCAM generic. Would it be useful to have inline comments somewhere along with the compset alias to remind what are typically required to be set in user_nl, provided user would look up for such a generic compset?

I have yet to review the tracer_data.F90. Thanks for pointing out there is an appropriate "use scamMod" at the subroutine level. It should be good then.

For the 5), it was just out of my curiosity of the purpose of using swrad_off lwrad_off. My thinking is, when either of them is off, surface energy balance would be very different, which would affect the model calculated surface fluxes (latent and sensible heat), and the results will be up to interpretation. It does not have to be enforced with prescribed surface fluxes, though, esp. if there is consideration for more flexible experimental design.

[PeterCaldwell]

Thanks Wuyin for your careful review. Your suggestions have definitely improved the SCM! In terms of the last point - the goal of lwrad_off is to allow cases like RICO where the LW radiative cooling is prescribed as part of the "advective forcing" so it's not that there's no radiation (which would be a really weird case and users would deserve whatever bizarre surface fluxes they got), it's just that it's coming from somewhere other than the radiation scheme. Are you saying that LW fluxes at the surface are used directly by the surface flux calculation (which would screw things up unless fluxes were prescribed, as you suggest)? The swrad_off case is easier to justify - we see this case in the real world every time it's night outside! ;-)

[wlin7]

Thanks Pete for sharing your thoughts. This sounds good with me and it represents an important added capability for the SCM. Regarding LW fluxes at surface, I am not sure if they are directly used to calculate surface fluxes. My thought was that indirectly through energy budget, it definitely matters, esp. over an extended period of simulation. Nevertheless, the current implementation as is should be good to go.

[wlin7]

Hi Pete, I am quite ignorant of the aerosol science so I am just focusing on the code logic, aided by your inline comments, concerning prescribe_aero.F90 and tracer_data.F90.

In precribe_aero.F90 on resetting randn to 0, should it also check if scm_observed_aero = true?

Similarly in tracer_data.F90 on setting file%stepTime = true, should scm_observed_aero also be true, to maintain what has been used until this update?

The array q_a(3,6) has fixed shape, but used within loop over nmodes and nspec that would be dynamically obtained. Could this be a problem, say, when MAM4 is used?

In subroutine ver_profile_aero, your comments suggest to apply a threshold-based treatment below and above 500 hPa. This design does not appear to be realized by the current codes. Can you please double check whether the implementation or the comments should be updated?

[wlin7]

Forgot to mention: what is the implication of changing several true/fasle in cice/cime_config/config_component.xml from lower to upper case concerning CICE_AUTO_DECOM? Is it to fix SCM issue over ocean/ice grids? I had problem with SCM over ocean grids during cice.buildbnml and at runtime involving cice codes and build options. I had to apply some adhoc treatment to get over it. It would be great if this change fix it.

[bogensch]

Hi, Wuyin, we are keeping the first two modifications you mention in prescribed_aero.F90 and tracer_data.F90 as per the reasoning in Lebassi-Habtezion and Caldwell 2014.

For now, we will keep q_a(3,6) fixed shape since all the supported cases we will add to the ACME library (at this time) will only have observed aerosols for the three modes. In the future, we will update this, which will require further mods.

In regards to the ver_profile_aero, while i did not write this block of code, it seems to me the code is doing what the comments say.

Also, yes changes to CICE_AUTO_DECOM is to allow the SCM to run over ocean/ice grids, which was broken.

[wlin7]

Thanks Pete for the explanation. All are good with me, except that I remain confused between the comments and codes in subroutine ver_profile_aero. vertprof_aero(k) uses different assignment expressions for k=1, 2, and the others. I don't see how it recognizes the 500 cutoff.

Going over the code again, if in the following statement (within the 'else' block)

vertprof_aero(k)=1._r8/(1._r8 + exp(-2._r8*(initial_val * pi + pi/4._r8*(k-2))))

'k-2' in the right hand side is replaced with 'counti-2', it would realize the design as described in the comments. Did I miss something?

[bogensch]

ah, okay @wlin7, I see what you mean now. I cleaned up the code and updated the comments to match what is actually being computer (but kept the solution non-answer changing).

[wlin7]

Thanks Pete. I have no further comment on this PR.

[rljacob]

@singhbalwinder do you know how to clean up history? Some of the commits on this branch can be squashed together.

[singhbalwinder]

Do you mean interactive rebase?
git rebase -i

[rljacob]

Yes.

[singhbalwinder]

Ok, I will squash commits which do not add much meaningful info before merging to next.

[rljacob]

@singhbalwinder can you get this ready to merge?

[singhbalwinder]

@bogensch : I don't see this file on acem or cesm SVN inputdata servers. Would you please upload it on the server? Here are the instructions: https://acme-climate.atlassian.net/wiki/display/WORKFLOW/ACME+Input+Data+Repository#ACMEInputDataRepository-UploadingFiles(fordeveloperscreatingnewACMEconfigurations):

[bogensch]

@singhbalwinder done

[singhbalwinder]

Thanks!

[singhbalwinder]

@rljacob : Yes, I will work on it and merge it soon.

[rljacob]

@singhbalwinder can you merge this to next today? Its open.

[singhbalwinder]

merged to next