hysys.rto reference guide - 한국에너지공단kemco.or.kr/up_load/blog/hysys-rto-refguide.pdfi...

Copyright Notice© 2002 Hyprotech Ltd. All rights reserved.

Hyprotech Ltd is the owner of, and have vested in them, the copyright and all other intellectual property rights of a similar nature relating to their software, which includes, but is not limited to, their computer programs, user manuals and all associated documentation, whether in printed or electronic form (the “Software”), which is supplied by us or our subsidiaries to our respective customers. No copying or reproduction of the Software shall be permitted without prior written consent of Hyprotech Ltd., Suite 800, 707 - 8th Avenue SW, Calgary AB, T2P 1H5, Canada, save to the extent permitted by law.

Hyprotech reserves the right to make changes to this document or its associated computer program without obligation to notify any person or organization. Companies, names, and data used in examples herein are fictitious unless otherwise stated.

Hyprotech does not make any representations regarding the use, or the results of use, of the Software, in terms of correctness or otherwise. The entire risk as to the results and performance of the Software is assumed by the user.

HYSYS, HYSYS.RTO, HYSYS Dynamics, HYSYS.Plant, HYSYS.Process, HYSYS.Refinery, HYSYS.Concept, HYSYS OTS Environment, HYSYS.RTO, Economix, HTFS TASC and MUSE, DISTIL, HX-NET, HYPROP III, and HYSIM are registered trademarks of Hyprotech Ltd.

Microsoft Windows, Windows 95/98, Windows NT, Windows 2000, Visual Basic, and Excel are registered trademarks of the Microsoft Corporation.

Documentation CreditsAuthors of the current release, listed in order of historical start on project (2002-1998):

Colleen Kachmarski, BAC; Nana Nguyen, BSc; Conrad Gierer, BASc; Lisa Hugo, BSc, BA; Ian McKay, BSc.

Since software is always a work in progress, any version, while representing a milestone, is nevertheless but a point in a continuum. Those individuals whose contributions created the foundation upon which this work is built have not been forgotten. The current authors would like to thank the previous contributors. A special thanks is also extended by the authors to everyone who contributed through countless hours of proof-reading and testing.

Contacting HyprotechHyprotech can be conveniently accessed via the following:

Web site: www.hyprotech.comInformation and Sales: [email protected]: [email protected]: [email protected] Support: [email protected]

Detailed information on accessing Hyprotech Technical Support can be found in the Technical Support section of the Get Started manual.

http://www.hyprotech.com

mailto:[email protected]




Table of Contents

1 Introducing HYSYS.RTO..............................................1-1

1.1 Welcome to HYSYS.RTO .....................................................1-3

2 Using HYSYS.RTO .......................................................2-1

2.1 Role of the Sub-Flowsheet ...................................................2-3

2.2 Optimization Objects.............................................................2-5

2.3 Collection Utilities .................................................................2-6

2.4 Optimizer Interface ...............................................................2-6

2.5 Data Reconciliation/Parameter Estimation Problem.............2-7

2.6 Optimization Problem ...........................................................2-8

2.7 Creating a Collection Utility...................................................2-9

3 Optimizer .....................................................................3-1

3.1 Optimizer Interface ...............................................................3-3

4 Derivative Utility .........................................................4-1

4.1 HYSYS.RTO Variables - Properties......................................4-3

4.2 HYSYS.RTO Constraints - Properties ..................................4-9

5 ESTIM DRU Overview..................................................5-1

5.1 The Problem .........................................................................5-3

5.2 The Solution..........................................................................5-3

5.3 The Benefits..........................................................................5-4

5.4 ESTIM DRU Facilities ...........................................................5-5

5.5 Using ESTIM DRU................................................................5-6

5.6 Configuring a Fitting Problem .............................................5-10

5.7 Estim Data Set Analysis .....................................................5-19

5.8 Optimization Objects...........................................................5-20

5.9 General Notes.....................................................................5-25

5.10 ESTIM DRU Diagnostic File Output....................................5-26

i

6 Data Reconciliation Utility..........................................6-1

6.1 Heat Exchanger Network Data Reconciliation......................6-3

7 Derivative Utility & Optimizer.....................................7-1

7.1 The Derivative Utility .............................................................7-3

7.2 Optimizer ............................................................................7-12

A HYSYS.RTO+ Example ................................................A-1

A.1 Data Reconciliation Example............................................... A-3

A.2 Install Data Reconciliation Utility.......................................... A-5

Index.............................................................................I-1

ii

Introducing HYSYS.RTO 1-1

1 Introducing HYSYS.RTO

1-1

1.1 Welcome to HYSYS.RTO .................................................................3

1-2

1-2

Introducing HYSYS.RTO 1-3

1.1 Welcome to HYSYS.RTOHYSYS.RTO is a real-time on-line optimization software package that combines the following two proven technologies:

• Rigorous first principal models and thermodynamic methods (from HYSYS).

• Optimization and data reconciliation routines (from RTO).

Optimization within HYSYS is based on a simultaneous modular approach. A flowsheet model is developed as a collection of Sub-flowsheets (SFS or the modular blocks) are connected through streams. Within each SFS are a collection of unit operations and streams that are appropriate to be solved together. During the course of the optimization run, each Sub-flowsheet is solved using one of the standard HYSYS solvers (non-sequential modular or one of the available column solvers).

When the model is being posed to the optimizer, each product stream from one SFS that serves as a feed stream to another SFS is "torn". The act of tearing the stream creates a collection of connection equations which the optimizer solves as part of its calculations. In the case of nested Sub-flowsheets, the tearing occurs at the terminal locations (i.e., between the stream which is calculated as the product of one unit operation, and the stream which feeds the next unit operation). There are no intermediate tears constructed.

Recycle locations in the flowsheet should be defined at the transition across a Sub-flowsheet boundary. This additional transfer basis allows the flowsheet to be initialized correctly, and then have the recycle replaced by connection equations when the model is posed to the optimizer.

Within each of the Sub-flowsheets are a number of decision variables, true process constraints and objective function variables. These are individually selected and configured by the user and are automatically associated with the corresponding block when the problem is posed to the optimizer.

1-3

1-4 Welcome to HYSYS.RTO

Upon configuration of the flowsheet, Derivative Utilities can be attached to the various Sub-flowsheet operations. These utilities allow the tearing of the appropriate streams to be invoked, and the various optimization objects (decision variables, constraints, objective function variables) collected into lists which are then provided to the optimizer.

When the optimizer is invoked, it accesses these lists from each of the utilities to construct its solution matrix. During the course of its solution, the optimizer configures the necessary information from each of the objects to determine aspects such as step size, derivative evaluations etc.

In the simultaneous modular approach, the blocks are treated as a matrix of variables (decision and tear) and constraints (true process constraints and connection equations). The derivatives that the optimizer then sees from any block are of the entire constraints vector with respect to each individual variable within the block. If the block contains variables which are part of the objective function, the gradient is also determined for each of the variables.

During the optimization, values are returned to the flowsheet through the utilities to be evaluated by the models, with the calculated results (tear equation residuals, process constraint values, objective function, etc.) returned to the optimizer. The interaction between the optimizer and the flowsheet continues until the defined solution criteria is met.

1-4

Using HYSYS.RTO 2-1

2 Using HYSYS.RTO

2-1

2.1 Role of the Sub-Flowsheet..............................................................3

2.1.1 Simultaneous Modular Optimization.........................................42.1.2 Implementation in HYSYS.RTO ...............................................42.1.3 Overview ..................................................................................4

2.2 Optimization Objects .......................................................................5

2.3 Collection Utilities............................................................................6

2.4 Optimizer Interface ..........................................................................6

2.5 Data Reconciliation/Parameter Estimation Problem ....................7

2.5.1 General Procedure ...................................................................7

2.6 Optimization Problem......................................................................8

2.6.1 General Procedure ...................................................................82.6.2 Flowsheet Tearing ....................................................................8

2.7 Creating a Collection Utility ............................................................9

2.7.1 Derivative Utility......................................................................112.7.2 Optimization Objects ..............................................................142.7.3 Optimization Object Installation..............................................15

2-2

2-2

Using HYSYS.RTO 2-3

2.1 Role of the Sub-FlowsheetIn the standard HYSYS modeling environment, the sub-flowsheet lets you provide a logical grouping of operations to facilitate understanding of the process behaviour. In addition, it provides the mechanism to encapsulate a solver (i.e., the Column sub-flowsheet) or to use different fluid packages (thermodynamics, component slates, etc.) within a simulation.

For optimization, the sub-flowsheet provides the same benefits plus a number of additional capabilities for the simultaneous modular approach. Foremost, it provides a location where the standard propagation of information can be broken. Once a model is torn for optimization, information does not propagate from one sub-flowsheet to another. This limits calculations to only those needed at a point in time.

Similarly, by selecting the structure of the Sub-flowsheets appropriately, unnecessary equations are never posed to the optimizer. In addition, if derivatives are being generated numerically, the potential for noise in the generated derivatives is minimized by constructing suitably sized Sub-flowsheets.

For operations that deliver analytical derivatives, these must be encapsulated within a single sub-flowsheet. For example, HYSYS columns being solved by the Newton solver are able to deliver the Jacobian matrix to the optimizer directly. Extension unit operations that deliver analytical derivatives are handled in the same manner.

2-3

2-4 Role of the Sub-Flowsheet

2.1.1 Simultaneous Modular OptimizationSimultaneous Modular Optimization (SMO) is a hybrid between Sequential Modular and Open Equation forms of optimization. It uses modular solvers to solve the unit operations themselves, and the Optimizer solver to solve both the Optimization and connection equation problems.

2.1.2 Implementation in HYSYS.RTOIn HYSYS.RTO, the SMO is facilitated by the development of Optimization Objects (which provide a generic interface to flowsheet variables), configuration utilities (Data Reconciliation and Derivative) and flowsheet tearing. The act of tearing the flowsheet blocks the propagation of information across the torn location, creating a set of connections equations which are exposed to the Optimizer for solution as part of the optimization problem.

2.1.3 OverviewFor the HYSYS user, the key pieces to configuring an optimization or data reconciliation problem are:

• Optimization Objects – A generic set of objects used to identify the underlying flowsheet variable and provide the necessary configuration information for use by Optim or Estim.

• Collection Utilities – Utilities used to identify the "pieces" of the flowsheet which are to be exposed to Optim or Estim.

• Optim and Estim parameters – Tolerances and flags.

The mechanics for creating either a Data Reconciliation or Optimization problem are essentially identical. The only differences are as follows:

• Optimization object types being used • Optim or Estim properties• Tolerances and flags being configured • Specific procedures to the type of problem being solved

2-4

Using HYSYS.RTO 2-5

2.2 Optimization ObjectsOptimization objects are the mechanism of identifying the flowsheet variables which are to be considered as part of the problem. The optimization and data reconciliation routines have the ability to set and retrieve flowsheet values as well as the necessary configuration parameters through the optimization object. While there are a number of different optimization object types, they all serve the same basic function.

The primary differences between the optimization objects are the properties they contain, and how Optim or Estim treats them. For flowsheet optimization, there are:

• Optimization Variable – Decision variables for the optimization that must be specified (blue) variables.

• Constraints – True process constraints, bounded variables that are instantiated by the user. These must be calculated (black) variables.

• Objective Function Variables – A variable that is part of the overall objective function. Each variable has its own defining equation, the results of which are combined into a single flowsheet objective function. These must be calculated (black) variables.

For Data Reconciliation and Parameter Estimation, there are:

• DCS Tags – Variables for which you have a set of measurements, which are used to calculate offsets in the measurements and update fitting parameters. These can be either specified or calculated variables.

• Fitting Parameters – Variables whose value is to be directly adjusted to match the supplied data. These must be specified (blue) variables.

There is a third type of Optimization Object used for Data Reconciliation called a DRU Stream (Data Reconciliation Utility Stream). This is essentially a data holder, i.e., it allows for multiple sets of stream data, each corresponding to a different data set, to be supplied by you. These values are taken as supplied, no offsetting is calculated for these streams.

2-5

2-6 Collection Utilities

2.3 Collection Utilities

Derivative and Data Reconciliation UtilityThere are two utilities used by HYSYS.RTO to provide the primary interface between the flowsheet model and the solver:

• Data Reconciliation Utility • Derivative Utility.

Their primary purpose is to collect appropriate optimization objects which are then exposed to the solvers.

These utilities are first "attached" with unit operation(s) within the flowsheet model. Then, based on the types of optimization objects that utility type is interested in, it collects those objects of the correct types which are attached to variables that are related to the targeted unit operations and their corresponding streams.

It is the corresponding lists of "variables" and "constraints" that are exposed to Optim.

2.4 Optimizer InterfaceThe Optimizer interface in HYSYS provides the collection points for the utilities within the flowsheet. Depending on the mode, the Optimizer invokes either Estim (Data Reconciliation and Parameter Fitting) or Optim (Optimization) and provides the necessary interfaces back into the process model.

2-6

Using HYSYS.RTO 2-7

2.5 Data Reconciliation/Parameter Estimation Problem

2.5.1 General Procedure1. Build the flowsheet.

2. Install a Data Reconciliation utility.

3. Select the unit operations from the flowsheet that are associated with the variables to be fit, or for which you have measured the data. The streams that are attached to the unit operations are automatically obtained at the same time.

4. Install Fitting Parameters from the Utility and attach them to the appropriate flowsheet variables to be fit.

5. Supply appropriate values for the Fitting Parameters.

6. Install DCS Tags and attach them to flowsheet variables for which you have measured data.

7. Supply required values for the Tags.

8. Supply the measured data.

9. If necessary, turn on the multiple data set option for attached streams, and supply corresponding data.

10. Set the appropriate Estim properties and tolerances and flags.

11. Invoke the HYSYS Optimizer F5 and turn on Data Reconciliation mode.

12. Identify the utility containing the unit operations and streams being reconciled.

13. Start the data reconciliation.

2-7

2-8 Optimization Problem

2.6 Optimization Problem

2.6.1 General Procedure1. Build the flowsheet.

2. Install a Derivative utility.

3. Select Flowsheet Wide for the Unit Operation.

4. Install Optimization Variables from the utility and attach them to the appropriate flowsheet variables.

5. Supply appropriate values for the Optimization Variables.

6. Install Constraints and attach them to appropriate flowsheet variables.

7. Supply required values for the Constraints.

8. Install the objective function object(s) and attach them to appropriate flowsheet variables.

9. Configure the appropriate prices for the objective function objects.

10. Invoke the Optimizer F5 and select Optimization.

11. Change appropriate Optim properties and tolerances and flags.

12. Start the Optimization.

2.6.2 Flowsheet TearingThere is an additional feature available for optimization which involves Flowsheet Tearing. With this approach, specific streams in the flowsheet are "torn" and appropriate connection equations written. These additional variables and constraints are passed to the Optimizer to be solved as part of the optimization problem. Typically, this approach requires multiple derivative utilities to be constructed.

