GFAS issue with Complex SOA scheme for POG variables

[Mashiat25]

Your name

Mashiat Hossain

Your affiliation

University of Illinois Urbana-Champaign

What happened? What did you expect to happen?

I am using the complex SOA scheme with semi-volatile POA in GEOS-Chem v14.3.1. I noticed that the file paths for variables POG1 and POG2 in different inventories are set as blank. While this doesn't cause any issues for most inventories, it resulted in an error when I attempted to use GFAS. I tried using GFAS with both default input files and emission weighted averaging of injection heights following issue #2330, but encountered the same error each time (attached). Once I updated the input file field in the HEMCO_Config.rc, the error was resolved. However, there is still no input file specified for anthropogenic emissions, yet we get POG outputs in the HEMCO_diagnostic.nc file. I am curious about what the empty file path signifies and whether the HEMCO emissions for POG variables are reliable.

What are the steps to reproduce the bug?

HEMCO_Config.rc.txt

Please attach any relevant configuration and log files.

What GEOS-Chem version were you using?

14.3.1

What environment were you running GEOS-Chem on?

Local cluster

What compiler and version were you using?

gcc 9.3.0

Will you be addressing this bug yourself?

Yes, but I will need some help

In what configuration were you running GEOS-Chem?

GCClassic

What simulation were you running?

Full chemistry

As what resolution were you running GEOS-Chem?

4x5

What meterology fields did you use?

MERRA-2

Additional information

No response

[yantosca]

Thanks for writing @Mashiat25.

The blank entries in HEMCO_Config.rc mean that HEMCO will use the variable from the specified file immediately above them. Listing this:

0 GFAS_OCPO  $ROOT/GFAS/v2018-09/$YYYY/GFAS_$YYYY$MM.nc ocfire        2003-2021/1-12/1-31/0 C xyL=1:scal300 kg/m2/s OCPO 73/75    5 3
0 GFAS_POG1  $ROOT/GFAS/v2018-09/$YYYY/GFAS_$YYYY$MM.nc ocfire        2003-2021/1-12/1-31/0 C xyL=1:scal300 kg/m2/s POG1 74/76/75 5 3
0 GFAS_POG2  $ROOT/GFAS/v2018-09/$YYYY/GFAS_$YYYY$MM.nc ocfire        2003-2021/1-12/1-31/0 C xyL=1:scal300 kg/m2/s POG2 74/77/75 5 3

will tell HEMCO to read the ocfire variable 3 times, which is a hit to performance. But if you type:

0 GFAS_OCPO  $ROOT/GFAS/v2018-09/$YYYY/GFAS_$YYYY$MM.nc ocfire        2003-2021/1-12/1-31/0 C xyL=1:300m kg/m2/s OCPO 73/75    5 3
0 GFAS_POG1  -                                                        -                     - xyL=1:300m kg/m2/s POG1 74/76/75 5 3
0 GFAS_POG2  -                                                        -                     - xyL=1:300m kg/m2/s POG2 74/77/75 5 3

then it should use the data read from the GFAS_OCPO container without having to re-read that.

We haven't yet pulled in the update from @jinlx described in #2330 and PR #2358 (but will do so soon for 14.5.0).

Also, do you happen to know the units of the injection height (read in as scale factor 300 from netCDF file)? HEMCO expects the units to be in meters, according to this link:

• https://hemco.readthedocs.io/en/stable/hco-ref-guide/hemco-config.html#cmdoption-arg-SrcDim

The error message is being generated in routine GetIdx in HEMCO. The error is raised at the bottom of the routine because HEMCO thinks that the altitude units are not in meters or is not the PBL height. See:

https://github.com/geoschem/HEMCO/blob/2192e0e88ee5f20fcd3bae71b613a902ec4c31ba/src/Core/hco_calc_mod.F90#L2403-L2524

You could try to print out the value of altu to see what it is. The acceptable values are:

https://github.com/geoschem/HEMCO/blob/2192e0e88ee5f20fcd3bae71b613a902ec4c31ba/src/Core/hco_types_mod.F90#L66-L70

That might shed some more light on what is going on. Keep us posted!