System simulation edge cases for event routing

[callumforrester]

• Run system simulations on their own (e.g. standalone zebra)
• Explicitly disallow disconnected graphs partly inside system simulations

[rosesyrett]

For that second point, do you mean like this:

[rosesyrett]

Do we want to support this kind of graphing, and if not, why not? To me it makes sense that you might want several disconnected processes going on in a system simulation component.

[callumforrester]

@abbiemery opinions?

[abbiemery]

I can't think of a reason you would want this, but that doesn't mean someone wont. I therefore don't mind supporting it provided there are tests which prove it works and catch if it doesn't. Including using the config loading to do so.

[rosesyrett]

It's been decided, after much discussion, that the SystemSimulationComponent should not be 'standalone', because that would require it to keep it's own time and 'master' scheduler logic, and effectively push it to running independently of the master scheduler. As a result, it should at least have dummy components that act as inputs/outputs.

I suppose this makes sense as all components in ticket are expected to list their inputs and outputs.

I would still like to work on the above issue, r.e. routing. I think the diagram I drew above should be an allowed use case; but the fix for this is reasonably complex, as it involves changing how the event router works.

[garryod]

Just seen this, and as far as I can recall the system in your diagram should work fine, what about it isn't working?

[rosesyrett]

@garryod At the moment, when the master scheduler does its initial tick, it calls the ticker with all of it's components, during which its to_update dictionary gets initialised with all of the components known to the master - in the diagram above, the external source, external sink, and system simulation component.

ticker.schedule_possible_updates gets called in this process, during which ticker figures out what needs updating first (i.e. isn't dependant on any other component) and effectively sends a message to the message bus asking the component to update.

Now, the components get these inputs (via component.handle_input) and do an on_tick. This includes the system simulation component, whose on_tick method involves it calling its own ticker, but only with any interrupts, wakeups or the "external" component. The consequence of this means that any components inside the system simulation component which are not connected to the "external" component that acts as its input are ignored.

[rosesyrett]

i.e. you can try running the simulation of the diagram above. The external sink will never see the value of the internal source (at the moment).

[garryod]

Gotcha, that makes sense. I was imagining the internal "Source" being interrupted which should produce an output as expected, but of course if it's a trampoline or likewise it'll never be started