See Also
The logical builtins — IF, THEN, ELSE, AND, OR, NOT — are used to create expressions, and then give values based upon whether the resulting expressions are TRUE or FALSE. When you have multiple conditions, the expressions to be evaluated must be enclosed in parentheses ( ).
This section describes the following builtins:
When using IF-THEN-ELSE logic to generate 0 - 1 switches or flags, be sure to use Euler's method. Because of the internal calculations associated with the Runge-Kutta methods, the IF-THEN-ELSE constructs designed to return integer values will not always do so when you use the 2nd- or 4th-order Runge-Kutta computation methods.
Examples:
Bonus_Payments = IF(TIME=5) OR (Sales>5000) THEN Bonus ELSE 0
This statement sets Bonus Payments to the value of Bonus at simulated time 5, or whenever the value of Sales is greater than 5000. When neither condition is met, the statement gives the value 0. Sales and Bonus are defined elsewhere in the model.
Capital_Acquisition = IF (IRR > = 0.1) AND (Cash > = 1000000) THEN 100000 ELSE 0
This statement sets Capital Acquisition at the value 100000 when IRR (internal rate of return) is greater than or equal to 0.1 and Cash is greater than or equal to 1000000. When one of the conditions is not met, Capital Acquisition is set to 0.
Thermo_Switch = IF (Temperature < Set_Point) THEN 1 ELSE 0
This statement sets Thermo Switch (a thermostatic switch on a furnace) at 1 - the "on" position - when Temperature is less than Set Point. The statement sets Thermo Switch at 0 - the "off" position - otherwise.
Thermo_Switch = IF NOT(Temperature > = Set_Point) THEN 1 ELSE 0
This statement sets Thermo Switch at 1 when Temperature is not greater than or equal to Set Point. The statement sets Thermo Switch at 0 otherwise.
The software is capable of supporting extremely complex conditional constructs. You should be careful, however, if you find a single equation becoming larger than the size of the equation box. Complex conditional statements can be exceedingly difficult to "debug." They also can be difficult to explain to your colleagues. Good modeling practice dictates that you divide such complex statements into logical groupings, using a converter to evaluate each.