output detailed aerosol radiation properties

[mahf708]

Adds additional detailed diagnostic outputs for aerosol radiation properties.

These diagnostics have long been used for production simulations (e.g., as inputs for SPA in SCREAM), but the code has never been incorporated in the main repository. The additions first include adding a visible-only AER_TAU_SW_VIS output to compare against AODVIS (if it weren't for not setting the night times to a fillvalue, the sum of this new output will be exactly the same as AODVIS). The more substantive addition are the optical properties needed for SPA MODAL_AER_TAU_SW, MODAL_AER_SSA_SW, MODAL_AER_G_SW, and MODAL_AER_TAU_LW. These outputs require adding two new history coordinates (swband and lwband), and can be ordered for RRTMG or RRTMGP (default to RRTMGP).

[BFB]

[github-actions]

PR Preview Action v1.4.7
🚀 Deployed preview to https://E3SM-Project.github.io/E3SM/pr-preview/pr-6317/
on branch gh-pages at 2024-08-09 02:06 UTC

[mahf708]

A blocker: the new higher-dimensioned fields make it impossible to restart the model. The error is of this sort: ERROR: set_field_dimensions: mdim size must be > 0 (the new dims are registered¹ correctly, but I suspect upon restart, the model tries to register them again and ends up failing with a zero dimsize)

To reproduce the fail:

./create_test ERS.ne4pg2_oQU480.F2010.eam-wcprod_F2010_spao

Footnotes

1. I also think we should print out the registration information by uncommenting lines like this in all the interfaces. ↩

[singhbalwinder]

Looks good to me! I have left some very minor nit-picky comments.

[mahf708]

Hi @singhbalwinder, thank you for the quick review! I have made some edits in response to your review. I also intentionally exposed the blocker to this PR in a testmod for repro and debug

# the ERS test fails upon restart with ERROR: set_field_dimensions: mdim size must be > 0
./create_test ERS.ne4pg2_oQU480.F2010.eam-wcprod_F2010_spao

Do you happen to have seen such errors before? Any tips? Thanks!

A (potentially useless) tip for debugging: P3_input and P3_output are two fields that can be requested as output in tapes and they share very similar characteristics to the fields in this PR, but they don't cause the restart issue.

[mahf708]

This shouldn't be merged until we figure out the restart bug. I think I heard of similar reports...

[rljacob]

Any progress on restart issue?

[mahf708]

Any progress on restart issue?

Someone will need to take a deeper dive to figure it out. Our code has diverged significantly enough from CAM. I am afraid to be the one taking the plunge here because it may just drive me crazy... :/

[mahf708]

After three months, I don't think I will be able to dedicate enough time for this PR. I don't like keeping stale PRs open, so I will close it. My thinking here is the following: We simply don't have bandwidth to resolve this niche issue (as much as I'd like it resolved for good). We are also potentially moving to C++ and so this is likely all moot anyway (at least for me personally). Closing.

[mahf708]

@rljacob, this is finally ready!

[singhbalwinder]

Thanks, Naser! Overall looks good to me but I have requested some minor changes.

You have added testmods but I don't see any new test added in this PR. Will there be a follow up PR with a test?

[singhbalwinder]

Since it can carry only two values, can we make it a boolean rather than an integer?

If we assign 1 to this variable by default, would it change the answers? I think it will at least change the netcdf files to add or change a dimension. The output files can be NBFB.

[mahf708]

Just diagnostic outputs (and I think it will DIFF even if the fields are not requested, because the coords will DIFF)

[mahf708]

In the next edit, I will set this to FALSE (i.e., have it go with the default radiation scheme, unless the user requests it otherwise in the namelist --- so, I will add this to the namelist too)

[singhbalwinder]

We should label it NBFB if it is going to cause DIFFs in the nightlies.

[singhbalwinder]

Unless I am missing something, sw_band_midpoints, sw_band_midpoints_p and lw_band_midpoints can all be local variables for subroutine modal_aer_opt_coords.

[singhbalwinder]

We should make rrtmg_to_rrtmgp_swbands a parameter to protect it from accidental changes.

[singhbalwinder]

I would call the modal_aer_opt_coords subroutine from modal_aer_opt_init rather than physpkg.F90. physpkg.F90 calls modal_aer_opt_init and it will be called during the model initialization.

[mahf708]

Thanks for the good reminder! Really, this routine doesn't belong in modal_aer_opt to begin with. I will move it to radiation_init (which is what is called by physpkg; it also calls modal_aer_opt_init). That way, this is a model-wide coord setting. I will also add a namelist parameter to allow the user to choose which coord they want and set it for rrtmg (i.e., no reordering, which default for model)

[singhbalwinder]

Yeah, that would be a better place to call it. If it doesn't work in the *init routine, you can call it from the *register routine.

[singhbalwinder]

We only use sw_band_midpoints_p if output_aer_props_rrtmgp == 1. We can rewrite this logic so that the model compute fields only if they are needed. For example (just a suggestion):

   ! Set history file coordinates for the short wave
   call get_sw_spectral_midpoints(sw_band_midpoints, 'nm')   
   if (output_aer_props_rrtmgp == 1) then
      ! Reorder bands to match RRTMGP order
      do i_nswband = 1, nswbands
         sw_band_midpoints_p(i_nswband) = sw_band_midpoints(rrtmg_to_rrtmgp_swbands(i_nswband))
      end do
      call add_hist_coord('swband', nswbands, 'Shortwave wavelength', 'nm', sw_band_midpoints_p)
   else
      call add_hist_coord('swband', nswbands, 'Shortwave wavelength', 'nm', sw_band_midpoints)
   end if
   
   ! Set history file coordinates for the long wave
   call get_lw_spectral_midpoints(lw_band_midpoints, 'nm')
   call add_hist_coord('lwband', nlwbands, 'Longwave wavelength', 'nm', lw_band_midpoints)

