Check behavior of timestep when using GriddynRunner
nightlark opened this issue · comments
See how the timestep parameter is used when running in a coupled simulation -- should be treated as the maximum time delta from the current time? vs telling GridDyn what time it should be at after returning from the step function.
I could see uses for both, but in most cases I have encountered the most natural interface is running to the next event which is relative to the beginning of the simulation, not the previous time-step.
relative timestepping can get really confusing if the simulator can return at different intervals than the requested one.
I could see adding a runFor(...) function that used relative timestepping.
We might be thinking of different things -- running to a time relative to the beginning of the simulation makes sense. The problem encountered was using the GridDyn runner interface, I think we told the simulation to step to something like time 6.695 and after returning from the Step call the returned time was 6.7; some events then got scheduled at time 6.698 and then GridDyn stopped advancing time. Changing the timestep parameter in the xml file from .01 to .001 made the problem go away.
I don't see the timeStep parameter getting used in the gridDynSimulation::step(nextStep, timeActual) function, so maybe the parameter was just affecting the times requested by griddyn (in the absence of events from other simulators) in a way that exposed a bug in the time advancement for fskit.
what would be the preferred behavior if given a requested time that is between allowable times? I think in HELICS it defaults to returning the next valid time after the requested one.
For an individual simulator, I don't think it should advance to a time that is past the time it has been granted (or if it does internally, it needs to be able to handle events that arrive with a time that is between the previous time it was at and its current time without hanging -- and it needs to be able to wait until the other simulators catch up; I think for noticing problems, skipping the time advancement and queuing events might make sense if iteration isn't supported, so then it would be safe to have an error if events ever get scheduled in the past).
If the granted time is between the current time and current time + timestep, it would be easiest as a user if GridDyn advanced to the in between time if it is able to handle a time with that resolution (fskit treats GridDyn as a variable step size simulator, and other federates as discrete step size simulators).
Right now, I think GridDyn might be handling the time step in an a way that is okay, since it looks like it advances to the time requested rather than the next closest time that is evenly divisible by the timestep param, and that the less frequent scheduling of null events with the bigger timestep resulted in time requests to fskit that messed up the time granted when it was taking into account time requests from the discrete time step simulators. Not completely sure yet, but maybe I can get a smaller test case to narrow down the source of the time mismatch between the simulators.
For HELICS the default behavior sounds okay since it is coordinating the time between all of the simulators.
In GridDyn, the timestep is used in some solver modes and not in others. Basically the step size taken unless instructed otherwise. (in some solver modes it mightly only be able to advance by integral units of the timestep based on the mathematics of the solver).