2-8

Using HYSYS.RTO 2-9

2.7 Creating a Collection UtilityUtilities are created from the FlowSheet Tools Menu Bar, or by using the CTRL U hot key combination. This produces a view containing the available and installed utilities in the flowsheet. Select Derivative Utility (as shown in Figure 2.1) or Data Recon Utility, and click the Add Utility button. This displays the corresponding Utility property view.

Utility Property ViewBoth the Data Reconciliation and Derivative Utility property views contain a number of tabs, that are organized around the optimization object types (variables, constraints, fitting parameters, DCS Tags, etc.).

Both utilities contain a similar section at the top of the view that provides access, on every tab, to the features for unit operation attachment and optimization object creation for the problem. While optimization objects can be created from the flowsheet prior to installing a utility, it is recommended that this be done from this location. Once unit operations are selected, optimization objects that are created, are tested as to whether they are associated with the attached operations and streams.

Figure 2.1

2-9

2-10 Creating a Collection Utility

Immediate feedback is provided when the objects are created and added directly to the lists contained within the utility, and are displayed directly on the property view. Information can either be supplied as objects are added, or at any time prior to running the solver.

The tabs of the Derivative Utility are defined as follows:

Figure 2.2

Tab Description

Structural Non-Zeroes

Assign variable/constraint associations such that a Jacobian element is always assigned to the pair regardless of the Jacobian Tolerance.

Independent Variables

Access the collection of variables (optimization Variables, Connection Equation Variables, and Solution Variables) associated with the utility

Constraints/Objective Function

Access the collection of dependent variables (Constraints, Technical Constraints, Solution Constraints and Objective Function variables) associated with the utility.

Derivative Analysis Access the numerical perturbation mechanism to allow examination of the sparsity pattern and Jacobian values, gradient and model noise which will be generated by the gradient calculations of the solution.

2-10

Using HYSYS.RTO 2-11

2.7.1 Derivative Utility

Configuration GroupAt the top of the Derivative Utility property view is the Derivative Utility Configuration group, which is displayed on every tab. This provides access to the following options:

Figure 2.3

Field Description

Unit Operation Selection Select the unit operation(s) for the given utility.

Add Add variables, constraints and objective function objects.

Master/Run Time Toggle Switch between Master and Run Time lists for display purposes. The Master List is all variables or constraints that are attached to utility. During the set up phase of an optimization problem, each variable and constraint is evaluated for its current parameter settings. Those which do not qualify for the current problem (i.e., the Optimize Flag is false) are not included in the list of variables and constraints exposed to the Optimizer, which is the Run Time list. This button lets you switch between lists (even when the problem is running).

2-11


Unit Operation SelectionThere are three modes for the derivative utility and they are as follows:

It is best to select the desired unit operation prior to installing any of the remaining optimization objects. Part of the procedure for attaching the unit operation to the utility is to obtain all existing optimization objects (of the appropriate type) from the simulation case.

For example, if the Specific Unit Oper radio button is selected, the view displays as shown in the figure below.

Select the target unit operations from the Object column of the view. Note that Sub-flowsheets (i.e., Columns), are to be selected as an Object, not as a Flowsheet. When a Unit Operation is selected, the utility displays all optimization objects currently installed in the simulation case which are associated (attached to) the unit operation(s) and their associated streams.

Mode Selection

Flowsheet Wide

Use when minimal flowsheet tearing is being employed, and no special derivative and solution mechanisms (such as extension operations) are being used. In this mode, a single derivative utility is used for the entire flowsheet.

Specific Unit Operation

Typically this is a sub-flowsheet, which is torn on both the feeds and products. The sub-flowsheet typically contains several unit operations which are solved either using the HYSYS standard solver, or one of the column solvers.

Extension Operation

Used when the sub-flowsheet contains an extension operation which is solved using the available OLE functions to allow the solver to solve the model equations as part of the optimization problem

Figure 2.4

2-12


Object and Property FiltersIn Optim, there are only variables and constraints. However, to assist with the interpretation of the optimization problem, these lists are divided according to the source of the attached variable. On the corresponding tabs of the utility, there are radio buttons which filter the objects into these types.

For the Variables tab, the Independent Properties can be selected by using the following radio buttons:

Figure 2.5

Variable Description

Optimization Variable True decision variables

Tear Variables Variables created by the tearing of a flowsheet stream

Solution Variables Variables created to support an extension operation which is to be solved as part of the optimization problem

2-13


Further filtering is provided to indicate which of the given object properties are as follows:

All of the appropriate optimization object types are displayed on the tab in a worksheet format. In addition to the properties, the view displays the flowsheet object and variable that each optimization object is associated with. Values that can be specified are indicated in blue, while calculated variables are displayed in black.

Unit conversion is provided for each of the appropriate object property combinations.

2.7.2 Optimization ObjectsThe Optimization object types which are used for optimization problems are as follows:

Radio Button Description

Input Required user input.

Output Values output from Optim.

Results Values resulting from the optimization problem.

All Access to all properties. There are a number of internal properties (i.e., Sparse Column), contained inside of the optimization object, but are used as internal values for the solution.

Type Description

Optimization Variable

Decision variables for the optimization that must be specified (blue) variables.

Constraints True process constraints, bounded variables and are instantiated by the user. These must be calculated (black) variables.

Objective Function Variables

A variable which is part of the overall objective function. Each variable has its own defining equation, the results of which are combined into a single flowsheet objective function. These must be calculated (black) variables.

2-14


2.7.3 Optimization Object InstallationOptimization objects appropriate for the utility (in the case of the Derivative utility - Optimization Variables, Constraints and Objective Function variables) can be added directly from the view. Use the drop-down list in the upper right corner of the Derivative Utility Configuration group, to select one of the three options. By selecting the appropriate option and clicking the Add button, the corresponding selection view is displayed:

By making the selection as shown (Flowsheet, Object, Variable and Variable Specifics), the Optimization Variable is created and added to the utilities collection.

Figure 2.6

2-15


By default, the new object is given the next available name. However, you can edit the name of the object directly from the utility view by highlighting the name in the Object Name column and typing a new string, as shown below

Constraints and Objective Function Objects are added in a similar manner. When an object of a given type is added, the utility automatically switches to the appropriate tab and filter type.

Specified Versus Calculated ValuesWhen you install a variable or constraint, you must examine the status of the Current Value property. Variables must display a status of Blue (specifiable), while Constraints must display a status of Black (calculated).

Figure 2.7

2-16


Units and Delta PropertiesAll communication with Optim for property values is conducted in HYSYS internal units. However, you can input your values in any necessary unit set, the conversion is handled internally. There are certain properties (typically span or range type properties) which are handled differently based on the variable type they are attached to (i.e., pressure and temperature). When you input a value for these types of property/variable combinations, the input is converted automatically to Delta; i.e., a Range for a temperature variable of 1 C displays as 1.8 F if the unit set is changed.

The only location where the chosen Units set influences the problem is with respect to the Objective Function object. The default formula for an Objective Function object is variable value X price. The calculations performed for determining the individual contribution of that object to the overall objective function are done in display units. For example, if the objective function object is attached to a LiquidVolumeFlow variable, and the current display units are in Barrels/Day, then the actual display value (1000 bbl/day) is used in determining the contribution to the objective function. You can create a new unit set (Tools/Preferences) for this purpose.

If you store a case and then reload it from disk, you should ensure that the correct units set is being used prior to running the optimization problem.

2-17


Derivative AnalysisThe Derivative Analysis tab of the utility property view provides access to the Jacobian and Gradient calculation mechanism used during the solution. Examine different perturbation sizes and single and two sided gradient calculations to see their impact on the calculated Jacobian and gradient for the variables.

Filtering is provided to allow examination of subsets of the overall variable and constraint lists. In addition, examine the model noise to determine if tighter solution tolerances on the individual unit operations (i.e., Columns) are necessary. Typically, a tighter solution tolerance requires more individual calculations at any phase, but improves the quality of the Jacobian being returned to Optim and reduces the time of the overall problem solution.

When the calculations are complete, examine both the individual Jacobian elements, or the Gradient, as well as the noise of the model. While the default solution tolerances for unit operations is valid for modelling purposes, experience shows that a tighter tolerance is more appropriate for Jacobian evaluations (where small changes are being

Figure 2.8

2-18


applied to determine the direction).

This is the original absolute model noise (comparison of the original value of the constraint, to the calculated value when the variable is returned to its starting value), while the screen below shows the values when a tighter tolerance is used in the calculations.

In addition to examining the affects of the perturbation size, gradient types, etc., on the calculated Jacobian and Gradient, you can also use the Derivative Analysis tab to determine the size of the Ranges best suited for the optimization problem. The size of the perturbation which applied to the variable is determined by the Range x the perturbation.

The Range is different from the span (which is used by the Optimizer in the Jacobian normalization, and is calculated as the Maximum - the Minimum).

If you have not supplied a value for the Range, the Span is used in determining the size of the perturbation. The reason for providing the span is that it allows for better control over the perturbation which is being applied to the given variable, i.e., large enough to generate a

Figure 2.9

Figure 2.10

2-19


sensical response, without impacting the conditioning of the optimization problem (i.e., a desired very small range to work with on the variable itself).

2-20

Optimizer 3-1

3 Optimizer

3-1

3.1 Optimizer Interface ..........................................................................3

3.1.1 Calculations............................................................................233.1.2 Results ...................................................................................23

3-2

3-2

Optimizer 3-3

3.1 Optimizer Interface While the derivative utilities are used for collecting and configuring the individual optimization objects for the problem, the Optimizer collects all of the utilities and exposes the combined list of variables and constraints to Optim. In addition, this is where you set the tolerances, flags and settings for the Optimization problem in its entirety. The Optimizer is accessed by pressing the F5 key.

The radio button selection provided along the bottom of the view provides access to the available options:

• Default – the existing HYSYS Optimizer• Optimization – access to Optimization (Optim)• Data Recon – access to Data Reconciliation (Estim)• Model – used specifically for Real Time applications

Figure 3.1

3-3

3-4 Optimizer Interface

Depending on the radio button selected, additional tabs are displayed on the view. A number of tabs (Testing, Properties, Transfer and Object Transfer) relate solely to the Real Time interfaces and should not be used. All of the necessary configuration for the Optimization Problem can be accessed through the Optim Configuration tab.

There are three pieces of the Configuration:

• SetUp – Identifying the optimization algorithm to be used, type of perturbations, level of diagnostics, etc.

• Tolerances – Access to the various solution tolerances and Optim parameters.

• Flags – Access to the various Optim configuration options which are Booleans.

Optim Configuration Set Up Inputs (Set Up Radio Button)These inputs consist of the following Optimizer properties:

AlgorithmThe algorithm used by the Optimizer, is one of the following:

• SS_LP – single-shot linear programming algorithm.• MDC_SLP – sequential linear programming algorithm.• MDC_SQP – two-phase sequential quadratic programming

algorithm with large-scale sparse matrix handling features.• NAG_SQP – single-phase sequential quadratic programming

algorithm.

Suggested Default: MDC_SQP

3-4

Optimizer 3-5

LP OptionsUsed to select the options to be used with the SS_LP algorithm. Select one of the following:

• None – No option.• Initialize – A single run of the linear programming algorithm is

conducted, and the Objective Value property of the Optimizer is reset to 0.0.

• Intercepts – The Optimizer Fix Variable Spans flag is switched on prior to carrying out the SS_LP optimization.

• Gradients – The Optimizer constraint and objective function gradients are re-evaluated prior to carrying out the SS_LP optimization. Otherwise, the gradients used during the SS_LP optimization are those found at the previous point.

Gradient CalculationsThis option specifies if one-sided or two-sided gradient calculations are used:

• 1-sided – Causes forward differences to be used when constructing gradient approximations.

• 2-sided – Causes central differences to be used. This option requires twice as many function evaluations at a given solution, but may provide a more accurate estimate of the constraint and objective gradients, particularly for highly non-linear problems, or problems featuring large amounts of noise.

In both cases, the perturbation size used for the Optimizer internal variables is given by the Optimizer Perturbation property.

Suggested Default: 1-sided

The SS_LP algorithm is not included in the current version.

3-5


Diagnostic Print LevelSelect one of the following options:

• None – No Optimizer diagnostic file is produced.• Partial_1, Partial_2, or Partial_3 – Increasing levels of Optimizer

output in the diagnostic file.• Full – The maximum amount of useful information in the Optimizer

diagnostic file.• Excessive – Only used for debugging the Optimizer.

Suggested Default: Partial_2

Max. IterationsThis parameter fulfils the following two roles:

• When Algorithm is set to MDC_SQP / MDC_SLP, this parameter gives the maximum number of Optimizer iterations allowed to improve an already feasible solution.

• When Algorithm is set to NAG_SQP, this parameter gives the maximum number of major iterations. A major iteration in this case consists of a sequence of minor iterations which minimize a linearly constrained subproblem.

Suggested Default: 50

Max. Feasible PointThis parameter also fulfils two roles:

• When Algorithm is set to MDC_SQP / MDC_SLP, this parameter gives the maximum number of Optimizer iterations allowed to find the first feasible solution.

• When Algorithm is set to NAG_SQP, this parameter gives the maximum number of minor iterations. A minor iteration in this case represents a sequence of local improvements to the linearized problem within a major iteration.


3-6

Optimizer 3-7

-7
3
Max. Constraint RelaxationsThis parameter relates to the Relax Violated Constraints flag. This flag is used to drive the Optimizer constraint bounds to their extreme values allowed by the Optimizer tolerances. This is done to help the feasible point search part of the MDC_SQP algorithm find the first feasible solution. The Max. Constraint Relaxations parameter gives a limit for the number of times this can occur.


Max. Hessian ResetsThe MDC_SQP algorithm operates using an approximation to the matrix of second derivatives of the objective function. On some problems, it is necessary to reset this approximation to the diagonal matrix arising from the FPS Hessian Diagonal parameter (during the FPS search) or to the diagonal matrix arising from the OPT Hessian Diagonal parameter (during the OPT search). The Max. Hessian Resets parameter gives a limit on the number of times this can be done.

This is useful if the algorithm suffers from step convergence meaning it is not used when the algorithm converges according to other criteria.


VerifyIn the NAG_SQP algorithm, you can carry out numerical checking on gradient elements. Setting Verify to -1 switches off this checking. The extent of the numerical checking conducted by the NAG_SQP algorithm depends on the setting for Verify. Refer to the following table:

Suggested Default: -1

Value Description

0 Results in a check on the gradients at the first feasible point.

1 Results in a check of the Optimizer objective gradients

2 Results in a check on the Optimizer constraint gradients

3 Checks both types of gradient. The checking takes place at the start of the optimization.


DV_LevelUsed to specify which gradients should be estimated by the NAG_SQP algorithm. Refer to the following table:

