- Email: [email protected]
Interfacing IPOPT with Aspen Open Solvers and CAPE-OPEN
10th International Symposium on Process Systems Engineering - PSE2009 Rita Maria de Brito Alves, Claudio Augusto Oller do Nascimento and Evaristo Chalbaud Biscaia Jr. (Editors) © 2009 Elsevier B.V. All rights reserved.
201
Interfacing IPOPT with Aspen Open Solvers and CAPE-OPEN Weifeng Chen, Zhijiang Shao and Jixin Qian State Key Laboratory of Industrial Control Technology, Institute of Industrial control,Zhejiang University, Hang Zhou 310027, China
Abstract CAPE-OPEN (CO) is brought forward as the standard for the next generation of process system simulation platform. In this work, the IPOPT algorithm and interface developed by (Lang and Biegler, 2005) is extended. IPOPT is encapsulated and is embedded into Aspen Plus through Aspen Open Solvers (AOS) Interface. A scaling module based on starting point is developed for scaling the models from Aspen Plus before optimization. The validity of AOS compliant IPOPT is tested by solving the economic optimization problem of depropanizer and debutanizer multi-column system and the reconciliation problem of large-scale air separation system. Compatibility of Aspen Plus for CO solvers is extended based on AOS interface through COM technology. In order to demonstrate validity of the extended compatibility, CO compliant IPOPT is integrated with Aspen Plus. It is tested by the same examples as AOS compliant IPOPT. Further analysis is made on effect of model scale on efficiency loss since the introduction of CO. Keywords: Aspen Open Solvers, CAPE-OPEN, Scaling, Optimization
1. Introduction Process system simulation and optimization have long been used as means to estimate the economic benefit and impact for environment of different design options. There have been many process simulation tools with excellent solvers, abundant unit models, or precise thermodynamic and physical properties. However, there are still critical demands for effective interactions among different modules. CAPE-OPEN (CO) is brought forward as the standard for the next generation of process system simulation platform. It is conceived to achieve the goals of facilitating process modeling and design and increasing interoperability among various process simulation tools. The CO interoperability standard allows interoperation among heterogeneous Process Modeling Components (PMCs) and Process Modeling Environments (PMEs) from different software providers, independent of their algorithmic details, programming languages and operating system (Yang et al, 2007). Many highly competitive software suppliers and famous research groups are involved in developing and utilizing CO compliant software, however, most of them focus on the development of CO compliant unit operations and CO compliant thermodynamic and physical properties (Ricardo et al, 2008; Testard et al, 2005). CO compliant numeric solvers, especially optimization solvers, are seldom concerned. In this paper, the IPOPT algorithm and interface developed by (Lang and Biegler, 2005) is extended. Section 2 discusses IPOPT for Aspen Plus through Aspen Open Solvers (AOS) Interface. Section 3 presents compatibility of Aspen Plus for CO solvers based
Corresponding author. E-mail address: [email protected]
202
W. Chen et al.
on AOS Interface through COM technology. Section 4 then presents a number of case studies that test the validity of AOS compliant IPOPT and the compatibility of Aspen Plus for CO solvers. A further analysis is made on the effect of model scale on efficiency loss. Finally, some concluding remarks are given.
2. AOS Compliant IPOPT This section deals with two issues for embedding IPOPT into Aspen Plus using Aspen Open Solvers (AOS) (Aspen Technology, 2003). First, a scaling module based on starting point is developed for scaling the models. And then, IPOPT is encapsulated into Dynamic Link Library (DLL) and an AOS wrapper for IPOPT is developed. 2.1. Scaling Module Since the scaled models from Aspen Plus sometimes are not suitable for IPOPT to solve because of the ill-conditioned matrix. A scaling module based on starting point is developed for scaling the models again before optimization. The scaling method is different from (Lid et al, 2008) which scales all the nonzero values of the Jacobian matrix of constraints. Original and scaled NLP formulations are
f (x) min °° x ® s.t. c ( x ) = 0 ° x t 0 ¯°
where the scaled variable x constraints c ( x )
min °° x ® s.t. ° °¯
f (x ) c ( x ) = 0 S x x t 0
(1)
S x1 x , the scaled objective f (x )=f ( S x x ) , the scaled
S c1c( S x x ) . S x and S c are fixed diagonal scaling matrices. The
proposed scaling procedure is as follows, 1. Scale variables based on the starting point. If the absolute initial value of some variable is larger than one, it will be scaled. The variable scaling matrix is as follows, where x0 is the starting point
S x (i, i )
° x0 (i ) , if x0 (i ) ! 1 ® °¯1, else
(2)
2. Scale constraints based on the initial Jacobian matrix,
Sc ( j , j )
wc j wc j ° S x ( wx ) , if S x ( wx ) i f i ® °1, else ¯
!1 f
wc j wxi
is a column vector.
(3)
The scaling module exposes an interface (IScalingModelInfo) to supply IPOPT with all the required information. 2.2. Embedding IPOPT into Aspen Plus We encapsulate IPOPT into DLL which exposes a class NLPStruct and a function AOS_IPOPT (NLPStruct* mynlp). NLPStruct is derived and the member methods of NLPStruct are overridden utilizing IScalingModelInfo interface. AOS_IPOPT is the entrance of the whole algorithm. PseudoSolver implementing AOSNumericNLPSystem and AOSNumericNLPSystemFactory interfaces exposes GetFactoryNLPSystem
Interfacing IPOPT with Aspen Open Solvers and CAPE-OPEN
203
method. When loading PseudoSolver, Aspen Plus looks for GetFactoryNLPSystem method and invokes it to create an instance of CNumericNLPSystemFactory class. For an AOSNumericNLPESO object in a being solved model, there is a corresponding CNumericNLPSystem instance allocated by the CNumericNLPSystemFactory instance in the PseudoSolver. Finally, AOSNumericNLPSystem is invoked and AOS_IPOPT function is called. IPOPT gets the required information of the model being solved by calling NLPStruct interface and CNLPStruct gets corresponding information by calling IScalingModelInfo interface. Interactions between IPOPT and Aspen Plus though AOS are shown as figure 1.
Fig 1 Component Diagram of Interaction between AOS Compliant IPOPT and Aspen Plus
3. Compatibility of Aspen Plus for CO Solver Aspen Plus supports the CO Unit Operation and CO Thermodynamics standards. Unfortunately, so far there is no report that Aspen Plus is compatible with CO solvers. The compatibility of Aspen Plus for CO solvers is extended based on AOS Interface through COM technology. The CO Optimization Interface issued by CO-LaN for MINLPs (CO-LaN, 2003a) is comprised of ICapeMINLP, ICapeMINLPSolverManager and ICapeMINLPSystem. One of the first steps for achieving the compatibility of Aspen Plus for CO compliant NLP solver is to implement the common CAPE-OPEN interfaces, such as Identification Common Interface (CO-LaN, 2003b), Parameter Common Interface (CO-LaN, 2003c) and Collection Common Interface (CO-LaN, 2003d). All the CAPE-OPEN components implement Identification Common Interface to provide their names and descriptions. Parameter Common Interface includes ICapeParameter, ICapeParameterSpec, ICapeOptionParameterSpec, ICapeRealParameterSpec, ICapeIntegerParameterSpec and ICapeBooleanParameterSpec. A CCapeParameterSpec class is created by implementing all the above referred parameter interfaces except ICapeParameter and it is contained in CCapeParameter class. The CCapeParameter class inherited from ICapeParameter represents all the parameters of the NLP solver. In order to facilitate handling parameters of the NLP solver, a CParameterCollection class is created by implementing ICapeCollection interface with map template class as a container. NLP is a special case of MINLP, so it can be completely described by ICapeMINLP. CCapeNLP exposing ICapeMINLP is created by using IScalingModelInfo to represent the scaled model. CCapeMINLPSystem inherited from ICapeMINLPSystem connects a
204
W. Chen et al.
selected NLP solver with a special CCapeNLP instance. CCapeMINLPSolverManager creates a CCapeMINLPSystem instance corresponding to a special CCapeNLP instance. It also handles the selection and configuration of the parameters of the selected solver. In order to illustrate the progress of embedding CO solver (in this paper, we utilize CO IPOPT (Lang and Biegler, 2005) and it can be replaced by other CO solver immediately) into CO compliant Aspen Plus clearly, the component diagram of interaction between CO compliant IPOPT and Aspen Plus is given as figure 2. We can compare it with figure 1 to find out what makes Aspen Plus compatible with CO solver.
Fig 2 Component Diagram of Interaction between CO Compliant IPOPT and Aspen Plus
4. Numerical Experiments This section deals with two issues. First, we test the validity of AOS compliant IPOPT by solving the economic optimization problem of depropanizer and debutanizer multicolumn system and the reconciliation problem of large-scale air separation system. Simultaneously, we demonstrate the validity of the compatibility of Aspen Plus for CO solver by solving the same examples as AOS compliant IPOPT. Second, the effect of model scale on efficiency loss of CO compliant IPOPT is evaluated by solving two variable scale models. All the numerical experiments are performed on the machine Dell Latitude D520 running Windows XP and with Intel(R) CPU T2300, 1.66GHz and 1.5G RAM memory. 4.1. Validity Test Case 1 The depropanizer and debutanizer multi-column system is an important part in the ethylene production. We can refer to (Jiang et al, 2006) for the illustration of the flow sheet and the formulation of the optimization problem. For this NLP problem, number of variables is 3889, number of equality constraints is 3887, the degree of freedom is 2, and the number of nonzero elements of Jacobian in constraints is 76197. The results for solving this problem with AOS compliant IPOPT and CO compliant IPOPT respectively are presented in table 1. AOS represents the CPU time for solving
205
Interfacing IPOPT with Aspen Open Solvers and CAPE-OPEN
the problem with AOS compliant IPOPT. CO-InProcess represents the CPU time for solving the problem with CO compliant IPOPT run in “in process” (in the same process as Aspen Plus) mode while CO-Local is CO compliant IPOPT run in “out of process” (a separate process on the same computer as Aspen Plus) mode. Tab.1 Numeric result of depropanizer and debutanizer multi-column system objective iteration feasibility AOS (s) CO-InProcess (s) CO-Local (s) 1.961e+1
11
1.95e-7
9.42
16.37
17.97
The problem is solved successfully and all the three runs have the same objective value, number of iterations and feasibility, we verify the validity of AOS IPOPT and the compatibility of Aspen Plus for CO IPOPT. Moreover, from table 1, we note that there is little difference in CPU time for solving this model in “in process” mode and in “out of process” mode. Case 2 A large-scale air separation system was constructed which contains 36 units and 68 feed streams. Each stream has 3 components which are oxygen, nitrogen and argon. The measurement data of the process system reflects the run status of equipments and is the basis for process simulation and optimization. As the measurement error of data is inevitable, we need to revise the data before they are used as experiment data. For this reconciliation model, the number of variable is 7184, the number of equality constraints is 7168, the degree of freedom is 16, and the number of nonzero elements of Jacobian of constraints is 40034. The results for solving this model using AOS compliant IPOPT and CO compliant IPOPT are shown in table 2. Tab.2 Numeric result of large-scale air separation objective iteration feasibility AOS (s) CO-InProcess (s) 4.005e-2
173
9.44e-7
75.02
CO-Local (s)
188.30
204.64
This model is also solved successfully and all the three runs have the same objective value, number of iterations and feasibility. 4.2. Efficiency Test From section 4.1, we see that CPU time of CO wrapping increases much compared with AOS compliant IPOPT. Interoperability of Aspen Plus is gained at the expense of efficiency loss. A further test is made on the effect of model scale on efficiency loss. Two variable scale examples from (Biegler et al, 2000; Schmid, 1994) are tested. Example 1 Example 2 n
n1
min 0.5¦xi2
min
x1(xj1 1) 10xj1 0, j 1,..., n 1
x j 2x j 1 3x j 2 1 0, j 1,..., n 2
x0j 0.1
x10
i 1
¦( x x i
i 1
)2
i 1
4, xi0 1, i ! 1
The scale of the both examples varies from 5,000 to 200,000 with step 5,000. The relationship between the model scale and the CPU time cost is illustrated by figure 3. ’no CO’ represents that the model is solved by AOS compliant IPOPT while ’CO’ represents CO compliant IPOPT. ’Extra’ represents the extra overhead because of the introduction of CO (namely ’CO’ minus ’no CO’). Figure 3 indicates that a nearly linear relationship holds between extra overhead and model scale. The reason for this phenomenon is the implementation of the CO interface involving extra memory allocation and data copy.
206
W. Chen et al.
Fig 3 Relationship between the model scale and the CPU time cost
5. Conclusion In this paper, we descirbe the development of AOS compliant IPOPT. The compatibility of Aspen Plus for CO solvers is extended based on AOS Interface through COM technology. The validity of AOS compliant IPOPT is tested by solving the economic optimization problem of depropanizer and debutanizer multi-column system and the reconciliation problem of large-scale air separation system. Moreover, validity of the extended CO compatibility of Aspen Plus is tested with the same examples as AOS compliant IPOPT. IPOPT is embedded into Aspen Plus successfully as a new tool for solving process optimization problems. Compatibility of Aspen Plus is extended for CO compliant solver. A nearly linear relationship holds between the efficiency loss and model scale.
References Aspen Technology, Inc. ,2003, Aspen Open Solvers 12.1 User Guide, available at http://support.aspentech.com/webteamasp/My/FrameDef.asp?/webteamasp/AllDocsDB.asp L. T. Biegler, J. Nocedal et al.,2000, Numerical experience with a reduced Hessian method for large scale constrained optimization, Computational Optimization and Applications, 15, 45-67. CO-LaN Consortium, 2003a, Open Interface Specification: Optimization Interface, version 2. http://www.colan.org/Spec%2010/Optimisation%20Interface%20Specification.pdf CO-LaN Consortium, 2003b, Open Interface Specification: Identification Common Interface, version 3. http://www.colan.org/Spec%2010/Identification%20Common%20Interface.pdf CO-LaN Consortium, 2003c, Open Interface Specification: Parameter Common Interface, version 5. http://www.colan.org/Spec%2010/Parameter%20Common%20Interface.pdf CO-LaN Consortium, 2003d, Open Interface Specification: Collection Common Interface, version 2. http://www.colan.org/Spec%2010/Collection%20Common%20Interface.pdf A. P. Jiang, Z. J. Shao, et al., 2006, Simulation and Optimization of Distillation Column Sequence in Large-Scale Ethylene Production. Chem. Ind. Eng. (China), 57, 9, 2128-2134. Y. D. Lang, L. T. Biegler, 2005, The IPOPT Interface to CAPE-OPEN. CAPE-OPEN Update, Vol. 10, available at http://www.colan.org/CO%20Update/IPOPTmain_Vol10.htm T. Lid, S. Skogestad, 2008, Scaled steady state models for effective on-line applications. Computers & Chemical Engineering, 32, 990-999. M. R. Ricardo, G. Rafiqul, et al., 2008, Use of CAPE-OPEN standards in the interoperability between modeling tools (MoT) and process simulators (Simulis Thermodynamics and ProSimPlus). Chemical Engineering Research and Design, 86, 7, 823-833. C. Schmid, 1994, Reduced Hessian Successive Quadratic Programming for Large-Scale Process Optimization, Ph. D. thesis, Carnegie Mellon University. L. Testard, J. P. Belaud, 2005, A CAPE-OPEN based framework for process simulation solution integration. Computer Aided Chemical Engineering, 20, 1, 607-612. A. Yang, B. Braunschweig, et al., 2007, A multi-agent system to facilitate component-based process modeling and design. Computers & Chemical Engineering, 32, 2290-2305.
201
Interfacing IPOPT with Aspen Open Solvers and CAPE-OPEN Weifeng Chen, Zhijiang Shao and Jixin Qian State Key Laboratory of Industrial Control Technology, Institute of Industrial control,Zhejiang University, Hang Zhou 310027, China
Abstract CAPE-OPEN (CO) is brought forward as the standard for the next generation of process system simulation platform. In this work, the IPOPT algorithm and interface developed by (Lang and Biegler, 2005) is extended. IPOPT is encapsulated and is embedded into Aspen Plus through Aspen Open Solvers (AOS) Interface. A scaling module based on starting point is developed for scaling the models from Aspen Plus before optimization. The validity of AOS compliant IPOPT is tested by solving the economic optimization problem of depropanizer and debutanizer multi-column system and the reconciliation problem of large-scale air separation system. Compatibility of Aspen Plus for CO solvers is extended based on AOS interface through COM technology. In order to demonstrate validity of the extended compatibility, CO compliant IPOPT is integrated with Aspen Plus. It is tested by the same examples as AOS compliant IPOPT. Further analysis is made on effect of model scale on efficiency loss since the introduction of CO. Keywords: Aspen Open Solvers, CAPE-OPEN, Scaling, Optimization
1. Introduction Process system simulation and optimization have long been used as means to estimate the economic benefit and impact for environment of different design options. There have been many process simulation tools with excellent solvers, abundant unit models, or precise thermodynamic and physical properties. However, there are still critical demands for effective interactions among different modules. CAPE-OPEN (CO) is brought forward as the standard for the next generation of process system simulation platform. It is conceived to achieve the goals of facilitating process modeling and design and increasing interoperability among various process simulation tools. The CO interoperability standard allows interoperation among heterogeneous Process Modeling Components (PMCs) and Process Modeling Environments (PMEs) from different software providers, independent of their algorithmic details, programming languages and operating system (Yang et al, 2007). Many highly competitive software suppliers and famous research groups are involved in developing and utilizing CO compliant software, however, most of them focus on the development of CO compliant unit operations and CO compliant thermodynamic and physical properties (Ricardo et al, 2008; Testard et al, 2005). CO compliant numeric solvers, especially optimization solvers, are seldom concerned. In this paper, the IPOPT algorithm and interface developed by (Lang and Biegler, 2005) is extended. Section 2 discusses IPOPT for Aspen Plus through Aspen Open Solvers (AOS) Interface. Section 3 presents compatibility of Aspen Plus for CO solvers based
Corresponding author. E-mail address: [email protected]
202
W. Chen et al.
on AOS Interface through COM technology. Section 4 then presents a number of case studies that test the validity of AOS compliant IPOPT and the compatibility of Aspen Plus for CO solvers. A further analysis is made on the effect of model scale on efficiency loss. Finally, some concluding remarks are given.
2. AOS Compliant IPOPT This section deals with two issues for embedding IPOPT into Aspen Plus using Aspen Open Solvers (AOS) (Aspen Technology, 2003). First, a scaling module based on starting point is developed for scaling the models. And then, IPOPT is encapsulated into Dynamic Link Library (DLL) and an AOS wrapper for IPOPT is developed. 2.1. Scaling Module Since the scaled models from Aspen Plus sometimes are not suitable for IPOPT to solve because of the ill-conditioned matrix. A scaling module based on starting point is developed for scaling the models again before optimization. The scaling method is different from (Lid et al, 2008) which scales all the nonzero values of the Jacobian matrix of constraints. Original and scaled NLP formulations are
f (x) min °° x ® s.t. c ( x ) = 0 ° x t 0 ¯°
where the scaled variable x constraints c ( x )
min °° x ® s.t. ° °¯
f (x ) c ( x ) = 0 S x x t 0
(1)
S x1 x , the scaled objective f (x )=f ( S x x ) , the scaled
S c1c( S x x ) . S x and S c are fixed diagonal scaling matrices. The
proposed scaling procedure is as follows, 1. Scale variables based on the starting point. If the absolute initial value of some variable is larger than one, it will be scaled. The variable scaling matrix is as follows, where x0 is the starting point
S x (i, i )
° x0 (i ) , if x0 (i ) ! 1 ® °¯1, else
(2)
2. Scale constraints based on the initial Jacobian matrix,
Sc ( j , j )
wc j wc j ° S x ( wx ) , if S x ( wx ) i f i ® °1, else ¯
!1 f
wc j wxi
is a column vector.
(3)
The scaling module exposes an interface (IScalingModelInfo) to supply IPOPT with all the required information. 2.2. Embedding IPOPT into Aspen Plus We encapsulate IPOPT into DLL which exposes a class NLPStruct and a function AOS_IPOPT (NLPStruct* mynlp). NLPStruct is derived and the member methods of NLPStruct are overridden utilizing IScalingModelInfo interface. AOS_IPOPT is the entrance of the whole algorithm. PseudoSolver implementing AOSNumericNLPSystem and AOSNumericNLPSystemFactory interfaces exposes GetFactoryNLPSystem
Interfacing IPOPT with Aspen Open Solvers and CAPE-OPEN
203
method. When loading PseudoSolver, Aspen Plus looks for GetFactoryNLPSystem method and invokes it to create an instance of CNumericNLPSystemFactory class. For an AOSNumericNLPESO object in a being solved model, there is a corresponding CNumericNLPSystem instance allocated by the CNumericNLPSystemFactory instance in the PseudoSolver. Finally, AOSNumericNLPSystem is invoked and AOS_IPOPT function is called. IPOPT gets the required information of the model being solved by calling NLPStruct interface and CNLPStruct gets corresponding information by calling IScalingModelInfo interface. Interactions between IPOPT and Aspen Plus though AOS are shown as figure 1.
Fig 1 Component Diagram of Interaction between AOS Compliant IPOPT and Aspen Plus
3. Compatibility of Aspen Plus for CO Solver Aspen Plus supports the CO Unit Operation and CO Thermodynamics standards. Unfortunately, so far there is no report that Aspen Plus is compatible with CO solvers. The compatibility of Aspen Plus for CO solvers is extended based on AOS Interface through COM technology. The CO Optimization Interface issued by CO-LaN for MINLPs (CO-LaN, 2003a) is comprised of ICapeMINLP, ICapeMINLPSolverManager and ICapeMINLPSystem. One of the first steps for achieving the compatibility of Aspen Plus for CO compliant NLP solver is to implement the common CAPE-OPEN interfaces, such as Identification Common Interface (CO-LaN, 2003b), Parameter Common Interface (CO-LaN, 2003c) and Collection Common Interface (CO-LaN, 2003d). All the CAPE-OPEN components implement Identification Common Interface to provide their names and descriptions. Parameter Common Interface includes ICapeParameter, ICapeParameterSpec, ICapeOptionParameterSpec, ICapeRealParameterSpec, ICapeIntegerParameterSpec and ICapeBooleanParameterSpec. A CCapeParameterSpec class is created by implementing all the above referred parameter interfaces except ICapeParameter and it is contained in CCapeParameter class. The CCapeParameter class inherited from ICapeParameter represents all the parameters of the NLP solver. In order to facilitate handling parameters of the NLP solver, a CParameterCollection class is created by implementing ICapeCollection interface with map template class as a container. NLP is a special case of MINLP, so it can be completely described by ICapeMINLP. CCapeNLP exposing ICapeMINLP is created by using IScalingModelInfo to represent the scaled model. CCapeMINLPSystem inherited from ICapeMINLPSystem connects a
204
W. Chen et al.
selected NLP solver with a special CCapeNLP instance. CCapeMINLPSolverManager creates a CCapeMINLPSystem instance corresponding to a special CCapeNLP instance. It also handles the selection and configuration of the parameters of the selected solver. In order to illustrate the progress of embedding CO solver (in this paper, we utilize CO IPOPT (Lang and Biegler, 2005) and it can be replaced by other CO solver immediately) into CO compliant Aspen Plus clearly, the component diagram of interaction between CO compliant IPOPT and Aspen Plus is given as figure 2. We can compare it with figure 1 to find out what makes Aspen Plus compatible with CO solver.
Fig 2 Component Diagram of Interaction between CO Compliant IPOPT and Aspen Plus
4. Numerical Experiments This section deals with two issues. First, we test the validity of AOS compliant IPOPT by solving the economic optimization problem of depropanizer and debutanizer multicolumn system and the reconciliation problem of large-scale air separation system. Simultaneously, we demonstrate the validity of the compatibility of Aspen Plus for CO solver by solving the same examples as AOS compliant IPOPT. Second, the effect of model scale on efficiency loss of CO compliant IPOPT is evaluated by solving two variable scale models. All the numerical experiments are performed on the machine Dell Latitude D520 running Windows XP and with Intel(R) CPU T2300, 1.66GHz and 1.5G RAM memory. 4.1. Validity Test Case 1 The depropanizer and debutanizer multi-column system is an important part in the ethylene production. We can refer to (Jiang et al, 2006) for the illustration of the flow sheet and the formulation of the optimization problem. For this NLP problem, number of variables is 3889, number of equality constraints is 3887, the degree of freedom is 2, and the number of nonzero elements of Jacobian in constraints is 76197. The results for solving this problem with AOS compliant IPOPT and CO compliant IPOPT respectively are presented in table 1. AOS represents the CPU time for solving
205
Interfacing IPOPT with Aspen Open Solvers and CAPE-OPEN
the problem with AOS compliant IPOPT. CO-InProcess represents the CPU time for solving the problem with CO compliant IPOPT run in “in process” (in the same process as Aspen Plus) mode while CO-Local is CO compliant IPOPT run in “out of process” (a separate process on the same computer as Aspen Plus) mode. Tab.1 Numeric result of depropanizer and debutanizer multi-column system objective iteration feasibility AOS (s) CO-InProcess (s) CO-Local (s) 1.961e+1
11
1.95e-7
9.42
16.37
17.97
The problem is solved successfully and all the three runs have the same objective value, number of iterations and feasibility, we verify the validity of AOS IPOPT and the compatibility of Aspen Plus for CO IPOPT. Moreover, from table 1, we note that there is little difference in CPU time for solving this model in “in process” mode and in “out of process” mode. Case 2 A large-scale air separation system was constructed which contains 36 units and 68 feed streams. Each stream has 3 components which are oxygen, nitrogen and argon. The measurement data of the process system reflects the run status of equipments and is the basis for process simulation and optimization. As the measurement error of data is inevitable, we need to revise the data before they are used as experiment data. For this reconciliation model, the number of variable is 7184, the number of equality constraints is 7168, the degree of freedom is 16, and the number of nonzero elements of Jacobian of constraints is 40034. The results for solving this model using AOS compliant IPOPT and CO compliant IPOPT are shown in table 2. Tab.2 Numeric result of large-scale air separation objective iteration feasibility AOS (s) CO-InProcess (s) 4.005e-2
173
9.44e-7
75.02
CO-Local (s)
188.30
204.64
This model is also solved successfully and all the three runs have the same objective value, number of iterations and feasibility. 4.2. Efficiency Test From section 4.1, we see that CPU time of CO wrapping increases much compared with AOS compliant IPOPT. Interoperability of Aspen Plus is gained at the expense of efficiency loss. A further test is made on the effect of model scale on efficiency loss. Two variable scale examples from (Biegler et al, 2000; Schmid, 1994) are tested. Example 1 Example 2 n
n1
min 0.5¦xi2
min
x1(xj1 1) 10xj1 0, j 1,..., n 1
x j 2x j 1 3x j 2 1 0, j 1,..., n 2
x0j 0.1
x10
i 1
¦( x x i
i 1
)2
i 1
4, xi0 1, i ! 1
The scale of the both examples varies from 5,000 to 200,000 with step 5,000. The relationship between the model scale and the CPU time cost is illustrated by figure 3. ’no CO’ represents that the model is solved by AOS compliant IPOPT while ’CO’ represents CO compliant IPOPT. ’Extra’ represents the extra overhead because of the introduction of CO (namely ’CO’ minus ’no CO’). Figure 3 indicates that a nearly linear relationship holds between extra overhead and model scale. The reason for this phenomenon is the implementation of the CO interface involving extra memory allocation and data copy.
206
W. Chen et al.
Fig 3 Relationship between the model scale and the CPU time cost
5. Conclusion In this paper, we descirbe the development of AOS compliant IPOPT. The compatibility of Aspen Plus for CO solvers is extended based on AOS Interface through COM technology. The validity of AOS compliant IPOPT is tested by solving the economic optimization problem of depropanizer and debutanizer multi-column system and the reconciliation problem of large-scale air separation system. Moreover, validity of the extended CO compatibility of Aspen Plus is tested with the same examples as AOS compliant IPOPT. IPOPT is embedded into Aspen Plus successfully as a new tool for solving process optimization problems. Compatibility of Aspen Plus is extended for CO compliant solver. A nearly linear relationship holds between the efficiency loss and model scale.
References Aspen Technology, Inc. ,2003, Aspen Open Solvers 12.1 User Guide, available at http://support.aspentech.com/webteamasp/My/FrameDef.asp?/webteamasp/AllDocsDB.asp L. T. Biegler, J. Nocedal et al.,2000, Numerical experience with a reduced Hessian method for large scale constrained optimization, Computational Optimization and Applications, 15, 45-67. CO-LaN Consortium, 2003a, Open Interface Specification: Optimization Interface, version 2. http://www.colan.org/Spec%2010/Optimisation%20Interface%20Specification.pdf CO-LaN Consortium, 2003b, Open Interface Specification: Identification Common Interface, version 3. http://www.colan.org/Spec%2010/Identification%20Common%20Interface.pdf CO-LaN Consortium, 2003c, Open Interface Specification: Parameter Common Interface, version 5. http://www.colan.org/Spec%2010/Parameter%20Common%20Interface.pdf CO-LaN Consortium, 2003d, Open Interface Specification: Collection Common Interface, version 2. http://www.colan.org/Spec%2010/Collection%20Common%20Interface.pdf A. P. Jiang, Z. J. Shao, et al., 2006, Simulation and Optimization of Distillation Column Sequence in Large-Scale Ethylene Production. Chem. Ind. Eng. (China), 57, 9, 2128-2134. Y. D. Lang, L. T. Biegler, 2005, The IPOPT Interface to CAPE-OPEN. CAPE-OPEN Update, Vol. 10, available at http://www.colan.org/CO%20Update/IPOPTmain_Vol10.htm T. Lid, S. Skogestad, 2008, Scaled steady state models for effective on-line applications. Computers & Chemical Engineering, 32, 990-999. M. R. Ricardo, G. Rafiqul, et al., 2008, Use of CAPE-OPEN standards in the interoperability between modeling tools (MoT) and process simulators (Simulis Thermodynamics and ProSimPlus). Chemical Engineering Research and Design, 86, 7, 823-833. C. Schmid, 1994, Reduced Hessian Successive Quadratic Programming for Large-Scale Process Optimization, Ph. D. thesis, Carnegie Mellon University. L. Testard, J. P. Belaud, 2005, A CAPE-OPEN based framework for process simulation solution integration. Computer Aided Chemical Engineering, 20, 1, 607-612. A. Yang, B. Braunschweig, et al., 2007, A multi-agent system to facilitate component-based process modeling and design. Computers & Chemical Engineering, 32, 2290-2305.