[BUG/ISSUE] Lingering issues with dry run

[jennyfisher]

Hi @yantosca - I couldn't figure out how to reopen #312 but I am now using v12.8.2 and having the same problem as @pkasibhatla.

Now when I run the dryrun, it tells me nearly all of the files are missing when in fact they are all clearly on my system... If I set up an actual run it works fine and there are no missing files.

[yantosca]

Hi Jenny (also tagging @pkasibhatla). Can you provide me with a list of steps to reproduce the issue on your system, and also the output?

We have added another fix into 12.9.0 (see commit afce43f) so that if the selected year is outside of the year range as specified in the HEMCO_Config.rc file, then the dryrun will terminate with an error msg. I am not sure if that will fix the issue but it might.

[jennyfisher]

Hi @yantosca

I'm using GEOS-Chem v12.8.2 out of the box. I set up a nested run (using the template for the North American tropchem run but changed the lat/lon bounds and filenames for my Australian nest). Running for 2015/01/01, for 1 day.

The dry run shows every required file missing, e.g.:

HEMCO: REQUIRED FILE NOT FOUND /g/data/m19/geos-chem/data/ExtData/HEMCO/XIAO/v2014-09/C3H8_C2H6_ngas.geos.1x1.nc
HEMCO: REQUIRED FILE NOT FOUND /g/data/m19/geos-chem/data/ExtData/HEMCO/BIOFUEL/v2014-07/biofuel.geos.4x5.nc
HEMCO: REQUIRED FILE NOT FOUND /g/data/m19/geos-chem/data/ExtData/HEMCO/BROMINE/v2015-02/Bromocarb_Liang2010.nc
HEMCO: REQUIRED FILE NOT FOUND /g/data/m19/geos-chem/data/ExtData/HEMCO/ACET/v2014-07/ACET_seawater.generic.1x1.nc
HEMCO: REQUIRED FILE NOT FOUND /g/data/m19/geos-chem/data/ExtData/HEMCO/MOH/v2019-12/MOH_seawater.low.kgCm3.generic.1x1.nc
HEMCO: REQUIRED FILE NOT FOUND /g/data/m19/geos-chem/data/ExtData/HEMCO/SOILNOX/v2014-07/DepReservoirDefault.nc
HEMCO: REQUIRED FILE NOT FOUND /g/data/m19/geos-chem/data/ExtData/HEMCO/SOILNOX/v2014-07/soilNOx.landtype.generic.025x025.1L.nc
HEMCO: REQUIRED FILE NOT FOUND /g/data/m19/geos-chem/data/ExtData/HEMCO/SOILNOX/v2014-07/soilNOx.climate.generic.05x05.nc
HEMCO: REQUIRED FILE NOT FOUND /g/data/m19/geos-chem/data/ExtData/HEMCO/DUST_DEAD/v2019-06/dst_tibds.geos.4x5.nc

and so on.

They are clearly there, for example:

[jaf574@gadi-login-03 ~]$ ls /g/data/m19/geos-chem/data/ExtData/HEMCO/XIAO/v2014-09/C3H8_C2H6_ngas.geos.1x1.nc
/g/data/m19/geos-chem/data/ExtData/HEMCO/XIAO/v2014-09/C3H8_C2H6_ngas.geos.1x1.nc

And the real run has no issues finding them.

Is there a way to pull just that specific commit into my code?

log.dryrun attached (with .txt suffix for Github)
log.dryrun.txt

[yantosca]

Lee Murray recently wrote:

I just downloaded dev/12.9.0 geos chem and the unit tester for the release candidate, and dryrun no longer works at all for me with a clean build test of merra2_4x5_standard. With the exception of the volcano files, all other fields (met fields, emissions, etc.) are not found, despite their being on the system.

Just wanted to give you a heads up before it is released.

I investigated and discovered that the FOUND argument to HEMCO routine SrcFile_Parse (which replaces YYYYMMDD hhmmss tokens with date/month/year hour/minute/second values) was uninitialized. Therefore on the compiler that I was using (gfortran 9.2), it was exiting the routine without ever having been assigned a value. In that case, it was being set with a junk initial value that caused the value to flip from FALSE (the correct value) to TRUE. This was in turn causing HEMCO to think that files that were missing on disk were actually found. Thus in a dry-run simulation, these files never got flagged as missing and requiring download.

The fix is simple, I basically set the RC and FOUND values to default values. See: 8b11ab4.

Because 12.9.0 is already in benchmarking, we will add this fix to 12.9.1. This will be released immediately after 12.9.0.

[yantosca]

Also, I should mention that we are currently ingesting HEMCO updates from several lines of development. This sometimes means that prior functionality gets clobbered inadvertently. Apologies for the inconvenience.

[neyranaz]

This was also probably caused by the inclusion of commit 286745c , #312