Skip to content

Latest commit

 

History

History
122 lines (108 loc) · 5.96 KB

notes.org

File metadata and controls

122 lines (108 loc) · 5.96 KB
Raw

Notes for modelers

On message simultaneity

  • Messages received at the same sim-time are considered simultaneous.
  • Models should not depend on the order that simultaneous messages are processed.

Implementation Notes

On the Non-Instantaneous Change Assumption (NIA)

  • Reference

    Barros, Fernando J. "On the representation of time in modeling & simulation." 2016 winter simulation conference (WSC). IEEE, 2016.

  • Every state must have a positive duration.
  • Message delivery is instantaneous.
  • A model cannot be immediately imminent.
    • If a simulation starts at t, then all of the models are already determined at t.

On the hyperreal time base.

Reference

Barros, Fernando J. "On the representation of time in modeling & simulation." 2016 winter simulation conference (WSC). IEEE, 2016.

Problem statement

  • Zero-length delays cannot represent causation.
  • In standard DEVS, users must understand that the transition function may be called multiple times before time advances.
  • With dynamic structure, if an event causes a model to be removed immediately, there is a chicken and egg paradox.

Solution: Use a hyperreal time base.

  • The hyperreal implementation is like Barros, but not the simulation semantics.
  • Differences from Barros:
    • Barros allows zero-length delays, but imposes an infinitesimal delay (ε) to every transition. We don’t allow zero-length delays, and so don’t need to add an additional delay.
    • Barros requires three steps (of duration ε) for a model to respond to external input with an output. (See Mealy Machine example.) I think this is to split the updates into something like: original model, w/ input, new state w/ output, new state. Our version follows the usual DEVS semantics, but with the constraint against zero-length delays.

On disallowing zero-length delays.

  • Rationale: There’s no such thing in the real-world. (I think) that is mostly equivalent to Barros; in that system, the modeler can specify a zero-length delay, but the system imposes an infinitesimal duration. The modeler still needs to be aware of this delay, so that they can subtract it from the next delay, if they want the outputs to align to whole numbers.
  • With this constraint, each simulator will only be updated once per time point.
  • Consequence: the earliest response to an external event is t+ε.
  • I like that the hyperreal values are all on the number line. They have a solid mathematical and physical basis (Barros).
  • My rationale is that zero-length delays are fundamentally flawed, and using the hyperreal base lets us avoid problems and add clarity without sacrificing anything that wasn’t already broken. For example, if a model is triggered when exactly 5 inputs arrive at the “same time”, then that notion of simultaneity should be modeled with some interval (e.g., events occurring within 100ms), and not rely on the inputs arriving at exactly the same point in time, which is impossible in the real world.
  • I don’t see the value in accomodating these zero-delay events. Superdense time, IIUC, works around them, so that modelers can continue to ignore the inherent problem. Barros allows them in some sense, but still adds an infinitesimal delay, so in what sense does it really allow them?

On two types of graphs

There are two graphs:

  1. The model network hierarchy, where nodes are models and edges are parent-child relationships.
  2. The connection topology, where nodes are models and edges are message routes.

On message routing across networks

  • It shouldn’t take any (logical) time for a message to cross networks.
    • That entails collecting all simulator output BEFORE invoking transitions.
    • I’m pretty sure that some of the algorithms in the literature do not account for this.

On optimization

Different models will have different resource requirements.

A one-size-fits-all solution isn’t feasible.

Modelers may exploit domain knowledge for optimization.

The performance of message routing depends on the model. For example, the model will determine how frequently messages cross networks. If they do so infrequently, then it may not be worthwhile to collapse routes in the implementation.

On the implementation of abstract simulators

The abstract simulators described in the literature are mathematical structures defining a class of concrete implementations.

For example, a distributed implementation might employ callbacks instead of function calls.

This library does not include every useful simulator implementation.

On external events

  • In this context, external events mean events that originate outside the logical simulation, such as the press of a key.
  • The support for external events is weak. There is top-level support for messages to enter and exit the simulation.
  • A more robust system might allow the modeler to specify an external connection directly to a model. That would avoid needing a route all the way from the root of the simulation to the target model.
    • I have not found a good way to implement that. Ultimately, you need something very close to they way it works now.
    • I considered automatically creating the route, but you can’t rely on every network implementing dynamic structure, and it would be confusing to the user to see debug info about a route they didn’t know they created. So, better to just be explicit.
    • I also considered implementing external events separate from normal messages, but you want to handle all the messages uniformly and synchonously, and it could be awkward to switch between using external events or normal messages (e.g., to replace user-input with a recording).