Addressing Ambiguous Causality Sequences

 In order to determine how GoldSim is to carry out its calculations, it first must create the causality sequence for all of the elements. This represents the sequence in which the elements must be logically computed.

In some models, however, there may be more than one valid way to sequence the system, and these different sequences may produce different results.  In these cases, GoldSim provides a way to manually force a particular causality sequence to ensure that the model accurately represents your system.

In order to better understand this, let’s construct a simple system where the causality sequence is ambiguous:

By default, the causality sequence for this model looks like this:

In order to fully understand this sequence, it is first necessary to recall a special rule regarding a Function Sequence involving Discrete Changes: Discrete Changes are propagated to any affected stock elements instantaneously when the Discrete Change is updated in the sequence (regardless of where the affected stocks are located in the sequence).

So in the sequence shown above, GoldSim does the following: Every timestep, after changing the system clock, GoldSim first computes the state variables that are intrinsic functions of time.  In this example, the only element that falls into this category is the Reservoir, so it is first brought up to the current time.  After doing this, GoldSim then computes the Function Sequence.  First, it computes the value of the Discrete Change, and instantaneously applies the Discrete Change to the Reservoir (this is actually regardless of where the Reservoir is in the Sequence).  Then it computes the Reservoir (i.e., it would store all of its inputs for use in the next timestep, but this would not change its current value). Finally, the Expression is computed.

The reason this system is ambiguous is related to the fact that the Reservoir is actually computed twice.  First, it is brought up to the current time (i.e., it solves a time integral).  Then, it is updated a second time within the Function Sequence (it is modified by the Discrete Change).  The ambiguity here arises from the fact that it is not completely clear when you might want to compute the Expression. 

There are two options:

1.  Compute the Expression after the Reservoir has been updated by the Discrete Change; or

2.  Compute the Expression after the Reservoir has been brought up to the current time, but before it has been updated by the Discrete Change.

GoldSim will sequence it assuming the first option is correct.  However, the second option is equally valid, and will produce a different result! Hence, when you have a system such as this, you must specifically instruct GoldSim how to sequence this system to ensure it accurately represents the system you are trying to model.

To facilitate this, GoldSim provides an option to manually force a particular causality sequence.  If you right-click on an element in the sequence, one of the options is to “Specify Precedent”.  You can then specify a particular element that you wish the selected element to follow in the causality sequence.  In this particular case, to force the second option listed above, we want the Expression to be a precedent for the Discrete Change.  Right-clicking on the Discrete Change and selecting “Specify Precedent” displays this dialog:

If we select Expression here, the causality sequence now looks like this:

Note that Expression is now in front of the Discrete Change.  The Discrete Change is highlighted in gold (indicating that it has a “forced” precedence).  The input port for the Discrete Change is also highlighted in gold, and its precedence requirement is added to its tool-tip:

If you right-click on the Discrete Change, you would see that there is a new option (“Remove Precedent”).

Three other points regarding forced precedence should be noted:

   You can only specify one precedence requirement for an element (although an element can have multiple elements that use it as a precedent).

   GoldSim will not allow you to specify a precedent that results in an invalid causality sequence (e.g., a recursive system). It only allows you to force sequences that are still valid. 

   Precedence requirements do not create a link to the element being referenced (i.e., the precedent).  As a result, if the precedent is deleted and replaced with an element with the same ID, the precedence will not be recreated.

An example of the use of forced precedence to control sequencing (Bounce.gsm) can be found in the General Examples folder in your GoldSim directory (accessed by selecting File | Open Example... from the main menu).

Learn more about: