Modeling Discrete and Continuous Processes

Transcription

1 Modeling Discrete and Continuous Processes by Magne Myrtveit Normally, we try to aggregate discreteness in System Dynamics (SD) models by making continuous flows. This is a good modeling practice, but in some cases discreteness may have a significant influence on system behavior (see note). Consequently, we need to model such discreteness to explore its impact on behavior. The System Dynamics (SD) technology was originally designed with support only for systems where the states change in a continuous manner over time. A SD model typically aggregates discrete events of the underlying system to a level where the events can be considered to be part of a continuous flow. As an example, the manufacture of individual products will be treated as a flow of products over time. Continuous simulations use integration with respect to time to represent the development of systems. With Studio 2001 Powersim introduces accumulation in addition to integration. In contrast, accumulation is used exclusively in spreadsheet models, as spreadsheets cannot integrate. Accumulation means that values are added to or subtracted from state variables. Below we will first deal with continuous systems, and how they can be used to represent discrete processes through a number of workarounds. Then we will describe how discrete parts of a system can be modeled using flows that accumulate as opposed to integrate. Finally, we will take a look at logical states and how they can be set, cleared and remembered using logical levels and flows. Table of Contents Continuous, discrete, and logical flows Integration expresses continuous flows Accumulation expresses discrete, numerical flows Logical states and flows Using continuous flows to represent discreteness TIMESTEP can be used to mimic discrete behavior Adding a quantity to a level Setting the value of a level Avoding a level going negative Drawbacks of using continuous flows on discrete phenomena Using discrete, numerical flows Modeling bank account using immediate discrete flow Assigning servers to clients using immediate numerical flows Using logical flows Controlling the level in a water tank using logical flows Continuous, discrete, and logical flows Powersim Studio supports three kinds of flows, namely integration, accumulation and switch logic. Integration is only supported for continuous data types, i.e., real and complex numbers. Accumulation is supported only by numerical data types, i.e., real, complex and integer. Switch logic is only supported by the logical data type. The choice of flow type is determined by the data type of the variables involved and the integration order setting for the variable. Available combinations are summarized below. Order Real Complex Integer Logical >0 Integration 0 Accumulation Switch logic In the following paragraphs we will define each of the flow types, and how they update the values of levels during simulation. Integration expresses continuous flows During simulation of a continuous system, levels are computed using numerical integration over time. A level L with a net flow F represents the following development over time:

2 The simulation is advanced one time step at the time, so the integration is divided into steps, and the result of one step is used to compute the following step. As an example, the value of the level L at time t+dt is equal to the value at time t plus the integral of the net flows from t to t+dt, where Dt is the time step of the simulation: The integration of a flow over one time step is approximated according to the integration settings of the simulation model. The simplest setting is the first-order (Euler) integration with fixed time step. More accurate accurate simulation results can be achieved by using one of the higher-order integration methods such as Runge-Kutta (although this will slow the simulation down as more calculations are required). The time step can be fixed or variable. If the time step is variable, the integration process will subdivide the integration interval further in order to keep the integration error within limits specified by the modeler. Integration is only possible on continuos data types, such as real numbers. If a variable is used to hold the index of an array element, for example, the variable should be defined as an integer. Integers can only take on values that are whole numbers, such as -2, -1, 0, 1, 2, etc. Integers do not integrate. This can be seen from the integration formula above. If first-order integration is used, the value of a level L at time t+ t is equal to the following: L t+ t + F t t where t is the time step of the simulation (TIMESTEP). The time step is a real number that does logically not belong to the model, but to the integration setting of the simulation engine. We cannot assume that the TIMESTEP (Dt) is 1 or any other integer value. On the contrary, the time step is typically a positive number that is less than one. This means that the value of the flow will typically be a real number, and not an integer. A variable of integer type cannot be incremented with a real value, as the result will not be of integer type. For example: TIME t L F F* t Comment t Both L and F are integers. t + t L is no longer an integer. The above example indicates that it is quite difficult to ensure that a level takes on integer values only. Powersim's support for zero order integration solves this problem, and also opens up many other interesting possibilities that can be used both for discrete (integer) and continuous (real and complex) data. Accumulation expresses discrete, numerical flows As described above, integration cannot be applied to integer values. But this is only one of the reasons for introducing accumulation in addition to integration to the simulation language. There are many situations where we need to model transactions that take place as events in time. Examples include deposits of money into a bank account, accrual of interest, batch processes, and transport by train, ship, or truck Accumulation can be expressed quite easily as a sum. As for the numerical integration, the accumulation process is split up into time steps, where the value of one time step is used to find the value for the next step: With accumulation, the unit of measure is the same for the flow and the level, as we do not multiply the flow with the time step. Furthermore, accumulation is defined both for discrete and continuous numbers. This means that we can now represent integer in addition to real and complex levels. Accumulation takes place only between time steps. This means that accumulation is not affected by higher order integration settings and variable time step. Studio allows values to accumulate either at the end of each time step, or at the beginning. Both forms are described below:

3 L t + t + F t L t + t + F t + t // delayed discrete numerical flow // immediate discrete numerical flow Logical states and flows Logical (or Boolean) values are used in most models. Traditionally, modeling software has used real numbers to represent logical values such as true and false. This solution puts a lot of responsibility on the modeler, as the rules for logical operations differ significantly from those for algebraic operations. Powersim Studio provides a logical data type that can be used for variables. Powersim's logical variables have a three-state logic. This means that there are three possible logical states; true, false and indefinite. The third value, indefinite, means "I do not know". The indefinite value is typically the result of a comparison operation that involves invalid numbers. Here are some examples: A B A<B Comment 1 2 TRUE FALSE INFINITY FALSE +INFINITY is the result of 1.0/0.0 (example). 39 NAN INDEFINITE The result of LN(0) is NAN (example). +INFINITY +INFINITY INDEFINITE We do not know which "INFINITY" is the bigger one. -INFINITY +INFINITY TRUE -INFINITY is clearly less than +INFINITY The three-state logic is very helpful in the quality assurance process of models, as all functions and operators that take logical inputs or produce logical results, deal separately with each of the three logical states. This means that numerical errors will typically propagate through the system, and show up as NAN values (for numbers) and INDEFINITE values (for logical variables). This makes it possible for the modeler to trace back through the dependency chain to find the source of an invalid operation. As an example, Studil's IF function has four arguments, the last one being optional. The expression IF(Condition, 1, 0) will return 1 if Condition is TRUE and 0 if Condition is FALSE. If Condition is INDEFINITE the returned value will be NAN (the default value). If you want something else to be returned in this case, you can add an extra parameter to the IF function, like this: IF(Condition, 1, 0, 0.5) Sometimes a simulation has to remember a logical value. The easiest way to remember data in a simulation is to use a level for that variable. In modeling software without explicit support for logical values, we would simply represent the logical value using a normal level. It is quite easy to introduce mistakes in a model using such an approach. Logical values do not integrate. Logical values do not even accumulate. This means that the formulas that we have provided for integration and accumulation cannot be used for logical values. L t + t + F t t // Integration is invalid for logical values L t + t + F t // Accumulation is invalid for logical values This means that the processes that we have defined for updating levels cannot be used within the logical domain. As an example, let us assume that a level B is used to represent a logical value. It is quite common to use the value zero (0) to represent false, and one (1) to represent true. In order to set B to true, we need to feed a value of one into B. In order to set B to false, we need to extract a value of one out of B. Here several things can go wrong. What if we feed something into B when it already has a value of 1 (true)? What if we take out a value of 1 (true) from B when it is already 0 (false)? Unless the modeler takes extreme care in writing the equations for managing logic through numerical operations, errors can easily get introduced. Studio 2001 introduces support logical levels and logical flows. Since plus and minus are not defined in the logical domain, we need to find other ways to define such flows. A logical level can be looked upon as a switch that remembers its current state. The switch can be set to its "on" state through an in-flow that with a value equal to TRUE. If the switch is already on, its value will remain TRUE, regardless of the value of the inflow. In order to swtich the level "off", we use an outflow with a value of TRUE. A level that is already FALSE, will remain false, regardless of the value of any outflow. From this explanation we see that logical states do not accumulate, and they do not conserve mass either. This makes sense, as logical values do not belong to the physical domain, where conservation of mass is important. Logical values carry information, and they can be created, shared, and transferred freely. As an example, you can share information with others without losing the information yourself. And if you already have a given piece of information, you do not get anything extra if somebody gives the same information to you again.