This parameter is only to be used for debugging the Optimizer.


Objective ValueThis displays the current plant model objective function value as calculated by the Optimizer.

Termination ReasonAn output from the optimization run, which is one of the following:

• OK – Used by the FPS to indicate a feasible termination of this phase.

• Impossible – This output signifies either a non-implemented Optimizer algorithm is selected, or the algorithms could not find a solution to the linearized problem. In this case, the problem constraint/variable bounds and feasibility tolerance parameters should be checked.

• No variables – The number of variables in the problem is zero.• Step convergence – During the Optimizer OPT phase of

MDC_SQP, the stepping back procedure has resulted in a step collapse to below the Step solution tolerance.

• Cost convergence – During the Optimizer OPT phase of MDC_SQP, two successive objective function values have returned a difference in cost less than the Cost solution tolerance. Note that only feasible points are considered for this test.

• Flat – A special case of cost convergence in which the objective function gradient is zero. Usually indicates an incorrectly defined (or scaled) objective function.

Value Description

0 Both missing constraint gradients and missing objective gradients are estimated.

1 Missing constraint gradients are estimated

2 Missing objective gradients are estimated.

3 No action is taken.

3-8

Optimizer 3-9

• Gradient convergence – Occurs when the gradient of the Lagrangian function for the given optimization problem is less than the Gradient solution tolerance.

• Globally infeasible – This occurs when the feasible region cannot be seen from the FPS starting point (i.e., even the linearization of the problem does not yield a feasible solution).

• The MDC_SQP Optimizer expands the variable local bounds (the Minimum and Maximum properties of the variables) out to the global bounds (the Global Minimum and Global Maximum properties of the variables) to attempt to solve the linearized problem with these bounds. If this still yields no solution, the FPS phase conducts a sequence of steps aimed at minimizing the constraint violations.

• An objective function is constructed which contains the sum of the constraint violations, and this function is minimized, producing a feasible solution to the problem (if one exists).

• Infeasible – In the FPS phase of the optimization, if a step collapse takes place while looking for a feasible point, then the problem is considered to be infeasible due to this. This is not the same as Globally infeasible.

• Unbounded – This occurs when the objective function is unbounded below (or is badly scaled), i.e., can be reduced without limit. This usually indicates incorrectly set constraint and/or variable bounds.

• Time out (feasible) – This report is generated by the OPT phase of the MDC_SQP Optimizer, when the number of Optimizer iterations during the OPT phase exceeds the Optimizer Max. Iterations parameter.

• Time out (infeasible) – This report is similar to the Time out (feasible) report, except occurs during the FPS phase, when the number of iterations exceeds the Max. Feasible Point parameter.

• Not converged – A report solely from the NAG_SQP algorithm.• Not run – Set during the Optimizer initialisation phase. This is

reported in the Optimizer screen while the Optimizer is initializing.• Stopped – Occurs when the you stop the Optimizer using the

control box on the Optimizer screen (beside the spreadsheet button).

Actual OptimizerThis is output from the Optimizer. It gives the number of iterations the Optimizer has conducted after finding the first feasible solution, when the MDC_SQP/SLP algorithms are used. When the NAG_SQP algorithm is used, this returns the number of major iterations used.

3-9


Feasible Point IterationsThis is output from the Optimizer. It gives the number of iterations the Optimizer has conducted in order to find the first feasible solution, again when the MDC_SQP/SLP algorithms are used. When NAG_SQP is used, this returns the number of minor iterations from the last major iteration (in this case the usefulness of this parameter is limited).

Solution PhaseThis is output from the Optimizer. It describes the current phase of the Optimizer search, which is one of:

• Initialize – A report that the Optimizer is initializing the diagnostics file, and preparing to carry out the FPS search.

• Results – Reported when the Optimizer is writing the final solution to the diagnostics file and completing any post-optimization calculations.

• Setup – The Optimizer variables and constraints are being inspected and set-up internally by the Optimizer using the user-supplied data.

• FPS – The beginning of the FPS phase of the Optimizer.• FPS Deriv – The Optimizer is calculating the gradients of the

constraints and objective function during the FPS phase. This occurs every time the Optimizer adjusts the current solution to improve the feasibility of the current point.

• FPS Visible – The Optimizer has successfully solved the linearized problem during the FPS phase.

• FPS Invisible – The linearized problem at the current solution in the FPS phase cannot be solved.

• FPS Shrink – The Optimizer is stepping back during the FPS phase. This occurs when the projected point in the FPS is less feasible than the current point, and so the projected point is adjusted.

• Optim – The Optimizer is preparing to enter the FPS phase.• OPT Deriv – The Optimizer is calculating the constraint and

objective function gradients during the OPT phase.• OPT Search – The Optimizer has successfully found a new,

improved solution which remains feasible, and has moved the current solution to this point.

• OPT Shrink – The Optimizer is stepping back in the OPT phase. This occurs if either the projected solution is infeasible, or the objective function has increased.

3-10

Optimizer 3-11

Gradient EvaluationsThis reports the number of gradient (constraint and objective function) evaluations during the course of the optimization. At present, this gives the correct number only when the Numerical Gradients flag is checked.

Model EvaluationsThis reports the number of plant model evaluations during the course of the optimization. At present, this gives the correct number only when the Numerical Gradients flag is checked.

Code VersionThe current version of the Optimizer.

Total CPU TimeThis reports the total time taken during both phases of the Optimization, in minutes and seconds.

Start ObjectiveThis gives the plant model cost function value at the starting point, before carrying out any optimization.

3-11


Optim Configuration Tolerance Inputs (Tolerance Radio Button)This section contains the tolerances to be used for generating approximations to the objective and constraint functions, controlling the path taken to Optimizer feasible/optimal solutions, and for determining whether an optimum point has been reached:

SigmaThis tolerance is not currently used.

Linesearch ToleranceThis is used by the NAG_SQP algorithm to control the accuracy of the linesearch phase.

Suggested Default: 0.8

Function PrecisionGives the precision to which functions are to be evaluated by the NAG_SQP algorithm. Used when constructing default Optimizer control parameters.

Suggested Default: 10-8

3-12

Optimizer 3-13

Optimality ToleranceGives the accuracy with which the linearized problem is solved by the MDC_SQP algorithm. This parameter is a tolerance below which any changes to the cost function of the linearized problem are considered to have caused cost convergence when solving the linearized problem.

Suggested Default: 1.e-8

Row ToleranceA tolerance used with the NAG_SQP algorithm which gives the feasibility tolerance within which linear constraints are to be satisfied. If a linear constraint violates a bound by a value not greater than the Row Tolerance (in absolute terms) the constraint is considered to be feasible by NAG_SQP.

In the current version of the Optimizer all constraints are considered to be non-linear, and so this property is not used.

Nonlinear Row Tolerance.As for Row Tolerance, except this applies to constraints defined as non-linear.


StepThe step convergence limit used in the MDC_SQP algorithm. If the algorithm at any point makes a step which is less than the Step tolerance, the algorithm is considered to have converged on step.


3-13


GradientThe tolerance which is the maximum value of the Lagrangian function gradient for which the MDC_SQP algorithm is considered to have converged on Lagrangian gradient. A value of 0.0 forces convergence of either the Step or Cost kind.


CostThis is the maximum magnitude of change in scaled objective function between Optimizer steps for which the Optimizer is considered to have converged on cost.


ZetaThe tolerance which is used in conjunction with the constraint Scale properties to define the feasibility tolerance for constraints in the MDC_SQP algorithm. The feasibility tolerance for an individual constraint is Zeta * Scale, for the given constraint. A value of 1.0 means that the feasibility of the individual constraints is controlled uniquely through the individual constraint Scale property.


BindA tolerance used with the NAG_SQP algorithm and in the solution of the linearized problem in the MDC_SQP algorithm. This tolerance gives a value which is the maximum absolute difference between a constraint and one of its bounds below which the constraint is considered to be binding (active) in the linearized problem.

In general, the solution of the linearized problem satisfies the constraint Minimum and Maximum property bounds, whereas the solution of the true non-linear problem satisfies the bounds (Minimum - Zeta * Scale,

3-14

Optimizer 3-15

Maximum + Zeta * Scale) for the given constraint. In this way, by enforcing tighter bounds in the linearization, there is a greater likelihood of the problem remaining feasible when the non-linearities are re-introduced.


PerturbationThe change in the scaled variables during gradient evaluation. An individual variable in the Optimizer is scaled according to the variable Minimum property, and the variable Span property (or the Range property if the Optimizer Fix Variable Spans property is checked).

In general, the Optimizer scales the problem variables v to produce a set of internal scaled variables x, according to the formula.

Where min is the variable Minimum property, and S is the variable Range property if the Optimizer Fix Variable Spans flag property is checked (the variable Span property otherwise). This allows equal magnitude gradients to be produced for all internal variables x, regardless of the magnitude of the external (model) variables v, by suitable choice of the variable Range properties.

The perturbation which is applied to the external variables v is therefore , where is the Optimizer Perturbation property.


Max. Iteration StepCalculated by the Optimizer, this gives the current maximum step under consideration for projecting the current point to the new point. The size of this parameter is based on the current history of the optimization run.

(3.1)xj

vj min–

S-------------------=

S δ× δ

3-15


Base Search StepThe upper limit for Max. Iteration Step. When the Optimizer finds a sequence of good linear approximations to the constraints and simultaneously improves the objective function, the Max. Iteration Step can be reset to the Base Search Step.


Max. Allowed MoveThis parameter gives the maximum allowable change in a scaled (internal Optimizer) variable over the entire course of an optimization run. A value of 1.0 indicates a 100% change in the variable.


FPS Hessian DiagonalThese give the starting values of the diagonal elements of the approximated Hessian matrices before the FPS phase of the Optimizer, of the MDC SQP algorithm.


OPT Hessian DiagonalThese give the starting values of the diagonal elements of the approximated Hessian matrices before the FPS and OPT phases of the Optimizer respectively, of the MDC SQP algorithm.


3-16

Optimizer 3-17

Jacobian EliminationThe value below which entries in the Jacobian matrix are deemed to be pure model noise, and are set to zero (or when the Optimizer Sparse Jacobian flag is checked, are excluded from the Jacobian sparsity pattern and hence never re-evaluated in future).


Max. CPU UsageThis parameter is not currently used.

Objective Scale FactorThis is used for scaling the objective function (and its gradient). The given function is divided by the Objective Scale Factor.


Major Damping ParameterUsed in the NAG_SQP algorithm to restrict the effects of major iteration variable moves of the scaled variables and the Lagrange multipliers. A value of 2.0 restricts the variable move to 200%.


Minor Damping ParameterUsed in NAG_SQP to restrict the effects of minor iteration variable moves. As Major Damping Parameter.


3-17


Penalty ParameterThis is used solely in the NAG_SQP algorithm. It is used for forcing convergence of the linearized constraints solved in each NAG_SQP minor iteration to their non-linear versions which are actually evaluated in the major iterations. The larger the Penalty Parameter the slower the algorithm converges upon a feasible solution, however, this may be necessary for highly non-linear constraints.


Scaling TypeThe scaling algorithm to be used by the NAG_SQP algorithm. When set to 0, no scaling is done. Otherwise the NAG_SQP algorithm attempts to scale the Jacobian matrix in order to make the matrix coefficients as close to 1 as possible. To scale the rows only, the parameter should be set to 1. To scale the rows and columns, the parameter should be set to 2.


Flow Field / Gradient EvaluationNot used.

3-18

Optimizer 3-19

19
3-
Optim Configuration Flag Inputs (Flag Radio Button)This section contains the Optimizer properties used for controlling the nature of the Optimizer search, for specify methods for handling the constraints, for initializing and terminating the Optimizer, and for specifying the nature of the gradient calculations.

Omit Tech. ConstraintsIndicates whether the technical constraints (specifications) are to be omitted entirely from the constraint residuals when searching for a feasible point. Technical constraints are used to obtain a valid model solution, e.g. pressure drop or mass balance residuals. Process constraints relate to the actual process being modelled, e.g. vessel pressure or unit throughput limits.

Suggested Default: unchecked

Relax Violated ConstraintsIf the MDC_SQP algorithm cannot find a feasible point, one method of proceeding is to relax the constraints. This property is therefore a flag indicating whether all of the constraints (unchecked) or only those which are currently violated (checked) are to be relaxed, during constraint relaxation. The maximum number of relaxation steps is given by the Max. Constraint Relaxations parameter.

Relaxing the violated constraints within the context of the MDC_SQP algorithm means the constraint bounds in the linearized problem (usually set to the constraint Minimum and Maximum properties) are expanded out to the bounds (Minimum - Zeta * Scale, Maximum + Zeta * Scale) for the given constraint.

Thus, under normal circumstances the linearized problem is solved to a much higher tolerance level than the true non-linear problem (which improves the chances of the current solution remaining feasible upon introducing the non-linearities back into the problem). However, when the Optimizer relaxes the violated constraints, both problems are solved to the same tolerance (the capacity of the solution of the linearized problem to satisfy the non-linearities is therefore much reduced).



RecentreThis is checked for testing purposes, in which case the Optimizer reflects the effects created by an on-line Optimizer. The Optimizer variable soft limits (the Minimum and Maximum properties) are re-calculated so that at the start of optimization, the current value of the variable lies mid-way between the soft limits, while ensuring that the soft limits do not fall out of range of the global limits.


Restricted StepUsed to indicate to MDC_SQP that the Max. Allowed Move parameter is to be used to limit the overall change in the Optimizer variables brought about during optimization. When this flag is checked, the optimization algorithm reduces the upper bound of each optimization variable by the Max. Allowed Move parameter, and increases the lower bound by the same amount.


Include Fixed ConstraintsIf this is checked then Optimizer variables that have their Optimize Flag property checked are nevertheless included in the optimization. This acts on every variable, and its Optimize flag property is checked. Otherwise, such variables remain with fixed values during the optimization.


NAG Calculated GradientsIf this flag is checked when the NAG_SQP algorithm is being used, then the NAG_SQP algorithm itself carries out numerical calculation of any gradient elements needed.


3-20

Optimizer 3-21

Fix Variable SpansThis flag indicates whether the Span (i.e. Maximum - Minimum) of the Optimizer variables is to be calculated and stored, or taken directly from the stream Range property (which is user-specified for each variable).


Sparse JacobianChecked when the user wants the Optimizer to calculate the Jacobian matrix of constraint gradients in sparse form (by storing only the nonzero elements, which usually indicates constraint-variable functional dependence). This is done once, at the start of the optimization, and establishes which Jacobian elements are stored for the rest of the optimization (the sparsity pattern).


Numerical GradientsUsed to indicate to the Optimizer the origin of the gradient elements for the constraints and objective function.

• If the flag is checked, the Optimizer carries out numerical calculation of the gradients by direct perturbation of variables using the method specified in the Gradient Calculation flag.

