Small bug in ISOP and OTHR formation yields to SOAP and SOAS

[ChiLi90]

Name and Institution (Required)

Name: Chi Li Institution: Washington University in St. Louis

Description of your issue or question

Dear GCST,

I might found a small bug in the simple SOA scheme in version 14.1.1.

In the current full-chem HEMCO_Config template (/run/GCClassic/HEMCO_Config.rc.templates/HEMCO_Config.rc.fullchem) for offline biogenic emissions, the 1.5% yields of ISOP to SOAP and SOAS have already been scaled by 1.13 to account for the carbon to mass basis conversion. The 5% yields of MONO and OTHR is similarly scaled.

#==============================================================================
# --- Offline biogenic VOC scale factors ---
#
# Isoprene      : 1.5% mass yield SOAP, 1.5% mass yield SOAS
# Monoterpenes  : 5.0% mass yield SOAP, 5.0% mass yield SOAS
# Other terpenes: 5.0% mass yield SOAP, 5.0% mass yield SOAS
#  --> Need to multiply by 1.133 to convert from carbon basis to mass basis
#==============================================================================
(((OFFLINE_BIOGENICVOC
610 ISOPtoSOA 0.0170 - - - xy 1 1
611 MONOtoSOA 0.0567 - - - xy 1 1
612 OTHRtoSOA 0.0567 - - - xy 1 1
)))OFFLINE_BIOGENICVOC

In the online MEGAN extension interface in the same Config file, the yields are still 1.5% and 5%.

108     MEGAN                  : on    ISOP/ACET/PRPE/C2H4/ALD2/MOH/EOH/MTPA/MTPO/LIMO/SESQ/SOAP/SOAS
    --> Isoprene scaling       :       1.0
    --> CO2 inhibition         :       true
    --> CO2 conc (ppmv)        :       390.0
    --> Isoprene to SOAP       :       0.015
    --> Isoprene to SOAS       :       0.015
    --> Monoterp to SOAP       :       0.050
    --> Monoterp to SOAS       :       0.050
    --> Othrterp to SOAP       :       0.050
    --> Othrterp to SOAS       :       0.050

In the HEMCO processing code (/HEMCO/src/Extensions/hcox_megan_mod.F90), the ISOPTOSOAP and ISOPTOSOAS yields is scaled by 1.13 (Line 3615-3616 and Line 3631-3632):

 !convert from carbon basis to mass basis
       Inst%ISOPTOSOAP = Inst%ISOPTOSOAP * 1.134
!convert from carbon basis to mass basis
       Inst%ISOPTOSOAS = Inst%ISOPTOSOAS * 1.134

For OTHR, similar issue also exists (Line 3676-3677 and Line 3691-3692):

!convert from carbon basis to mass basis
       Inst%OTHRTOSOAP = Inst%OTHRTOSOAP * 1.134
!convert from carbon basis to mass basis
       Inst%OTHRTOSOAS = Inst%OTHRTOSOAS * 1.134

while for MONO, the scaling is commented out (Line 3646-3647 and Line 3661-3662):

!convert from carbon basis to mass basis
       Inst%MONOTOSOAP = Inst%MONOTOSOAP ! * 1.134
!convert from carbon basis to mass basis
       Inst%MONOTOSOAS = Inst%MONOTOSOAS ! * 1.134

My understanding is that since the online processing used 1.5% and 5%, then we should not comment the MONO yields out? For the offline emissions, I believe the current numbers are correct.

Chi

[yantosca]

Thanks for writing @ChiLi90. I am tagging the Emissions Working Group co-chairs: @eamarais @jaegle and also @dylanbm

[yantosca]

Also tagging @SaptSinha

[eamarais]

Hi @ChiLi90, it's not clear why the MONO conversion factor is commented out. My impression is that it should be used. @dylanbm, can you confirm this is the case?