4 Below, we have defined the meaning of logical flows on a logical level: L t+ t O t I t where means NOT, means AND, and means OR. Here L is the level variable, and O the union of all outflows and I the union of all inflows. The above is the definition of delayed logical flows. Immediate logical flows are defined like this: L t+dt O t+dt I t+dt A logical flow is always a discrete flow. You can think about an inflow with a value of TRUE as a hand that pushes the level's state to the TRUE (on) position. Correspondingly you can think of an outflow with a value of TRUE as a hand that pulls the level's state to the FALSE (off) position. A FALSE flow does not change the state of associated levels. In order to take INDEFINITE values into account, we can simply use the semantics of the logical operators NOT, OR, and AND and our equation for logical levels to find the effect on a logical flow structure. The table below lists all the possible combinations of values for (the union of) inflows, the (unions of) outflows and a level. Union of inflows Old state of level Union of outflows New state of level Comment TRUE any any TRUE Switch ON INDEFINITE TRUE FALSE TRUE INDEFINITE TRUE TRUE, INDEFINITE INDEFINITE INDEFINITE FALSE, INDEFINITE any INDEFINITE FALSE TRUE, INDEFINITE INDEFINITE INDEFINITE FALSE FALSE INDEFINITE FALSE FALSE any TRUE FALSE Switch OFF FALSE L FALSE L (unchanged) Left unchanged All in all, the above table covers 3x3x3=27 different cases. The comment column describes the three most common situations, which are to switch a level on (TRUE), off (FALSE), or just leave it unchanged. Using continuous flows to represent discreteness If you are already familiar with modeling, this section will show you the kinds of things that you can do more elegantly using Studio's discrete functionality. For readers who are new to modeling, this section explains why discrete functionality is so useful in many models. In the real world each separate product is an individual object that goes through a production process and gets completed at a given point in time. Aggregation of individual objects into masses or quantities that can be stored in state variables (levels) and moved through flows is helpful in reducing the complexity of simulation models. In order to reduce the time and effort it takes to develop, analyze and maintain a simulation model, we should always seek to represent groups of objects rather than individual items, and average attributes instead of individual object properties. There are, however, situations where we need to capture individual events that take place in a model. In a system that supports only continuous flows, we need to use workarounds in order to find ways to express discreteness. One way of doing this is to make explicit use of the TIMESTEP of the simulation. Another solution is to use some of the built-in functions that make implicit use of TIMESTEP, such as PULSE. TIMESTEP can be used to mimic discrete behavior A simulation will run faster with larger time steps, but smaller time steps normally produce the most accurate results. If the time step is set too small, the simulation advances more slowly and results can also become inaccurate due to accumulation of many tiny numerical errors. With a time step that is too large, the system behavior may start to oscillate or diverge because of inaccuracies in the integration process. This can lead to wrong conclusions about system characteristics. Therefore you should always run your model with different time steps in order to find the best tradeoff between accuracy and simulation time. For this reason a model should not rely on a particular choice of time step in order to produce the correct results. Explicit use of TIMESTEP within model equations is in general not good modeling practice, and must only be done with great

