Click here to load reader
Date post: | 25-May-2015 |
Category: |
Documents |
Upload: | alkis-vazacopoulos |
View: | 137 times |
Download: | 2 times |
Click here to load reader
Hybrid Dynamic Simulation (HDS) Industrial Modeling Framework (HDS-‐IMF)
“Simultaneously Simulate Over Time, Space, Structure and Phenomena for
Combined Discrete and Discontinuous Systems”
i n d u s t r IAL g o r i t h m s LLC. (IAL) www.industrialgorithms.com
October 2014 Introduction to Hybrid Dynamic Simulation (HDS), UOPSS and QLQP Presented in this short document is a description of how to model and solve hybrid (discrete and discontinuous) and dynamic simulation (HDS) problems in IMPL. There is a substantial amount of literature on this subject such as Barton (1992), Mao and Petzold (2002), Nedialkov and von Mohrenschildt (2002) as well as surveys by Astrom et. al. (1998) and Gani et. al. (2012). HDS is typically a combination of the capability and functionality of discrete event simulators (DES) used for discrete-‐parts manufacturing and continuous process simulators (CPS) used in the continuous process industries although there are also batch process simulators (BPS) found in the batch process industries. There also exist continuous and batch production simulators which include implementations in Microsoft Excel/VBA to simulate the production across multiple production lines and units with inventory. The usual architecture of these types of hybrid dynamic simulators is to integrate or step over time using explicit Euler’s method by dividing the future time-‐horizon into small time-‐intervals or time-‐periods and solving the spatial/structural details simultaneously or sequentially. At each time-‐interval, two types of events known as “time-‐events” and “state-‐events” are checked based on current information (solution-‐data) and if the event conditions are violated or activated then specified actions are executed (i.e., “if-‐then”, “when-‐then”, etc. clauses also known as “business rules”) and the procedure repeats to the next time-‐period. An excellent example of this type of simulation is found in Nadales et. al. (2014) who model and solve a small tank process and controller using gPROMS shown in Figure 1a with the gPROMS code listing found in Figure 2.
Figure 1a. Simple Tank Process and Controller (Nadales et. al. 2014).
The tank process exhibits a “reversible discontinuity” (Barton, 1992) where if the holdup, inventory, volume or level of the tank is below the weir volume (4.0) the outflow equals SQRT(Volume) but if the tank level is above the weir volume then the outflow equals SQRT(2.0 * Volume -‐ 4.0). The tank controller is of the “on/off” type where of course there are other types of level controllers available (Kelly, 1998). This type of controller exhibits “asymmetric discontinuities” (Barton, 1992) given that if or when the volume is greater than or equal to the high-‐limit of 10.0 then the upstream valve is closed and if/when the volume is less than or equal to the low-‐limit of 2.0 then the valve is opened. If the volume is in between 2.0 and 10.0, then depending on the status or state of the valve, this will determine the status/state of the valve. Figure 1b depicts the same problem represented in our UOPSS flowsheet paradigm (Kelly, 2004; Kelly 2005; Zyngier and Kelly, 2012). The flow of material travels from the “Supply” to the “Demand” perimeters where the “Tank” object or shape models the law of conservation of matter. The “Valve” shape has two operations labeled “Opened” and “Closed” and the hypothetical “Pump” shape, expressing the gravity flow of the material, also has two operations labeled “AboveWeir” and “BelowWeir”.
Figure 1b. Simple Tank Process as a UOPSS Flowsheet.
The interesting feature of this superstructure or flowsheet is our transparent ability to create, construct or configure different operations, modes, tasks, activities, etc. for the same unit which provides the capability to model disjunctions, disconnections, discontinuities, etc. These operations are programmatically activated (inactivated), turned on (off), set-‐up (set-‐down), etc. by constructing logical and relational arithmetic or mathematical expressions using IMPL’s special functions i.e., IF(), NOT(), AND(), OR(), XOR() and EQ(), NE(), LT(), LE(), GT() and GE() as can be found in Appendix B. These simple functions return either 1.0 (one) or 0.0 (zero) depending on whether the condition or predicate is true (1.0) or false (0.0) i.e., Boolean values which is also known as “zero crossing detection”. This leads to another interesting feature of our formulation which is our ability to simulate or solve the problem simultaneously over all time-‐periods in the future without having to perform what is called “step-‐and-‐check” found in all numerical/digital simulators. The step-‐and-‐check protocol steps through the problem one time-‐period or spatial/structural object at a time and checks each specified or loaded event. If the event is fired, then the appropriate action is taken. Although IMPL can be easily configured to perform the step-‐and-‐check protocol by using a computer programming language such as Fortran, C, C++, C#, VBA, Java, Python and Julia to detect or check for any activated events after the intermediate problem has been solved in IMPL, using the above special functions
we can declaratively and completely model and solve the entire discrete/discontinuous problem as one nonlinear simulation i.e., simultaneously over time, space, structure and phenomena. To solve these types of HDS problems, IMPL has a specific and special solver called the Simultaneous/Successive Equation-‐Oriented Simulation Engine (SEOSE) which can call any sparse basis factorization package (BFP) such as Y12M, NSPIV, MA28 and PARDISO. To reduce the size of the simulation problem, if required, it is also possible to use well established decomposition techniques to partition the temporal and structural dimensions appropriately (Kelly, 2002; Kelly and Mann, 2004). Industrial Modeling Framework (IMF), IMPL and SSIIMPLE To implement the mathematical formulation of this and other systems, IAL offers a unique approach and is incorporated into our Industrial Modeling Programming Language we call IMPL. IMPL has its own modeling language called IML (short for Industrial Modeling Language) which is a flat or text-‐file interface as well as a set of API's which can be called from any computer programming language such as C, C++, Fortran, C#, VBA, Java (SWIG), Python (CTYPES) and/or Julia (CCALL) called IPL (short for Industrial Programming Language) to both build the model and to view the solution. Models can be a mix of linear, mixed-‐integer and nonlinear variables and constraints and are solved using a combination of LP, QP, MILP and NLP solvers such as COINMP, GLPK, LPSOLVE, SCIP, CPLEX, GUROBI, LINDO, XPRESS, CONOPT, IPOPT, KNITRO and WORHP as well as our own implementation of SLP called SLPQPE (Successive Linear & Quadratic Programming Engine) which is a very competitive alternative to the other nonlinear solvers and embeds all available LP and QP solvers. In addition and specific to DRR problems, we also have a special solver called SECQPE standing for Sequential Equality-‐Constrained QP Engine which computes the least-‐squares solution and a post-‐solver called SORVE standing for Supplemental Observability, Redundancy and Variability Estimator to estimate the usual DRR statistics. SECQPE also includes a Levenberg-‐Marquardt regularization method for nonlinear data regression problems and can be presolved using SLPQPE i.e., SLPQPE warm-‐starts SECQPE. SORVE is run after the SECQPE solver and also computes the well-‐known "maximum-‐power" gross-‐error statistics (measurement and nodal/constraint tests) to help locate outliers, defects and/or faults i.e., mal-‐functions in the measurement system and mis-‐specifications in the logging system. The underlying system architecture of IMPL is called SSIIMPLE (we hope literally) which is short for Server, Solvers, Interfacer (IML), Interacter (IPL), Modeler, Presolver Libraries and Executable. The Server, Solvers, Presolver and Executable are primarily model or problem-‐independent whereas the Interfacer, Interacter and Modeler are typically domain-‐specific i.e., model or problem-‐dependent. Fortunately, for most industrial planning, scheduling, optimization, control and monitoring problems found in the process industries, IMPL's standard Interfacer, Interacter and Modeler are well-‐suited and comprehensive to model the most difficult of production and process complexities allowing for the formulations of straightforward coefficient equations, ubiquitous conservation laws, rigorous constitutive relations, empirical correlative expressions and other necessary side constraints. User, custom, adhoc or external constraints can be augmented or appended to IMPL when necessary in several ways. For MILP or logistics problems we offer user-‐defined constraints configurable from the IML file or the IPL code where the variables and constraints are referenced using unit-‐operation-‐port-‐state names and the quantity-‐logic variable types. It is also possible to
import a foreign *.ILP file (row-‐based MPS file) which can be generated by any algebraic modeling language or matrix generator. This file is read just prior to generating the matrix and before exporting to the LP, QP or MILP solver. For NLP or quality problems we offer user-‐defined formula configuration in the IML file and single-‐value and multi-‐value function blocks writable in C, C++ or Fortran. The nonlinear formulas may include intrinsic functions such as EXP, LN, LOG, SIN, COS, TAN, MIN, MAX, IF, NOT, EQ, NE, LE, LT, GE, GT, AND, OR, XOR and CIP, LIP, SIP and KIP (constant, linear and monotonic spline interpolations) as well as user-‐written extrinsic functions (XFCN). It is also possible to import another type of foreign file called the *.INL file where both linear and nonlinear constraints can be added easily using new or existing IMPL variables. Industrial modeling frameworks or IMF's are intended to provide a jump-‐start to an industrial project implementation i.e., a pre-‐project if you will, whereby pre-‐configured IML files and/or IPL code are available specific to your problem at hand. The IML files and/or IPL code can be easily enhanced, extended, customized, modified, etc. to meet the diverse needs of your project and as it evolves over time and use. IMF's also provide graphical user interface prototypes for drawing the flowsheet as in Figure 1 and typical Gantt charts and trend plots to view the solution of quantity, logic and quality time-‐profiles. Current developments use Python 2.3 and 2.7 integrated with open-‐source Gnome Dia and Matplotlib modules respectively but other prototypes embedded within Microsoft Excel/VBA for example can be created in a straightforward manner. However, the primary purpose of the IMF's is to provide a timely, cost-‐effective, manageable and maintainable deployment of IMPL to formulate and optimize complex industrial manufacturing systems in either off-‐line or on-‐line environments. Using IMPL alone would be somewhat similar (but not as bad) to learning the syntax and semantics of an AML as well as having to code all of the necessary mathematical representations of the problem including the details of digitizing your data into time-‐points and periods, demarcating past, present and future time-‐horizons, defining sets, index-‐sets, compound-‐sets to traverse the network or topology, calculating independent and dependent parameters to be used as coefficients and bounds and finally creating all of the necessary variables and constraints to model the complex details of logistics and quality industrial optimization problems. Instead, IMF's and IMPL provide, in our opinion, a more elegant and structured approach to industrial modeling and solving so that you can capture the benefits of advanced decision-‐making faster, better and cheaper. Hybrid Dynamic Simulation (HDS) Synopsis At this point we explore further the application of modeling and solving HDS problems in IMPL. Figure 2 displays the gPROMS code listing for the simple tank process and controller from (Nadales et. al., 2014). The future time-‐horizon is 10-‐seconds with a 0.1-‐second time-‐period duration. Figure 3 shows the simulation results using gPROMS. It is easy to observe the endogenous timings of when the valve is opened (green line) and its direct effect on the volume in the tank (black line). The inflow (blue line) corresponds directly to the opening and closing of the valve and the outflow (red line) follows the discontinuity depending on the volume in the tank.
Figure 2. gPROMS Code Listing of Simple Tank Example (Nadales et. al., 2014)
Figure 3. Simple Tank Example Plot using gPROMS (Nadales et. al., 2014).
The same problem is modeled and solved in IMPL using SEOSE taking 20 iterations and less than 0.05-‐seconds of computer time where the number of variables and constraints equals 1,100 respectively indicating that there are no degrees-‐of-‐freedom. The UPS and IML files are found in the Appendices where the Valve shape/object has an explicit “Status” variable for both the Opened and Closed operations. The two statuses are determined for each time-‐period using the following logic equations:
OR(LE(Volume[-1];Vlo);AND(AND(GT(Volume[-1];Vlo);LT(Volume[-1];Vhi));Status[-1]))
OR(GE(Volume[-1];Vhi);AND(AND(GT(Volume[-1];Vlo);LT(Volume[-1];Vhi));Status[-1]))
The [-‐1] denotes a single lag or time-‐shift of one (1) time-‐period into the past where Vlo = 2.0 and Vhi = 10.0. A status of one (1) in the logic propositions below indicates that the unit-‐operation is active or setup. Valve-‐Opened: IF (Volume,t-1 <= Vlo) OR (Volume,t-1 > Vlo AND Volume,t-1 < Vhi AND Status,t-1 = 1) THEN Status,t = 1
Valve-‐Closed: IF (Volume,t-1 >= Vhi) OR (Volume,t-1 > Vlo AND Volume,t-1 < Vhi AND Status,t-1 = 1) THEN Status,t = 1
Figure 4a shows the Gantt chart from the IMPL solution where the outflow discontinuity is well displayed by the grey lines for the Pump,AboveWeir and Pump,BelowWeir unit-‐operations. The
Tank and Valve,Opened grey lines highlight the volume in the tank and when the valve is opened which correspond identically to those found in Figure 3 from the gPROMS solution. Figure 4b verifies that the Tank volume profile from IMPL mirrors very closely with gPROMS Tank volume.
Figure 4a. Simple Tank Example Gantt Chart using IMPL.
Figure 4b. Tank Volume Plot using IMPL. In summary, it should be clear that IMPL can be used to model and solve hybrid dynamic simulation (HDS) problems. The approach used here with IMPL is unique to the other simulation architectures given that we do not use a step-‐and-‐check procedure but instead model and solve the logic conditionals i.e., the time-‐ and variable-‐events as mathematical/arithmetic expressions directly into the simulation equations. We are also able to easily handle difficult discrete and discontinuous types of processes by taking advantage of our UOPSS flowsheeting technology. Without this ability, we would not be able to accommodate irreversible and asymmetric discontinuities as outlined by Barton (1992). References
Barton, P.I., “The modeling and simulation of combined discrete/continuous processes”, Department of Chemical Engineering, Imperial College of Science, Technology and Medicine, London, PhD Thesis, (1992). Astrom, K. J., Elmquist, H., Mattsson, S.E., “Evolution of continuous-‐time modeling and simulation”, The 12th European Simulation Multi-‐Conference (ESM’98), Manchester, UK, June, (1998). Kelly, J.D., “Tuning digital PI controllers for minimal variance in manipulated input moves applied to imbalanced systems with delay”, Canadian Journal of Chemical Engineering, 76, 967-‐974, (1998). Mao, G., Petzold, L.R., “Efficient integration over discontinuities for differential-‐algebraic systems”, Computers and Mathematics with Applications, 43, 65-‐79, (2002). Kelly, J.D., “Chronological decomposition heuristic for scheduling: a divide and conquer method”, American Institute of Chemical Engineering Journal, 48, (2002). Nedialkov, N.S., von Mohrenschildt, M., “Rigorous simulation of hybrid dynamic systems with symbolic and interval methods”, Proceedings of the American Control Conference, Anchorage, AK, May, (2002). Kelly, J.D., Mann, J.L., “Flowsheet decomposition heuristic applied to scheduling: a relax and fix method”, Computers and Chemical Engineering, 28, (2004). Kelly, J.D., "Production modeling for multimodal operations", Chemical Engineering Progress, February, 44, (2004). Kelly, J.D., "The unit-‐operation-‐stock superstructure (UOSS) and the quantity-‐logic-‐quality paradigm (QLQP) for production scheduling in the process industries", In: MISTA 2005 Conference Proceedings, 327, (2005). Gani, R., Cameron, I., Lucia, A., Sin, G., Georgiadis, M., “Process systems engineering, 2. modeling and simulation”, Ullmann’s Encyclopedia of Industrial Chemistry, Wiley, Germany, (2012). Zyngier, D., Kelly, J.D., "UOPSS: a new paradigm for modeling production planning and scheduling systems", ESCAPE 22, June, (2012). Nadales, D.E., Hufner, M., Reiners, M.A., “Specifications and validation of gPROMS semantics”, CIF Technical Report, (http://se.wtb.tue.nl/sewiki/cif/publications2) accessed October, (2014). Appendix A – HDS-‐IMF.UPS File i M P l (c) Copyright and Property of i n d u s t r I A L g o r i t h m s LLC. checksum,59 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ! Unit-Operation-Port-State-Superstructure (UOPSS) *.UPS File. ! (This file is automatically generated from the Python program IALConstructer.py) !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! &sUnit,&sOperation,@sType,@sSubtype,@sUse Demand,,perimeter,, Pump,AboveWeir,processc,blackbox%, Pump,BelowWeir,processc,blackbox%, Supply,,perimeter,, Tank,,pool,, Valve,Closed,processc,blackbox%, Valve,Opened,processc,blackbox%,
&sUnit,&sOperation,@sType,@sSubtype,@sUse ! Number of UO shapes = 7 &sAlias,&sUnit,&sOperation ALLPARTS,Demand, ALLPARTS,Pump,AboveWeir ALLPARTS,Pump,BelowWeir ALLPARTS,Supply, ALLPARTS,Tank, ALLPARTS,Valve,Closed ALLPARTS,Valve,Opened &sAlias,&sUnit,&sOperation &sUnit,&sOperation,&sPort,&sState,@sType,@sSubtype Demand,,i,,in, Pump,AboveWeir,i,,in, Pump,AboveWeir,o,,out, Pump,BelowWeir,i,,in, Pump,BelowWeir,o,,out, Supply,,o,,out, Tank,,i,,in, Tank,,o,,out, Valve,Closed,i,,in, Valve,Closed,o,,out, Valve,Opened,i,,in, Valve,Opened,o,,out, &sUnit,&sOperation,&sPort,&sState,@sType,@sSubtype ! Number of UOPS shapes = 12 &sAlias,&sUnit,&sOperation,&sPort,&sState ALLINPORTS,Demand,,i, ALLINPORTS,Pump,AboveWeir,i, ALLINPORTS,Pump,BelowWeir,i, ALLINPORTS,Tank,,i, ALLINPORTS,Valve,Closed,i, ALLINPORTS,Valve,Opened,i, ALLOUTPORTS,Pump,AboveWeir,o, ALLOUTPORTS,Pump,BelowWeir,o, ALLOUTPORTS,Supply,,o, ALLOUTPORTS,Tank,,o, ALLOUTPORTS,Valve,Closed,o, ALLOUTPORTS,Valve,Opened,o, &sAlias,&sUnit,&sOperation,&sPort,&sState &sUnit,&sOperation,&sPort,&sState,&sUnit,&sOperation,&sPort,&sState Pump,AboveWeir,o,,Demand,,i, Pump,BelowWeir,o,,Demand,,i, Supply,,o,,Valve,Closed,i, Supply,,o,,Valve,Opened,i, Tank,,o,,Pump,AboveWeir,i, Tank,,o,,Pump,BelowWeir,i, Valve,Closed,o,,Tank,,i, Valve,Opened,o,,Tank,,i, &sUnit,&sOperation,&sPort,&sState,&sUnit,&sOperation,&sPort,&sState ! Number of UOPSPSUO shapes = 8 &sAlias,&sUnit,&sOperation,&sPort,&sState,&sUnit,&sOperation,&sPort,&sState ALLPATHS,Pump,AboveWeir,o,,Demand,,i, ALLPATHS,Pump,BelowWeir,o,,Demand,,i, ALLPATHS,Tank,,o,,Pump,AboveWeir,i, ALLPATHS,Tank,,o,,Pump,BelowWeir,i, ALLPATHS,Valve,Closed,o,,Tank,,i, ALLPATHS,Valve,Opened,o,,Tank,,i, ALLPATHS,Supply,,o,,Valve,Closed,i, ALLPATHS,Supply,,o,,Valve,Opened,i, &sAlias,&sUnit,&sOperation,&sPort,&sState,&sUnit,&sOperation,&sPort,&sState Appendix B – HDS-‐IMF.IML File i M P l (c) Copyright and Property of i n d u s t r I A L g o r i t h m s LLC. !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ! Calculation Data (Parameters) !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! &sCalc,@sValue PERIOD,0.1 START,-2*PERIOD BEGIN,0.0 END,10.0 Vlo,2.0 Vhi,10.0 Vweir,4.0 &sCalc,@sValue !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ! Chronological Data (Periods)
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! @rPastTHD,@rFutureTHD,@rTPD START,END,PERIOD @rPastTHD,@rFutureTHD,@rTPD !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ! Construction Data (Pointers) !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Include-@sFile_Name HDS-IMF.ups Include-@sFile_Name !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ! Capacity Data (Prototypes) !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! &sUnit,&sOperation,@rHoldup_Lower,@rHoldup_Upper Tank,,0.0,20.0 &sUnit,&sOperation,@rHoldup_Lower,@rHoldup_Upper &sUnit,&sOperation,@rRate_Lower,@rRate_Upper Valve,Opened,0.0,1000.0 Valve,Closed,0.0,1000.0 Pump,AboveWeir,0.0,1000.0 Pump,BelowWeir,0.0,1000.0 &sUnit,&sOperation,@rRate_Lower,@rRate_Upper &sUnit,&sOperation,&sPort,&sState,@rTeeRate_Lower,@rTeeRate_Upper ALLINPORTS,0.0,1000.0 ALLOUTPORTS,0.0,1000.0 &sUnit,&sOperation,&sPort,&sState,@rTeeRate_Lower,@rTeeRate_Upper &sUnit,&sOperation,&sPort,&sState,@rTotalRate_Lower,@rTotalRate_Upper ALLINPORTS,0.0,1000.0 ALLOUTPORTS,0.0,1000.0 &sUnit,&sOperation,&sPort,&sState,@rTotalRate_Lower,@rTotalRate_Upper &sUnit,&sOperation,&sPort,&sState,@rYield_Lower,@rYield_Upper,@rYield_Fixed Valve,Opened,i,,1.0,1.0, Valve,Opened,o,,1.0,1.0, Valve,Closed,i,,1.0,1.0, Valve,Closed,o,,1.0,1.0, Pump,AboveWeir,i,,1.0,1.0, Pump,AboveWeir,o,,1.0,1.0, Pump,BelowWeir,i,,1.0,1.0, Pump,BelowWeir,o,,1.0,1.0, &sUnit,&sOperation,&sPort,&sState,@rYield_Lower,@rYield_Upper,@rYield_Fixed !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ! Condition Data (Properties) !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! &sCondition Volume Status &sCondition &sUnit,&sOperation,&sCondition,@rCondition_Lower,@rCondition_Upper,@rCondition_Target Valve,Opened,Volume,0.0,1000.0 Valve,Closed,Volume,0.0,1000.0 Pump,AboveWeir,Volume,0.0,1000.0 Pump,BelowWeir,Volume,0.0,1000.0 Valve,Opened,Status,0.0,1.0, Valve,Closed,Status,0.0,1.0, &sUnit,&sOperation,&sCondition,@rCondition_Lower,@rCondition_Upper,@rCondition_Target UOHoldupUOCondition-&sUnit,&sOperation,&sUnit,&sOperation,&sCondition Tank,,Valve,Opened,Volume Tank,,Valve,Closed,Volume Tank,,Pump,AboveWeir,Volume Tank,,Pump,BelowWeir,Volume UOHoldupUOCondition-&sUnit,&sOperation,&sUnit,&sOperation,&sCondition ConditionsUOCondition-&sUnit,&sOperation,&sCondition,@sType,@rValue,@sValue Valve,Opened,Status,?,3,OR(LE(Volume[-1];Vlo);AND(AND(GT(Volume[-1];Vlo);LT(Volume[-1];Vhi));Status[-1])) Valve,Closed,Status,?,3,OR(GE(Volume[-1];Vhi);AND(AND(GT(Volume[-1];Vlo);LT(Volume[-1];Vhi));Status[-1])) ConditionsUOCondition-&sUnit,&sOperation,&sCondition,@sType,@rValue,@sValue ConditionsUOPSRate-&sUnit,&sOperation,&sPort,&sState,@sType,@rValue,@sValue Valve,Opened,o,,?,3,Status * 5.0 Valve,Closed,o,,?,3,Status * 0.0 Pump,AboveWeir,o,,?,3,GE(Volume;Vweir) * SQRT(2.0 * Volume - 4.0) Pump,BelowWeir,o,,?,3,LT(Volume;Vweir) * SQRT(Volume) ConditionsUOPSRate-&sUnit,&sOperation,&sPort,&sState,@sType,@rValue,@sValue !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ! Content Data (Past, Present Provisos) !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! &sUnit,&sOperation,@rHoldup_Value,@rStart_Time Tank,,10.0,0.0
&sUnit,&sOperation,@rHoldup_Value,@rStart_Time &sUnit,&sOperation,&sCondition,@rCondition_Value,@rStart_Time Valve,Opened,Volume,10.0,-2*PERIOD Valve,Opened,Volume,10.0,-PERIOD Valve,Closed,Volume,10.0,-2*PERIOD Valve,Closed,Volume,10.0,-PERIOD Valve,Opened,Status,0.0,0.0 Valve,Closed,Status,1.0,0.0 &sUnit,&sOperation,&sCondition,@rCondition_Value,@rStart_Time !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ! Command Data (Future Provisos) !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! &sUnit,&sOperation,@rSetup_Lower,@rSetup_Upper,@rBegin_Time,@rEnd_Time ALLPARTS,1,1,BEGIN,END &sUnit,&sOperation,@rSetup_Lower,@rSetup_Upper,@rBegin_Time,@rEnd_Time &sUnit,&sOperation,&sPort,&sState,&sUnit,&sOperation,&sPort,&sState,@rSetup_Lower,@rSetup_Upper,@rBegin_Time,@rEnd_Time ALLPATHS,1,1,BEGIN,END &sUnit,&sOperation,&sPort,&sState,&sUnit,&sOperation,&sPort,&sState,@rSetup_Lower,@rSetup_Upper,@rBegin_Time,@rEnd_Time