nikhilgupta10
commented
7 years ago nikhilgupta10 imported these comments from Sourceforge: "mhauer": * status changed from new to accepted
r3618 should fix the issue for 3.0. It looks like all the tinkering with which time value is stored where in exec.c wasn't entirely meshed with what was being done in load.c for #set starttime and clock.starttime & clock.timestamp. Needs additional validation.
,
"mhauer":r3622
,
"mhauer": * owner changed from mhauer to jcfuller
- priority changed from critical to validate
- status changed from accepted to assigned
r3734
,
"dchassin": * priority changed from validate to critical
-
type changed from defect to validation ,
"jcfuller": * owner changed from jcfuller to andyfisher ,
"andyfisher": * status changed from assigned to closed
- resolution set to fixed
I ran a couple autotest in the current revision of trunk and 3.0 and t0 is the given starttime in each case when I entered the presync of various objects for the first time. closing the ticket.
,
In pre-sync on the very, very first pass, t0=946684800 (1-1-2000) and t1=1230786000 (1-1-2009, start date of the simulation). What I don/u2019t understand is why t0 starts at a date prior to the simulation date? During the first pass, shouldn/u2019t t0 and t1 just be the start date of the simulation, whether or not you/u2019ve done anything with time in init()?? What am I missing here?
Follow up:
Looks like in globals.c, 946684800 is the initial value. If I use:
set starttime='2009-01-01 00:00:00'
It correctly captures the initial time, rather than pulling it from the clock object directly:
clock {
}
I believe this might be what is causing a number of the failures in the trunk build right now, as objects are trying to look at time differentials that may be on the order of years during the first pass (it is certainly screwing up house_e).
As an aside, we/u2019ll also want to capture what a lot of people do with the clock which is to use /u2018timestamp/u2019 and /u2018starttime/u2019 interchangeably:
clock {
}
,