Add Cloud-J as new default photolysis option

[lizziel]

Name and Institution (Required)

Name: Lizzie Lundgren
Institution: Harvard University

Describe the update

This update introduces the Cloud-J photolysis package as the default method of computing J-values, replacing Fast-JX v7.0. Fast-JX remains as a compiler-time alternative to Cloud-J. Cloud-J is a new submodule in the GC-Classic and GCHP super projects and the PRs that add them should be merged at the same time as this PR.

Expected changes

All photolysis rates change in this update. A 1-month benchmark comparison of GEOS-Chem Classic 14.3.0 (dev) using Fast-JX versus Cloud-J is at https://ftp.as.harvard.edu/gcgrid/geos-chem/validation/cloudj_validation/1mo_benchmark. Global OH decreased by 0.35%, and both MCF and CH4 lifetimes increased by around 1%. A comparison using GCHP will be posted soon.

Sources of differences

The changes are predominately explained by differences in the handling of clouds between Fast-JX and Cloud-J. Other smaller differences are introduced due to differences in the computation of aerosol optical depth.

Differences in cloud handling

1. Criteria for ice versus liquid water cloud are different

   • Fast-JX: We compute liquid and ice water cloud optical depths (COD) to pass to Fast-JX by applying a temperature mask to the total cloud optical depth (State_Met%OPTD). Ice water COD is set to OPTD where T<=233K. Liquid water COD is set to OPTD where T>233K. Ice and liquid water cloud are assumed to never exist in the same grid cell at the same time.
   • Cloud-J: Cloud-J takes ice and liquid water paths rather than COD as input. To compute them we use the ice and liquid water cloud optical depths (TAUCLI and TAUCLW). This allows for the presence of both ice and liquid water cloud in the same grid cell.
   • Examples:
     • Plot 1a: Optical depth differences for ice water cloud after one timestep
     • Plot 1b: Optical depth differences for liquid water cloud after one timestep
   • Conclusion: The changes are an improvement over how we identify and quantify ice versus liquid clouds in Fast-JX.

2. Optical properties used for ice water clouds are different

   • Fast-JX: Fast-JX uses optical properties for irregular ice water cloud for all ice water cloud grid cells, meaning every grid cell with temperature less than or equal to 233K. Optical properties for hexagonal ice are not used.
   • Cloud-J: Cloud-J uses both irregular and hexagonal ice properties. Irregular is used for temperatures greater 233K which is the opposite of Fast-JX. Hexagonal is used for temperatures less than or equal to 233K.
   • Examples:
     • jv_spec_mie.dat: Fast-JX LUT for optical properties, including clouds. Only entries 10 and 14 are used for clouds in Fast-JX.
     • FJX_scat-cld.dat: Cloud-J LUT for cloud scattering properties. All entries in the file are used.
   • Conclusion: The changes are an improvement in computing ice water cloud optical depth.

3. Cloud optical depth is computed in Cloud-J from an approximate effective radius

   • Fast-JX: The total cloud optical depth from the meteorology is passed directly to Fast-JX. A simple scaling is applied to interpolate optical properties from a LUT for different wavelengths.
   • Cloud-J: Cloud-J does not accept optical depth as an input. Instead, it is computed within Cloud-J from effective radius [microns] and water path [g/cm2] which are passed as arguments to Cloud-J. Since these quantities are not available from the meteorology we compute them from the meteorology optical depths (TAUCLI, TAUCLW) and water content (QI, QL) within GEOS-Chem to pass to Cloud-J. The computation makes an assumption of extinction efficiency Q = 2.06 when calculating effective radius. We do this because all cloud effective radii are much bigger (2piReff >> 500 nm) so that Q (extinction efficiency = optical cross section / pirr) is nearly constant at 2.06 (see Cloud-J cloud LUT here).
   • Examples:
     • Plot 3a: Total column optical depth computed in Cloud-J with LUT Q values
     • Plot 3b: Same as above except using Q=2.06 in the Cloud-J optical depth calculation to more closely reconstruct meteorology optical depth from passed effective radius and water path
   • Conclusion: The extinction assumption in preparing Cloud-J inputs is an approximation and introduces some amount of error.

