[BUG/ISSUE] Using "EF" CRE for Offline Emissions, QFED, etc. causes emissions to repeat each day

[chfite]

What institution are you from?

Florida State University

Description of the problem

I have offline emissions turned on for BIOVOC, SEASALT, DUST, and SOILNOX (and their associated extensions turned off), but for each new day in my simulation the logged output does not mention that it is opening new Offline emission files for that day. I do not think those emissions are being released, and I think it may have to do with the "EF" CRE they now use in HEMCO_Config in newer model versions. However, I am not sure what is actually causing the bug. This bug causes the model to repeat those emissions from the first day of the simulation.

I'll note that I was also seeing this same issue with the QFED emissions, that also now use the "EF" CRE. All Offline and QFED emissions DID open on the first day of the simulation, but on following days they did not. Offline Lightning does open at the beginning of each new model date, but that is likely because it uses RFY3 instead of EF for its CRE.

Description of troubleshooting performed

I had done a 12 month simulation before realizing this issue, and when I looked at the monthly mean HEMCO Diagnostic output the global mean offline emissions magnitudes were the same for each month.

I then did additional tests for only a 3 day period (20190901-00UTC to 20190904-00UTC), saving out daily mean HEMCO diagnostics. Again, each day of those simulations reported the same mean rates for offline emissions for the globe. I cross-checked these with the actual offline emission files in /data/ExtData/HEMCO/ and they DO vary in magnitude each day, so it wasn't an issue with the netcdf file inputs.

Finally, I did a test reverting back to using the "C" CRE like was used for QFED and Offline emissions in the past, and it fixed the issue, the files were found and opened at the beginning of the new dates, and the HEMCO diagnostic outputs varied daily as they should. I am not sure if this is an issue with the timestamps of the input files or if it's the code that handles an EF CRE that is the issue.

This sounds somewhat similar to b474612 but that issue was with boundary conditions using CRE's of EY (not EF), with the fix involving changing EY to EFY. Would a similar fix be needed here?

GEOS-Chem version

I am using v13.3.4 complexSOA_SVPOA and GEOS-FP 2x2.5, however I did cherry-pick a few bug fixes/updates relevant to me that were added in 13.4.0. I have attached a patch file that should describe any changes I made.

Description of modifications

Here is the attached patch files with my changes to v13.3.4:
GEOS-Chem_13.3.4_with_some_13.4_updates.patch.txt.
HEMCO_3.2.2_with_several_updates.patch.txt
My HEMCO changes were: geoschem/HEMCO#132, geoschem/HEMCO#138, and the PR that involved making HCO_Readline strip out tabs and end-of-line comments (geoschem/HEMCO#150). I don't think these would affect the CRE interpretation?

Input/Log files

This is my HEMCO_Config file that uses EF as the CRE for offline emissions and QFED. Changing those to C fixes the issue (for me), but I know using C isn't desirable as the default for these emissions.
HEMCO_Config.rc.txt

Software versions

• CMake version: 3.22.1
• Compilers (Intel or GNU, and version): Intel

[chfite]

Apologies, I am actually realizing that in the edits I made to v13.3.4, while I was updating offline emission file paths to more recent versions, the C flag was changed to EF by me. I put EF because that is what I saw specified in the commit comment on 20942a5. However, I see that in the actual file changes those were written as EY. I assume EY does not have this issue like EF did for me? I have not tested that yet.

[chfite]

However, EF does appear to still be used for QFED in recent model versions, so that would need to be changed in order to have those emissions update each day

[chfite]

I did a test using EY and had the same issue. Is it then advisable to use EFY or C?

[yantosca]

Hi @chfite, thanks for writing. I'm also tagging @msulprizio here.

I tried a HEMCO standalone simulation with EFY and that seems to read the data for each day. So we might need to use this in simulations.

 Calculate emissions at 2019-07-01 00:00:00