• If it is unchecked, the Optimizer obtains the gradient elements from HYSYS.RTO using the same method. The main difference is that in the latter case certain gradient elements may be computed analytically, and are therefore potentially more accurate.


Include ScalesWhether the constraint Scale properties are to be included when normalizing the Jacobian matrix of constraint gradients and calculating the bounds for the linearized subproblems in the MDC_SQP algorithm.


3-21


Adjust ScalingNot used.

Pert_ResetUsed at the start of optimization to indicate that the gradient calculation process removes noise elements (checked) or not (unchecked).

When calculating the gradient functions by perturbing Optimizer variables, model noise is introduced into the gradient elements, which can mislead the Optimizer. When perturbing variable vj, if it does not affect constraint ci, the corresponding noise can be removed from the gradients by recalculating the constraint functions after removing the perturbation from the variable.

This recalculation is done once for each variable, (i.e., for the first gradient calculation) and is used for establishing the sparsity pattern of the Jacobian matrix. The sparsity pattern is stored for use during the rest of the optimization, if the Sparse Jacobian property flag of the Optimizer is checked.

The advantages of this method are as follows:

• Removes noise terms which can mislead the Optimizer.• Does not need the Jacobian Elimination tolerance parameter, which

may be difficult to set.• Is required once only (the efficient sparse storage of the Jacobian

eliminates this kind of noise from all future Optimizer steps).

The disadvantages are as follows:

• For certain models it may take much more CPU time to carry out the extra plant model evaluations, compared with the use of the Jacobian Elimination tolerance method.

• The presence of structural zeros in the Jacobian matrix are ignored. A structural zero is a forced presence of a Jacobian element, which, during first pass evaluation of the Jacobian, is zero and therefore could be excluded from the sparsity pattern.

This flag should be checked along with the Sparse Jacobian flag, since it takes advantage of the removal of model noise in terms of future computation of gradients and their storage. However, it is still possible to use this method with a dense Jacobian matrix (where all zero elements are retained during optimization).

3-22

Optimizer 3-23


If empty or invalid values are entered, the Optimizer uses a set of in-built default values.

3.1.1 CalculationsThe Optimizer controls the running of the continuous optimization algorithms. A description of the techniques used is given in the Continuous Optimizer Overview.

3.1.2 ResultsThe results produced at the end of the optimization run are as follows:

• A price for the current model data• Values of the Optimizer constraints and variables• Shadow prices for the constraints and variables, if they exist• A termination reason• A feasibility flag for the model data at termination of the Optimizer• Iterations taken• CPU time taken

3-23


3-24

Derivative Utility 4-1

4 Derivative Utility

4-1

4.1 HYSYS.RTO Variables - Properties.................................................3

4.1.1 Inputs: Object Object Name - Range .......................................44.1.2 Inputs: Global Minimum - Price ................................................64.1.3 Inputs: Sparse Column - Jac Num ...........................................74.1.4 Calculations..............................................................................8

4.2 HYSYS.RTO Constraints - Properties ............................................9

4.2.1 Inputs: Object Name - Maximum............................................104.2.2 Inputs: Scale - Sparse Row....................................................114.2.3 Inputs: Current – Bias1...........................................................134.2.4 Calculations............................................................................14

4-2

4-2


4.1 HYSYS.RTO Variables - Properties

The Variables in a HYSYS.RTO optimization problem are held in a Derivative Utility. This is used for holding all of the data used for defining the HYSYS.RTO Optimizer constraints and variables.

For detailed information on the Optimizer properties, see the Optimizer Properties document[3].

• The Optimizer contains a number of properties used for specifying and controlling an optimization problem for a given HYSYS.RTO case.

• The Optimizer is also associated with a Derivative Utility which contains, a list of Independent Properties and Dependent Properties. The Independent Properties are the variables in the plant model that are changed to satisfy the Dependent Properties (the constraints on the plant model) simultaneously minimizing the plant model cost function.

Figure 4.1

4-3

4-4 HYSYS.RTO Variables - Properties

This document has the following styles:

• All properties of the Optimizer/Variables/Constraints are shown in italic.

• Important notes are shown in bold.

4.1.1 Inputs: Object Object Name - RangeThe Independent Properties have a number of inputs and they are described following the figure below:

The Independent Properties inputs are as follows:

• Object Name – The name of the HYSYS.RTO object which is used as optimizer variable.

• Attached Object – The object (e.g., Stream or Unit Op, etc.) that is attached or associated with the listed variable.

• Attached Property – The property relating to the Attached Object and variable.

• Start Value – The starting value for the property of the Object Name in the plant model.

Figure 4.2

4-4


• Status – The current status of the variable, which is calculated by the Optimizer. Unlike constraints, variables are not allowed to move out of their bounds. The Status property is set to one of:• Not Evaluated – The status of the variable is not evaluated by

the Optimizer.• Inactive – The variable Output property lies between the Minimum

and Maximum properties, but not on one of the bounds. • Equality – The maximum and minimum properties of the variable,

Minimum and Maximum, are equal, and the Output property has the same value as well.

• Active Low – The variable Output property value is equal to that of the Minimum.

• Active High – The variable Output property value is equal to that of the Maximum.

• Current Value – The current value for the property of the Object Name in the plant model.

• Optimize Flag – Determines if the variable is to be used in the optimization process. If this flag is not set, no attempt is made by the Optimizer to include this variable into optimization process.

• Minimum – The lower bound property for the variable during the optimization process. This value might be different from its global minimum, if the change in the variable is restricted to its allowed amount, set by the maximum rate of change, during the period in the optimization process.

• Maximum – The upper bound property for the variable during the optimization process. This value might be different from its global maximum, if the change in the variable is restricted to its allowed amount, set by the maximum rate of change, during the period in the optimization process.

• Range – A user-specified alternative for the span. The purpose of the range is to scale the gradients of the cost function and constraints, to give similar gradient magnitudes for each variable. The gradients of the objective function (and constraints) vary inversely with the variable ranges.

4-5


4.1.2 Inputs: Global Minimum - Price

• Global Minimum – Represents the absolute minimum value for which the variable is operated. This value is user-specified.

• Global Maximum – Represents the absolute maximum value for which the variable is operated. This value is also user-specified.

• Span – The difference between the Global Minimum and Global Maximum values for the variable and is calculated by the variable set-up. The role of the span is to convert every variable into the range (0, 1), to use uniform numerical perturbations and convergence tests.

• Output – It is the current value of the variable in the plant model. The output value is determined by the optimizer during the optimization process.

• Price – The shadow price (Lagrange multiplier) for the given variable, calculated by the Optimizer. The shadow price is used to estimate the effect which small changes to variable bounds have on the plant cost function.

Figure 4.3

4-6


4.1.3 Inputs: Sparse Column - Jac Num

• Sparse Column – The column occupied by the given variable in the Jacobian matrix. Unused variables are given a sparse column of 0.

• Old Var Value – This is the cached value of variable prior to perturbation, during gradient calculation.

• Delta Var – The change in variable after perturbation, during gradient evaluation.

• Gradient – • Tear Variable – • Jac Offset – The Jacobian Offset.• Jac Num – The Jacobian Number.

Figure 4.4

4-7


4.1.4 CalculationsThe following properties are set by the user before an optimization run:

• Global Minimum• Global Maximum• Range• Start value• Sparse Column

The following properties are Initialized by the HYSYS.RTO model before an optimization run:

• Minimum• Maximum• Span

The following properties are updated by the HYSYS.RTO model during an optimization run:

• Old Var Val• Delta Var

The following properties are updated by the Optimizer during and after an optimization run:

• Status• Price• Output

4-8


4.2 HYSYS.RTO Constraints - Properties

The constraints in a HYSYS.RTO optimization problem are held in a Derivative Utility and are used for holding all data used for defining the HYSYS.RTO Optimizer constraints and variables. For details about the Optimizer properties, see the Optimizer Properties document[3].

The Optimizer contains a number of properties used for specifying and controlling an optimization problem for a given HYSYS.RTO case. It is associated with a Derivative Utility that contains a list of Independent Properties and Dependent Properties. The Independent Properties are the variables in the plant model that are changed to satisfy the Dependent Properties (the constraints on the plant model) simultaneously minimizing the plant model cost function.

Properties of the Optimizer/Variables/Constraints are shown in italic and important notes are bold.

Figure 4.5

4-9

4-10 HYSYS.RTO Constraints - Properties

4.2.1 Inputs: Object Name - Maximum

The Dependent Properties have a number of inputs and they are as follows:

• Object Name – The name of the HYSYS.RTO object to be constrained.

• Attached Object – The object (e.g. Stream or Unit Op, etc.) that is attached or associated with the listed variable.

• Property – The property related to the Attached Object and variable.

• Current Value – The current value for the property of the object Name.

• Use Flag – Determines whether the constraint is to be used in the optimization. If this flag is not set, no attempt is made by the Optimizer to satisfy this constraint.

• Minimum – The lower bound for the constraint, which is user-specified.

• Maximum – The upper bound for the constraint, which is also user-specified.

Figure 4.6

4-10


4.2.2 Inputs: Scale - Sparse Row

• Scale – A user-supplied number that gives the scale on which the feasibility of the constraint is measured. This property is used in conjunction with the Optimizer Zeta property, which is a relative feasibility tolerance. In general, a constraint is said to be feasible if:

• Where Minimum and Maximum are the lower and upper bound properties respectively, of the constraint, and Current is its current value (equivalent to Hooked Property for constraints which have the Use Flag checked).

• Minimum Chi Square – Determines whether or not a chi-square test is done for the constraint.

Figure 4.7

Minimum Scale Zeta×– Current Maximum Scale Zeta×+≤ ≤

4-11


• Status – The current status of the constraint, which is calculated by the Optimizer. The Status property is set to one of:• Not Evaluated – The status of the constraint has not been evaluated

by the Optimizer. • Inactive – The constraint Current property lies between the

Minimum and Maximum properties, but is neither Active High nor Active Low.

• Violated Low – The constraint Current property is less than Minimum - Scale x Zeta, where Scale is the constraint Scale property and Zeta is the Optimizer Zeta tolerance property.

• Violated High – The Current property is greater than Maximum + Scale x Zeta.

• Active Low – The constraint Current property is less than Minimum + Scale x Zeta, but greater than Minimum - Scale x Zeta.

• Active High – The constraint Current property is greater than Maximum - Scale x Zeta, but less than Maximum + Scale x Zeta.

• Normalization – When the Jacobian matrix is first calculated (first pass evaluation) the Normalization property for the constraint is set to be the largest Jacobian entry in the row ( Sparse Row ) of the Jacobian matrix corresponding to this constraint. This number is used to normalize the rest of the given Jacobian row, for all remaining Optimizer search steps (i.e., is not recalculated).

• Base Value – When calculating the gradient of a given constraint with respect to each variable, the internal scaled variable is perturbed away from the current point by adding the number specified in the Optimizer Perturbation property. The new value of the constraint is found corresponding to the new variable value, and the change in constraint, divided by the change in the variable, is the corresponding Jacobian element.

• The constraint Base property stores the pre-perturbation value of the constraint. Under certain circumstances, however, the Base property itself can change during the Jacobian calculation. This is due to the fact that removing a perturbation from a perturbed variable, and re-running the plant model, will not reproduce the previous Base property within the constraint Current property; this is due to noise in the model arising from non-zero convergence tolerances (i.e., the de-perturbed constraint Current differs slightly from the pre-perturbed Current).

• Therefore, under certain circumstances (when the Pert_Reset flag property of the Optimizer is checked) the Optimizer will remove the perturbation from the variable, re-run the plant model, and then re-set the Base property of the constraint to match the re-calculated Current property. This eliminates associated noise from the Jacobian matrix. This method is discussed in more detail in the Optimizer Properties document[3], in the Pert_Reset section.

4-12


• Price – The shadow price (Lagrange multiplier) for the given constraint, calculated by the Optimizer. If a feasible solution is found by the Optimizer, then a simple interpretation of the Lagrange multiplier is that it gives the gradient of the cost function along the corresponding constraint normal. Thus, the shadow price indicates the approximate change to the objective function when increasing (i.e., relaxing) the given active bound by a unit amount.

• Hard Constraint – A user-specified flag that indicates whether the constraint is a technical one, i.e., is a process specification such as a mass balance or a temperature, as opposed to purely an economic constraint.

• Off Flag – A user-specified flag that indicates whether the constraint is in the 'off' state, or not. This is often used when related items of equipment are being constrained, which themselves have an on-off behaviour.

• Sparse Row – The number of the row in the Jacobian matrix which is occupied by the given constraint.

4.2.3 Inputs: Current – Bias1

• Current – The current value the constraint possesses in the plant model.

Figure 4.8

4-13


• Old Cons Value – The value of the constraint prior to perturbation of a variable, during gradient calculation.

• Bias1• Delta Cons – The change in constraint after perturbing a variable,

during gradient evaluation.

4.2.4 CalculationsThe following properties are updated by the HYSYS.RTO model during an optimization run:

• Base Value• Old Cons Val

The following properties are updated by the Optimizer during and after an optimization run:

• Status• Normalization• Price• Sparse Row• Current

4-14

ESTIM DRU Overview 5-1

5 ESTIM DRU Overview

5.1 The Problem .....................................................................................3

5.2 The Solution .....................................................................................3

5.3 The Benefits .....................................................................................4

5.4 ESTIM DRU Facilities .......................................................................5

5.4.1 Error Detection/Correction........................................................55.4.2 Model Updating ........................................................................55.4.3 Utilities......................................................................................5

5.5 Using ESTIM DRU ............................................................................6

5.5.1 Measurement Problem .............................................................65.5.2 Basic Methods..........................................................................7

5.6 Configuring a Fitting Problem ......................................................10

5.6.1 Configuration Tab ...................................................................115.6.2 Results Tab.............................................................................145.6.3 Stream Initialization Tab .........................................................165.6.4 Parameter Fit Tab ...................................................................175.6.5 DCS Tags Tab ........................................................................18

5.7 Estim Data Set Analysis ................................................................19

5.8 Optimization Objects .....................................................................20

5.8.1 Connection Tab ......................................................................215.8.2 Properties Tab ........................................................................225.8.3 Transfer Tab............................................................................25

5.9 General Notes.................................................................................25

5-1

5-2

5-2

5.10 ESTIM DRU Diagnostic File Output............................................26

5.10.1 Initial Problem Parameters ...................................................275.10.2 Iteration Output ....................................................................295.10.3 Final Output .........................................................................31


5.1 The ProblemModern instrumentation and distributed control and management information systems produce a wealth of plant data. The plant operator/manager has a problem making sense of all this data where:

• It may be inconsistent or inaccurate.• It may not give a complete or understandable indication of plant

performance.

