Sulfur in-cloud chemistry disconnected from TOMAS in V14 [BUG/ISSUE]

[BettyCroft]

What institution are you from?

WashU/Dalhousie

Description of the problem

The default setting of Do_SulfateMod_Cld to false in v14 leaves PSO4_SO2AQ defined as zero when TOMAS calls CHEM_SO4_AQ in sulfate_mod.F90. Unfortunately, TOMAS simulations will run with this default setting - but will be erroneously excluding the key process of sulfur in-cloud chemistry - yielding excessive sulfate concentrations in TOMAS.

Description of troubleshooting performed

The simple fix of setting Do_SulfateMod_Cld to true in Headers/state_chm_mod.F90 had worked in v13 but is now giving run-time segmentation faults in v14. One long-term solution is to define and pass PSO4_SO2AQ out of KPP to TOMAS. The CHEM_SO4_AQ subroutine could also be moved out of sulfate_mod.F90. I've started work on the latter - and would welcome advice on best approaches for this fix. In the short-term - would there be a simple fix to enable functionality of Do_SulfateMod_Cld set to true such that TOMAS is not broken?

GEOS-Chem version

Version 14.0.1

Description of modifications

Log files

• Build log (if applicable):
• Run logs (if applicable):
• Run script (if applicable):

Software versions

• CMake version: 3.19.4
• Compilers (Intel or GNU, and version): esm:intel-2021.1.2
• NetCDF version:

[msulprizio]

Thanks for reporting this @BettyCroft. Please also see #1378 and if possible make any additional changes off of the features/TOMAS branch referenced there.

I'm also tagging @yantosca and @msl3v as they did the recent work on the sulfur chemistry.

Also tagging @Jourdan-He for reference.

[yantosca]

Hi @BettyCroft; When we migrated the sulfate chemistry to KPP, We didn't test with TOMAS of course. It would make sense to try to keep the sulfur chemistry in KPP for TOMAS for consistency.

If you can move these arrays out of sulfate_mod.F90 and into State_Chm, then that would let you use these arrays across modules:

#ifdef TOMAS
  !---------------------------------------------------------------
  ! For TOMAS microphysics: Define PSO4_SO2aq array
  !---------------------------------------------------------------
  REAL(fp),  ALLOCATABLE :: PSO4_SO2AQ(:,:,:)
  REAL(fp),  ALLOCATABLE :: SO4_ANTH(:,:,:)
#endif

I think that is the first step.

[BettyCroft]

Thanks Bob and Melissa. TOMAS needs gas and aqueous phase SO4 production separately from KPP - i.e. PSO4gas and PSO4aq. At the moment it looks like both gas and aqueous production might be going together into PSO4. Would you be able to advise on how we can define gas and aqueous phase SO4 production separately in the KPP framework for passing to TOMAS?

[BettyCroft]

Hi @yantosca, @msulprizio and @msl3v; Thanks again for your advice and sorry that I forgot to tag you in my reply yesterday. Keeping the sulfur chemistry in KPP for TOMAS sounds good. To get this working - I'll start today by moving the TOMAS arrays out of sulfate_mod.F90 and into state_chm_mod.F90.

A couple of questions - Am I correct in understanding that PSO4 from KPP includes both the gas- and aqueous-phase production together when Do_SulfateMod_Cld is false? Being new to KPP, I'll need some help to set up separate PSO4aq and PSO4gas arrays since the TOMAS processes need to treat gas and aqueous production separately. Currently TOMAS is treating PSO4 as if it is always entirely gas-phase production.

[yantosca]

Hi @BettyCroft. The PSO4 is a "dummy" species that is typically used for diagnostics. I think it is added to every reaction that has SO4 in it. You should be able to see in which routines it is added to if you look at KPP/fullchem/gckpp_Monitor.F90

I think you should be able to set up PSO4gas and PSO4aerosol in KPP by defining those as families (similar to POx), and include all of the species that you want to be counted in each.

[yantosca]

@BettyCroft: you would also need to rebuild the fullchem mechanism: See our Update chemical mechanisms with KPP instructions at ReadTheDocs.

[BettyCroft]

Thanks @yantosca for this helpful advice! Where I'll need help next is with getting the correct list to define the sulfate production from gas-phase reactions and aqueous-phase production reactions separately.

[BettyCroft]

@yantosca: Would there be someone who might be available to do this rebuild of the fullchem mechanism? Perhaps we could move ahead more efficiently if someone with expertise on the KPP sulfate were to setup separate outputs for the gas-phase and aqueous phase production - and then I could work on the TOMAS side of things, to setup correct usage of those outputs by TOMAS. Thoughts on this approach?

I'm thinking that other users of size-resolved simulations such as APM would also be interested to have separate outputs for the gas-phase production versus the aqueous-phase production of sulfate.

[yantosca]