HEMCO: Opening /n/holyscratch01/external_repos/GEOS-CHEM/gcgrid/data/ExtData/HEMCO/TIMEZONES/v2015-02/timezones_voronoi_1x1.nc
HEMCO: Opening /n/holyscratch01/external_repos/GEOS-CHEM/gcgrid/data/ExtData/HEMCO/OFFLINE_DUST/v2021-08/0.5x0.625/2019/07/dust_emissions_05.20190701.nc
HEMCO: Opening /n/holyscratch01/external_repos/GEOS-CHEM/gcgrid/data/ExtData/HEMCO/OFFLINE_BIOVOC/v2021-12/0.5x0.625/2019/07/biovoc_05.20190701.nc
HEMCO: Opening /n/holyscratch01/external_repos/GEOS-CHEM/gcgrid/data/ExtData/HEMCO/OFFLINE_SEASALT/v2019-01/0.5x0.625/2019/07/seasalt_05.20190701.nc
HEMCO: Opening /n/holyscratch01/external_repos/GEOS-CHEM/gcgrid/data/ExtData/HEMCO/OFFLINE_SOILNOX/v2021-12/0.5x0.625/2019/07/soilnox_05.20190701.nc
 Calculate emissions at 2019-07-01 01:00:00
 Calculate emissions at 2019-07-01 02:00:00
 Calculate emissions at 2019-07-01 03:00:00
 Calculate emissions at 2019-07-01 04:00:00
 Calculate emissions at 2019-07-01 05:00:00
 Calculate emissions at 2019-07-01 06:00:00
 Calculate emissions at 2019-07-01 07:00:00
 Calculate emissions at 2019-07-01 08:00:00
 Calculate emissions at 2019-07-01 09:00:00
 Calculate emissions at 2019-07-01 10:00:00
 Calculate emissions at 2019-07-01 11:00:00
 Calculate emissions at 2019-07-01 12:00:00
 Calculate emissions at 2019-07-01 13:00:00
 Calculate emissions at 2019-07-01 14:00:00
 Calculate emissions at 2019-07-01 15:00:00
 Calculate emissions at 2019-07-01 16:00:00
 Calculate emissions at 2019-07-01 17:00:00
 Calculate emissions at 2019-07-01 18:00:00
 Calculate emissions at 2019-07-01 19:00:00
 Calculate emissions at 2019-07-01 20:00:00
 Calculate emissions at 2019-07-01 21:00:00
 Calculate emissions at 2019-07-01 22:00:00
 Calculate emissions at 2019-07-01 23:00:00
 Calculate emissions at 2019-07-02 00:00:00
HEMCO: Opening /n/holyscratch01/external_repos/GEOS-CHEM/gcgrid/data/ExtData/HEMCO/OFFLINE_DUST/v2021-08/0.5x0.625/2019/07/dust_emissions_05.20190702.nc
HEMCO: Opening /n/holyscratch01/external_repos/GEOS-CHEM/gcgrid/data/ExtData/HEMCO/OFFLINE_BIOVOC/v2021-12/0.5x0.625/2019/07/biovoc_05.20190702.nc
HEMCO: Opening /n/holyscratch01/external_repos/GEOS-CHEM/gcgrid/data/ExtData/HEMCO/OFFLINE_SEASALT/v2019-01/0.5x0.625/2019/07/seasalt_05.20190702.nc
HEMCO: Opening /n/holyscratch01/external_repos/GEOS-CHEM/gcgrid/data/ExtData/HEMCO/OFFLINE_SOILNOX/v2021-12/0.5x0.625/2019/07/soilnox_05.20190702.nc
 Calculate emissions at 2019-07-02 01:00:00
 Calculate emissions at 2019-07-02 02:00:00
 Calculate emissions at 2019-07-02 03:00:00
 Calculate emissions at 2019-07-02 04:00:00
 Calculate emissions at 2019-07-02 05:00:00
 Calculate emissions at 2019-07-02 06:00:00
 Calculate emissions at 2019-07-02 07:00:00
 Calculate emissions at 2019-07-02 08:00:00
 Calculate emissions at 2019-07-02 09:00:00
 Calculate emissions at 2019-07-02 10:00:00
 Calculate emissions at 2019-07-02 11:00:00
 Calculate emissions at 2019-07-02 12:00:00
 Calculate emissions at 2019-07-02 13:00:00
 Calculate emissions at 2019-07-02 14:00:00
 Calculate emissions at 2019-07-02 15:00:00
 Calculate emissions at 2019-07-02 16:00:00
 Calculate emissions at 2019-07-02 17:00:00
 Calculate emissions at 2019-07-02 18:00:00
 Calculate emissions at 2019-07-02 19:00:00
 Calculate emissions at 2019-07-02 20:00:00
 Calculate emissions at 2019-07-02 21:00:00
 Calculate emissions at 2019-07-02 22:00:00
 Calculate emissions at 2019-07-02 23:00:00
 Calculate emissions at 2019-07-03 00:00:00