In addition, plant models can only be configured to a specific operational instance, whereas the performance of actual equipment varies as conditions change and equipment degrades. Thus, the model behaviour may start to diverge from actual plant behaviour.

5.2 The SolutionThe ESTIM DRU addresses these issues and produces concise information to aid decision making and aid model tuning and off-line investigation.

Firstly, it can perform data reconciliation. Measurements are subject to error and, therefore, provide inconsistent information. ESTIM DRU can detect and correct measurement errors, thereby providing a consistent and accurate data set.

Secondly, a model representing a specific item of plant can be updated whereby ESTIM DRU is able to reconcile model and actual plant values, to ensure that the model continues to represent actual plant performance.

5-3

5-4 The Benefits

5.3 The BenefitsThe ESTIM DRU brings real benefits by ensuring good representation of plant equipment, and providing indications of poor plant data as an aid to decision making in the following areas:

• Identification of process unit performance, in particular condition monitoring.

• Identification and quantification of instrument errors.

This leads to improvements due to:

• Better process operation in general.• More effective and efficient equipment maintenance and/or

replacement.• More effective and efficient instrument maintenance.• Improved plant model representation.

ApplicationsCurrent applications of the ESTIM DRU include:

• Compressor model updating/condition monitoring• Catalyst performance monitoring/updating• Thermal cracker model updating• Steam system data reconciliation• Gas turbine model parameter updating• Heat exchanger fouling effect updating• Reactor model parameter updating• Boiler model updating and condition monitoring• General network reconciliation (e.g., oil & gas fields, steam systems,

etc.)

In fact, anywhere where plant measurements are available around process equipment, the ESTIM DRU can be applied.

5-4


5.4 ESTIM DRU Facilities

5.4.1 Error Detection/CorrectionNo measurement is perfect, so by using a number of sets of data and statistical routines, the ESTIM DRU sorts the good from the bad and only uses good data. This is a pre-requisite for model updating and the essence of data reconciliation.

5.4.2 Model UpdatingThe ESTIM DRU can update the parameters of even the most complex model.

5.4.3 UtilitiesThe ESTIM DRU invokes a number of statistical and optimization routines to perform the following tasks:

• Parameter Estimation – Calculation of model parameters which may change with time, such as reaction rate coefficients, heat transfer coefficients, etc.

• Data Reconciliation – Model based reconciliation of over-determined systems, such as steam system mass balancing, where there are many flow-meters, or estimation of power output of a turbine with both steam flow and driven load being measured.

• Bad Data Elimination – Results of data reconciliation calculations can be examined statistically to determine whether bad data is present, and if so eliminate the bad data.

5-5

5-6 Using ESTIM DRU

5.5 Using ESTIM DRUThe ESTIM DRU comes in the form of a tool kit, comprised of the following:

• A set of related screens in HYSYS for attaching an ESTIM DRU to a HYSYS plant model simulation case.

• Demonstration examples describing how to use the DRU[1]. This lets you configure plant model updating and data reconciliation routines within the HYSYS environment without recourse to programming or expert assistance.

5.5.1 Measurement ProblemMeasurement devices are often assumed to have zero bias and random errors, i.e. the instrument is assumed to be in working order, (correctly calibrated) so that any deviations from true are due to "noise".

Expressed mathematically we have:

Where y is the reading on the instrument, x is the true measurement and e the error. The mean of e is assumed to be zero and the distribution symmetric, i.e. the error is assumed equally likely to be positive or negative and, given enough readings, its affect disappears.

This model of instrument errors is used as a basis of many traditional methods of data reconciliation, e.g. least squares. However, equation (1) is not generally the case and, in practice, the most serious problem is due to gross errors and real bias, represented by broken or badly calibrated instruments. Thus, it is no surprise that the application of traditional methods is unsatisfactory and has the effect of sharing out the errors so that in a case where just one instrument is in error, all instruments are affected.

(5.1)y x e+=

5-6


Therefore, methods such as least squares can not be relied on exclusively. Within ESTIM DRU these methods are pre-fixed by others which are based on the assumption that measurements may be either grossly wrong or out of calibration.

5.5.2 Basic MethodsThere are a number of techniques within ESTIM DRU that can be used. The current available techniques are:

• Elimination of Measurement Bias• Solution of the Unbiased Problem• Practical Considerations• Estim. Offline - For Model Updating

Elimination of Measurement BiasAs identified in the last section, where there are systematic errors and failures the real world problem is transformed into one where there is no bias and the errors are random. This is done in two ways:

• Allowance for Systematic Errors – To cope with systematic errors offset variables are introduced into the problem to represent these errors.

• Integer Programming – This allows the identification of grossly wrong instruments, i.e. stuck or failed. Instruments from the historical data-set can be systematically disregarded.

5-7

5-8 Using ESTIM DRU

Solution of the Unbiased Problem• Normal Least Squares – This estimator requires that no statistical

(a prior) weighting may be applied to an accurate measuring device, such as a thermocouple, or a lower weighting to an analyser. Fundamental weighting exists between offsets and parameters to bias the calculation method between these two types of fitting.

• Minimum – Has knowledge of the measurement and calculates the values of the model parameters (and measurement offsets) which minimize the sum of the squares of the differences between the actual and predicted data.

• Weighted Least Squares – The least squares estimator may be modified by adding weighting factors on certain errors to either preferentially reduce errors or allow for differences in measurement quality. For example, a higher Variance - If we have information on the variance (likely error bound) of the measuring elements we can use a minimum variance estimator. This minimizes the variance of the estimator, rather than the error squared. It can be compared to weighted least squares with weights of 1/ .

Practical ConsiderationsWhen using parameter updating for a model it is important to have a large enough history of results, which, over a short time period is unlikely. There are two reasons for this requirement and they are as follows:

• Firstly, it is impossible to update a performance curve, such as the efficiency/flow curve on a compressor, from a small knot of data. Depending on the technique, the best that can happen is the curve moves up or down, and the worst that can happen is the curve becomes totally wrong towards the extremes.

• Secondly, it is impossible to calculate a goodness-of-fit parameter. This makes determination of faulty measurements difficult.

When these problems are anticipated, it is better to adopt a strategy where an updated correction factor is applied to the model curve instead of updating the performance curve.

This does not preclude updating performance curves in the longer term by manual inspection and re-fitting.

HYSYS models are written in such a way that it is a simple task for ESTIM DRU to update either a curve or a performance parameter.

σ

σ

5-8


Estim. Offline - For Model UpdatingUsing the ESTIM DRU for model updating is purely a matter of configuration. No programming or expert knowledge is required.

The basic task is to identify the following elements:

• A list of measured values from the plant that are used to update model parameters. These values should represent data that can be used as inputs to the model and data that corresponds to calculated results of an associated model run. At a minimum, at least one data-point corresponding to a model result must be configured.

• A list of parameters to be updated. The parameters should have an effect on the chosen model calculated results.

• A list (subset) of the measurement data to which offsets are applied.• Scaling being applied to the measurement data and general

problem. This should initially be chosen so the scaled values are of the same order of magnitude, before further scaling is implemented to bias certain measurements.

• The model being run which produces the modelled values. This may be a model of the whole plant, or just of a single unit.

The following is an example of model updating.

If we take a model with parameters, for example a compressor, the flowchart within ESTIM DRU consists of the following steps:

1. Read actual performance data from measurements.

2. Calculate model performance based on measured model input data.

3. Optimize model parameters to minimize the difference between actual performance (measured) and predicted performance (calculated).

4. Calculate goodness of fit and statistical properties based on selected model parameters. If the goodness of fit is acceptable, update the model parameters.

The following is an example of the steps involved in measurement offset fitting, including data elimination:

1. Read actual performance data from measurements.

2. Calculate model performance based on zero-offset measured model input data.

3. Optimize measured data offsets to minimize the difference between actual performance (measured) and predicted performance (calculated).

5-9

5-10 Configuring a Fitting Problem

4. Calculate goodness of fit and statistical properties based on selected measurement offsets. If the goodness of fit is acceptable, update the measured data offsets.

5. Calculate the data elimination goodness of fit. If the fit is good, the task is completed. If the fit is bad, eliminate the offset fitting for the data set with the largest relative offset, and allow the offset to "float" (i.e. remove from the offset portion of the fitting function and allow the routine to select an unrestricted fit value). Recalculate the fitting problem with the eliminated data set.

5.6 Configuring a Fitting ProblemThe ESTIM DRU fitting configuration is carried out in HYSYS using the Data Reconciliation Utility model detailed below. Figure 5.1 shows the Data Reconciliation Utility property view.

Figure 5.1

5-10


5.6.1 Configuration TabThe Configuration tab of the Data Reconciliation Utility property view is comprised of the following three groups:

• Problem Formulation• Solver Parameters and Tolerances• Data Set Configuration.

Problem Formulation GroupThis group defines the main user-controls to be supplied with data to fit the parameter and/or measured data offsets. In the Fitting column, the parameter fitting can be switched off or on using the Mode cell.

The Confidence can be set to determine the level of fit required for a good result. The higher the confidence, the closer the fit needs to be to a normalized curve for the fit to be deemed good.

The Run After N counter allows the ESTIM DRU model to be exercised to only perform the fit calculations every N-th time. This allows the associated measurement data blocks to gather the historical data without full recalculation being performed for each new data set. If required, the counter can be set to 1. The Current field indicates the current number of runs related to this.

The Maximum cell allows you to enter a maximum number of iterations (error function gradient evaluations, i.e., optimizer moves) for calculating the optimal parameters.

In addition, the utility produces a diagnostic file: diagnostic print can be set to levels of None, through to Downpour (no diagnostics through to full diagnostics).

5-11


Solver Parameters & Tolerances GroupThe ESTIM DRU tolerances can be user defined using the Data Reconciliation Utility property view. If tolerances are not defined, default values (generated/set by the optimization algorithm) are used.

The Central and Forward Difference Intervals are used to determine the perturbation in the parameters / offset used for the calculation of the (error function) objective gradients with respect to the variables. If these values are not set, the optimization routine uses additional model evaluations to determine the values to be used.

The Optimality Tolerance is the smallest relative change in the total error function during the error minimization below which the optimization is deemed to have converged by the algorithm.

The Linesearch tolerance is used by the optimization routine to determine the accuracy of the optimal step with respect to the gradient evaluations. The larger the Linesearch tolerance, the further along the optimal path the next optimal step will be. This number must be between zero and one.

The Maximum Step determines how far each of the variables (parameters, offsets) can be moved in an optimal step. This prevents the optimizer from overstepping on each iteration, thus speeding solution.

The Maximum Iteration Limit determines the maximum number of iterations allowed to the optimizer to generate its optimal solution. Generally, after approximately five iterations, the optimizer is close enough to the fitting solution to be terminated with confidence. This is because the optimization problem is unconstrained, the only limits are imposed from the parameters.

The Objective Scaling allows the emphasis between offset and parameter fitting to be varied when both offsets and parameters are fitted simultaneously. The emphasis is squared based on the given number; a function scale factor of 10 places 100 times more emphasis on the elimination of measured / model error than on fitting the offsets.

The Convergence Tolerance is the smallest change to occur to every parameter/offset below which the minimization is deemed to have converged.

5-12


Data Set Configuration GroupThe minimum number of good data sets required for an Estim DRU calculation is given in Minimum Data sets. A good data set is one that is not excluded at the start of the ESTIM DRU calculation. The maximum number of historical data sets to be stored locally during the estimation (but not necessarily all used) is given in Maximum Data Sets. You can set this to store as many time-slices of information as he/she wishes (although the upper limit is 32).

The number of data sets in the parameter estimation problem is given in Current Data Sets. Eventually, after a sufficient number of ESTIM DRU runs this number is equal to the Maximum Data Sets parameter. The measurement horizon for the data is given in Horizon. This gives the number of most-recent data sets to be used in the ESTIM DRU, out of the Maximum Data Sets stored.

5-13


5.6.2 Results Tab

The updating routine produces a set of results, that can be seen on the Results tab of the Data Reconciliation Utility property view.

The Fit Error (Total) gives the total sum of the errors, for all the datablocks of reach good historical data-set, between the measured values and the model calculated values, the error being calculated using the final value of the predicted parameters and measurement offsets.

The value of x2 gives the x2 calculation bases on the sum of the data block errors scaled by the sigma, s, for each of the output data blocks. This value is then checked against the maximum x2 value (Maximum Chi2), which is calculated from the stated confidence and the calculated number of degrees of freedom (Degrees of Freedom) for the problem. If the calculated x2 values is less than the maximum value, the Fit flag is deemed good, and the parameters and offsets are updated. A bad fit leaves the parameters and offsets with their original values.

Figure 5.2

5-14


The Goodness of Fit returns whether a good or bad fit was returned by the x2-test. Major Iterations indicates the number of parameter variation steps undertaken by the optimization algorithm with minimizing the total error.

The value for Function Calls indicates how many times the plant model was executed by the updating algorithm in arriving at the fit answer.

The change in objective function can be seen by comparing the Starting Objective to Final Objective. The objective quoted is the actual objective seen by the optimization routine, and is based on the scaled offsets and error functions.

A summary of the user-supplied parameters is also supplied in the Number Of group.

Parameter/OffsetsThese are the most important results obtained from the updating. They define the parameters which most accurately describe the actual plant for the data given in the model input and output blocks.

The parameter results can be viewed on the Parameter Fit tab.

The calculated offsets can be seen by examining the individual data blocks on the DCS Tags tab as shown in the next section.

In most cases, successive updating over time should result in a progressively more accurate solution.

5-15


5.6.3 Stream Initialization Tab

Figure 5.3 shows the Stream Initialization tab. This indicates the connections from the estimated entries in the plant model to the measurement data list that contains the input and the output measurement data blocks. The screen identifies whether a measurement data block is a model input or calculated result.

This form displays information concerning flowsheet model inlet / outlet streams, energy streams, and internal streams. An inlet stream is a stream in the model that is an inlet to a reconciled unit operation (targeted using the Target Objects button), but not an outlet. An outlet stream is an outlet to a reconciled unit operation, but not an inlet.

Energy stream refers to the standard HYSYS energy streams. Internal streams are both inlet and outlet streams (i.e., are both feeds and products to unit operations), or are either feeds or products to a unit operation which is not reconciled. The initialization prior to carrying out a run of the estimation is done using DRU streams, streams created by you specially for the purpose of storing simulated plant data in

Figure 5.3

5-16


flowsheet streams; the DRU streams are effectively storage mechanisms. The Multiple flag column indicates whether historical data is available for the flowsheet stream, data which is stored in the ESTIM DRU object; if unchecked, any specified values of the corresponding flowsheet stream are held constant for the duration of the parameter estimation.

The Data Sets column indicates the number of data sets available for each stream kind (Inlet, in this case). The Comp Basis column represents the basis for the component calculation in each stream.

5.6.4 Parameter Fit Tab