Impact of cloud differences on J-values

Below are differences after one timestep in NO2 surface and zonal mean J-values due to differences in cloud handling. Contributions from dust, hygroscopic growth aerosols, and stratospheric aerosols are disabled.

Aerosols

Differences are also caused by changes in the optical depth computation for aerosols. Fast-JX takes the aerosol optical depths computed within GEOS-Chem. In contrast, Cloud-J computes the optical depths from concentrations [g/m2] passed to the model and aerosol density and effective radius taken from the Cloud-J LUT FJX_scat-aer.dat. Concentrations passed to Cloud-J are constructed to mimic what Fast-JX does as closely as possible with the exception of stratospheric aerosols. Stratospheric aerosol concentrations passed to Cloud-J is simply SO4 everywhere

A detailed comparison of all aerosols in isolation, including J-values and optical depths, is on the Harvard ftp site here.

Out-of-the-box differences in J-values

Below are differences after one timestep in NO2 surface and zonal mean J-values. Unlike the previous plot, these include the contributions from aerosols (dust, hygroscopic growth, stratospheric). The difference pattern and magnitude strongly resembles the earlier plot that isolated only cloud differences. The large differences in the far southern latitudes are due to differences in stratospheric SO4 (see here and here) for reasons not yet well understood.

For more detailed comparisons of surface NO2, zonal mean NO2, and optical depths for each of the contributors to the computation of J-values, please see plots here.

Reference(s)

Prather, M. J.: Photolysis rates in correlated overlapping cloud fields: Cloud-J 7.3c, Geosci. Model Dev., 8, 2587–2595, https://doi.org/10.5194/gmd-8-2587-2015, 2015.

Related Github Issue(s)

geoschem/GCClassic#27
closes #953

[msulprizio]