HEMCO: Opening /n/holyscratch01/external_repos/GEOS-CHEM/gcgrid/data/ExtData/HEMCO/OFFLINE_DUST/v2021-08/0.5x0.625/2019/07/dust_emissions_05.20190703.nc
HEMCO: Opening /n/holyscratch01/external_repos/GEOS-CHEM/gcgrid/data/ExtData/HEMCO/OFFLINE_BIOVOC/v2021-12/0.5x0.625/2019/07/biovoc_05.20190703.nc
HEMCO: Opening /n/holyscratch01/external_repos/GEOS-CHEM/gcgrid/data/ExtData/HEMCO/OFFLINE_SEASALT/v2019-01/0.5x0.625/2019/07/seasalt_05.20190703.nc
HEMCO: Opening /n/holyscratch01/external_repos/GEOS-CHEM/gcgrid/data/ExtData/HEMCO/OFFLINE_SOILNOX/v2021-12/0.5x0.625/2019/07/soilnox_05.20190703.nc
 Calculate emissions at 2019-07-03 01:00:00
 Calculate emissions at 2019-07-03 02:00:00
 Calculate emissions at 2019-07-03 03:00:00
 Calculate emissions at 2019-07-03 04:00:00
 Calculate emissions at 2019-07-03 05:00:00
 Calculate emissions at 2019-07-03 06:00:00
 Calculate emissions at 2019-07-03 07:00:00
 Calculate emissions at 2019-07-03 08:00:00
 Calculate emissions at 2019-07-03 09:00:00
 Calculate emissions at 2019-07-03 10:00:00
 Calculate emissions at 2019-07-03 11:00:00
 Calculate emissions at 2019-07-03 12:00:00
 Calculate emissions at 2019-07-03 13:00:00
 Calculate emissions at 2019-07-03 14:00:00
 Calculate emissions at 2019-07-03 15:00:00
 Calculate emissions at 2019-07-03 16:00:00
 Calculate emissions at 2019-07-03 17:00:00
 Calculate emissions at 2019-07-03 18:00:00
 Calculate emissions at 2019-07-03 19:00:00
 Calculate emissions at 2019-07-03 20:00:00
 Calculate emissions at 2019-07-03 21:00:00
 Calculate emissions at 2019-07-03 22:00:00
 Calculate emissions at 2019-07-03 23:00:00
HEMCO_STANDALONE FINISHED!

We will investigate further. Thanks for bringing this to our attention.

I think our rationale for using exact E in the CRE flags was so that the offline emissions would not be applied except on the exact date specified. This was supposed to alert users to potentially unwanted behavior (i.e. applying one year's emissions to another simulation year, etc.). But maybe there is an issue in the code. We'll check it out.

[stale]

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.

[stale]

Closing due to inactivity

[msulprizio]

@chfite @yantosca I'm looking into fixing this in 14.1.0. In hco_config_mod.F90, the CRE flags are described as:

    ! - "E"   : exact, read/query once
    ! - "EF"  : exact, forced (error if not exist), read/query once
    ! - "EFY" : exact, forced, always use sim year
    ! - "EFYO": exact, forced, always use sim year, read once
    ! - "EC"  : exact, read/query continuously (e.g. for ESMF interface)
    ! - "ECF" : exact, forced, read/query continuously
    ! - "EY"  : exact, always use simulation year, read/query once

So using EF is intended to read/query only once. This is clearly a bug for the offline emissions and QFED. We should be able to change this to EFY (as you both tested) or ECF to tell HEMCO to continuously read those fields. I will create a PR for this using EFY assuming users will always want to use the simulation year for those emissions.

[msulprizio]

The PR for this issue has now been merged into dev/14.1.0.