wrong start date read from a netcdf forcing file

[mee067]

I processed CaSRv3.1 for the MRB. Trying to run it, I get this error:

The simulation starts at: ****/05/15 19:38:00.000000
Checking the start dates of the input files...
INFO: The records in 'basin_shortwave.nc' start at: ****/05/15 19:38:00.000000
INFO: The records in 'basin_longwave.nc' start at: 1979/12/30 18:00:00.000000
INFO: Skipping no records in 'basin_longwave.nc'.
INFO: The records in 'basin_rain.nc' start at: 1979/12/30 18:00:00.000000
INFO: Skipping no records in 'basin_rain.nc'.
INFO: The records in 'basin_temperature.nc' start at: 1979/12/30 18:00:00.000000
INFO: Skipping no records in 'basin_temperature.nc'.
INFO: The records in 'basin_wind.nc' start at: 1979/12/30 18:00:00.000000
INFO: Skipping no records in 'basin_wind.nc'.
INFO: The records in 'basin_pres.nc' start at: 1979/12/30 18:00:00.000000
INFO: Skipping no records in 'basin_pres.nc'.
INFO: The records in 'basin_humidity.nc' start at: 1979/12/30 18:00:00.000000
INFO: Skipping no records in 'basin_humidity.nc'.

Obviously, it read the date of the shortwave file wrongly. This is version 1.5.1. Tried 1860_ME_ZT, it read it wrongly but produced a different date/time. Not sure why it sets that date for the start of the simulation - run options start 1980 1 0 0

All forcing files are extracted the same way. Shortwave forcing happens to be the first one that MESH processes. It reads the others correctly!! applying a 7 hour time shift (MRB median time zone).

N.B. the files go from 1979-12-31 13:00 UTC, but:
double time(time) ;
time:standard_name = "time" ;
time:long_name = "Validity time" ;
time:units = "hours since 1980-01-01T12:00:00" ;
time:calendar = "gregorian" ;
time:axis = "T" ;

meaning that the first day has -ve values for the time from -23 to 0. It comes like this from CaSRv3.1 (or maybe the datatool set it like that). Could that be the problem? I guess MESH needs to read it correctly still. cdo timestamps come out correctly.

[kasra-keshavarz]

Would be happy to adjust datatool if that's the source of the issue.

Following this thread.

[mee067]

Hi Kasra,

Are you changing anything in the time axis of the data?

[kasra-keshavarz]

Not for this dataset, no.

[dprincz]

This is fixed in 1.5.3+. It's because of the T in the time units.

[mee067]

Well, I guess MESH should be fixed to read the time axis correctly. As a temporary measure, I am resetting the time axis to start 1979-01-01:12:00 to remove any negative values and will see if this fixes it. This can be done by the datatool too.

[mee067]

Will try 1.5.3, I guess it should be available on the dev branch?

but why did it occur only for the first file?

[dprincz]

It's fixed in MESH 1.5.3 and later versions (All releases are here: Releases)

I don't exactly recall if the workaround to force the forcing data override via MESH_input_run_options.ini works in this case. Alternatively, you can modify the time units attribute in the NetCDF file, which should resolve the issue using MESH 1.5.1.

[dprincz]

Will try 1.5.3, I guess it should be available on the dev branch?

To test against r1860_ME_ZT through r1860_MT_ZT3, I suggested testing MESH 1.5.1 because changes to CLASS in MESH 1.5.3 could change the results owing to bare-ground areas. MESH 1.5.4 adds the SIMSTATS changes from r1860_ME_ZT3_FY (with the exception of permitting zero-flows in the calculations). If you didn't notice problems against existing runs of the GWF code, I suggest using MESH 1.5.5 for anything new.

[mee067]

I remember that the override does not work for netcdf format. We had a long discussion about it because it was not consistent with the behavior with other forcing formats (e.g. r2c) where you could still have timestamps.

I found that T between date and time in all forcing files - why only the first one (shortwave) was affected?

[mee067]

Can I have r1860_ME_ZT3_FY for comparisons?

[dprincz]

I'm not sure why it only happens for the first one, without digging into the code. It might relate to how it selected the simulation start date, since it corresponds to the date derived erroneously from that file.

To rename the units, this might work using ncatted:

ncatted -a units,time,o,c,"hours since 1980-01-01 12:00:00" input.nc output.nc

That's the code as provided but we didn't carry everything over (some of the CLASS and SIMSTATS changes): r1860_ME_ZT3.outputs_variables-fix.pad-outlets_FY_merged.zip

[mee067]

yep, I already used ncatted to change time units and the files are now usable. Btw, for that particular command, output.nc is not necessary. It will change the input if no output file is given - it takes a blink this way no matter how big the file is and no need to have duplicate files.

Thanks for sharing the code. I will be posting bug fixes for 3 issues to be considered for 1.5.6 or later.