5 care. The discrete data types and flows of Powersim Studio make it possible to avoid explicit use of TIMESTEP altogether, as we will explain below. But first, let us look at how TIMESTEP is used with continuous flows to represent discreteness. Adding a quantity to a level The first example covers a situation where we want a quantity Q to flow into a level L during the next time step. If we assume that L has only one flow, we can express the value of L at time t+dt like this: In other words, the value of L t+ t is equal to Lt plus the integral of R between t and t + t. If we assume first order integration and a fixed time step, we can express the integral as R*TIMESTEP. If we now define R equal to Q/TIMESTEP, the level will receive the quantity Q during the time step: L t + R*TIMESTEP // Assuming first order integration + (Q/TIMESTEP)*TIMESTEP + Q The above solution has several weaknesses. First of all, it works only with first-order integration (Euler) and a fixed time step. If the model uses reservoirs, each time step may be integrated using several intermediate steps. To fix this problem, the EULER function can be used on the rate, like this: flow L = +dt*r aux R = EULER(Q/TIMESTEP) Another weakness is the readability of the equation for R. A third weakness relates to input and output of values. If we output the value of R, we will see a result that depends on the time step. If Q has the value of 100, for example, and the time step is 0.5, R will display a value of 200. For this reason, some modelers tend to use a time step of one. This is bad practice, however, as we should always be free to change the time step of a model. If we make proper use of units for time, it is not possible to use a time step of 1 unless we also provide a measurement unit, for example day or month. Setting the value of a level Sometimes a level is used to represent a logical state or it can be an index into an array. In such situations we need to be able to set the value of the level much as in an assign statement of a programming language like Visual Basic. Let us take the example where a level S is used to keep an index for an array A. At a given point in time we want to assign the index K to the level. This can be done like this: flow S = +dt*setk -dt*clears aux SetK = EULER(K/TIMESTEP) aux ClearS = IF(SetK <> 0, EULER(S/TIMESTEP), 0) The above statements do nothing if K is zero. If K is unequal to zero, we remove the old value of S through the outflow ClearS, and we insert the new value through the inflow SetK. We can use substitution to see that the value of S changes to K after the execution of one time step: S := S + SetK*TIMESTEP - ClearS*TIMESTEP = S + K/TIMESTEP*TIMESTEP - S/TIMESTEP*TIMESTEP = S + K - S = K The above solution will work only if we use first-order integration and a fixed time step. The reason for this is that if the integration is subdivided into smaller intervals within one time step, the value of S will neither be equal to the old value S(T) or the new value K(T) for times within the interval. Below is an example where the time step is divided into two sub-steps: Time S K Netflow of S T T + ½ T T + T 11 We see that after the step is completed, S has the correct value, but in the middle of the step we have an intermediate value for S as well. If S is used to index an array, the result will be undefined in the middle of the

