Talk:Spec:Subsecond

General discussion

 * 1) I don't see a dT from the switch to EVENT to DELTA, i.e., the sum of all the passed deltamode_timesteps. --user:jcfuller
 * 2) * The postupdate callback passes the final clock time, which should include the accumulated delta time. (That's missing. See S5 discussion.) --user:dchassin
 * 3) Coherent -> steady-state ?? --user:jcfuller
 * 4) * Added definition of coherent to R2. Coherent means that all objects have the same internal time. We need to distinguish that from consistent, which means that all object states are consistent with each other.  That is something that cannot be guaranteed during subsecond simulations because of simulation lag. --user:dchassin
 * 5) Does the system automagically swap from EVENT to DELTA and back when it hits the full second boundaries? --user:mhauer
 * 6) * Switching will have to be triggered from inside the modules as needed. There is no provision for automatically going from EVENT to DELTA.  Same goes for switching back except we need to consider the maximum time permitted in DELTA mode.  It certainly can't be more than 1 hour because we know that certain things are almost always going to change then. --user:dchassin
 * 7) Can the system reiterate on subsecond moments? --user:mhauer
 * 8) * If you mean backup and redo, then I think the answer is no. --user:dchassin
 * 9) What is the return type for ***update?  Should the updates return a subsecond t2?  Should there be a special value for "after the next second boundary [ignore me]"? --user:mhauer
 * 10) * The usual 0->failure, 1->success. Interupdate has a third value to indicate that the model is steady, which would allow for an automatic switch to event mode when all modules agree the model is steady. --user:dchassin
 * 11) Does an interupdate fire after the clock change to a second boundary where a postupdate will be called? --user:mhauer
 * 12) * Good question. It's easier to do it after every tick, but then there will be one extra one at the end of the loop.  Is that ok? --user:dchassin
 * 13) * Amendment to S7 make it necessary to call interupdate after every update, including the last one. --user:dchassin
 * 14) Are preupdate and postupdate implicitly called on the second boundaries? (timing question) --user:mhauer
 * 15) * No. The specs carefully avoids making 1 second a magical boundary because there is not such requirement.  The boundary will be determined exclusively by the module implementation.  The core is agnostic on the question. --user:dchassin
 * 16) Mode switches need to be easily requested by modules before entering the main event loop. --user:ftuffner
 * 17) * Added an export of deltamode_desired to address this (S2). --user:dchassin
 * 18) Interupdate needs to be able to specify whether event mode is permissible and the switch back to event mode done when all modules agree that it is permissible. --user:ftuffner
 * 19) * Expanded meaning of interupdate to include third value 2 that indicates the event mode is permissible. This value should be returned when the module thinks the model is steady. --user:dchassin

S2

 * 1) Defines coherent state in an implicit fashion.
 * 2) * Added definition of coherent to Req:Subsecond and clarify distinction between coherent and consistent R2. --user:dchassin

S3

 * 1) Bludgeons the naysayers. --user:mhauer
 * 2) * Indeed it does. (See R3 discussion.) --user:dchassin

S5

 * 1) Does not include TIMESTAMP t1?  Could use a signed long without losing nanosecond precision. --user:mhauer
 * 2) * Absolute clock is not passed with update calls. It is passed in by interupdate, which b.t.w. is missing the accumulated delta time. --user:dchassin
 * 3) This may be answered in the above question/response, but how will the EVENT handle updates if DELTA is not switched off before the next EVENT update?  e.g., EVENT wants a 1 second update, but DELTA remains active for the equivalent of 5 seconds.  This may end up being more of a model issue (individual models assuming a return time is never overshot - however minimum_timestep code testing should have already revealed this problem). --user:ftuffner