It also looks like the carbon-to-compound conversion factor is only needed for online emissions. According to the HEMCO_Config file and the README.txt file in http://geoschemdata.wustl.edu/ExtData/HEMCO/OFFLINE_BIOVOC/v2021-12/README.txt, MEGAN offline is read in as "kg" and MEGAN online as "kg C". If this is the case, then currently there is an artificial increase in emissions in the MEGAN offline emissions.

@yantosca, is it possible to move application of the carbon to compound conversion factor for the online biogenic emissions from the HEMCO code to the HEMCO_Config file for consistency? And in the update, to also apply it to MONO to address the bug identified by @ChiLi90?

[ChiLi90]

Hi Eloise,

I agree that the best way to proceed is to uniformly use “kg/m2” for both online and offline data, and remove the hard-coded scaling in the hco_megan processing code.

Chi

[dylanbm]

Hi all: I will defer to others who are better-versed in the SOA simulation. (@yantosca note that Jintai is the 3rd Emissions WG co-chair along with @eamarais and Lyatt)

[eamarais]

@dylanbm , the conversion factors are tied to the biogenic emissions that now fall under the working group you're in, so it would be great if you could confirm that these are indeed bugs that need to be addressed. Feel free to include others from the working group to weigh in if needs be. Do you know if there's any reason to not apply a carbon-to-compound conversion factor to MONO emissions? My impression is these are all emitted in the online scheme as "kg C", so the conversion factor should be applied.

[dylanbm]

Also tagging @cdholmes @amospktai @jgeddes85

The units in hcox_megan_mod are confusing partly because many of the comments pre-date HEMCO and refer to units that HEMCO now handles externally. But I think the issue above is highlighting a unit inconsistency further down within MEGAN that seems to have arisen with HEMCO / unit changes somewhere along the line. The code I am looking at is v13 but I think this is unchanged in the more recent versions.

Within CALC_AEF we are reading in AEF data from file for some species (ISOP, MBOX, BPIN, CARE, LIMO, OCIM, SABI) but computing AEF values for others (APIN, MYRC, OMON, FARN, BCAR, OSQT, MOH, ACET, EOH, CH2O, ALD2, HCOOH, ACTA, C2H4, TOLU, HCN).

According to HEMCO_Config the AEF values being read in from file (for the first set of species) are now provided in carbon units, e.g.: 108 MEGAN_AEF_ISOP $ROOT/MEGAN/v2018-05/MEGAN2.1_EF.geos.025x03125.nc AEF_ISOPRENE 1985/1/1/0 C xy kgC/m2/s * 61 1 1

But the AEFs being computed in hcox_megan_mod (for the second set) are being derived in compound units (kg/m2/s).

One way to make the two consistent again would be to adjust the unit conversions beginning here to go to kgC/m2/s: ! Convert AEF arrays from [ug/m2/hr] to [kg/m2/s] FACTOR = 1.0e-9_hp / 3600.0_hp Inst%AEF_APIN = Inst%AEF_APIN * FACTOR ... (etc) ...

But that may still be problematic because we still have a situation with units hardwired within MEGAN for some species but specified dynamically by HEMCO for others.

Thoughts from the group on how best to address this?

[ChiLi90]

Hi Dylan,

Thanks! I believe this issue also still matters for the OTHR (other terpenes) category. Since some terpenes are derived from one interface, and the other terpenes are from the other.

Chi

[yantosca]

Would someone be able to fix this and submit a pull request? That would help us out.

[dylanbm]

Hi all - sorry to be slow on this. We'll submit a fix to correct the immediate issue. There will still be the non-optimal situation with units being specified in one place for some compounds and in another place for others but at least the bug will be removed.

[msulprizio]

@ChiLi90 @dylanbm Is there an update on a fix for this?

I've removed the 14.2.0 milestone since we will begin benchmarking that version later today or on Monday. We will aim to resolve this in 14.3.0 instead.

[dylanbm]

Hi - yes, we plan to get this submitted in the next couple weeks.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. If there are no updates within 7 days it will be closed. You can add the "never stale" tag to prevent the Stale bot from closing this issue.