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[bot]]

PR Preview Action v1.4.7 :---: :rocket: 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[^1] 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

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

[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!

[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).