[BUG/ISSUE] Unintuitive error message from ExtData when multi-year file is missing

[sdeastham]

What institution are you from?

MIT

Description of the problem

Usually, if ExtData comes across a file which it needs but cannot find it fails with an intuitive error message. However, it appears that there is an edge case which still produces a confusing error. The TransportTracers simulation requires the file EDGAR_v42_SF6_IPCC_2.generic.01x01.nc, which contains data for several years (full path: HcoDir/SF6/v2019-01/EDGAR_v42_SF6_IPCC_2.generic.01x01.nc). If the file is missing, ExtData gets very confused because it follows the logic branch for an entry covering multiple years, and which crucially assumes that there will be at least one file per year. This results in it trying to fill out the file template with successively earlier years, and testing to see if a file is present. For reasons which are not 100% clear to me, this results in a failure in ESMF rather than specifically in MAPL, and hence the confusing error.

No matter what level of debug logging is specified in logging.yml, there will be no error thrown by GCHP or MAPL. An error is thrown to stdout/stderr:

pe=00038 FAIL at line=01044    MAPL_ExtDataGridCompMod.F90              <status=2>
pe=00038 FAIL at line=01844    MAPL_Generic.F90                         <Error during the 'Initialize' stage of the gridded component 'EXTDATA'>
pe=00038 FAIL at line=00766    MAPL_CapGridComp.F90                     <status=1>
...

This simply points to line 2185 (https://github.com/geoschem/MAPL/blob/a96739015a3da07954b17a036add99b20f88bdf0/base/MAPL_ExtDataGridCompMod.F90#L2185) in MAPL_ExtDataGridCompMod.F90, which calls ESMF_TimeGet. The error actually pops up in the PETNN.ESMF_LogFile log; each PET's file reports ERROR PET00 ESMF_Time.F90:810 ESMF_TimeGet() Object Set or SetDefault method not called - Object not Initialized (PET00 replaced with PETNN as appropriate, and the line preceded by a timestamp).

One fix for this might be to adjust the logic in MAPL_ExtDataGridCompMod.F90 so that this case is caught; however, it may also be that this could be prevented by using a different specification for the file in question. Currently, ExtData.rc shows this file as

EDGAR_SF6 1 N Y F%y4-01-01T00:00:00 none none emi_sf6 ./HcoDir/SF6/v2019-01/EDGAR_v42_SF6_IPCC_2.generic.01x01.nc

@bena-nasa may have an idea if there is a better alternative?

GEOS-Chem version

13.3.0

Description of code modifications

Nothing relevant.

Log files

• Run log (if applicable): N/A

Software versions

• Compilers (Intel or GNU, and version):
• NetCDF version: 4.7.2
• MPI version: OpenMPI 4.0.4
• ESMF version:

[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.

[lizziel]

@LiamBindle, we discussed this issue at a MAPL meeting but I think you may not have been present at that one. The if-else at the link above needs added error handling in the file not found block for the case of the file having no time tokens.

if (index(item%file, '%') .lt. 1) then
   _ASSERT(.false.,'File ' // trim(item%file) // ' not found')
else if (allowExtrap .and. (item%cyclic == 'n') ) then

I don't mind putting this in if you don't think you'll get to it for 13.4. It needs to be fed back to GEOS-ESM/MAPL too.

[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

[lizziel]

Is there any follow-up for this issue?

[lizziel]

I will put a fix for this into 13.4.0.