@lizziel I changed the base branch to main to avoid having this PR closed when we remove a dev/* branch upon release of that version. Feel free to reassign it to a specific dev branch when these updates are ready.

[msulprizio]

@lizziel I have changed the target branch to main here to avoid having this PR closed when the dev/14.2.0 branch is eventually deleted.

[lizziel]

Tagging Chemisty Working Group Co-chairs et al: @mje1398, @christophkeller, @barronh, @luhu0, @jingqiumao, @randallvmartin, @sdeastham, @pratherUCI, @viral211.

Please see the PR description above for an analysis of Fast-JX versus Cloud-J.

[barronh]

Thanks for tagging us. And, thanks for the clear assessment of the source of differences. I see two out of three sources of difference are an improvement, and the third is maybe a degradation -- at least an approximation. The history document in the Cloud-J repo is very useful for understanding why we should make this move.

This seems like progress and I have just a couple questions. All questions are just for information:

1. How hard would it be to replace the lookup table Q with the better representation in the online version?
2. Are the integrated (i.e., binned) cross-section and quantum yield sources documented? (or inherited from Fast-JX?)
3. Is there a process for updating the integrated cross-section and quantum yields?

[mje1398]

There are surprisingly small differences between the old and the new.

I think there is probably a need for us to think about having the code in place to do the averaging of the cross sections and to do a bit of a think about whether they are the most up to date ones?

It would be useful to have the full definitions of the cross sections / Quantium yields somewhere and then the code to do the averaging.

I think there was some FORTRAN code floating around for doing that?

Perhaps we can re-code it into Python?

Mat

[lizziel]

@barronh and @mje1398, these are good points to discuss. Here are my thoughts.

How hard would it be to replace the lookup table Q with the better representation in the online version?

I am not sure what the better representation would look like. The meteorology optical depth presumably assumes a wavelength which would help target what Q to use to compute effective radius from it. For Fast-JX we assumed 600 nm and then scaled optical depth accordingly within Fast-JX for different wavelengths based on differences in Q. That also introduced error. @pratherUCI, do you have any comments on the Q=2.06 assumption? You suggested it with the logic that cloud Reff is large so Q is roughly constant. Would the error introduced be worth improving upon or is it less than or on par with other error in the model?

Are the integrated (i.e., binned) cross-section and quantum yield sources documented? (or inherited from Fast-JX?)

The GEOS-Chem species cross-sections and quantum yields are the same as used for Fast-JX. I adapted FJX_spec.dat LUT used in Cloud-J from the equivalent file used in Fast-JX. Both of those contain text for each species referencing the data source, e.g. J10. Additional notes on the sources are at the bottom of both files.

Is there a process for updating the integrated cross-section and quantum yields?

Do you mean regenerating the table using updated sources, or adding new species, or both? Michael Prather has a fortran tool available to do the averaging, and I copied it into the Cloud-J repository in the tools directory. As for regenerating the table for GEOS-Chem using new sources, I am not sure what prompts it to be done. I believe every now and then we receive updates from the community to put into the model. These are documented in the README within the Fast-JX folder on ExtData.

I think there is probably a need for us to think about having the code in place to do the averaging of the cross sections and to do a bit of a think about whether they are the most up to date ones?
It would be useful to have the full definitions of the cross sections / Quantium yields somewhere and then the code to do the averaging.
I think there was some FORTRAN code floating around for doing that?

The current code from Prather to do this is at https://github.com/geoschem/Cloud-J/tree/main/tools/AddXs. We are looking to the community to determine whether the sources used for GEOS-Chem are the most up to date ones. It would be great if we had a system in place for evaluating this periodically, and also documenting the sources better. One option is to store the tables and a description of the sources within the GEOS-Chem repository. The option could be there to use a file outside of GEOS-Chem, but the default could be local. The advantage of this is that it would be under version control.

Perhaps we can re-code it into Python?

It would be fantastic to have the tools/AddXs code in Python. @pratherUCI, are you open to this idea? I can do this work if it looks like it is worth it. Regardless, I want to make the tool easier to understand and use.

[sdeastham]

My two cents - I get hit with requests for help adding cross-sections from time to time, and would strongly support adaptation of the cross-section generation code into Python. I've seen at least one case of someone misinterpreting the nature of the wavelength bins with disastrous results (given that the high-frequency bins are actually weighted averages of non-contiguous wavelength bins, which is not obvious).

[jennyfisher]

Hi @lizziel @viral211 and all,

For the Hg simulation, can we just archive the aerosol concentrations from full chemistry and use those? I'm pretty sure the optical depth files we used before would have just been archived from a full chem simulation.

While I'm here, my 2¢ on the question of cross sections/quantum yields as a (relatively) frequent user of these processes. I would support having something that did this on the fly in GEOS-Chem. We could build in some caveats for new species - for example, forced stops that prompt the user to consider all the things @sdeastham and @pratherUCI mention above and to then manually remove the error message code (we've done that before with things like not having the right lightning file, etc.).

My feeling is that right now the traceability of our decision-making is poor. Just stating things like "J10" doesn't give all the information you would need to understand these. In some places, we have X-sec that is actually QY * X-sec but that is non-intuitive and you have to really dig through the notes to understand this. I think calculating this real-time or at least storing in the folder all of the original data files (cross sections and individual species add-X codes that were used to prepare the relevant files) would help a lot.

I have also seen in my group that folks have difficulty working out how to write their own add-X routines from the examples, but we hadn't seen the new ones linked above, so we will check these out - thanks for sharing!

Cheers,
Jenny

[lizziel]

Thanks for your input @jennyfisher! I am going to make a separate issue for reading in offline aerosol files for use with Cloud-J in mercury simulations. Using legacy Fast-JX is still an option in GEOS-Chem by compiling with -DFASTJX=y. We will recommend using that in mercury simulations until there is an update to read in offline archived files.