Thoughts on how to design a generalized co-simulation

[PhilipFackler]

The path toward a general co-simulation application diverges (after #546) depending on how often we want to synchronize: just at every time step OR at every call to evaluateResidual. In either case, I would recommend resurrecting the "IOPorts" PR (#481).

• Every residual: Extend the "IOPorts" implementation to make ports configurable...enabling the zmq exchange to be triggered at the moment signals are read from ports.
• Every step
  • Add a modified version of ConstantSignalSource that would interface with zmq to update its (no-longer-constant) values.
  • Use "IOPorts" as-is/was to enable a more natural means of access from outside the system (no new component needed). This would make the most sense from the application perspective because the application input file could simply specify which signals to assign to the network.

I'll add that in either of the "IOPorts" scenarios the co-simulation "manager" could be set up to exchange all necessary variables in one send/recv.

[pelesh]

Co-simulation usually implies that the co-simulated parts are black-box simulators. evaluateResidual function is an implementation detail and in principle should not be visible to co-simulation platform. The DynamicSimulation app has ability to manage step size and system input/output. I would think that a system model object would have several input and output signals to communicate with a co-simulation platform.

CC @hambrickjc