@BettyCroft: Unfortunately, right now the GCST doesn't have a lot of time that isn't already budgeted for other tasks. We would have to clear it with Randall & Daniel.

I'm thinking that maybe due to the additional modifications needed that this won't be ready for 14.1.0.

[BettyCroft]

Thanks @yantosca, I'll start off from the documents you mentioned. What would you recommend as the best contact route/(s) for questions related to understanding the sulfur chemistry in KPP? I'll tag @theloniuspunk here as an update.

[yantosca]

Also @msl3v is a good person to ask for about the sulfur chemistry.

[BettyCroft]

Thanks @yantosca, I'll check in with him also.

[BettyCroft]

Hi @msl3v, Would you have a moment for a question on the sulfur chemistry in KPP (as I'm not too familiar yet with KPP)? I'd like to have a diagnostic similar to PSO4 but tracking the sulfate production from the in-cloud reactions only, separately from the rest of the sulfate production. In fullchem.kpp we define the family PSO4 : SO4; - what is the most straightforward way to separate off the in-cloud production only (similar to what was done with PSO4_SO2AQ for TOMAS in sulfate_mod.F90)? It seems like there would be a need for a separate in-cloud SO4 tracer. Or is there an easier solution? Please send along your advice. Thanks!

[msl3v]

Hi Betty, Can you e-mail me at ***@***.***?

[theloniuspunk]

It's masking your email for me, so I don't think Betty can see it either. -Jeff

[msl3v]

Hmm. msl3v@virginia.edu

[BettyCroft]

Hi @yantosca and @msulprizio, I've developed a fix that appears to be giving reasonable results. Prior to sending a pull request, I'd like to get clarity on the following question.

In KPP/fullchem/fullchem.eqn I've added 2 diagnostics (PH2SO4 and PSO4AQ) in the DEFVAR section and then add them to various equations that produce SO4. After rebuilding the chemical mechanism, I'd been expecting that GeosCore/fullchem_mod.F90 would be resetting PSO4AQ and PH2SO4 to zero in the loop at line 706 but I need to do it as below. Would you have insights on why that is happening and how to prevent them having SpcId>0?

    DO N = 1, NSPEC
      SpcID = State_Chm%Map_KppSpc(N)
      C(N)  = 0.0_dp
      IF ( SpcId > 0 ) C(N) = State_Chm%Species(SpcID)%Conc(I,J,L)
   ENDDO
     C(ind_PH2SO4) = 0.0e+0_fp  !betty                                                                                                                                                                                             
     C(ind_PSO4AQ) = 0.0e+0_fp  !betty                                                                                                                                                                                             

In case this helps to understand the problem - I also need to be sure to exclude PH2SO4 and PSO4AQ from the list of outputs in HISTORY.rc under SpeciesConc or else some mapping related error occurs related to PH2SO4 and PSO4AQ.

I'll tag @msl3v and @theloniuspunk here to keep them updated.

[yantosca]

Thanks for writing @BettyCroft. I believe we have to keep even the dummy prod/loss species in the species database because GEOS-Chem needs the molecular weights for unit conversions. I think what you've done is OK for now.

NOTE: We are working on a fix that would ignore prod/loss species from being included in the error. This would probably fix your issue. See: KineticPreProcessor/KPP#66

[msl3v]

Hey Bob, The behavior that prompts this is that C(ind_PSO4AQ) and C(ind_PH2SO4) aren't getting set to zero. Does GC automatically add all KPP species to the state_chm object? So that their values are preserved between timesteps? If so, that explains the issue.

…

On 12/19/22 15:04, Bob Yantosca wrote: Thanks for writing @BettyCroft <https://github.com/BettyCroft>. I believe we have to keep even the dummy prod/loss species in the species database because GEOS-Chem needs the molecular weights for unit conversions. I think what you've done is OK for now. NOTE: We are working on a fix that would ignore prod/loss species from being included in the error. This would probably fix your issue. See: KineticPreProcessor/KPP#66 <KineticPreProcessor/KPP#66> — Reply to this email directly, view it on GitHub <#1511 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABVE23ZLK772ACO6FNYADHLWOC5UHANCNFSM6AAAAAASCREI2E>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[yantosca]

@msl3v @BettyCroft, yes all species (advected or not) are added to State_Chm.

[BettyCroft]

Thanks @yantoscan and @msl3v. Good to hear that these updates are sounding ok. I'll put together a pull request for the TOMAS-sulfate-production-rate bug fix. Tagging also @msulprizio and @theloniuspunk as an update.

[BettyCroft]

Hi @yantosca, @msulprizio, @theloniuspunk and @msl3v - PR #1569 was submitted today as a fix for this TOMAS bug. Thanks again for all your help with this issue.

[msulprizio]

The PR associated with this issue has now been merged into the 14.2.0 development branch.