[GRASS-user] Itzi results have one day lead from input data

GRASS GRASS user
1

   I created a rainfall STRDS (in mm/hr) from 2013-11-15 through 2013-12-08.
The Itzi model parameter file's start_time is 2013-11-15. t.register
specifies the start date as 2013-11-15 and an increment of 1 day.

   When the model was started the first day processed was 2013-11-15, and the
last day was 2013-12-08.

   When I look at the t.info output I see
Start time:................. 2013-11-16 00:00:00
End time:................... 2013-12-09 00:00:00
Granularity:................ 1 day

   Why does the STRDS move the dates ahead by one day?

Rich

2

The strds does not move any dates, it gathers all dates of the maps
and shows the first and last date. The interval time model of the
temporal framework is left closed right open. That means that the end
time is not part of the interval but the start time for a potential
predecessor. This avoids end times like: 2013-12-08 23:59:59.

Please use t.rast.list to inspect all time intervals of your raster maps.

Best regards
Soeren

2017-03-23 19:09 GMT+01:00 Rich Shepard <rshepard@appl-ecosys.com>:

  I created a rainfall STRDS (in mm/hr) from 2013-11-15 through 2013-12-08.
The Itzi model parameter file's start_time is 2013-11-15. t.register
specifies the start date as 2013-11-15 and an increment of 1 day.

  When the model was started the first day processed was 2013-11-15, and the
last day was 2013-12-08.

  When I look at the t.info output I see
Start time:................. 2013-11-16 00:00:00
End time:................... 2013-12-09 00:00:00
Granularity:................ 1 day

  Why does the STRDS move the dates ahead by one day?

Rich

_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

3

Rich,

Is this t.info output taken from the STRDS created by Itzï?
The current version of Itzï does not record the initial state.
So if you tell Itzï that the simulation starts at 2013-11-15 00:00:00
and the record_step is 24:00:00, then the first registered map will be
at 2013-11-16 00:00:00.
However, the last record should be equal to the end_time given in the
Itzï configuration file. If not, please fill-up an issue
(https://bitbucket.org/itzi-model/itzi/issues)

Regards,
Laurent

2017-03-23 12:09 GMT-06:00 Rich Shepard <rshepard@appl-ecosys.com>:

  I created a rainfall STRDS (in mm/hr) from 2013-11-15 through 2013-12-08.
The Itzi model parameter file's start_time is 2013-11-15. t.register
specifies the start date as 2013-11-15 and an increment of 1 day.

  When the model was started the first day processed was 2013-11-15, and the
last day was 2013-12-08.

  When I look at the t.info output I see
Start time:................. 2013-11-16 00:00:00
End time:................... 2013-12-09 00:00:00
Granularity:................ 1 day

  Why does the STRDS move the dates ahead by one day?

Rich

_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

4

On Thu, 23 Mar 2017, Sören Gebbert wrote:

The strds does not move any dates, it gathers all dates of the maps and
shows the first and last date. The interval time model of the temporal
framework is left closed right open. That means that the end time is not
part of the interval but the start time for a potential predecessor. This
avoids end times like: 2013-12-08 23:59:59.

Please use t.rast.list to inspect all time intervals of your raster maps.

Soeren,

   Thanks for explaining.

Rich

5

On Thu, 23 Mar 2017, Laurent C. wrote:

Is this t.info output taken from the STRDS created by Itzï?

Laurent,

   I assume so since the registered maps are Itzi output.

The current version of Itzï does not record the initial state. So if you
tell Itzï that the simulation starts at 2013-11-15 00:00:00 and the
record_step is 24:00:00, then the first registered map will be at
2013-11-16 00:00:00.

   This is what Soeren wrote, too.

However, the last record should be equal to the end_time given in the Itzï
configuration file. If not, please fill-up an issue
(https://bitbucket.org/itzi-model/itzi/issues)

   Here is the time portion of the parameter file:

[time]
start_time = 2013-11-15 00:00
duration = 600:00:00
record_step = 24:00:00

and the end turns out to be 2013-12-09 00:00.

Thanks,

Rich

6

2017-03-23 12:49 GMT-06:00 Rich Shepard <rshepard@appl-ecosys.com>:

On Thu, 23 Mar 2017, Laurent C. wrote:

Is this t.info output taken from the STRDS created by Itzï?

Laurent,

  I assume so since the registered maps are Itzi output.

Itzï is creating the maps and a STRDS where maps are registered.
But the maps could be registered in various STRDS.

The current version of Itzï does not record the initial state. So if you
tell Itzï that the simulation starts at 2013-11-15 00:00:00 and the
record_step is 24:00:00, then the first registered map will be at
2013-11-16 00:00:00.

  This is what Soeren wrote, too.

However, the last record should be equal to the end_time given in the Itzï
configuration file. If not, please fill-up an issue
(https://bitbucket.org/itzi-model/itzi/issues)

  Here is the time portion of the parameter file:

[time]
start_time = 2013-11-15 00:00
duration = 600:00:00
record_step = 24:00:00

and the end turns out to be 2013-12-09 00:00.

If I do the calculation, the simulation will actually ends on
2013-12-10 00:00:00 :

from datetime import datetime, timedelta
start_time=datetime(year=2013, month=11, day=15)
duration=timedelta(hours=600)
end_time = start_time + duration
print(end_time)
2013-12-10 00:00:00

So the last record is missing.
I just checked the source code and there is actually a bug that
prevents the record of the very last maps.
It should be fixed for the next release of Itzï.

Laurent

7

On Thu, 23 Mar 2017, Laurent C. wrote:

So the last record is missing. I just checked the source code and there is
actually a bug that prevents the record of the very last maps. It should
be fixed for the next release of Itzï.

Laurent,

   The last map I read in, 2013-12-09, is actually one day past the last date
of interest based on what you had written earlier in this process. So the
bug should not affect my models.

Thanks,

Rich