The model parameters can be accessed from the Parameter Fit tab of the Data Reconciliation Utility property view. These are the parameters that are adjusted to give the best fit of the model to the data given in the output blocks, e.g., the efficiency of a heat exchanger or the reaction coefficients of a reactor model.

Figure 5.4

5-17


The Minimum and Maximum values define the range over which the parameters are allowed to vary. These values should be considered carefully so as not to constrain the model to a region in which the model solution is greatly different from the actual plant.

The Start and Current values show the values of the parameters before and after an update was carried out. After an update, and only if the fit is good, the new values are placed directly into the model. The Result Value stores the value of the parameter after the last run of the ESTIM DRU. The Hooked Object/Variable refer to the object and property in the flowsheet model which is estimated.

5.6.5 DCS Tags Tab

The DCS Tags tab is used for defining the transfer of measured data to the flowsheet model during the ESTIM DRU calculations.

Figure 5.5

5-18


The Tag Filter group has options to display model Input data, Output data, or All data (input and output), depending on the radio button selected. Input data consists of property values of streams that are read in the model, but are not reconciled. Output data, consisting of property values, are then reconciled to these (read) values by the parameter estimation algorithms in the ESTIM DRU.

5.7 Estim Data Set Analysis

When running ESTIM DRU offline, the Data Set Analysis view can be used to see how well each variable behaves over up to 15 data sets, or how up to 15 variables perform against observed plant data for any particular data set. The absolute and percentage difference between the observed and predicted data, and the arithmetic average and standard deviation of these differences are displayed to show the statistical accuracy of the model.

The Data Set Analysis view is accessed by clicking the Data Set Analysis button on the Data Reconciliation Utility property view after running the ESTIM DRU offline. The view includes both ‘Good’ and ‘Bad’ data. Select the data sets to be included in the analysis and either input tags or output tags. The analysis is run by clicking the Run button on the above screen.

Figure 5.6

5-19

5-20 Optimization Objects

5.8 Optimization ObjectsAn ESTIM DRU stream (discussed in Section 5.6.3 - Stream Initialization Tab) and DCS Tags (discussed in Section 5.6.5 - DCS Tags Tab) are considered to be Optimization Objects. These optimization objects are input tags or output tags, corresponding to input or output data from the model.

These objects can be accessed by selecting Optimization Objects from the Flowsheet menu on the desktop. A given optimization object can be edited by highlighting it and clicking the Edit button on the Select Optimization Object dialog.

The Optimization Object property view for the selected object displays. There are three tabs in this property view:

• Connection• Properties• Transfer

These tabs are described in the following sections.

Figure 5.7

5-20


5.8.1 Connection Tab

The Connection tab gives the connections of an optimization object to the flowsheet Object name. The connection in this case is to an extra data value of the T-100 column.

Figure 5.8

5-21


5-22

5.8.2 Properties Tab

The second tab lists the Properties of an optimization object. The myvarval property (“my variable value”) stores the value of the connected object property. The scale value is used to scale the measured values, and hence the (measured - model) error, to ensure the optimizer objective function sees the errors with required weightings. Generally, the scaling should be selected so that the relative values for each of the errors on the model outputs is approximately equal. This ensures the optimizer selects a fair set of parameters and/or offsets to fit equally on the measured outputs.

If an output is to be favoured, its scaling should be smaller so the relative error is larger, forcing the optimizer to correct that error over the other errors. For offset fitting, the scaling is important for both input and output blocks since the offset is scaled by this amount for the objective function. For output blocks the scaling is also used to calculate the relative error between the measured and model values, so offset is scaled the same as the error. To counter this, the ESTIM DRU tolerances allow the overall offset portion of the objective function to be scaled differently to the error portion, thus enabling preference of fitting for either offsets or parameters. When parameter fitting only, the scaling is only relevant to the output blocks where it is used to scale the absolute error to a relative error.

Figure 5.9


The offset value indicates the absolute offset to be applied to the measure values; this can be a fixed, known amount, or an offset calculated by the fitting algorithm. The exact use is determined by the set-up flags in the data block. For offset fitting, there are no minimum and maximum limits since the optimizer is attempting to minimize the value of the offsets, and thus be driving them to zero.

The error property stores the calculated error between the fitted model data and the actual measured data, for a given data set. The sigma property is an estimate of the true asymptotic standard deviations of the measured value from the plant. The estimate is updated at each run of the ESTIM DRU in such a way it causes it to asymptotically approach the correct value for the instrument. The update takes account of the current value of sigma, and weighting which takes into account the previous estimate. The initial value of sigma selected is typically large (~1000), to provide a good initial fit. Sigma is only calculated for output data blocks (Output Tags).

The value of sigma is used to calculate the goodness of fit; the scaled error between model calculated value and the measured value is divided by the sigma value to determine the effect of the data block in the overall x2 fit calculations. The smaller the value, the smaller the error allowed to maintain a good fit. Where the sigma is not reset on each run, the closer the measured value is to the model value, the smaller the calculated sigma is for use in the cumulative sigma update. As this is calculated cumulatively, it tends to its natural sigma value. It should be noted that the sigma value is only used for the goodness of fit calculations, and plays no part in the actual fitting optimization.

The next_value property is the value most recently assigned to the given tag (i.e., as if it were read in from a DCS system).

5-23


The remaining properties have no unit dependency on the connection:

• Count – The number of measured value updates to the DCS Tag since the last estimation run.

• Totcount – The total number of measured value updates.• Calc_bias – Used to tell the algorithm that the data block is to be

included in the offset fitting set, and thus the offset is adjusted to attempt to minimize the measured/model error. If the data-block is set to calculate offsets, then it is also included in the bad data elimination algorithm.

• Over_data – Not currently used in the ESTIM DRU.• Next_good – Stores whether the next value (obtained from the use

in the offline case, or from a DCS system in the on-line case) is considered good or bad data.

• Input – Indicates if the variable is an input to the model or not.• Use_bias – Set by the user if you want to use the current biases

during model runs, not the updated ones, if they are calculated. The flag tells the algorithm that a fixed, known offset is to be applied to each set of measured data for use in the generation of measure/model error. In this case, the offset value is not calculated, and the data block is not included for elimination in the bad data elimination algorithm.

• Fill – Reserved for future use.• Eliminated – Returned as a result from the bad data elimination

algorithm to indicate that the data set is deemed bad. In this case, the offset is removed from the objective function and allowed to “float”. The resultant model calculated value is then available from the myvarval field. The flag can also be used during normal offset fitting to determine a model calculated value without restricting the offset in the normal optimization objective function.

• Curval, and curerror – Indicates the current value and error of the object in the calculation.

5-24


5.8.3 Transfer Tab

The Transfer tab lists the Transfer flags of an optimization object. These flag properties are not used in the offline situation.

5.9 General NotesIf the ESTIM DRU model has a Run After N value set, it only runs every N-th time, allowing the data blocks to build up the historical data for the actual fitting calculations. This allows the historical data to be stored before the fitting calculations are performed.

Figure 5.10

5-25

5-26 ESTIM DRU Diagnostic File Output

Setting up the Bad Data Elimination Problem (GROSS ERROR DETECTION)The bad data elimination problem is set up and calculated using the Data Reconciliation Utility screen. Bad data elimination is specified by selecting the Gross Error Detection:Perform Calculations flag. This selection assumes that the ESTIM DRU is configured with the offset data blocks that correspond to the measurements that are available for elimination.

The Mode indicates whether Full fitting is performed, or if a Shortcut (single) data set is used. The single data set mode uses the first good set, and does not fit parameters defined in the ESTIM DRU Parameter Fit tab. The purpose of this mode is to provide a quick method of determining bad data within a single set based on the associated model.

After the ESTIM DRU is run with these settings, the results are displayed on the Estim Results tab of the Data Reconciliation Utility screen. No. of Eliminations and Max Eliminations show how many data blocks are eliminated in the given problem, and show how many accepted eliminations are allowed before the fitting cannot be exercised further.

The confidence is similar to that for the standard fitting, in that it is used to calculate the Maximum x2 to determine whether a good fit was achieved. The Fit Error (Total) is compared to the maximum tolerance to give the Goodness of Fit flag. The tolerance figure is based on a x2 distribution for the offsets only, expecting a good fit to have small offsets close to zero value.

The fitting calculation is always performed when the elimination model is run.

5.10 ESTIM DRU Diagnostic File OutputThe following section details the diagnostics available from ESTIM DRU and the associated optimization routine.

There are three sections produced in the diagnostic output from an

5-26


ESTIM DRU run. These sections are covered separately. In addition, several levels of output are available, based on the level selected within the ESTIM DRU. The descriptions below deal with diagnostics produced when the Downpour diagnostic option is selected. All output produced is generated by the optimization routines; MDC Technology Ltd. do not currently supply additional output from the ESTIM DRU routine.

The name of the diagnostic file produced by the ESTIM DRU is of the form <ESTIM DRU name> .txt, where <ESTIM DRU name> is the name of your ESTIM DRU object in HYSYS.

5.10.1 Initial Problem ParametersThe first section of output produced by the optimization routine details the input parameters for the particular problem to be solved. These are either supplied as a result of the problem, or are defaults used by the algorithm. Since the application of the optimizer to the ESTIM DRU task is an unconstrained problem, several of the parameters and variables produced as part of the output are not relevant to the task and should be ignored.

• Linear constraints – The number of linear constraints in the problem. This is not applicable for ESTIM DRU.

• Linear feasibility – The maximum acceptable violation of linear constraints at a feasible point. This is not applicable for ESTIM DRU.

• Variables – The number of variables (parameters or offsets) to be optimized (fitted) in the current problem.

• Crash tolerance – This is used when COLD start is selected. Variables within this tolerance of their bounds are selected for the initial working set of the problem.

• Infinite bound size – Any bound greater/less than this number is considered +/- .

• COLD start – Specifies the initial working set for the problem. This is selected from the initial value of the variables, including variables at, near, or just violating their bounds.

• Infinite step size – The magnitude of a change in the variables that would indicate an unbounded problem (the objective is said to be unbounded in the feasible region). Since ESTIM DRU variables are all bounded between -1 and +1, this parameter is not relevant to an ESTIM DRU task.

• EPS (machine precision) – The machine precision, used to determine the default values for several other parameters.

∞

5-27


• Step limit – The maximum change in a variable on the first step of the linesearch. This prevents overflow situations from occurring.

• Nonlinear constraints – The number of non-linear constraints. This is not applicable for ESTIM DRU problems.

• Nonlinear feasibility – The maximum acceptable violation of non-linear constraints at a feasible point. This is not applicable for ESTIM DRU problems.

• Nonlinear objective vars – Number of (non-linear) variables used to minimize the objective function.