6 time step. As always, a workaround is possible; we can use EULER around S whenever S is used to index an array: aux E = LOOKUP(A, INTEGER(EULER(S))) The built-in function INTEGER is used to convert S into the right type for the second argument to LOOKUP, and LOOKUP(A,S) obtains the value of element number S of the array A. Avoiding a level going negative Another common use of TIMESTEP is to ensure that a level does not get emptied below zero. Again, we use the simplified assumption that a flow during a time step is equal to the rate times the time step. Below is an example where a level L is emptied using a constant outflow C until the level is empty: flow L = -dt*r aux R = EULER(MIN(C, L*TIMESTEP)) const C =... // the constant outflow of L The above flow rate definition of R has the limitation that it does not work correctly if L has other flows, which is typically the case. In order to fix this problem, the other flows of L must be taken into the definition of R, like this: aux R = EULER(MIN(C, L*TIMESTEP + INFLOWS - OUTFLOWS)) In Powersim Studio we can simply make L into a reservoir, and write the equation for R like this: aux R = IF(L > 0, C, 0) If L has other inflows and outflows, they should be included as above in the definition of R. Above we have described how to move a given quantity, Q, into a level during one time step using TIMESTEP. Here is how this can be done using the PULSEIF function. flow L = +dt*r aux R = PULSEIF(TRUE,Q) The above definition of R is equivalent to: aux R = IF(TRUE, EULER(Q/TIMESTEP, 0)) Drawbacks of using continuous flows on discrete phenomena The examples in the previous section illustrate how continuous flows can be used to add a quantity to a level and to assign a value to a level. The solutions involve the use of TIMESTEP and EULER directly or indirectly through functions like PULSE and PULSEIF. Below is a summary of the drawbacks relating to the workarounds that must be used when expressing discrete variables and flows using continuous modeling constructs. 1. Model readability-the use of TIMESTEP, EULER and similar functions reduce the readability of equations. 2. Model correctness-when a real number is used to represent an integer variable, such as an array index, the modeling software cannot ensure that the value of the variable will always be an integer. It is up to the modeler to place the necessary logic into the model, and perform the necessary tests to ensure that the model never produces non-integer values for such variables. 3. Input/output readability-when a flow that is discrete in nature gets represented as a continuous rate, the value of the rate will be displayed with a different unit and value than the discrete value it represents. As an example, a quantity of 12 will be displayed as 120 if the time step is Choice of time step-models that do not include TIMESTEP in the right places will only work with a time step of 1 (one). This makes it very difficult to verify that the model does not produce results with significant numerical integration errors. (Since testing for numerical integration error requires change of time step.) 5. Choice of integration-models that do not include EULER and TIMESTEP at the right places will only work with Euler integration (first order). Higher order integration and variable step integration implies that the time step will be subdivided into smaller steps during simulation. Studio's reservoir setting also implies that the model must use TIMESTEP and EULER correctly for all variables. The discrete features of Powersim Studio address all of the above problems. 1. Model readability is enhanced as discreteness can be expressed directly, without the use of TIMESTEP, PULSE, EULER, etc. The unit consistency checking of Studio will automatically produce an error in places where a flow does not have the correct unit compared to the associated levels. Such errors may stem from the wrong use of the TIMESTEP function.

7 2. Studio supports integers as well as real numbers. If you define a variable as an integer, Studio ensures that the variable will never take on values outside the integer domain. 3. Discrete flows in Studio display the correct value for the flow rate. I.e., the value is not divided by the time step of the integration. 4. The integration settings for variables in Studio make it straightforward to create models that will not depend on the choice of time step. 5. In Studio it is quite easy to create a model that will run using higher order integration and variable time steps. Using discrete, numerical flows A discrete, numerical flow is an accumulating flow. Accumulation means that values will be subtracted from the level at the tail end of the flow and added to the level at the head of the flow. Studio supports two kinds of discrete, numerical flows; the delayed and the immediate discrete flow. The delayed flow is accumulated at the end of each time step, while the immediate flow is accumulated when the time step is entered. Below the mathematical definitions are given: L t+ t + F t // delayed discrete numerical flow L t+ t + t + F t+ t // immediate discrete numerical flow Discrete flows are not accumulated during intermediate steps of higher order integration. The delayed discrete flow is added to the level before entering a new time step. The immediate discrete flow is computed when the simulation has entered a new step, and added to the level right away. Below are some examples of how this can be used to ease modeling. Modeling a bank account using immediate discrete flows If you try to represent flows using a spreadsheet, you will only be able to work with addition and subtraction, i.e., discrete flows. Let us look at an example where a bank account accumulates interest over a number of periods. If the initial amount is DEM 100 and the interest rate is 7% p.a. the account develops like this: The formulas used to define the "flow" of interest into the account are displayed below: A typical (but incorrect) SD model of the above system is the following: The model equations are show below:

