Consistency of aerosol microphysical properties with optics tables

[pcolarco]

@acollow implemented a mechanism for recalling RH-dependent particle effective radius and density from optics tables. This implemented, for example, in calls to Chem_SettlingSimple by passing the diag_mie object and the subroutine resolves the effective radius and density.

The issue: this approach is not complete/consistent across the code. Examples:

• GA_Environment is pulling particle density and effective radius from instance files
• DU uses that radius in call to DustAerosolDistributionKok (and also radius bin boundaries), DustEmissionGOCART2G, DryDeposition, WetRemovalUFS, stored for use in NI hetchem
• DU uses that shop in call to DustEmissionFENGSHA, DryDeposition
• DU uses instance rlow and rup in call to Aero_Compute_Diags
• SS uses bin edges used in call to SeasaltEmission, storage of GA_Environment rmed for use in NI hetchem
• NI uses attribute per bin radius (rmedDU, rmedSS) from imported states for heterogeneous calculations
• SU is getting radius from instance file to decide to settle (or not) per bin, but uses the diag_Mie to settle for sulfate, rmed sigma and rhop from instance file are used in call to SU_Compute_Diags to (at least) calculate surface area density desired by chemistry
• CA uses that radius for WetRemovalUFS

Question: Do we want to complete the thought? Assuming so:

The approach: remove particle parameters from the instance files and strip from GA_environment, ensure complete information is in optics tables and modify code accordingly.

Thoughts? This has implications for UFS.

[acollow]

Thanks for generating the list of all the places the instance file radius is used! There is one more place that needs to added - the PM2.5 calculation. My preference is exactly as you stated. To ultimately remove particle radii from the instance files and solely rely on the values in the optics files. I am happy to take on this task if we are all in agreement that this is the direction we want to move forward with. I would prefer to start from a branch that uses the new optics files though.

[pcolarco]

I support this approach, but Arlindo would have to decide and we might consider consulting the NOAA folks. I presume they use our optics tables. Pete From: Allie Collow ***@***.***> Date: Wednesday, April 30, 2025 at 8:19 AM To: GEOS-ESM/GOCART ***@***.***> Cc: Colarco, Peter R. (GSFC-6140) ***@***.***>, Author ***@***.***> Subject: [EXTERNAL] [BULK] Re: [GEOS-ESM/GOCART] Consistency of aerosol microphysical properties with optics tables (Issue #318) CAUTION: This email originated from outside of NASA. Please take care when clicking links or opening attachments. Use the "Report Message" button to report suspicious messages to the NASA SOC. [Image removed by sender.]acollow left a comment (GEOS-ESM/GOCART#318)<#318 (comment)> Thanks for generating the list of all the places the instance file radius is used! There is one more place that needs to added - the PM2.5 calculation. My preference is exactly as you stated. To ultimately remove particle radii from the instance files and solely rely on the values in the optics files. I am happy to take on this task if we are all in agreement that this is the direction we want to move forward with. I would prefer to start from a branch that uses the new optics files though. — Reply to this email directly, view it on GitHub<#318 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ANW73YB5HFHZVHS6PEZ634D24C5ULAVCNFSM6AAAAAB4D6RXAGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQNBRG44TGMRYGE>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[bbakernoaa]

@pcolarco we do use your optics tables but mainly for diagnostics as the operational products come from our post processing which uses CRTM.

Likely we need to exchange any modifications since we last retrieved them. I'm not opposed to it off hand as it likely won't affect us much. My only question is how would we specify the number of bins etc and their ranges if not in the .rc files. I would prefer to maintain the ability to modify these as needed for the number of species etc.

[acollow]

@bbakernoaa, The number of bins is a separate line in the instance rc files for dust and sea salt (example at

GOCART/ESMF/GOCART2G_GridComp/DU2G_GridComp/DU2G_instance_DU.rc

Line 56 in c393e57

nbins: 5

). The ranges for each of the bins would need to come from the optics files.

[bbakernoaa]

@acollow

Are you saying that the size ranges are predetermined based off the optics files based on the number of bins? Could you give me an example of what this would mean for instance if I say that nbins: 3 vs nbins: 5. I just want to make sure I'm understanding. What if we wanted to include super coarse aerosols such as dust > 20 um?

[acollow]

@acollow

Are you saying that the size ranges are predetermined based off the optics files based on the number of bins? Could you give me an example of what this would mean for instance if I say that nbins: 3 vs nbins: 5. I just want to make sure I'm understanding. What if we wanted to include super coarse aerosols such as dust > 20 um?

Exactly, in this situation the code would read in rUp, rLow, rEff, etc. from the optics files for the specified number of bins (so technically calling it an "optics" file would become a misnomer) and use that for routines that require a radius. If you wanted to add a new bin, you would just need to make sure it is represented in the optics file specified for the species. This is already implemented in the develop branch for settling -

GOCART/ESMF/GOCART2G_GridComp/DU2G_GridComp/DU2G_GridCompMod.F90

Line 974 in 837737f

call Chem_SettlingSimple (self%km, self%klid, self%diag_Mie, n, self%cdt, MAPL_GRAV, &

[pcolarco]

@bbakernoaa If you wanted to have more size bins in a given instance of dust or sea salt you would have to provide an optics table with more bins. That's hard and fast I think, as it would crash without those. You could provide a "superset" table with more bins than you want to run. I could see in that case that we may want to preserve the number of bins in the instance files.

The other species are a little more complicated: sulfur has four tracers but only one has aerosol optical properties assigned, the carbons each have two by design, and the nitrate has five tracers but only three have optical properties.

The issue @acollow addressed already was to tie the hydrated particle size used in settling to be the same as is done in the optics tables. In principle this consistency is desired and should apply to other places where microphysics comes in. It's not consistency implemented now.