Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Advanced Production Control Using Julia & IMPL

571 views

Published on

Presented in this short document is a description of what is well-known as Advanced Process Control (APC) applied to a small linear three (3) manipulated variable (MV) by two (2) controlled variable (CV) problem. These problems are also known as Model Predictive Control (MPC) (Grimm et. al., 1989) and Moving Horizon Control (MHC). Figure 1 shows the 3 x 2 APC problem configured in our unit-operation-port-state superstructure (UOPSS) (Kelly, 2004, 2005; Zyngier and Kelly, 2012) as an Advanced Planning and Scheduling (APS) problem as opposed to a traditional APC problem.

Although there is a tremendous amount of stability, performance and robustness theory associated with APC which can be directly assumed to APS problems (Mastragostino et. al., 2014), our approach is to show that APC can equally be set into an APS framework except that APS has far less sensitivity technology due to its inherent discrete and nonlinear modeling complexities i.e., especially non-convexities. In order to eliminate the steady-state offset between the actual value and its target, it is well-known to apply bias-updating though other forms of “parameter-feedback” is possible. Typically, APS applications only employ “variable-feedback” i.e., opening or initial inventories, properties, etc. but this alone will not alleviate the steady-state offset as demonstrated by Kelly and Zyngier (2008).

Published in: Data & Analytics
  • Be the first to comment

  • Be the first to like this

