In most common (procedural) programming languages, the order of statements is important.  For example, the following two series of statements result in different final values for the variables x and y:


Statement Series 1


x = 0

y = 1

x = y + 1

y = x + 1


This series of statements results in the final values x = 1 and y = 2.


Statement Series 2


x = 0

y = 1

y = x + 1

x = y + 1


This series contains the same statements, but in a different order.  The final values of the variables in this case are x = 2 and y = 1.


While the CSL language respects the order of equations/statements in the initial, terminal, dynamic, and discrete sections, the derivative sections handles equations a little differently.  In this section, the ordering of statements is not important.  As part of the Magnolia CSL code translation process, equations are ordered such that any inputs to a particular equation are computed before that equation is evaluated.  Consider the following CSL code:


y = cos(x)

x = sin(t)


The first statement requires "x" as an input the the equation on the right side of the equal sign, but the value of "x" is not computed until the following statement.  As part of the translation process, Magnolia will reverse the order of evaluation of these two equations, namely:


x = sin(t)

y = cos(x)


The number of equations, and corresponding dependencies between equations, can be very large for a complex model.  But for a properly constructed model, it should be possible to put the equations in sorted order.

The INTEG Operator

It is important to note that the INTEG operator works a little differently than other operators.  An statement containing the INTEG operator should be considered more of a declaration than an executable statement.  The INTEG operator essentially says: the variable on the left side of the equals sign is a state, and its value will be computed by the Magnolia ODE solver prior to evaluating the derivative section code.  So, for sorting purposes, all state values are assumed to be computed before any equations in the derivative section are calculated.

Other Variables and Constants

Like state variables, the values of constants are determined before evaluation of any derivative section code for purposes of sorting.  In fact, the values of constant are set before execution of ANY model code; rather constants are set at build time.


Typically, other variables in the model code are calculated by equations in the derivative section.  But if they need to be initialized, this can be done in the INITIAL section.


The variable representing the independent variables (T, by default) is also set prior to evaluation of any derivative code.

Multiply Defined Symbols

One error which can arise in coding CSL models comes about from having a particular variable occur on the left side of the equal sign in more than  one equation in the derivative section.  This has the effect of presenting two conflicting equations to the Magnolia translator.  To resolve this, consider the system being modeled: do the two variables really represent the same quantity, or is a variable name being incorrectly used twice to represent different quantities?  If so, make difference variable names for the two quantities.  Is the variable being used twice as part of a multi-step calculation?  Then consider putting this section of the code into a PROCEDURAL section, defined later.  If the variable is used as an output in different branches of a IF/ELSE block, the translator should sort the equations correctly automatically.  Is one of the equations being used to assign an initial value to the variable?  Then the initialization statement should be put in the INITIAL section.


This error is detected by the Magnolia translator and reported as an error in the Command and Alerts windows.

Algebraic Loops

In some cases, it is impossible to put the derivative statements into sorted order.  This is typically due to a programming error.  Consider a very simple example like the following:


x = y

y = x


Neither the variable x or y can be determined because of the circular dependency in these two equations.  The resolution to this error typically involves checking the offending equations for consistency in input/output dependencies.  If the error is not due to a simple typo, the solution may involve the use of a PROCEDURAL section or an INTEG operator.