[mahf708]

@singhbalwinder I added the testmod here. I wasn't planning to add it to tests.py (our test suites) but I could do that. Any recommendation for which test suite to add this to? Paging @rljacob for advice as well :)

[singhbalwinder]

Sorry, I missed this file. This looks fine to me unless we would like to compare against the baselines. If we want to add it to the nightlies, we can add it to one of the integration suites.

[rljacob]

Add it to e3sm_atm_integration

[rljacob]

Can you see if there's a CF standard name for any of these new variables and add it to the addfld call?
https://cfconventions.org/Data/cf-standard-names/current/build/cf-standard-name-table.html

[rljacob]

I did some searching and looks like aerosol-radiative properties broken down by short/longwave are not there.

[mahf708]

I think this applies (if we choose to):

atmosphere_optical_thickness_due_to_ambient_aerosol_particles
alias: atmosphere_optical_thickness_due_to_ambient_aerosol
alias: atmosphere_optical_thickness_due_to_aerosol
The optical thickness is the integral along the path of radiation of a volume scattering/absorption/attenuation coefficient. The radiative flux is reduced by a factor exp(-optical_thickness) on traversing the path. A coordinate variable of radiation_wavelength or radiation_frequency can be specified to indicate that the optical thickness applies at specific wavelengths or frequencies. The atmosphere optical thickness applies to radiation passing through the entire atmosphere. "Aerosol" means the system of suspended liquid or solid particles in air (except cloud droplets) and their carrier gas, the air itself. "Ambient_aerosol" means that the aerosol is measured or modelled at the ambient state of pressure, temperature and relative humidity that exists in its immediate environment. "Ambient aerosol particles" are aerosol particles that have taken up ambient water through hygroscopic growth. The extent of hygroscopic growth depends on the relative humidity and the composition of the particles. To specify the relative humidity and temperature at which the quantity described by the standard name applies, provide scalar coordinate variables with standard names of "relative_humidity" and "air_temperature". The specification of a physical process by the phrase due_to_process means that the quantity named is a single term in a sum of terms which together compose the general quantity named by omitting the phrase.

emphasis:

A coordinate variable of radiation_wavelength or radiation_frequency can be specified to indicate that the optical thickness applies at specific wavelengths or frequencies.

[mahf708]

And technically, we can merge the SW and LW, but that may be a bit of a messy work...

[mahf708]

Here's the others:

asymmetry_factor_of_ambient_aerosol_particles
The asymmetry factor is the angular integral of the aerosol scattering phase function weighted by the cosine of the angle with the incident radiation flux. The asymmetry coefficient is assumed to be an integral over all wavelengths, unless a coordinate of radiation_wavelength is included to specify the wavelength. "Aerosol" means the system of suspended liquid or solid particles in air (except cloud droplets) and their carrier gas, the air itself. "Ambient_aerosol" means that the aerosol is measured or modelled at the ambient state of pressure, temperature and relative humidity that exists in its immediate environment. "Ambient aerosol particles" are aerosol particles that have taken up ambient water through hygroscopic growth. The extent of hygroscopic growth depends on the relative humidity and the composition of the particles. To specify the relative humidity and temperature at which the quantity described by the standard name applies, provide scalar coordinate variables with standard names of "relative_humidity" and "air_temperature".

single_scattering_albedo_in_air_due_to_ambient_aerosol_particles
"Single scattering albedo" is the fraction of radiation in an incident light beam scattered by the particles of an aerosol reference volume for a given wavelength. It is the ratio of the scattering and the extinction coefficients of the aerosol particles in the reference volume. A coordinate variable with a standard name of radiation_wavelength or radiation_frequency should be included to specify either the wavelength or frequency. "Aerosol" means the system of suspended liquid or solid particles in air (except cloud droplets) and their carrier gas, the air itself. "Ambient_aerosol" means that the aerosol is measured or modelled at the ambient state of pressure, temperature and relative humidity that exists in its immediate environment. "Ambient aerosol particles" are aerosol particles that have taken up ambient water through hygroscopic growth. The extent of hygroscopic growth depends on the relative humidity and the composition of the particles. To specify the relative humidity and temperature at which the quantity described by the standard name applies, provide scalar coordinate variables with standard names of "relative_humidity" and "air_temperature". The specification of a physical process by the phrase "due_to_" process means that the quantity named is a single term in a sum of terms which together compose the general quantity named by omitting the phrase.

[mahf708]

radiation_wavelength
alias: electromagnetic_wavelength
The radiation wavelength can refer to any electromagnetic wave, such as light, heat radiation and radio waves.

[mahf708]

Could you point me to how I could add the CF names to these fld calls?

[rljacob]

Use the standard_name optional argument at the end of the call.

call addfld ('MODAL_AER_TAU_SW', (/'lev ','swband'/), 'A', '1', &
'Aerosol shortwave extinction optical depth', flag_xyfill=.true., &
standard_name='atmosphere_optical_thickness_due_to_ambient_aerosol_particles')

[mahf708]

If I try to set the coords in a more coherent manner in radiation (as opposed to the ad hoc manner in the modal model), I get into all sorts of problems. I am going to give up on this. I wasted way too much time debugging this and trying all sorts of different things to make it work. It's simply not worth it. I am going to close the PR (again) and move on.

The PR as-is works and is in good shape. However, it is bad design to define these coords in modal_aer_opt. They should be defined as intrinsic part of radiation. When I try to move there, things break down.

If someone is interested in this type of PR, the current state is a good (and working) starting point. Before merging to mainline E3SM, the coords should be handled gracefully in radiation (not in the modal model).