Next: 5.18 Documenting a Network Up: 5. Working with Networks Previous: 5.16 Undoing/Redoing a Connection Contents Index
``Network Execution'' means one or more modules must be executed in a coordinated fashion. SCIRun's scheduler manages the coordinated execution of modules.
Note that some modules need to be compiled before they are executed (see Dynamic Compilation). Compilation delays network execution. Usually, occurs only one time per module. After a module is compiled, it does not need to be compiled again. Modules change color during compilation.
The scheduler is invoked when an event triggers a module's execution. The scheduler creates a list of all modules that must execute in coordination with the triggered module. Modules upstream (directly or indirectly) from the triggered module are put on the execution list if they have not previously executed. All modules downstream from the triggered module are put on the execution list. Once the scheduler determines which modules must be executed, it executes them (in parallel where possible).
Network execution is mostly transparent. That is, events that trigger module execution usually generate automatically. Sometimes, however, the user must manually generate a triggering event by choosing the item from a module's pop-up menu.
Each module executes in its own thread and blocks (waits) until its upstream modules can supply it with data. After a module completes its computation, it sends the results to its downstream modules. This completes a module's execution cycle. The module will not have another chance to receive data from its input ports and send data to its output ports until some event puts the module back on the scheduler's execution list.
This behavior prevents modules from computing in an iterative fashion (sending intermediate results to their downstream modules), because downstream modules cannot receive results until they are in their execution cycle. Downstream modules would need to be executed each time the upstream module posts an intermediate result.
Some modules are designed to be used in an iterative fashion. They use a method called send_intermediate to send the results of each iteration. When this method is used, the scheduler (re)executes downstream modules each time the upstream module posts its next result. Downstream modules are able to receive the results of each iteration as soon as the upstream module sends them.
Modules SolveMatrix and MatrixSelectVector (from the SCIRun package and Math category) are examples of modules that compute iteratively using the send_intermediate method.
Some modules are designed to be used exclusively in feedback loops. Their output ports can be connected directly or indirectly to their input ports. These modules also use the send_intermediate method.
Examples of feedback modules are DipoleSearch and ConductivitySearch from the Inverse category of the BioPSE package and BuildElemLeadField from the LeadField category of the BioPSE package.