Restart runs: internal times in CHANOBS and CHRTOUT_DOMAIN files are incorrect

[jmccreight]

(This is the case when model time matches the time in the restart file, not same as previous bug).

The times calculated for CHANOBS and CHRTOUT_DOMAIN share a common bug.

One "non-standard" detail: I run at 15minute timestep and output that frequently in both models.

In LSM times, these are the runs
Run 1: 2013-09-12 00:00 - 2013-09-16 00:00
Restart run: 2013-09-13 00:00 - 2013-09-13 06:00 (restarts at 2013-09-13 00:00)

Looking at the first CHANOBS output file

jamesmcc@hydro-c1[2109]> ncVarRng time_observation 201309130015.CHANOBS_DOMAIN2
time_observation : Range=( 23400 , 23400 )

jamesmcc@hydro-c1[2112]> ncdump -h 201309130015.CHANOBS_DOMAIN2
...
int time_observation(recNum) ;
        time_observation:units = "seconds since 2013-09-12 00:00 UTC" ;
        time_observation:long_name = "time of observation" ;
...

but (following in R):

as.POSIXct('2013-09-12 00:00:00',tz='UTC') + 23400
[1] "2013-09-12 06:30:00 UTC"

is not the timestamp on the file: 201309130015. The timestamp on the file is correct.

All the following output files are off by exactly the same shift.

If I print diagnostics on the following line in module_HYDRO_io.F:output_chrt() (~ line 2825)

seconds_since = int(dtrt_ch)*K

At the first output, I get

K:           26
dtrt_ch:    900.0000

Their product is the 23400.
The number should actually be 87300 = (24x60+15)x60

I believe there are issues with both:

1. K should be alot more because outputs were written 4x24 hours to get to this point, and 26 may be off somehow (i could understand 25)
2. dtrt_ch is actually 180 while DT is 900 (you can see that DT gets passed to dtrt_ch, so the name may just be misleading here).

The correct calculation might be something more like:

as.POSIXct('2013-09-12 00:00:00',tz='UTC') + (24*(60*60/900)+1)*900
[1] "2013-09-13 00:15:00 UTC"

But I dont want to tinker with this myself.

[jmccreight]

This is likely particular to reach-based routing.