Q. What is the firing order of modules? When I have multiple connections to an output of a module, in what order will my modules be fired?

A: A module can be in one of three states:

   1. Satisfied
   2. Changed (needs to run)
   3. Scheduled (needs to run and is on the "run queue")

If a module is changed, it usually goes directly from "Satisfied" to "Scheduled" unless other modules are running AND the change of this module did not result from the execution of a currently running module.

Take a simple network.. read volume -> isosurface -> geometry viewer

If you click on read volume's file browser while isosurface is running, it will not re-run until read volume and geometry viewer are complete.

In this case, the read volume module is placed on the "Changed" list but not Scheduled. geometry viewer, however, is scheduled immediately after isosurface completes.

The next key issue is how do we determine which of two scheduled modules to run next. This is done by sorting the queue of modules as we add each module. The sorting rules are as follows:

• if module A is connected to module B (directly or indirectly) and module B is NOT connected to module A (either directly or indirectly), the module A goes first.
• if B is connected to A (and A is not connected to B), then B goes first.
• if they are not connected to each other directly, they can be run in parallel and are stored next to each other in the list. In this case, the order is determined by which order they are scheduled. If they are both attached to the same upstream module, this order is determined by what order the connections are made to the upstream module.
• if they are both connected to each other, the sorting rules are not properly defined. We do some heuristic tests like: data before filters, filters before mappers, mappers before renderers. This case is not likely to occur very often.