Advanced Production Control Using Julia & IMPL

  1. 1. Advanced Process Control (MPC) Industrial Modeling Framework in the Julia Programming Language (APC-IMF-Julia) “Advanced Process Control from an Advanced Planning and Scheduling Perspective” 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 Advanced Process Control (APC), UOPSS and QLQP Presented in this short document is a description of what is well-known as Advanced Process Control (APC) applied to a small linear three (3) manipulated variable (MV) by two (2) controlled variable (CV) problem. These problems are also known as Model Predictive Control (MPC) (Grimm et. al., 1989) and Moving Horizon Control (MHC). Figure 1 shows the 3 x 2 APC problem configured in our unit-operation-port-state superstructure (UOPSS) (Kelly, 2004, 2005; Zyngier and Kelly, 2012) as an Advanced Planning and Scheduling (APS) problem as opposed to a traditional APC problem. Although there is a tremendous amount of stability, performance and robustness theory associated with APC which can be directly assumed to APS problems (Mastragostino et. al., 2014), our approach is to show that APC can equally be set into an APS framework except that APS has far less sensitivity technology due to its inherent discrete and nonlinear modeling complexities i.e., especially non-convexities. In order to eliminate the steady-state offset between the actual value and its target, it is well-known to apply bias-updating though other forms of “parameter-feedback” is possible. Typically, APS applications only employ “variable- feedback” i.e., opening or initial inventories, properties, etc. but this alone will not alleviate the steady-state offset as demonstrated by Kelly and Zyngier (2008). Figure 1. Advanced Process Control (APC) as a UOPSS Flowsheet.
  2. 2. The diamond shapes or objects are the sources and sinks known as perimeters, the rectangle shapes without cross-hairs are batch-process units and the shapes with cross-hairs are continuous-process units. The circle shapes with no cross-hairs are in-ports which can accept one or more inlet flows and are considered to be simple or uncontrolled mixers. The cross- haired circles are out-ports which can allow one or more outlet flows and are considered to be simple or uncontrolled splitters. The lines, arcs or edges in between the various shapes or structures are known as internal and external streams and represent in this context the flows or transfers of materials from one shape to another. In this formulation we do not use the manipulated variable “moves” (MV,t – MV,t-1) traditionally found in Dynamic Matrix Control (DMC) for example but instead we use the actual MV values. Each batch-process corresponds to one MV and has as many CV “states” as there are out-ports configured. Given that we are not using MV moves, we use the finite impulse-response (FIR) for each MV-CV pair as opposed to the step-response (SR). The interesting feature of this implementation is our use of the batch-process with relative-time yield patterns or profiles (Kondili et. al., 1993, Zyngier and Kelly, 2009) to model the ad hoc and relative-time-varying nature of the FIR. This also allows for the pure delay, dead-time or lag where the FIR is set to zero (0) for the initial relative-time-periods given that there is no appreciable CV response with respect to the MV. Furthermore, in our formulation we also support the use of lower and upper yield values for each relative-time-period which can be used to represent some level of uncertainty, variation or distribution in the FIR i.e., from the FIR identification and parameter estimation. To describe in more detail our unique formulation highlighted in Figure 1, we have delineated the five (5) stages of an Advanced Process Control (APC) problem modeled as an Advanced Planning and Scheduling (APS) problem: 1. “Supply” the manipulated (independent/exogenous) variables which have lower and upper hard bounds as well as target soft bounds (i.e., ideal or desired steady-state values). Non-manipulated variables are also independent/exogenous such as feedforward and measured/unmeasured disturbance variables but have their lower, upper and target bounds fixed i.e., they are not manipulatable. 2. “Process” (transform, transfer) the manipulated variables into controlled (dependent/endogenous) variable states modeled as batch-processes with relative-time yields representing the finite impulse-responses (FIR). If we were to use manipulated variable moves (temporal deviations) then we would replace the FIR curve with a SR curve. For open-loop stable or self-regulating (minimum-phase) processes, the impulse- response resembles a delayed monotonic decaying, declining or degrading process yield profile and eventually goes to zero (0). For non-minimum phase processes the impulse-response or yield profile will be non-monotonic with at least one extreme point. For integrating processes such as holdup or inventory processes, the impulse-response coefficient will settle to a non-zero constant. 3. “Sum” (superimpose) the controlled variable states, or contributions from each manipulated variable, to yield a composite or total controlled variable prediction.
  3. 3. 4. “Bias” update (estimate) and augment the controlled variable’s prediction using a bias parameter or coefficient computed using the actual or measured controlled variable’s current value minus its previous prediction value for the same time-period/interval from the last iteration, cycle or execution of the controller. The bias parameter is an estimate over time of the uncertainty or mismatch between what is known and what is unknown in the system. If there is no measurement feedback such as in an off-line simulation or the meter, instrument, device or analyzer is mal-functioning, then the bias equals zero (0). Conversely, if a manipulated variable has failed or is saturated, then it can be easily fixed to its existing value by configuring its lower and upper bounds to be the same. Other advanced parameter updating techniques known as Moving Horizon Estimation (MHE) can also be used but this requires Nonlinear Dynamic Data Reconciliation and Regression (NDDRR) techniques with hopefully rich data in order to observe both structurally and statistically all of the updated or real-time/on-line coefficients. With this type of on-line or real-time estimation puts the strategy into the class of adaptive control. 5. “Demand” (control, command) the level, amount or activity of each controlled variable required to fulfill the necessary requirements of the controller considering both the upstream and downstream integration of the process and/or production. The activity is managed using the lower, upper and target bounds which can be time-varying within the controller’s prediction time-horizon. It should be noted that for bias-updating an explicit biasing stage or step is not required given that the bias can be simply subtracted from the controlled variable’s target, setpoint or reference value. 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
  4. 4. (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 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
  5. 5. 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. Advanced Process Control (Model Predictive Control/Moving Horizon Control) Synopsis At this point we explore further the application of APS to model and solve the 3 x 2 APC problem found in Figure 1. Appendices A and B show the UPS and IML files respectively where the IML files contains the FIR configuration found in the “Constriction Data” (see the keyword LIP which stands for linear (monotonic) interpolation). There are six (3 x 2 = 6) FIR’s which are identical in sizings except for changes in signs. For example, the FIR for CV1 w.r.t. MV1 is 0.0, 1.0, 0.5, 0.25, 0.0, … 0.0 for relative-time-periods 0, 1, 2, 3, 4, …, 90. Relative-time-period 0 will always be zero (0.0) given that for discrete sampled systems it will be impossible for the MV’s to affect the CV’s at the zero instant or interval of time. It should be noted that it is possible to configure both lower and upper bounds for the FIR’s which can be used to manage uncertainty in the FIR identification and estimation as mentioned previously. Appendix C provides the Julia code necessary to call IMPL including the calls to our IPL routines. Julia is a relatively new and fast scientific computing programming language that is open-source and is similar to Mathwork’s Matlab but is free. Julia allows the user to call C and Fortran compiled DLL’s and SO’s that can be embedded seamlessly using its ccall() functionality which we use extensively. Note that Julia wrappers could be easily written to make the IMPL ccall()’s simpler for the user to call. For this problem we set the past/present time-horizon to be ten (10) time-periods and the future time-horizon to be also ten (10) time-periods with the latter known as the “prediction-horizon” in MPC terminology (Grimm et. al., 1989). There can also be a “control-horizon” but we have chosen for this to be identical to the prediction-horizon. The number of simulation intervals is set at fifty (50) and we make setpoint or target changes of -1.0 for CV1 and 1.0 for CV2 at simulation interval one (1) and are configured in IPL using the IPL routine IMPLreceiveUOPSrateorder(). To implement the variable-feedback, we use the routine IMPLreceiveUOholdupopen() which configures the past/present values for the MV values as batch-process holdup openings (or batch-size initial-conditions). To implement the parameter- feedback, we also use the routine IMPLreceiveUOPSrateorder()similar to the target/setpoint CV orders except that we assume the CV1 and CV2 biases are both zero (0.0) and fix the lower and upper bounds to this value i.e., we are assuming the FIR model is perfect. With regards to the CV and MV weightings, the routines IMPLreceiveUOPSflowweight() and IMPLreceiveUOholdupsmooth() are used respectively. The flow weight routine provides the 2- norm weight in the weight * (CV,t – CV,t,Target)^2 QP objective function term and the holdup smoothing routine provides the 2-norm weight in the weight * (MV,t – MV,t-1)^2 term also known as “move-suppression”. These are also implemented to achieve what is known as “dynamic- tuning” given that the controller is re-computed for each simulation instance. Figures 2a and 2b highlight the MV’s and CV’s respectively using the Julia package called Winston where the QP solver used is IBM’s CPLEX 12.6 with each simulation interval taking 0.035-seconds of computer-time for this small 3 x 2 APC type of problem using an APS strategy.
  6. 6. Figure 2a. MV1 (Blue Triangles), MV2 (Green Stars) and MV3 (Magenta Pluses) Responses. Figure 2b. CV1 (Blue Triangles) and CV2 (Green Stars) Responses.
  7. 7. In summary, we have highlighted the use IMPL to model and solve a small linear 3 x 2 APC problem in an APS optimization framework coded in the computer programming language Julia. The results would be identical to the same problem being modeled and solved using other APC technology and software. The step-responses are replaced by finite impulse-responses configured into IMPL’s batch-processes with relative-time-varying yields where these yields can be contained between arbitrary lower and upper bounds to mitigate model mismatch for example. Finally, one of the primary reasons to show that APS is functionally the same as APC is to bring together these two disciplines in order to increase the spread or coverage of applying industrial optimization technologies with the hopes of increasing the benefits that these technologies provide collectively to the process industries. References Grimm, W.M., Lee, P.L., Callahan, P.J., “Practical robust predictive control of a heat exchange network”, Chemical Engineering Communications, 81, 25-53, (1989). Kondili, E., Pantelides, C.C., Sargent, R.W.H., “A general algorithm for the short-term scheduling of batch operations – I MILP formulation”, Computers and Chemical Engineering, 17, 211, (1993). 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). Kelly, J.D., Zyngier, D., "Continuously improve planning and scheduling models with parameter feedback", FOCAPO 2008, July, (2008). Zyngier, D., Kelly, J.D., "Multi-product inventory logistics modeling in the process industries", In: W. Chaovalitwonse, K.C. Furman and P.M. Pardalos, Eds., Optimization and Logistics Challenges in the Enterprise", Springer, 61-95, (2009). Zyngier, D., Kelly, J.D., "UOPSS: a new paradigm for modeling production planning and scheduling systems", ESCAPE 22, June, (2012). Mastragostino, R., Patel, S., Swartz, C.L.E., “Robust decision making for hybrid process supply chains via model predictive control”, Computers and Chemical Engineering, 62, 37-55, (2014). Appendix A – APC-IMF.UPS (UOPSS) 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. !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ! Unit-Operation-Port-State-Superstructure (UOPSS) *.UPS File. ! (This file is automatically generated from the Python program IALConstructer.py) !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! &sUnit,&sOperation,@sType,@sSubtype,@sUse CV1Bias,,perimeter,, CV1Demand,,perimeter,, CV1Sum,,processc,, CV2Bias,,perimeter,, CV2Demand,,perimeter,, CV2Sum,,processc,, MV1Process,,processb,, MV1Supply,,perimeter,,
  8. 8. MV2Process,,processb,, MV2Supply,,perimeter,, MV3Process,,processb,, MV3Supply,,perimeter,, &sUnit,&sOperation,@sType,@sSubtype,@sUse ! Number of UO shapes = 12 &sAlias,&sUnit,&sOperation ALLPARTS,CV1Bias, ALLPARTS,CV1Demand, ALLPARTS,CV1Sum, ALLPARTS,CV2Bias, ALLPARTS,CV2Demand, ALLPARTS,CV2Sum, ALLPARTS,MV1Process, ALLPARTS,MV1Supply, ALLPARTS,MV2Process, ALLPARTS,MV2Supply, ALLPARTS,MV3Process, ALLPARTS,MV3Supply, &sAlias,&sUnit,&sOperation &sUnit,&sOperation,&sPort,&sState,@sType,@sSubtype CV1Bias,,o,,out, CV1Demand,,i,,in, CV1Sum,,i,,in, CV1Sum,,o,,out, CV2Bias,,o,,out, CV2Demand,,i,,in, CV2Sum,,i,,in, CV2Sum,,o,,out, MV1Process,,i,,in, MV1Process,,o1,,out, MV1Process,,o2,,out, MV1Supply,,o,,out, MV2Process,,i,,in, MV2Process,,o1,,out, MV2Process,,o2,,out, MV2Supply,,o,,out, MV3Process,,i,,in, MV3Process,,o1,,out, MV3Process,,o2,,out, MV3Supply,,o,,out, &sUnit,&sOperation,&sPort,&sState,@sType,@sSubtype ! Number of UOPS shapes = 20 &sAlias,&sUnit,&sOperation,&sPort,&sState ALLINPORTS,CV1Demand,,i, ALLINPORTS,CV1Sum,,i, ALLINPORTS,CV2Demand,,i, ALLINPORTS,CV2Sum,,i, ALLINPORTS,MV1Process,,i, ALLINPORTS,MV2Process,,i, ALLINPORTS,MV3Process,,i, ALLOUTPORTS,CV1Bias,,o, ALLOUTPORTS,CV1Sum,,o, ALLOUTPORTS,CV2Bias,,o, ALLOUTPORTS,CV2Sum,,o, ALLOUTPORTS,MV1Process,,o1, ALLOUTPORTS,MV1Process,,o2, ALLOUTPORTS,MV1Supply,,o, ALLOUTPORTS,MV2Process,,o1, ALLOUTPORTS,MV2Process,,o2, ALLOUTPORTS,MV2Supply,,o, ALLOUTPORTS,MV3Process,,o1, ALLOUTPORTS,MV3Process,,o2, ALLOUTPORTS,MV3Supply,,o, &sAlias,&sUnit,&sOperation,&sPort,&sState &sUnit,&sOperation,&sPort,&sState,&sUnit,&sOperation,&sPort,&sState CV1Bias,,o,,CV1Demand,,i, CV1Sum,,o,,CV1Demand,,i, CV2Bias,,o,,CV2Demand,,i, CV2Sum,,o,,CV2Demand,,i, MV1Process,,o1,,CV1Sum,,i, MV1Process,,o2,,CV2Sum,,i, MV1Supply,,o,,MV1Process,,i, MV2Process,,o1,,CV1Sum,,i, MV2Process,,o2,,CV2Sum,,i, MV2Supply,,o,,MV2Process,,i, MV3Process,,o1,,CV1Sum,,i, MV3Process,,o2,,CV2Sum,,i, MV3Supply,,o,,MV3Process,,i, &sUnit,&sOperation,&sPort,&sState,&sUnit,&sOperation,&sPort,&sState ! Number of UOPSPSUO shapes = 13 &sAlias,&sUnit,&sOperation,&sPort,&sState,&sUnit,&sOperation,&sPort,&sState ALLPATHS,CV1Bias,,o,,CV1Demand,,i, ALLPATHS,CV1Sum,,o,,CV1Demand,,i, ALLPATHS,MV1Process,,o1,,CV1Sum,,i, ALLPATHS,MV2Process,,o1,,CV1Sum,,i, ALLPATHS,MV3Process,,o1,,CV1Sum,,i,
  9. 9. ALLPATHS,CV2Bias,,o,,CV2Demand,,i, ALLPATHS,CV2Sum,,o,,CV2Demand,,i, ALLPATHS,MV1Process,,o2,,CV2Sum,,i, ALLPATHS,MV2Process,,o2,,CV2Sum,,i, ALLPATHS,MV3Process,,o2,,CV2Sum,,i, ALLPATHS,MV1Supply,,o,,MV1Process,,i, ALLPATHS,MV2Supply,,o,,MV2Process,,i, ALLPATHS,MV3Supply,,o,,MV3Process,,i, &sAlias,&sUnit,&sOperation,&sPort,&sState,&sUnit,&sOperation,&sPort,&sState Appendix B – APC-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 START,-100.0 BEGIN,0.0 END,100.0 PERIOD,1.0 LARGE,10000.0 &sCalc,@sValue !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ! Chronological Data (Periods) !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! @rPastTHD,@rFutureTHD,@rTPD START,END,PERIOD @rPastTHD,@rFutureTHD,@rTPD !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ! Construction Data (Pointers) !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Include-@sFile_Name APC-IMF.ups Include-@sFile_Name !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ! Capacity Data (Prototypes) !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! &sUnit,&sOperation,@rRate_Lower,@rRate_Upper CV1Sum,,-LARGE,LARGE CV2Sum,,-LARGE,LARGE &sUnit,&sOperation,@rRate_Lower,@rRate_Upper &sUnit,&sOperation,@rHoldup_Lower,@rHoldup_Upper MV1Process,,-LARGE,LARGE MV2Process,,-LARGE,LARGE MV3Process,,-LARGE,LARGE &sUnit,&sOperation,@rHoldup_Lower,@rHoldup_Upper &sUnit,&sOperation,&sPort,&sState,@rTeeRate_Lower,@rTeeRate_Upper ALLINPORTS,-LARGE,LARGE ALLOUTPORTS,-LARGE,LARGE &sUnit,&sOperation,&sPort,&sState,@rTeeRate_Lower,@rTeeRate_Upper &sUnit,&sOperation,&sPort,&sState,@rTotalRate_Lower,@rTotalRate_Upper ALLINPORTS,-LARGE,LARGE ALLOUTPORTS,-LARGE,LARGE &sUnit,&sOperation,&sPort,&sState,@rTotalRate_Lower,@rTotalRate_Upper &sUnit,&sOperation,&sPort,&sState,@rYield_Lower,@rYield_Upper,@rYield_Fixed MV1Process,,i,,1.0,1.0 MV2Process,,i,,1.0,1.0 MV3Process,,i,,1.0,1.0 MV1Process,,o1,,0.0,0.0 MV1Process,,o2,,0.0,0.0 MV2Process,,o1,,0.0,0.0 MV2Process,,o2,,0.0,0.0 MV3Process,,o1,,0.0,0.0 MV3Process,,o2,,0.0,0.0 CV1Sum,,i,,1.0,1.0 CV1Sum,,o,,1.0,1.0 CV2Sum,,i,,1.0,1.0 CV2Sum,,o,,1.0,1.0 &sUnit,&sOperation,&sPort,&sState,@rYield_Lower,@rYield_Upper,@rYield_Fixed !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ! Constriction Data (Practices/Policies) !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! &sUnit,&sOperation,@rUpTiming_Lower,@rUpTiming_Upper MV1Process,,1.0,1.0 MV2Process,,1.0,1.0 MV3Process,,1.0,1.0
  10. 10. &sUnit,&sOperation,@rUpTiming_Lower,@rUpTiming_Upper &sUnit,&sOperation,&sPort,&sState,@rFlowDelaying_Lower,@rFlowDelaying_Upper MV1Process,,o1,,0.0,90.0 MV1Process,,o2,,0.0,90.0 MV2Process,,o1,,0.0,90.0 MV2Process,,o2,,0.0,90.0 MV3Process,,o1,,0.0,90.0 MV3Process,,o2,,0.0,90.0 &sUnit,&sOperation,&sPort,&sState,@rFlowDelaying_Lower,@rFlowDelaying_Upper &sUnit,&sOperation,&sPort,&sState,@rYieldDelaying_Lower,@rYieldDelaying_Upper,@rInitial_Time,@sType MV1Process,,o1,,0.0,0.0,0.0,LIP MV1Process,,o1,,1.0,1.0,1.0,LIP MV1Process,,o1,,0.5,0.5,2.0,LIP MV1Process,,o1,,0.25,0.25,3.0,LIP MV1Process,,o1,,0.0,0.0,4.0,LIP MV1Process,,o1,,0.0,0.0,90.0,LIP MV1Process,,o2,,0.0,0.0,0.0,LIP MV1Process,,o2,,-1.0,-1.0,1.0,LIP MV1Process,,o2,,-0.5,-0.5,2.0,LIP MV1Process,,o2,,-0.25,-0.25,3.0,LIP MV1Process,,o2,,0.0,0.0,4.0,LIP MV1Process,,o2,,0.0,0.0,90.0,LIP MV2Process,,o1,,0.0,0.0,0.0,LIP MV2Process,,o1,,-1.0,-1.0,1.0,LIP MV2Process,,o1,,-0.5,-0.5,2.0,LIP MV2Process,,o1,,-0.25,-0.25,3.0,LIP MV2Process,,o1,,0.0,0.0,4.0,LIP MV2Process,,o1,,0.0,0.0,90.0,LIP MV2Process,,o2,,0.0,0.0,0.0,LIP MV2Process,,o2,,1.0,1.0,1.0,LIP MV2Process,,o2,,0.5,0.5,2.0,LIP MV2Process,,o2,,0.25,0.25,3.0,LIP MV2Process,,o2,,0.0,0.0,4.0,LIP MV2Process,,o2,,0.0,0.0,90.0,LIP MV3Process,,o1,,0.0,0.0,0.0,LIP MV3Process,,o1,,1.0,1.0,1.0,LIP MV3Process,,o1,,0.5,0.5,2.0,LIP MV3Process,,o1,,0.25,0.25,3.0,LIP MV3Process,,o1,,0.0,0.0,4.0,LIP MV3Process,,o1,,0.0,0.0,90.0,LIP MV3Process,,o2,,0.0,0.0,0.0,LIP MV3Process,,o2,,1.0,1.0,1.0,LIP MV3Process,,o2,,0.5,0.5,2.0,LIP MV3Process,,o2,,0.25,0.25,3.0,LIP MV3Process,,o2,,0.0,0.0,4.0,LIP MV3Process,,o2,,0.0,0.0,90.0,LIP &sUnit,&sOperation,&sPort,&sState,@rYieldDelaying_Lower,@rYieldDelaying_Upper,@rInitial_Time,@sType MV1Process,,,1.0 MV2Process,,,1.0 MV3Process,,,1.0 &sUnit,&sOperation,@rHoldupSmoothing1_Weight,@rHoldupSmoothing2_Weight &sUnit,&sOperation,@rHoldupSmoothing1_Weight,@rHoldupSmoothing2_Weight !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ! Cost Data (Pricing) !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! CV1Demand,,i,,,,1.0, CV2Demand,,i,,,,1.0, &sUnit,&sOperation,&sPort,&sState,@rFlowPro_Weight,@rFlowPer1_Weight,@rFlowPer2_Weight,@rFlowPen_Weight &sUnit,&sOperation,&sPort,&sState,@rFlowPro_Weight,@rFlowPer1_Weight,@rFlowPer2_Weight,@rFlowPen_Weight !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ! Content Data (Past, Present Provisos) !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! MV1Process,,0.0,-1.0 MV2Process,,0.0,-1.0 MV3Process,,0.0,-1.0 &sUnit,&sOperation,@rHoldup_Value,@rStart_Time &sUnit,&sOperation,@rHoldup_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,@rStartup_Lower,@rStartup_Upper,@rBegin_Time,@rEnd_Time MV1Process,,1,1,BEGIN,END MV2Process,,1,1,BEGIN,END MV3Process,,1,1,BEGIN,END &sUnit,&sOperation,@rStartup_Lower,@rStartup_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 CV1Demand,,i,,-100.0,100.0,0.0,BEGIN,END CV2Demand,,i,,-100.0,100.0,0.0,BEGIN,END
  11. 11. CV1Bias,,o,,0.0,0.0,,BEGIN,END CV2Bias,,o,,0.0,0.0,,BEGIN,END &sUnit,&sOperation,&sPort,&sState,@rTotalRate_Lower,@rTotalRate_Upper,@rTotalRate_Target,@rBegin_Time,@rEnd_Time &sUnit,&sOperation,&sPort,&sState,@rTotalRate_Lower,@rTotalRate_Upper,@rTotalRate_Target,@rBegin_Time,@rEnd_Time Appendix C – APC-IMF-Julia.JL File ############################################################################### # INDUSTRIAL ALGORITHMS LLC. CONFIDENTIAL & PROPRIETARY ####################### ############################################################################### # # File: IMPLjulia.jl # # Author: Jeffrey D. Kelly # Date: September 21, 2014 # Language: Julia. # # Program Description: # # This program embeds IMPL into Julia using its ccall() functionality to perform # a closed-loop advanced process control (APC) simulation of a small linear model # predictive control (MPC) or moving horizon control (MHC) problem. # # This program highlights the difference between "variable-feedback" and "parameter- # feedback" (Kelly and Zyngier, 2008). Variable-feedback is measurement-feedback # using the measured independent and dependent variables values as openings, # starting-values or initial-conditions. Parameter-feedback is also measurement- # feedback but involves calculating parameters or coefficients using either data # reconciliation and regression (DRR) or simple bias-updating (see moving horizon # estimation (MHE)). Without parameter-feedback, steady-state offsets will occur # with omni-present model-mismatch or uncertainty i.e., non-zero differences between # the setpoint, reference or target from the actual or measured controlled variable values. # # The reason for delineating the differences between variable and parameter- # feedback is to demonstrate that in advanced planning and scheduling (APS) # applications, if variable-feedback alone is used (via opening values only) without # parameter-feedback as used in advanced process control (APC) with at least bias-updating, # then significant actual versus plan/schedule deviations, deltas or offsets will occur # (Kelly and Zyngier, 2008) due to the unmanaged uncertainties in the system. # # References: # # Kelly, J.D., Zyngier, D., "Continuously improve planning and scheduling models with # parameter feedback", FOCAPO 2008, July, (2008). # # Revision History: # # 1.0 J.D. Kelly, September 21, 2014 # # Start date of program - Version 14.9.211 # ############################################################################### # INDUSTRIAL ALGORITHMS LLC. CONFIDENTIAL & PROPRIETARY ####################### ############################################################################### # Use Winston as the Julia plotting module - see also ASCIIPlots and Gadfly. using Winston # Include the IMPL constants (see the IMPL.hdr file). include("C:IndustrialAlgorithmsProgramsimpljuliainclude.jl") # Set the path to where the IMPL shared objects (DLL's) are located. cd("c:industrialalgorithmsplatformimpl") #cd("c:impl") # Set the IML file containing the "base" model-data. The "delta" model-data is set # using IPL during the simulation loops, cycles or iterations. #fact = "C:IndustrialAlgorithmsPortfolioAPC-IMF" fact = "C:implapcAPC-IMF" println(fact) # Set and get the USELOGFILE setting. setting = "USELOGFILE" rtnstat = ccall( (:IMPLreceiveSETTING,"IMPLserver"), Cint, (Ptr{Uint8},Cdouble), setting,IMPLyes) IMPLuselogfile = ccall( (:IMPLretrieveSETTING,"IMPLserver"), Cdouble, (Ptr{Uint8},), setting) println("USELOGFILE = ",IMPLuselogfile) # Initialize the environment and allocate the IMPL resource-entities i.e., sets, lists, # catalogs, parameters, variables, constraints, derivatives, expressions and formulas. rtnstat = ccall( (:IMPLroot,"IMPLserver"), Cint, (Ptr{Uint8},) ,fact) rtnstat = ccall( (:IMPLreserve,"IMPLserver"), Cint, (Ptr{Uint8},Cint), fact,IMPLall) # Get the RNNON setting. setting = "RNNON" IMPLrnnon = ccall( (:IMPLretrieveSETTING,"IMPLserver"), Cdouble, (Ptr{Uint8},), setting) println("RNNON = ",IMPLrnnon)
  12. 12. # "Interface" to the base model-data using the IML file specified ("fact"). form = IMPLsparsic #form = IMPLsymbolic fit = IMPLdiscrete filter = IMPLlogistics focus = IMPLoptimization face = IMPLimport factor = IMPLscale fob = IMPLsipherless frames = string(char(0)) rtnstat = ccall( (:IMPLinterfaceri,"IMPLinterfaceri"), Cint, (Ptr{Uint8},Cint,Cint,Cint,Cint,Cint,Cdouble,Clonglong,Ptr{Uint8 }), fact,form,fit,filter,focus,face,factor,fob,frames) # Set the durations of past/present and future time-horizons and the time-period (discrete-time). # # * Note that the duration of the future time-horizon (dthf) is identical to the "prediction-horizon" # and "control-horizon" found in model predictive control (MPC) theory. dthp = -10.0 dthf = 10.0 dtp = 1.0 rtnstat = ccall( (:IMPLreceiveT,"IMPLinteracter"), Cint, (Cdouble,Cdouble,Cdouble), dthp,dthf,dtp) # "Serialize" the base model-data to a binary (unformatted) file which is faster to re-read than the IML # (ASCII) flat-file. # # * Note that at this point we are establishing a base model-data which is over-loaded or incrementally # modified during the closed-loop simulation by adding what IMPL calls "openings" and "orders" for the # variable- and parameter-feedback. rtnstat = ccall( (:IMPLrender,"IMPLserver"), Cint, (Ptr{Uint8},Cint), fact,IMPLall) # Get the number of discretized time-periods in the past/present and future time-horizons. NTP = int32(abs(dthp) / dtp) NTF = int32(dthf / dtp) # Set the number of closed-loop simulation intervals or iterations. NSIM = 50 # Initialize the manipulated and controlled variable (MV and CV) solution vectors. MV1 = zeros(Float64,NSIM+NTP) MV2 = zeros(Float64,NSIM+NTP) MV3 = zeros(Float64,NSIM+NTP) CV1 = zeros(Float64,NSIM+NTP) CV2 = zeros(Float64,NSIM+NTP) # Initialize the controlled variable setpoint/reference/target scenarios. CV1S = zeros(Float64,NSIM) CV2S = zeros(Float64,NSIM) for i = 1:NSIM if i > 0 CV1S[i] = -1.0 end if i > 0 CV2S[i] = 1.0 end end # Initialize the IMPL objective function terms which must be set as 1D arrays or vectors in # Julia in order to return or retrieve values by-reference. profit = Cdouble[0.0] performance1 = Cdouble[0.0] performance2 = Cdouble[0.0] penalty = Cdouble[0.0] total = Cdouble[0.0] tic() TI = zeros(Float64,NSIM) for i = 1:NSIM TI[i] = i # Refresh the IMPL resource-entities and restore the base model-data from the previously rendered or # serialized binary file. rtnstat = ccall( (:IMPLrefresh,"IMPLserver"), Cint, (Cint,) ,IMPLall) rtnstat = ccall( (:IMPLrestore,"IMPLserver"), Cint, (Ptr{Uint8},Cint), fact,IMPLall) # * IMPORTANT NOTE * - Model-Data Configuration via ASCII/Flat-File (IML) and API/Callable Libraries (IPL). # # IMPL allows a mix of two methods to configure the static and dynamic model-data in any order. This is through # IMPL's "interfacer" and the "interacter". The IMPLinterfacer() configures the model-data through the IML # (Industrial Modeling Language) and the IMPLinteracter() configures the model-data through the IPL (Industrial # Programming Language). #
  13. 13. # This allows partial configuration using whatever method is convenient and prudent for th e user. # Set the "variable-feedback" for the manipulated variables. This is also referred to as "initial-conditions" # or "boundary-conditions" in ODE's and DAE's or "openings" in APS (Kelly and Zyngier, 2008). oname = " " status = IMPLkeep for t = 1:NTP uname = "MV1Process" value = MV1[i+NTP-t] starttime = -float64(t) * dtp rtnstat = ccall( (:IMPLreceiveUOholdupopen,"IMPLinteracter"), Cint, (Ptr{Uint8},Ptr{Uint8},Cdouble,Cdouble,Cint), uname,oname,value,starttime,status) uname = "MV2Process" value = MV2[i+NTP-t] rtnstat = ccall( (:IMPLreceiveUOholdupopen,"IMPLinteracter"), Cint, (Ptr{Uint8},Ptr{Uint8},Cdouble,Cdouble,Cint), uname,oname,value,starttime,status) uname = "MV3Process" value = MV3[i+NTP-t] rtnstat = ccall( (:IMPLreceiveUOholdupopen,"IMPLinteracter"), Cint, (Ptr{Uint8},Ptr{Uint8},Cdouble,Cdouble,Cint), uname,oname,value,starttime,status) end # Set the "orders" which set the lower, upper and target (setpoint/reference) bounds. # # * Note that these are flowrate orders or transaction as they represent a flow of stock, goods, # resources or signals. uname = "CV1Demand" oname = " " pname = "i" sname = " " lower = -100.0 upper = 100.0 target = CV1S[i] begintime = 0.0 endtime = dthf rtnstat = ccall( (:IMPLreceiveUOPSrateorder,"IMPLinteracter"), Cint, (Ptr{Uint8},Ptr{Uint8},Ptr{Uint8},Ptr{Uint8},Cdouble,Cdouble,Cdouble,Cdouble,Cdouble,Cint), uname,oname,pname,sname,lower,upper,target,begintime,endtime,status) uname = "CV2Demand" target = CV2S[i] rtnstat = ccall( (:IMPLreceiveUOPSrateorder,"IMPLinteracter"), Cint, (Ptr{Uint8},Ptr{Uint8},Ptr{Uint8},Ptr{Uint8},Cdouble,Cdouble,Cdouble,Cdouble,Cdouble,Cint), uname,oname,pname,sname,lower,upper,target,begintime,endtime,status) # Set the orders which set the parameter-feedback biases. # # * Note that because we are not simulating the actual plant the biases are zero (0). # # * Note that it is also possible to simply bias the setpoints/reference/targets above when simple bias -updating # is employed. uname = "CV1Bias" oname = " " pname = "o" sname = " " lower = 0.0 upper = 0.0 target = IMPLrnnon rtnstat = ccall( (:IMPLreceiveUOPSrateorder,"IMPLinteracter"), Cint, (Ptr{Uint8},Ptr{Uint8},Ptr{Uint8},Ptr{Uint8},Cdouble,Cdouble,Cdouble,Cdouble,Cdouble,Cint), uname,oname,pname,sname,lower,upper,target,begintime,endtime,status) uname = "CV2Bias" rtnstat = ccall( (:IMPLreceiveUOPSrateorder,"IMPLinteracter"), Cint, (Ptr{Uint8},Ptr{Uint8},Ptr{Uint8},Ptr{Uint8},Cdouble,Cdouble,Cdouble,Cdouble,Cdouble,Cint), uname,oname,pname,sname,lower,upper,target,begintime,endtime,status) # Set the setpoint/reference/target 2-norm performance weight for the CV's. # # * Note that these 2-norm performance weights are "tuning" parameters found in other model predictive # controllers such as DMC, etc. uname = "CV1Demand" pname = "i" prowt = 0.0 per1wt = 0.0 per2wt = 1.0 penwt = 0.0 rtnstat = ccall( (:IMPLreceiveUOPSflowweight,"IMPLinteracter"), Cint, (Ptr{Uint8},Ptr{Uint8},Ptr{Uint8},Ptr{Uint8},Cdouble,Cdouble,Cdouble,Cdouble,Cint), uname,oname,pname,sname,prowt,per1wt,per2wt,penwt,status) uname = "CV2Demand" per2wt = 1.0 rtnstat = ccall( (:IMPLreceiveUOPSflowweight,"IMPLinteracter"), Cint, (Ptr{Uint8},Ptr{Uint8},Ptr{Uint8},Ptr{Uint8},Cdouble,Cdouble,Cdouble,Cdouble,Cint), uname,oname,pname,sname,prowt,per1wt,per2wt,penwt,status)
  14. 14. # Set the 2-norm performance weight for the MV's also known as "move-suppression". From an APS viewpoint or perspective we call # this "smoothing" which minimizes the temporal deviations i.e., minimize weight * (dMV,t = MV,t - MV,t-1)^2. # # * Note that this is similar to "dynamic tuning" given that we changing the performance weights "on -line" during the simulation. uname = "MV1Process" per1wt = 0.0 per2wt = 1.0 rtnstat = ccall( (:IMPLreceiveUOholdupsmooth,"IMPLinteracter"), Cint, (Ptr{Uint8},Ptr{Uint8},Cdouble,Cdouble,Cint), uname,oname,per1wt,per2wt,status) uname = "MV2Process" per1wt = 0.0 per2wt = 1.0 rtnstat = ccall( (:IMPLreceiveUOholdupsmooth,"IMPLinteracter"), Cint, (Ptr{Uint8},Ptr{Uint8},Cdouble,Cdouble,Cint), uname,oname,per1wt,per2wt,status) uname = "MV3Process" per1wt = 0.0 per2wt = 1.0 rtnstat = ccall( (:IMPLreceiveUOholdupsmooth,"IMPLinteracter"), Cint, (Ptr{Uint8},Ptr{Uint8},Cdouble,Cdouble,Cint), uname,oname,per1wt,per2wt,status) # "Model" the problem by first creating the dependent sets, lists, catalogs and parameters, then the variables and # finally the constraints. # # Since this problem is linear (with a quadratic objective function), the derivatives are also created with the # constraints else if a nonlinear problem then only the sparsity-pattern is created and the derivatives are calculated # simultaneoulsy during the solving. filler = IMPLsupplementalless foreign = IMPLsupplementaryless force = IMPLparameter rtnstat = ccall( (:IMPLmodelerv,"IMPLmodelerv"), Cint, (Ptr{Uint8},Cint,Cint,Cint,Cint,Ptr{Clonglong},Ptr{Uint8},Ptr{Cint}), fact,form,fit,filter,focus,&filler,foreign,&force) force = IMPLvariable rtnstat = ccall( (:IMPLmodelerv,"IMPLmodelerv"), Cint, (Ptr{Uint8},Cint,Cint,Cint,Cint,Ptr{Clonglong},Ptr{Uint8},Ptr{Cint}), fact,form,fit,filter,focus,&filler,foreign,&force) force = IMPLconstraint rtnstat = ccall( (:IMPLmodelerc,"IMPLmodelerc"), Cint, (Ptr{Uint8},Cint,Cint,Cint,Cint,Ptr{Clonglong},Ptr{Uint8},Ptr{Cint}), fact,form,fit,filter,focus,&filler,foreign,&force) # "Presolve and solve" the problem using either a commerical QP (CPLEX) or an open-source QP (IPOPT). # # * Note that the QP problem can also be solved by IMPL's SECQPE solver which ignores all of the inequality # constraints and only respects equality constraints. Several basis factorization packages are also # available including PARDISO from Intel's MKL which is parallelizable. This is the same solver used to # data reconciliation and regression (DRR) problems. factorizer = IMPLsemisolverless fresh = IMPLfirstsession flashback = IMPLflatfile feedback = IMPLsummonsless fork = IMPLcplex # fork = IMPLipopt # fork = IMPLslpqpecplex # fork = IMPLsecqpey12m # fork = IMPLsecqpenspiv # fork = IMPLsecqpema28 # fork = IMPLsecqpepardiso rtnstat = ccall( (:IMPLpresolver,"IMPLpresolver"), Cint, (Ptr{Uint8},Cint,Cint,Cint,Cint,Cint,Cint,Cint,Cint,Ptr{Int64}), fact,form,fit,filter,focus,factorizer,fork,fresh,flashback,&feedback) # Get the current manipulated variable (MV) solution values required by the "variable -feedback". # # When we use finite impulse-responses (discrete convolution model) with the batch-process's relative-time yields then the # controlled variables are completely calculatable or determinable using the past/present manipulated variables only. If # transfer functions are used which model the time-series using efficient rational polynomial quotients then both past/present # manipulated (independent) and controlled (dependent) variables are required. uname = "MV1Process" oname = " " MV1[i+NTP] = ccall( (:IMPLretrieveUOholdup1,"IMPLinteracter"), Cdouble, (Ptr{Uint8},Ptr{Uint8},Cin t,Cint,Cint), uname,oname,NTP,NTF,-(1+NTP)) uname = "MV2Process" MV2[i+NTP] = ccall( (:IMPLretrieveUOholdup1,"IMPLinteracter"), Cdouble, (Ptr{Uint8},Ptr{Uint8},Cint,Cint,Cint), uname,oname,NTP,NTF,-(1+NTP)) uname = "MV3Process" MV3[i+NTP] = ccall( (:IMPLretrieveUOholdup1,"IMPLinteracter"), Cdouble, (Ptr{Uint8},Ptr{Uint8},Cint,Cint,Cint), uname,oname,NTP,NTF,-(1+NTP)) # Get the current controlled variable (CV) solution values required by both "parameter -feedback" and # "variable-feedback" or bias-updating. # # * Note, given that we are only performing off-line simulation, there are no measured or actual values for # the controlled variables so the biases are naturally zero (0) and we do not need to update these in the # model-data using order or transactions. # # If this were an on-line situation with actual field or laboratory measurements at time t then we would take # these CV measurements subtract them from the CV predictions at time t to compute the simple biases. These biases # can then be subtracted from the setpoints, references or targets with the explicit bias flow streams.
  15. 15. uname = "CV1Demand" oname = " " pname = "i" sname = " " CV1[i+NTP] = ccall( (:IMPLretrieveUOPSflow1,"IMPLinteracter"), Cdouble, (Ptr{Uint8},Ptr{Uint8},Ptr{Uint8},Ptr{Uint8},Cint,Cint,Cint), uname,oname,pname,sname,NTP,NTF,-(1+NTP)) uname = "CV2Demand" CV2[i+NTP] = ccall( (:IMPLretrieveUOPSflow1,"IMPLinteracter"), Cdouble, (Ptr{Uint8},Ptr{Uint8},Ptr{Uint8},Ptr{Uint8},Cint,Cint,Cint), uname,oname,pname,sname,NTP,NTF,-(1+NTP)) # Get the objective function terms where given our pure QP objective function, only the performance2 (2 -norm) # is non-zero. ccall( (:IMPLretrieveOBJterms2,"IMPLinteracter"), Void, (Ptr{Cdouble},Ptr{Cdouble},Ptr{Cdouble},Ptr{Cdouble},Ptr{Cdouble}), profit,performance1,performance2,penalty,total) println("Profit = ",profit[1]) println("Performance1 = ",performance1[1]) println("Performance2 = ",performance2[1]) println("Penalty = ",penalty[1]) println("Total = ",total[1]) # Get the total objective function value and the equality constraint closure 2-norm as IMPL statistics. setting = "OBJVALUE" objvalue = ccall( (:IMPLretrieveSTATISTIC,"IMPLserver"), Cdouble, (Ptr{Uint8},), setting) println("objvalue = ",objvalue) setting = "ECLOSURE2" eclosure2 = ccall( (:IMPLretrieveSTATISTIC,"IMPLserver"), Cdouble, (Ptr{Uint8},), setting) println("eclosure2 = ",eclosure2) # Write a log message to the IMPL log file (*.ldt). logmessage = "Iteration # " * string(i) rtnstat = ccall( (:IMPLwritelog,"IMPLserver"), Cint, (Ptr{Uint8},), logmessage) end toc() # Write the IMPL export (*.exl) and data files (*.dta or *.adt). face = IMPLexport rtnstat = ccall( (:IMPLinterfacere,"IMPLinterfacere"), Cint, (Ptr{Uint8},Cint,Cint,Cint,Cint,Cint,Cdouble,Clonglong,Ptr{Uint8 }), fact,form,fit,filter,focus,face,factor,fob,frames) rtnstat = ccall( (:IMPLwriteall,"IMPLserver"), Cint, (Ptr{Uint8},Cint,Cint,Cint), fact,IMPLseriesset,0,0) rtnstat = ccall( (:IMPLwriteall,"IMPLserver"), Cint, (Ptr{Uint8},Cint,Cint,Cint), fact,IMPLsimpleset,0,0) rtnstat = ccall( (:IMPLwriteall,"IMPLserver"), Cint, (Ptr{Uint8},Cint,Cint,Cint), fact,IMPLsymbolset,0,0) rtnstat = ccall( (:IMPLwriteall,"IMPLserver"), Cint, (Ptr{Uint8},Cint,Cint,Cint), fact,IMPLcatalog,0,0) rtnstat = ccall( (:IMPLwriteall,"IMPLserver"), Cint, (Ptr{Uint8},Cint,Cint,Cint), fact,IMPLlist,0,0) rtnstat = ccall( (:IMPLwriteall,"IMPLserver"), Cint, (Ptr{Uint8},Cint,Cint,Cint), fact,IMPLparameter,0,0) rtnstat = ccall( (:IMPLwriteall,"IMPLserver"), Cint, (Ptr{Uint8},Cint,Cint,Cint), fact,IMPLvariable,0,0) rtnstat = ccall( (:IMPLwriteall,"IMPLserver"), Cint, (Ptr{Uint8},Cint,Cint,Cint), fact,IMPLconstraint,0,0) # Write the IMPL model symbology in the *.ndt file. ptr_dll = ccall( (:LoadLibraryA,"kernel32"), stdcall, Clonglong, (Ptr{Uint8},), "IMPLmodelerc") ptr_mdl = ccall( (:GetProcAddress,"kernel32"), stdcall, Clonglong, (Clonglong,Ptr{Uint8}), ptr_dll,"IMPLmodelerc") flag = 0 rtnstat = ccall( (:IMPLwritesymbology,"IMPLserver"), Cint, (Ptr{Uint8},Ptr{Int64},Cint), fact,&ptr_mdl,flag) rtnstat = ccall( (:IMPLreport,"IMPLserver"), Cint, (Ptr{Uint8},), fact) rtnstat = ccall( (:IMPLsummary,"IMPLserver"), Cint, (Ptr{Uint8},), fact) # Release (de-allocate) all of the IMPL resource-entity memory. rtnstat = ccall( (:IMPLrelease,"IMPLserver"), Cint, (Cint,), IMPLall) # Plot the MV and CV solution values. p1 = plot(MV1[1+NTP:NSIM+NTP],"b^-",MV2[1+NTP:NSIM+NTP],"g*:",MV3[1+NTP:NSIM+NTP],"m+--",title="Manipulated Variables",xlabel="time",ylabel=" ") savefig("C:IndustrialAlgorithmsPortfolioAPC-IMF-MV.png") display(p1) p2 = plot(CV1[1+NTP:NSIM+NTP],"b^:",CV2[1+NTP:NSIM+NTP],"g*-",title="Controlled Variables",xlabel="time",ylabel=" ") savefig("C:IndustrialAlgorithmsPortfolioAPC-IMF-CV.png") display(p2)

×