8 level Account = 100<<DEM>> + dt*interest aux Interest = Account * 'Interest rate' const 'Interest rate' = 7<<%/yr>> The problem with this model is that it works only for a time step of one year. If we reduce the time step to 1 day, for example, the compounding of interest will take place every day instead of every year. We can see the error by making two runs of the model, one with a time step of one year, and another with time step of one day. Over a period of six years the accumulated error is 1.41%. In this example the error is relatively small. However, sometimes we need to produce 100% accurate results, in particular when it comes to financial models. It is not easy to build an exact bank account model using continuous flows. If we use discrete flows, however, the situation becomes much easier, as explained below. In the above model we accumulate interest earned into an intermediate level variable, and add the interest to the account only once every period (year). The dotted flow line indicates a discrete flow. The definitions look like this: const 'Interest rate' = 7<<%/yr>> aux Interest = Account * 'Interest rate' level 'Accrued interest' = 0<<DEM>> + dt*interest - 'Accrue interest' aux 'Accrue interest' = IF(TIMEIS(DATE(YEAR(TIME))), 'Accrued interest',0<<dem>>) level Account = 100<<DEM>> + 'Accrue interest' The integration settings for 'Accrue interest' is zero order immediate. This means that the flow accumulates at the beginning of each new time step. The above model will work for any time step that is not bigger than the accrual period of one year. The time step should preferably be a fractin of one year. Typical time step settings for financial models are day, week, month, quarter and year. If you want to take leap years into account, you should use the Gregorian calendar setting, and select one day as time step. (Month, quarter and year are not defined units when Gregiorian calendar is selected.) The interested reader should develop a correct bank account model using only continuous flows in order to see how messy the diagram will look compared to the version that makes use of a discrete flow. Assigning servers to clients using immediate discrete, numerical flows A a client server system is an example of a model that can be built easily using arrays. The need for discrete levels (integers) and flows come in if you need to keep track of which server serves a particular user. In this example we assume that a number of users need to have a piece of work done by a server. There are several equivalent servers, who can serve any of the requesting users. However, only one server can serve a given user at the time, and a user can only be served by one server at the time. The diagram below illustrates how this can be modeled.