• Optimality tolerance – The accuracy of the final iterate to approximate a solution to the problem, i.e. a solution is deemed valid if the relative change in the objective function is less than this tolerance. In effect, this value indicates the number of correct figures required in the objective function at solution (i.e. if the tolerance is 10-6 and the optimization terminated successfully, approximately the first six figures of the objective function are correct. This is an indication of the "tightness" of the problem solution.

• Nonlinear Jacobian vars – The number of variables used to evaluate the Jacobian matrix of the problem.

• Linesearch tolerance – The accuracy of the step taken during each iteration to approximate a minimum of the merit function along the search direction. This determines how far along the search path the next point is to be taken.

• Derivative level – This indicates how many of the objective (and constraint) gradients are supplied to the algorithm. ESTIM DRU uses the algorithm with a level of 0, which indicates that all gradients are not supplied, and have to be calculated using difference approximations.

• Function precision – The accuracy with which functions are assumed to be evaluated.

• Verify level – A value of zero indicates that the optimization routine performs a 'cheap' finite-difference test on the objective gradient components of the problem. This is not applicable for ESTIM DRU (where no gradients are supplied).

• Major iterations limit – The maximum number of major iterations performed before the problem is terminated (unsuccessfully).

• Major print level – Determines the output level on each major iteration.

• Minor iterations limit – The maximum number of iterations used to calculate the optimality of the QP subproblem.

• Minor print level – Determines the output level on each minor iteration.

• Difference interval – The interval used in the forward difference approximation for the objective gradients in the Jacobian matrix.

• Central difference interval – The interval used in the central difference approximation for the objective gradients in the Jacobian matrix. Central difference approximations are used if the forward difference approximations are found to be not accurate enough.

5-28


• JTJ initial Hessian – Controls the initial value of the upper triangular matrix R (the estimate of the transformed and re-ordered Hessian of the Lagrangian). J is the objective Jacobian matrix.

• Reset frequency – The number of major iterations after which the Hessian is reset to JTJ.

In addition to the above parameters, the work arrays are checked for suitable sizing, and a summary of the Jacobian element estimations is given.

5.10.2 Iteration OutputOn each major iteration, output is generated to detail the progress of the optimization algorithm in minimizing the ESTIM DRU function. The output for each iteration is given under the iteration header, Major iteration n. The following list details the tabulated output produced; the heading is only produced for the first iteration.

• Itn – The major iteration count.• ItQP. – The sum of the iterations required by the feasibility and

optimality phases of the QP problem (which generates the optimal step direction and length). Large values indicate difficulty in finding a new optimal point.

• Step – The step, , taken along the computed search path. On a reasonably behaved problem, this tends to unity.

• Nfun – The cumulative number of subfunctions needed for the linesearch (excluding finite difference calculations). This provides a guide on the amount of work performed in the linesearch.

• Objective – This is the value of the objective function, which should decrease monotonically as the optimization progresses. This should not be confused with the objective function calculated upon termination of the ESTIM DRU task. This value is also repeated after the table (with more significant figures).

• Bnd – The number of simple bound constraints in the predicted active set. This is not applicable for the ESTIM DRU task, and is always zero (after the first iteration).

• Lin – The number of linear constraints in the predicted active set. This is not applicable for the ESTIM DRU task, and is always zero.

• Nz – The number of variables less the number of constraints in the predicted active set. For an ESTIM DRU task this is always the number of parameters or offsets being fitted.

• Norm Gf – The Euclidean norm of the gradients of the objective function with respect to the free (unbounded) variables.

• Norm Gz – The Euclidean norm of the projected gradient. This is approximately zero near the solution.

α

5-29


• Cond H – The lower bound on the condition number of the Hessian approximation, H.

• Cond Hz – The lower bound on the condition number of the projected Hessian approximation, Hz. The larger this number is, the more difficult the problem is to minimize.

• Cond T – The lower bound on the condition number of the matrix of predicted active constraints. This is not relevant to the ESTIM DRU application.

• Conv – This is a three letter indication of the convergence test status. The letters indicate True or False. The letters detail the following points, in order:• sequence of iterates has converged• projected gradient (Norm Gz) is sufficiently small• constraint residual norm in the active set (Norm C) is sufficiently

small (this is always true in the ESTIM DRU application)

The following letters may display at the end of an output line:

For each major iteration, a section is produced detailing the "Values of the constraints and their predicted status". The variables are listed in order, giving the value of the scaled variable (which is scaled internal to the optimization routine between -1 and +1), and its predicted status.

For instance, if a parameter is allowed to vary in the model between 0 and 100, and lies at the model value of 25, the scaled value internal to the optimization routine would be -0.5. The predicted status is a binary number, zero indicating the variable is free, and one indicating the variable is at one of its bounds.

Also produced are the diagonals of R, which are the triangulation factors of the transformed and re-ordered Hessian.

Letter Description

C Indicates the use of central difference approximation in the gradient evaluations.

L Indicates that the linesearch produced a change in a variable greater than specified by STEP LIMIT.

R Indicates that refactorization of the approximated Hessian is performed.

5-30


5.10.3 Final OutputUpon termination of the optimization algorithm, whether successful or not, the final output is produced. The number of subfunction calls made by the optimization routine differs from that made by the ESTIM DRU task, since ESTIM DRU evaluates the subfunction outside of the optimization routine as part of its solution. The following details are written as final output from the optimization algorithm.

• INFORM – This details the status of the algorithm solution. Zero indicates successful solution.

• MAJITS – The number of major iterations performed.• NFUN – The total number of function evaluations performed during

the optimization (excluding those needed for gradient estimations).• NGRAD – The number of function evaluations performed for

gradient estimations.• Varbl – The name (V) and the index of the variable.• Value – The scaled value of variable V.• State – The status of the variable. FR indicates the variable is

unbounded, LL indicates the variable is bounded at its lower limit, and UL indicates the variable is bounded at its upper limit.

• Lower Bound – this is the value of the lower bound for the variable within the optimization routine. For ESTIM DRU tasks this is always -1.

• Upper Bound – This is the value of the upper bound for the variable within the optimization routine. For ESTIM DRU tasks this is always +1.

• Lagr Mult – This gives the Lagrangian multiplier of the variable, if the variable is bounded. The value is zero for a free variable, positive for a variable at its lower limit, and negative for a variable at its upper limit.

• Residual – This is the difference between the variable and its NEAREST bound.

The optimization routine termination code is printed and the final value of the (internal) objective function is displayed as the last output (this is not the same as displayed by ESTIM DRU, since the optimization value is internally scaled).

5-31


5-32

Data Reconciliation Utility 6-1

6 Data Reconciliation Utility

6-1

6.1 Heat Exchanger Network Data Reconciliation ..............................3

6.1.1 Installing/Viewing the DRU.......................................................5

6-2

6-2


6.1 Heat Exchanger Network Data Reconciliation


• DCS Tags – Variables for which you have a set of measurements, used to calculate offsets in the measurements, and update fitting parameters. These can be either specified or calculated variables.

• Fitting Parameters – Variables whose value is to be directly adjusted to match the supplied data. These must be specified (blue) variables.

There is a third type of Optimization Object used for Data Reconciliation called a DRU Stream (Data Reconciliation Utility Stream). This is essentially a data holder (i.e., it allows for multiple sets of stream data each corresponding to a different data set), to be supplied by the user. These values are taken as supplied, no offsetting is calculated for these streams.

The following section lists the properties which are found with each optimization object type.

• Name – The display name of the property.• Type – This can be either input (required user input), output

(calculated value by the solver), internal (a value which is being used by the solver in its solution), or RTO (appropriate only for real time applications).

• Data Type – This is either a double, an integer, a Boolean, or text.

6-3

6-4 Heat Exchanger Network Data

Fitting Parameter

DCS Tag

Name Type Data Type Description

Minimum Input Double The bound on the parameter

Maximum Input Double The upper bound on the parameter

Fit Input Boolean Determines whether to include the parameter in the current run

Start Value Input Double The desired starting value for the parameter

Evaluate Output Double What is currently being sent from Estim for evaluation

Result Value Output Double The final answer


Scale Input Double The lower bound on the constraint

Offset Input Double The offset to be applied to the measured value

Total Error Output Double The calculated total error for the tag

Calculate Bias Input Boolean Whether Estim is to calculate a bias for the tag

Use Bias Input Double Whether Estim is to use the current bias in calculations

Percent Output Double Percentage of the offset value with respect to the scaled value

Input Input Double A flag indicating if the tag is an “input” (specified flowsheet variable)

Eliminated Output Boolean Whether Estim has eliminated the tag from the problem

Evaluated Value

Internal Double The measured value which is currently being used

Current Error Internal Double The error for the current measured value

Next Value RTO Boolean The value that is transferred from the Plant

Count RTO Double The current count (number of data points)

Total Count RTO Double The total number of data points

Over Data RTO Double Logical, when TRUE, turns off an instrument, ignoring the data linked to that particular instrument in the dataset

6-4


6.1.1 Installing/Viewing the DRUA simple heat exchanger network is used to illustrate the installation and configuration of a Data Reconcilation problem:

Next Good RTO Double A flag indicating if the Next Value is good

Limit RTO Double Biasing limit, a positive number. When bias is used as the optimizer variable, it is restricted to a range [current_bias-limit, current_bias+limit], usually with current_bias=0. If limit is set to zero, the range is assumed to be unbounded.

Figure 6.1


6-5


Data Reconciliation UtilityOpen the hen.hsc sample case found in the HYSYS.RTO Cases folder. You can view the PFD by clicking the PFD icon in the Tool Bar.

To install a DRU:

1. Open the Tools menu and select Utilities.

2. Click on Data Recon Utility in the list on the right.

3. Click the Add Utility button.

In the case that you’ve opened, hen.hsc, a DRU is already installed, so view that DRU. In the list on the left, click Data Recon Utility-1 and then click the View Utility button.

The Data Reconciliation Utility property view displays as shown in the figure below.

Figure 6.2

PFD icon

6-6


There are five tabs in this property view:

Selection of Unit Operation(s)The first step in the implementation of the Data Reconciliation Utility is the selection of the unit operations to be considered (click the Target Object button). This produces the Target Objects view as shown in the figure below:

This view displays all of the unit operations currently attached to the Utility. You can either Add or Remove unit operations from the utilities collection.

Tab Description

Configuration Define the problem type (parameter fit, data offsetting or both) and set the remaining solution options.

Results Updated results of the progress and final solution of the data reconcilation, as well as additional configuration information (number of input tags, output tags, etc.).

Stream Initialisation Create the DRU Streams and configure them (if necessary).

Parameter Fit Provides access to, and installation of, Fitting Parameter optimization objects associated with the operation(s) and streams being considered.

DCS Tages Provides access to and installation of DCS tag objects associated with the operation(s) and streams being considered.

Figure 6.3

6-7


The Object Filter group found at the bottom left of the view provides options for filtering the display of available objects. In addition, the Flowsheet Wide option is provided to allow the application of the Data Reconciliation Utility to the entire flowsheet. For this example, this is the correct choice.

When you have moved the desired items into the right column (highlight them in the Available Objects list and then press the right arrow button), click the Accept List button . The appropriate optimization objects (DCSTags, DRUStreams and Fitting Parameters which are attached to these operations and their associated streams are collected from the simulation case.

The Stream Initialization tab lets you acccess (and create if desired) the DRU Streams (Data Reconciliation Utility Streams) which are used to hold multiple sets of Feed, Product or Internal Stream data for a Data Reconciliation Utility.

There are a number of features associated with the DRU’s (such as converting data for a new Component Basis in an associated stream, inserting and removing data sets , etc).

Figure 6.4

6-8


For this problem however, the composition of the Feeds and Products remains fixed and Tags are used to modify any of the stream data for the problem.

If a "Specific Stream" is selected, it allows an Internal stream (one that is connected to two unit operations in the collection) to be created. This can be used to store internal stream data from the results of the data reconciliation (a copy of the stream data is saved for each data set).

By default, all of the DRU’s have their Multiple flag set to True. This needs to be turned "off" for Inlet DRU’s.

The figure below illustrates the option of selecting a new stream basis for the flowsheet stream, which results in any of the supplied data (if desired) being converted to the new basis.

There are three options when a new basis is selected for the streams compositional basis. You can set all supplied values to unknown, convert the previously supplied value to the new basis, or retain the values as supplied and have them interpreted in the new basis.

Figure 6.5

6-9


The next step is the installation of the fitting parameters. Go to the Parameter Fit tab.

The Fit Parameters in the table on this tab are selected through the Add button beside the Fit Parameter drop-down list. When you click the Add button, the Select Optimization Variable view is displayed.

Figure 6.6

6-10


The first Fit Parameter that was selected for the DRU was the E-100 object, Spec Value variable and the UA variable specifics as shown in the figure below.

Figure 6.7

6-11


Selection of TagsMove to the DCS Tags tab in the Data Reconciliation Utiltiy property view.

The Input DCS Tags in the Tag Filter group on this tab are selected using the Add button beside the DCS Tags drop down menu. When you click the Add button, the Select Optimization Variable view is displayed.

Figure 6.8

6-12


The first Input DCS Tag that was selected for the DRU was selected as shown in the figure below.

The tag is automatically placed in the Tag Filter list as the variable (Stream 2 Flow) is specified in the flowsheet.

The Output DCS Tags were added as shown below.

Figure 6.9

Figure 6.10

6-13


If you return to the Configuration tab of the Utility and specify the minimum number of data sets to be four, the appropriate number of data sets are created for each tag and DRU Stream.

Return to the DCS Tags tab and in the Tag Filter group, click the All radio button and the Parameters radio button. The configuration data was supplied for each of the Input and Output tabs as described in the following table:

Tag Offset Limit Scale Sigma Calc Bias Use Bias

2 Flow 0 0 1 1000 False False






61 T 0 0 1 1000 False False





6-14


The DCS Tags tab is displayed as follows:

Select the Measured Data radio button and view the data:

Figure 6.11

Tag Data Set 1 Data Set 2 Data Set 3 Data Set 4

2 Flow (lbmole/hr) 900 1000 1100 1200

3 Flow (lbmol/hr) 1450 1550 1650 1750

59 Flow (lbmol/hr) 600 550 500 450

30 Flow (lbmol/hr) 1500 1600 1700 1800

14 Flow (lbmol/hr) 1350 1450 1550 1650

1 Flow (lbmol/hr) 2350 2550 2750 2950

61 T (F) -33.25 -33.16 -33.06 -32.96

4 T (F) -24.48 -23.01 -21.59 -20.24

5 T (F) -59.96 -56.64 -53.63 -50.88

7 T (F) -37.89 -37.12 -36.34 -35.57

8 T (F) -44.85 -43.85 -42.80 -41.76

6-15


Figure 6.12

6-16

Derivative Utility & Optimizer 7-1

7 Derivative Utility & Optimizer

7-1

7.1 The Derivative Utility .......................................................................3

7.1.2 Required Input for Variables .....................................................87.1.3 Required Input for Constraints................................................107.1.4 Objective Function Variables ..................................................11

7.2 Optimizer ........................................................................................12

7.2.1 Running the Optimization .......................................................13

7-2

7-2


7.1 The Derivative UtilityTo further illustrate how to use HYSYS.RTO to solve optimization problems, the following process is used. This example models the distillation of a crude tower. The Optimizer is used to determine the optimum steam feed rates.

7.1.1 Installing/Viewing the Derivative UtilityOpen the R-13opt.dox.hsc case found in the HYSYS.RTO Cases folder. View the PFD by clicking the PFD icon in the Tool Bar.

To install a Derivative Utility:

1. Open the Tools menu and select Utilities.

2. Click Derivative Utility in the list box on the right and click on the Add Utility button. In the case, R-13opt.dox.hsc, a Derivative Utility is already installed, so you are viewing that utility.

Figure 7.1

PFD icon

7-3

7-4 The Derivative Utility

3. In the list box on the left, click on Utility-1 and then click on the View Utility button. The Derivative Utility property view displays as shown below:

Selection of Unit Operation(s)The first step in the implementation of the Derivative Utility is the selection of the unit operations to be considered (click the Operations button). The following view is displayed:

Figure 7.2

Figure 7.3

7-4


There are three modes for the derivative utility and they are as follows:

• Flowsheet Wide – Use when minimal flowsheet tearing is to be employed, and no special derivative and solution mechanisms (such as extension operations) are to be used. In this mode, a single derivative utility is used for the entire flowsheet.

• Specific Unit Operation – Typically, this is a sub-flowsheet that is torn on both the feeds and products. The sub-flowsheet typically contains several unit operations that are solved either using the HYSYS standard solver, or one of the column solvers.

• Extension Operation – Used when the sub-flowsheet contains an extension operation that is solved using the available OLE functions to allow the solver to solve the model equations as part of the optimization problem.

It is best to select the desired unit operation prior to installing any of the remaining optimization objects. You should attach all existing optimization objects to the Derivative Utility, and this is how the correct mode is selected.

For this example, a Specific Unit Operation (T-100) is selected for the derivative utility. Use this mode to optimize variables pertaining to the T-100 unit operation.

Figure 7.4

7-5


Installing Optimization Variables from the UtilityOptimization objects appropriate for the utility (in the case of the Derivative Utility - Optimization Variables, Constraints and Objective function variables) can be added directly from the view. In the Derivative Utility Configuration group, there is a drop-down menu on the right side of the group. The drop-down list contains three options:

• Propcons• OptVars• ObjFunc

By selecting the appropriate option (OptVar in this case) and clicking the Add button to the left of the drop-down list, the selection view is displayed.

By making the selection as shown, the Optimization Variable is created and is added into the utility. By default, the new object is given the next available name. However, you can edit the name of the object directly from the utility view by highlighting the name in the Object Name column and typing a new string.

Figure 7.5

Figure 7.6

7-6


When optimization objects are created for the model, they are displayed in a WorkSheet format as shown below.

The Object Name column lets you modify the name of the created variables. In addition, the Attached Object and Attached Property are also displayed in the view, as well as the variable’s current value. The start value is updated at the start of an optimization run. There are several other properties also displayed in this view.

The Independent Properties radio buttons filter the overall list of variables to those of the specific types described previously. In addition, the Master and Runtime lists toggle the display between all objects and those being considered for the current evaluation.

The properties can be filtered into the following:

• All – All properties• Input – Properties requiring user input• Output – Calculated and outputted values• Results – Solution results

Figure 7.7

7-7


7.1.2 Required Input for VariablesThe only required input for optimization variables are:

• Optimize Flag• Minimum• Maximum• Range (optional)• Global Minimum• Global Maximum

The latter are appropriate only for real time applications and can be set at the same values as the minimum and maximum.

The Optimize flag works in conjunction with Run Time and Master lists. When the optimization problem is being set up, this flag is evaluated for each variable. If the flag is false, then the variable is not exposed to the Optimizer and the value remains at its starting value for the length of the solution. With this, you can switch problems easily by turning variables and constraints on and off.

The value for the variable Range is used for the calculation of a perturbation, range x perturbation factor. If none is provided, the span (maximum - minimum) is used for the calculations.

All required input for the variables can be done through the Utility view, which provides access to unit conversion capabilities.

7-8


The following tab shows all inputs of optimization variables:

Constraints (ProcCons) and Objective Function (ObjFunc) objects can similarly be added from the view by selecting the appropriate option in the drop-down list next to the Add Button.

Figure 7.8

7-9


7.1.3 Required Input for ConstraintsThe required inputs for Constraints are as follows:

• Use Flag• Minimum• Maximum• Scale

All constraints are treated by the Optimizer as ranged constraints, i.e., the value of the constraint should lie between the minimum and maximum at solution, within the prescribed Scale tolerance. The scale can be considered as an approach, the boundary around the minimum and maximum values that define whether the constraint is active, or violated. This information is reported during and after the solution as the status of the constraint.

The following tab shows input of constraints. To view this tab, click the Constraints/Objective Function tab and select the Proc. Constraints radio button in the Dependant Properties group, as shown in the figure below:

Figure 7.9

7-10


7.1.4 Objective Function VariablesObjective function variables are installed individually, which facilitates the calculation of the gradient during the course of Jacobian evaluations.

Alternatively, an Objective Function can be built in a spreadsheet operation, with a single cell representing the results, and having a single objective function object attached to this result cell.

For this problem, individual objective function objects are installed as shown below. To view this screen, change the Dependant Properties radio button to Obj. Functions.

At this point, all required input (for the various objects)is provided, and the Optimizer can be invoked.

Figure 7.10

The Prices of the objective function objects are based on Field Units.

7-11

7-12 Optimizer

7.2 OptimizerThe Optimizer interface is used to collect all of the derivative utilities within the current simulation case and provide them to the Optimizer. The Optimizer is invoked by pressing F5 or, open the Simulation menu and select Optimizer.

To access the configuration options for the Optimizer, first select the Optimization radio button at the bottom of the view. This provides access to the Optim Configuration tab, as shown below.

In addition, the Optimizer Control drop-down list at the bottom of the view provides the mechanism to Start, Stop, Restart, and control the solving mode of the Optimizer.

Figure 7.11

7-12


The Configuration group in the upper left corner of the view contains a collection of radio buttons that control the information and input options that are displayed:

• SetUp – Selection of the optimization scheme, print levels, as well displaying the running results

• Tolerances – Specification of Optimizer settings and solution tolerances

• Flags – Access to a number of flag settings that control the solution mechanism

7.2.1 Running the OptimizationAfter all the information is configured, the model can be run. To run the model, select Start on the Optimizer Control view, using the drop-down list. Scroll though the list to find this option.

While the model is running, you can move through HYSYS, but don’t change any of the values.

Figure 7.12

7-13

7-14 Optimizer

To examine the results on the variables and constraints, use the Derivative Utility. This screen is accessed through the Derivative Utility group in the Optimizer view.

Figure 7.13

7-14


Examining the Process Constraints/Results combination, the constraints are sorted to show those which are violated, followed by those which are active, followed by those which are inactive.

For more information, look at the information displayed when the Obj. Functions radio button is selected. This displays the cost/profit of each item.

Figure 7.14

7-15

7-16 Optimizer

7-16

HYSYS.RTO+ Example A-1

A HYSYS.RTO+ Example

A-1

A-2

A-2


A.1 Data Reconciliation ExampleIn this example, HYSYS.RTO+ is used to do both data reconciliation and parameter fitting. The main flowsheet of this example is shown below.

The sub-flowsheet GT-1 is shown as follows:

For the above process, you are going to reconcile measured data of mass flows of inlet streams Fuel, Dils, BFW1 and BFW2, as well as measured data of temperatures of outlet streams GT1 STM1, GT1 STM2 and Strm

Figure A.1

Figure A.2

A-3

A-4 Data Reconciliation Example

5T, and mass flow of outlet stream GT1 Stackage. You are also going to do parameter fitting of UA of heat exchanger E-100 and E-101.


• DCS Tags – variables for which the user has a set of measurements, and are used to calculate offsets in the measurements, and update fitting parameters. These can be either specified or calculated variables.

• Fitting Parameters – variables whose value is to be directly adjusted to match the supplied data. These must be specified (blue) variables.

There is a third type of Optimization Object used for Data Reconciliation called a DRU Stream (Data Reconciliation Utility Stream). This is essentially a data holder, i.e., it allows for multiple sets of stream data, each corresponding to a different data set, to be supplied by the user. These values are taken as supplied, no offsetting is calculated for these streams.

A-4


A.2 Install Data Reconciliation UtilityInstall the data reconcilation utility in the same manner as for the Derivative Utility (Tools -> Utilities or <Crtl><U>). The Data Reconciliation Property view is shown below:

There are five pages and they are described in the following table:

Figure A.3

Page Description

Configuration Define the problem type (parameter fit, data offsetting or both) and set the reamining solution options.

Results Updated results of the progress and final solution of the data reconcilation, as well as additional configuration information (number of input tags, output tags, etc.)

Stream Initialization Create the DRU Streams and configure them (if necessary)

Parameter Fit Provides access to, and installation of, Fitting Parameter optimization objects associated with the operation(s) and streams being considered.

DCS Tag Provides access to and installation of DCS tag objects associated with the operation(s) and streams being considered.

A-5

A-6 Install Data Reconciliation Utility

A.2.1 Selection of Unit Operation(s)The first step is to select the unit operations to be considered (press the Target Objects button, located in the top of the Configuration view). This produces the view shown below.

The first step is to select the unit operations to be considered (press the Target Objects button, located in the top of the Configuration view). This produces the view shown below.

This view displays all of the unit operations currently attached to the Utility. You can either add or remove unit operations from the utility’s collection.

When you press Accept List button, all of the appropriate optimization objects (DCSTags and Fitting Parameters) which are attached to these operations and their associated streams are collected from the simulation case. DRU streams are automatically created for inlet, outlet, and energy streams. Internal streams have to be added manually.

Figure A.4

A-6


DCS Tags used for this example are listed in the following table.

Optimization objects (Fitting Parameters and DCS Tags) can be created as shown in the above example. The following views show some settings for DRU streams, fitting parameters and DCS Tags.

1. DataRecon Utility - Stream Initialization – Make sure that the data in your Stream Initialization view is similar to what is shown here. To

Input Tag Name Variable Output Tag Name Variable

Fuel Mass Flow of GT1 Fuel

TSTM1 Temperature of GT1 STM1

Dils Mass Flow of GT1 Dil. Steam

TSTM2 Temperature of GT1 STM2

BFW1 Mass Flow of GT1 BFW1

MassStackgas Mass Flow of GT1Stackgas

BFW2 Mass Flow of GT1 BFW2

Strm 5T Temperature of 5

A-7


view this data, the Inlet and Set Up radio buttons must be selected.

Figure A.5

A-8


Figure A.6

A-9


The DRU stream contains multiple data sets of stream information associated with each of the measured data sets, but the information is not used for reconciliation. The values supplied are applied to the streams as each data set is evaluated.

Figure A.7

A-10


2. DataRecon Utility - Parameter Fitting – Examine the Parameters Fit page.

If a parameter needs to be fitted, its check box "Fit" should be checked.

3. DataRecon Utility - DCS Tags

Each of the tags (flowsheet variables for which there is measured data) is associated with a DCS Tag optimization object. When the optimization object is created and attached, the Data Recon Utility

Figure A.8

A-11


displays appropriate information about the actual flowsheet variable.

Information about the tags and how they are to be treated for the problem, can be set by selecting the parameters radio button. The key parameters are:

Calc Bias and Use Bias - whether a bias (offset) is to be calculated for the tag during the solution, or whether the supplied offset is to be used directly (Use Bias).

The Scale parameter is available so the user can apply scaling to the calculated error. In general, all tags should have a similar scaled error, however, there are situations, as described previously, where the user may want to apply different scalings to the tags.

Figure A.9

A-12


For a first evaluation of the model, using the unity scale is sufficient.

Once the number of data sets to be used is set, the measured data radio button can be selected. This provides access to the following view which

Figure A.10

A-13


allows the supply of data.

Figure A.11

A-14


Similar information should be supplied for the outlet tags.

Figure A.12

A-15


To run data reconciliation and parameter estimation, use the Optimizer. By selecting the DataRecon radio button, the following view is shown. The Estim Configuration and Estim Results pages are identical to pages

Figure A.13

A-16


of Configuration and Results of data reconciliation utility.

By selecting Start from the drop-down list of Estim Control, the Optimizer runs the data reconciliation utility. The results are given in

Figure A.14

A-17


the following pages.

Figure A.15

A-18


Figure A.16

A-19


A-20

Index
B
BndSee also ESTIM DRU

iteration output

C

Central difference intervalSee also ESTIM DRU

initial problem parametersCOLD start

See also ESTIM DRUinitial problem parameters

Collection Utilities 2-6constraints/objective function 2-10creating 2-9data reconciliation 2-6derivative 2-6derivative analysis 2-10independent variables 2-10structural non-zeroes 2-10

Cond HSee also ESTIM DRU

iteration outputCond Hz

See also ESTIM DRUiteration output

Cond TSee also ESTIM DRU

iteration outputConv


Crash toleranceSee also ESTIM DRU

initial problem parameters

D

Data Reconheat exchanger 6-3

Data Recon Utility 6-1DCS tag selection 6-12DCS Tag terminology 6-4DCS Tags 6-3

fitting parameter terminology 6-4fitting parameters 6-3installing and viewing 6-5property view 5-10

Configuration tab 5-11DCS Tags tab 5-18, 6-12Parameter Fit tab 5-17, 6-10Results tab 5-14Stream Initialization tab 5-16, 6-8

selecting unit ops 6-7stream 6-3

Data Reconciliationparameter estimation problem 2-7

Data Set ConfigurationSee also Data Recon Utility

Configuration tabDerivative Analysis 2-18Derivative level


Derivative Utility 2-11, 4-1(dependent) constraints calculations 4-14(dependent) constraints properties 4-9independent variable calculations 4-8independent variable properties 4-3

Difference intervalSee also ESTIM DRU

initial problem parametersDRU Stream

See also Data Recon Utilitystream

E

EPS (machine precision)See also ESTIM DRU

initial problem parametersEstim Data Set Analysis 5-19ESTIM DRU

applications 5-4basic methods 5-7benefits 5-4diagnostic file output 5-26

final output 5-31initial problem parameters 5-27

I-1

I-2

I-2

iteration output 5-29error detection/correction 5-5facilities 5-5fitting configuration 5-10general notes 5-25gross error detection 5-26measurement problem 5-6model updating 5-5overview 5-1practical considerations 5-8solution 5-8utilities 5-5utilizing 5-5

Estim Offline 5-9

F

Flowsheet Tearing 2-8Flowsheet Wide 6-8Function precision


H

HYSYS.RTO+using the program 2-1

I

Infinite bound sizeSee also ESTIM DRU

initial problem parametersInfinite step size


InformSee also ESTIM DRU

final outputItn


ItQPSee also ESTIM DRU

iteration output

J

JJ initial HessianSee also ESTIM DRU


L

Lagr MultSee also ESTIM DRU

final outputLin


Linear constraintsSee also ESTIM DRU

initial problem parametersLinear feasibility


Linesearch toleranceSee also ESTIM DRU

initial problem parametersLower Bound

See also ESTIM DRUfinal output

M

MajitsSee also ESTIM DRU

final outputMajor iterations limit


Major print levelSee also ESTIM DRU

initial problem parametersMinor iterations limit


Minor print levelSee also ESTIM DRU

initial problem parametersModel updating 5-9

N

NgradSee also ESTIM DRU

final outputNonlinear constraints


Nonlinear feasibilitySee also ESTIM DRU


Index I-3

Nonlinear Jacobian varsSee also ESTIM DRU

initial problem parametersNonlinear objective vars


Norm GzSee also ESTIM DRU

iteration outputNormGf


NzSee also ESTIM DRU

iteration output

O

ObjectiveSee also ESTIM DRU

iteration outputOptim Configuration

actual optimizer 3-9algorithm 3-4base search step 3-16bind 3-14code version 3-11cost 3-14diagnostic print level 3-6DV_level 3-8feasible point iterations 3-10fix variable spans 3-21flag inputs 3-19FPS Hessian diagonal 3-16function precision 3-12gradient 3-14gradient calculations 3-5gradient evaluations 3-11include fixed constraints 3-20include scales 3-21Jacobian elimination 3-17linesearch tolerance 3-12LP options 3-5major damping parameter 3-17max. allowed move 3-16max. constraint relaxations 3-7max. CPU usage 3-17max. feasible point 3-6max. Hessian resets 3-7max. iteration step 3-15

max. iterations 3-6minor damping parameter 3-17model evaluations 3-11NAG calculated gradients 3-20nonlinear row tolerance 3-13numerical gradients 3-21objective scale factor 3-17objective value 3-8omit tech. constraints 3-19OPT Hessian diagonal 3-16optimality tolerance 3-13penalty parameter 3-18pert_reset 3-22perturbation 3-15recentre 3-20relaxed violated constraints 3-19restricted step 3-20row tolerance 3-13scaling type 3-18set up inputs 3-4sigma 3-12solution phase 3-10sparse Jacobian 3-21start objective 3-11step 3-13termination reason 3-8tolerance inputs 3-12total CPU time 3-11verify 3-7zeta 3-14

Optimality toleranceSee also ESTIM DRU

initial problem parametersOptimization

problem 2-8Optimization Objects 2-5, 5-20

constraints 2-5DCS Tags 2-5fitting parameters 2-5installation 2-15objective function variables 2-5optimization variable 2-5property view

Connection tab 5-21Properties tab 5-22Transfer tab 5-25

types 2-14Optimizer 3-1

calculations 3-23

I-3

I-4

I-4

interface 2-6, 3-3optim configuration 3-4results 3-23

P

Parameter EstimationDCS Tags 6-3fitting parameters 6-3

Parameter/OffsetsSee also Data Recon Utility

Results tabProblem Formulation

See also Data Recon UtilityConfiguration tab

R

Reset frequencySee also ESTIM DRU

initial problem parametersResidual


S

Simultaneous Modular Optimization 2-4Solver Parameters and Tolerances

See also Data Recon UtilityConfiguration tab

StateSee also ESTIM DRU

final outputStep


Step limitSee also ESTIM DRU

initial problem parametersSubFlowsheet 2-3

implementation in HYSYS.RTO+ 2-4overview 2-4

U

Upper boundSee also ESTIM DRU

final outputUtilities

Bad Data Elimination 5-5Data Reconciliation 5-5

Parameter Estimation 5-5

V

ValueSee also ESTIM DRU

final outputVarbl


Verify levelSee also ESTIM DRU


hysys.rto reference guide - 한국에너지공단kemco.or.kr/up_load/blog/hysys-rto-refguide.pdfi...

Documents