CDI: unexpected reference and forecast date for time-constant fields (steptype=TSTEP_CONSTANT)
Dear Uwe @m214003 , Dear Sergey @m300488,
we are currently preparing a new ICON binary for our operational weather forecasts at DWD. During our tests, we stumbled across an unexpected CDI behavior which, unfortunately, prevents us from using the latest ICON version (RC).
The problem we observed is as follows:
When writing an output file which exclusively contains time-constant fields (i.e. steptype=TSTEP_CONSTANT
), the reference and forecast date is unconditionally set to the dummy date 10101
. Below is the output of cdo sinfov
for a forecast run starting at 2017-04-15T00:00:00Z:
File format : GRIB2
-1 : Institut Source T Steptype Levels Num Points Num Dtype : Parameter name
1 : DWD unknown v instant 91 1 327680 1 P16 : HHL
2 : DWD unknown v instant 1 2 327680 1 P16 : HSURF
3 : DWD unknown v instant 1 3 327680 1 P16 : FR_LAND
4 : DWD unknown v instant 1 3 327680 1 P16 : CLON
5 : DWD unknown v instant 1 3 327680 1 P16 : CLAT
6 : DWD unknown v instant 1 3 491520 2 P16 : ELON
7 : DWD unknown v instant 1 3 491520 2 P16 : ELAT
Grid coordinates :
1 : unstructured : points=327680
grid : number=24 position=1
uuid : 9b0b03ca-18c4-11e4-9318-776f158edd08
2 : unstructured : points=491520
grid : number=24 position=3
uuid : 9b0b03ca-18c4-11e4-9318-776f158edd08
Vertical coordinates :
1 : generalized_height : levels=91
height : 1 to 91 by 1
bounds : 1-0 to 91-0 by 1
uuid : b3d63ca1-092c-5f0e-b9f4-4c9b2a052be0
typeOfSecondFixedSurface : 101
2 : surface : levels=1
typeOfSecondFixedSurface : 101
3 : surface : levels=1
Time coordinate : 1 step
RefTime = 0001-01-01 00:00:00 Units = minutes Calendar = proleptic_gregorian
YYYY-MM-DD hh:mm:ss YYYY-MM-DD hh:mm:ss YYYY-MM-DD hh:mm:ss YYYY-MM-DD hh:mm:ss
0001-01-01 00:00:00
If I add a single time-dependent variable (e.g. the sea ice fraction), then the reference and forecast date are set 'properly' in the output file. i.e. in accordance with our explicitly chosen reference date which we specify in mo_name_list_output_init:setup_output_vlist
of the ICON code.
idate = cdiEncodeDate(INT(time_config%tc_exp_startdate%date%year), &
& INT(time_config%tc_exp_startdate%date%month), &
& INT(time_config%tc_exp_startdate%date%day))
itime = cdiEncodeTime(time_config%tc_exp_startdate%time%hour, time_config%tc_exp_startdate%time%minute, &
INT(time_config%tc_exp_startdate%time%second))
CALL taxisDefRdate (taxisID, idate)
CALL taxisDefRtime (taxisID, itime)
This behavior is different from the behaviour of CDI 1.8.x: With the previous CDI version we were able to switch between from the 'normal' date to the dummy date, by setting
vlistDefVarTypeOfGeneratingProcess(vlistID, varID, 196)
see also the CDI code
gribapiDefTime(int editionNumber, int productDefinitionTemplate, int typeOfGeneratingProcess, grib_handle *gh,
CdiDateTime vDateTime, int tsteptype, int numavg, int taxisID, int gcinit)
{
UNUSED(numavg);
int taxistype = (taxisID == -1) ? -1 : taxisInqType(taxisID);
if (typeOfGeneratingProcess == 196)
{
vDateTime = cdiDateTime_set(10101, 0);
taxistype = TAXIS_ABSOLUTE;
}
Or in other words, it was possible to write files which have the 'normal' reference and forecast date, even though the files contain only time-constant fields. This feature is rather important for use, as we use the reference and forecast date for writing/retrieving these time-constant fields to/from our database.
I was able to enforce the old behavior by changing
varID = vlistDefVar(vlistID, gridID, zaxisID, MERGE(TIME_CONSTANT, TIME_VARYING, info%isteptype == TSTEP_CONSTANT))
CALL vlistDefVarTsteptype(vlistID, varID, info%isteptype)
to
varID = vlistDefVar(vlistID, gridID, zaxisID, TIME_VARYING)
CALL vlistDefVarTsteptype(vlistID, varID, info%isteptype)
in mo_util_cdi:create_cdi_variable
, but I am not sure if this is a proper solution.
Would it be possible to revert the responsible code changes or do you have any suggestion how we can enforce the desired behavior?
Best wishes, Daniel