9 Variable Dimension Data type Explanation Available Servers servers LOGICAL Is the server free? Idx Available Servers INTEGER Index of the first free server. Requesting User users LOGICAL Does user 'u' need a server? Idx Requesting User INTEGER Index of first requesting user. Begin Served users INTEGER Index of server beginning to work for user 'u'. Served By users INTEGER Index of server working for user 'u'. End Served users INTEGER Index of server stopping to work for user 'u'. Remaining Work users REAL Amount of work (time) left to do for user 'u'. Do work users REAL Rate of work done. Value is 1. Initial Work REAL Amount of work (time) to do for each user. The interesting part of the model is the flow of server index numbers into and out of the level Served by. The definitions of this level and its flows are the following: level 'Served by' = 0 + 'Begin served' - 'End served' aux 'Begin served' = FOR(u=users IF(NUMERICAL(u) = 'Idx requesting user', 'Idx available server', 0 ) // End IF ) // End FOR aux 'End served' = FOR(u=users IF('Remaining work'[u] <= 0<<da>>, 'Served by'[u], 0 ) // End IF ) // End FOR The two auxiliaries above both have zero order integration settings. Finding the index of the (first) requesting user and the (first) available server is done like this: aux 'Idx available server' = SCANEQ('Available servers',true) aux 'Idx requesting user' = SCANEQ('Requesting users',true) The implementation makes use of the fact that SCANEQ returns zero (0) if it cannot find an element with the requested value (second parameter) in the given array (first parameter). The remaining variables are defined like this. aux 'Available servers' = FOR(s=servers SCANEQ('Served by',numerical(s)) = 0) aux 'Requesting users' = FOR(u=users 'Remaining work'[u]>0<<da>> AND 'Served by'[u]=0) const 'Initial work' = 14.2<<da>> level 'Remaining work' = 'Initial work' - dt*'do work'

10 aux 'Do work' = IF('Served by'>0 AND 'Remaining work'>0<<da>>, 1<<da/da>>, 0) The level 'Remaining work' has a reservoir setting, so it does not go below zero. This way we can use the very simple definition of 'Do work'; as long as we have a server and there is remaining work to do, perform one unit of work per time unit. (1<<da/da>> is equivalent to writing just 1.) Using logical flows A logical flow is always discrete, as it works on a discrete data type Logical. As explained above, logical values cannot be integrated, and they cannot be accumulated either. Integration is impossible since multiplication of a logical and a real value is not defined. What does TRUE*0.5 mean, for example? Accumulation is impossible since plus and minus are undefined for logical values. What is TRUE+TRUE, for example? Is it very true? We have also explained that logical flows do not conserve mass. This characteristic of logical flows comes as a natural consequence of the fact that truth-values cannot be added. This leads to the special meaning of logical states (levels) and flows, as they are based on operations of the logical value domain, as opposed to the numerical domain. The numerical domain defines operations such as multiplication, addition, division and subtraction of numbers. In the logical domain we have operators such as AND, OR, and NOT working on the logical values TRUE, FALSE and INDEFINITE. The comparison operators such as less than (<) and equal to (=) take inputs from the numerical domain, and produces outputs in the logical domain. As an example, the expression 12 < 14 produces the logical result value TRUE. Studio supports two kinds of logical flows; a delayed and an immediate variant, defined like this: L t+ t O t I t // Delayed logical flow L t+dt O t+dt I t+dt // Immediate logical flow Logical flows are not computed during intermediate steps of higher order integration. The delayed flow is computed and used to update associated levels before entering a new time step. The immediate flow is computed when the simulation has entered a new step, and used to update the associated levels right away. The following section contains an example of how logical flows can be used in a simulation model. Controlling the level in a water tank using logical flows Note! Before you create the model described below, be sure to add the unit 'l' (liter) under Global Units. (Right-click inside the view, and select l - liter on the Add Standard Unit submenu.) This example is a model of a water tank system, with a regulator installed that keeps the level of water between a high and a low limit. These are set to 30l and 20l respectively. Water is drained from the tank at a constant rate. When the level of water in the tank drops below the low limit, the regulator will open a water tap, and water starts to flow into the tank. As long as the water tap is open, the level of water increases until the desired high limit is reached, in which case the regulator closes the tap. The diagram below shows the structure of such a system. The top part of the model represents the flow of water in and out of the water tank. The inflow adds water to the tank when the tap is open. The outflow transports water out of the tank at a constant rate. level 'Water Tank' = 100<<l>> + dt*'water Tap Rate' - dt*'water Drain Rate' const 'Water Drain Rate' = 15<<l/hr>> Red color is used for logical variables. The two switches have zero order immediate integration setting, which is indicated by the dotted flow lines. The water tap is switched open when the level of water in the tank is below or equal to the lowest acceptable level. Correspondingly, the water tap is closed when the level of water in the tank is over or equal to the highest acceptable level. The equations are given below. Note how easy it is to

11 express the logic of the system, and to verify that it is correct. level 'Water Tap Is Open' = FALSE + 'Open Tap' - 'Close Tap' const 'Tank Lowest Level' = 80<<l>> const 'Tank Highest Level' = 120<<l>> aux 'Open Tap' = ('Water Tank' <= 'Tank Lowest Level') aux 'Close Tap' = ('Tank Highest Level' <= 'Water Tank') Finally, the auxiliary Water Tap Rate represents the water being filled into the tank. The variable is dependent on the state of the water tap, and its definition is given below: aux 'Water Tap Rate' = IF('Water Tap Is Open', 40<<l/hr>>, 0<<l/hr>>) The time graph below displays how the water level in the tank develops over time. Note Observe how the water level oscillates between the low and high settings. In Industrial Dynamics (1961) Forrester argues: "At times it [discreteness] will become significant. For example, it may create a disturbance that will cause system fluctuations that can be mistakenly interpreted as externally generated cycles (such as where annual design changes, or summer employee vacation, or yearly budgeting procedures create effects that resemble a seasonal demand in consumer sales). When a model has progressed to the point where such refinements are justified, and there is reason to believe that discreteness has a significant influence on behavior, discontinuous variables should be explored to determine their effect on the model." (Back to top...)