Each object has a set of slots for which new values will cause the object to try to solve. These are the object’s dispatch slots. All dispatch slots are time series slots. All slots which can be linked to slots on other objects are dispatch slots, and all slots which are included in the dispatch conditions of any dispatch method are dispatch slots. Whenever a value is set on a dispatch slot, the object on which the slot resides must examine its state to determine if it needs to solve; i.e., execute a dispatch method.

Dispatch methods are the algorithms for solving the physical process equations of RiverWare objects. There is one dispatch method for each combination of inputs and outputs for which a solution is possible.

If an object determines that it can execute a dispatch method, it notifies the controller of the method it will execute. The controller adds the object to a queue of objects waiting to execute their methods. When a dispatch method on an object is executed, we say that the object has dispatched. The objects dispatch in the order they are added to the queue.

Each dispatch method has a set of dispatch conditions which must be met for that dispatch method to be executed during a timestep. The dispatch conditions specify the input/output data combination required for that method to successfully execute. The dispatch conditions for each method are made up of two slot lists called the knowns and the unknowns. If all of the required knowns are known and all of the required unknowns are not known, the object may solve using that dispatch method. The dispatch conditions are checked whenever a value is set on a dispatch slot and no dispatch method has yet executed at that timestep.

After an object has dispatched once, if one or more of its dispatch slots gets a new value (for example by link propagation from another object), the object must resolve. In pure simulation, the object simply redispatches with the same dispatch method as the first time it dispatched in the timestep. In other words, an object may solve using only one combination of input/output data on any given timestep.

Each object has a conflict list which lists a combination of slots which, if all are known, result in too many knowns and not enough unknowns for the object to solve. If this situation is detected during a run, an over-determination error is posted, and the simulation is halted. Also, each slot keeps track of where its values originate: user input, link propagation, or set by the object’s methods. At each timestep, each slot can receive information from only one of these three sources. If a slot is set by one source, and subsequently reset by another source, an over-determination error is posted, and the simulation is halted. As a result, values may only propagate across a link in one direction during a single timestep.