EAMXX: Implement aqueous and gas state diagnostic output on request.

[overfelt]

The "mam4_microphysics_tendency_gas_phase_chemistry" and "mam4_microphysics_tendency_aqueous_chemistry" diagnostics are added.

This PR also:
. Adds a namelist flag to control diagnostic output (default: false)
. Adds a REP CIME test where the namelist flag is turned to true

[BFB]

[singhbalwinder]

Thanks, James for putting this together with the MAM4xx codes. I left some comments to get feedback from other on the variabable names. We might need to add one master flag for diganostics as well.

[singhbalwinder]

This PR should be BFB. Do we know why the tests are failing?

[overfelt]

Yes this merge request, #7459 , should be BFB but there is one unit test that fails on GPU only and I do not know why. I'm doing a GPU build now to track it down.

[singhbalwinder]

I have tested it on Frontier, and it works for a short test.

[mahf708]

re names:

• mixing_ratio_tendency_due_to_gas_phase_chemistry
• mixing_ratio_tendency_due_to_aqueous_chemistry

Mixing ratio of what specifically? In the model, most mixing ratios are 3D resolved (i.e., they have col and lev dimensions). This doesn't seem to be like that, right? If so, you'd want to clearly indicate the reduction in the name so that it is clear they are somehow reduced (I assumed you vertically integrate it them in mam4xx, which is unwise and should be redone --- these should be exposed as 3D variables and eamxx utilities can take care of the reduction/integration).

Feel free to delete "due to" (it's implied)

[overfelt]

@mahf708 Yes, the full mixing ratio diagnostic arrays are dimentioned by (number of columns) by (number of levels) by (number of gas and aerosol constituents). It is the full 3D variables so the eamxx utilities can take care of any reduction/integration over columns. (also removed "due_to" from name)

[mahf708]

I am still not sure what these mixing ratios are...

I assume they're not "qc", right? You will need a better description of what they are. Are they "aerosol" mixing ratios?

[tcclevenger]

@singhbalwinder @overfelt Is this ready to integrate?

[singhbalwinder]

Not yet, I need to add a test for these diagnostics. I will let you know when this is ready to merge.

[mahf708]

I suggest renaming the fields in add_field calls to something like (e.g., prefixing with "mam_microphysics")

• mam_microphysics_tendency_gas_phase_chemistry
• mam_microphysics_tendency_aqueous_chemistry

re

O3, H2O2, H2SO4, SO2, DMS,SOAG, so4_a1, pom_a1, soa_a1, bc_a1, dst_a1, ncl_a1, mom_a1, num_a1, so4_a2, soa_a2, ncl_a2, mom_a2, num_a2, dst_a3, ncl_a3, so4_a3,bc_a3, pom_a3, soa_a3, mom_a3, num_a3, pom_a4, bc_a4, mom_a4, num_a4

@singhbalwinder, is this how these were output in EAM days? As one big structure? Or were they output individually? Either way, I think it is unsustainable to have mam_tendency_gas_phase_chemistry output many (30+?) fields at once. What if someone just wants the DMS tendency? Also, some of these will be zero, right?

You can rework this to output them separately in two ways:

1. you can do it here, by simply doing doing add_field("DMS_mam_tedency...", scalar3d, ...) and then assigning the specific index of the big vector3d you get back from the submodule; you will do the assignment in a kernel or you can use ekat subviewing utils (or subfielding utils if you end up making the big one a field, but that would be duplicating stuff)
2. you can do it later by asking the diagnostics/analysis people to add something under src/diagnostics to parse out specific fields; components/eamxx/src/diagnostics/aodvis.cpp is a good example to follow for that

[mahf708]

wanna expose this in the xml file or are you planning to do that later? Also, I would name it after the process (mam_microphysics or mam4_microphyiscs)

[singhbalwinder]

I will add it along with the test.

[singhbalwinder]

@mahf708: Thanks for your suggestion. That is a very good point. These species are output as separate variables in EAM. We can do the same (or better) using the approach you suggested (using the src/diagnostics folder) to request the species that we need. We can do that in follow-up PRs.

I have now added a test, renamed diagnostic variables, added the namelist flag, and guarded the older diagnostic variable also under the new flag. Is there anything else we need to do before merging?

[singhbalwinder]

@overfelt: Why was this machine entry removed?

[overfelt]

I think a rebase to master will fix the config_machines.xml diff. This file was not changed in this PR and the diff shown is what was updated on master recently.

[singhbalwinder]

guarded the older diagnostic variable also under the new flag

I am undoing this in this PR. We will add this in a follow-up PR (see #7469 ).

[mahf708]

✅

[mahf708]

All good, but be sure to do a clean rebase before merging. The rebase in here is not clean in the sense it is pulling in random commits that don't need to be included.

[singhbalwinder]

This PR should be ready to merge once the ghci tests pass. I have rebased it and pointed the mam4xx submodule to its main branch.