[BUG/ISSUE] Invalid time index in daily data organized in monthly files if HEMCO is not called at midnight of last day every month #141
Labels
category: Bug
Something isn't working
never stale
Never label this issue as stale
topic: Input Data
Related to input/emissions data, or disk read/write operations
Report a HEMCO bug or technical issue
This bug was discovered by Xu Feng (@fengx7) when running WRF-GC, but this could happen in any model using HEMCO. A detailed autopsy is below.
Scenario
HEMCO will crash in this scenario saying
Invalid time index
for data at2019-10-31 00:02:00
.Why is this happening?
The HEMCO verbose log shows that:
In this case, HEMCO was called not at midnight. It attempts to search for
201910310002.
. Even though this is daily data, HEMCO first checks thetime slice range
and finds that201910310002.
is after the last time slice available in the file,20191031000.000
, and thus crashes.The expected behavior is that HEMCO will read
201910310000.
because this is daily data and the hour/minute does not matter.This does not crash at other days because otherwise the current HEMCO clock still lies between 00:00 of the first month and 00:00 of the last day. e.g., if
201910300002.
is the current HEMCO clock, HEMCO will correctly recognize that this is within the range201910010000.
and201910310000.
, and select the closest time slice (201910300000.
). There is no drift.Proposed solution
In this case HEMCO should recognize that
201910310000.000
is a valid time slice for the daily-updated data requested at time step201910310002.
I think a fix to the range check would be OK, because if that happens HEMCO will correctly find the closest time slice.The text was updated successfully, but these errors were encountered: