Vous êtes sur la page 1sur 20

Troubleshooting EquationOriented Models

Troubleshooting EquationOriented Models


Aspen Plus documentation contains several kinds of troubleshooting
information for EO problems:

Troubleshoot by error or warning message

Troubleshoot by a description of the problem

Troubleshoot by checking a list of common problems

Troubleshoot using a step-by-step guide to isolate the problem

Troubleshoot problems with EO flashes without electrolytes or with


electrolytes

Troubleshoot using solver reports

Troubleshoot using EO Commands

Common Causes of EO
Problems
The problems listed below are common causes of failures in EO models.

Specifications between un-related variables. Spec-Groups allow the pairing


of any two variables regardless of the relationship between them. Pairing
variables that have no effect on one another can create a singularity.

Structural Singularities. Fixing all the variables in a single equation, either


directly or indirectly, can cause a structural singularity. These can be
trapped by the solvers, but not always. They commonly occur in these
situations:

Both the material input and output to an area of the flowsheet are fixed.

Recycle loops where all the pressures are set via pressure drops leaving the
pressures indeterminate.

This documentation is an excerpt of the Aspen Plus 2006.5 online help. 2007 Aspen Technology.

Closed circuits. Cooling or heating systems with a closed circuit are singular.
The loop must be opened and only the temperature, enthalpy and molar
volume stream attributes should be connected through User connections.

Pure component flashes. A stream with a pure component with its


temperature and pressure specified exactly at the boiling point is singular
since the enthalpy is indeterminate. The energy balance needs to be fixed,
usually by fixing the vapor fraction or the duty rather than the temperature.

Fugacities that are very large or very small. This can cause problems in the
solver. Sometimes the physical property system will set the fugacity to an
upper limit of 1E20, which may be un-solvable. A warning will be issued in
this case. Try to avoid the flash or use the Light-Key and Heavy-Key option
for the flash.

Flashes occurring in the supercritical region. The property system considers


any stream above the critical pressure and below the critical temperature to
be a liquid and above the critical temperature to be a vapor. The fugacities
at this pseudo-phase boundary at the critical temperature are not well
defined and singularities can occur in this region.

Flashes in blocks that are highly superheated or subcooled. Look for vapor
fractions that are greater than 1.5 (the upper limit is 2.0) or less than -0.5
(the lower limit is -1.0). If these streams have no chance of moving into the
two-phase region, change the phase to vapor-only or liquid-only. Though
the Auto-Phase function should do this automatically, certain flashes are not
considered such as zone analysis in the heat exchanger models.

Troubleshooting User Models in


EO
If user models are present and seem to be the cause of the difficulties, use
the following commands to help diagnose any problems.
ANALYZE JACOBIAN
As mentioned in step 13, this command can help localize analytic and numeric
differences. If there appears to be large differences, change to numeric
derivatives.
ANALYZE SPARSITY
This command compares the analytic sparsity provided by the models with
the sparsity computed by numerical perturbation. Missing numericallygenerated entries can cause non-convergence.
If the ATSLV file shows highly non-linear behavior with a user-model
equation, check that the equation is continuous. It is imperative that any
residual be continuous in value with respect to the variables. The solvers will
fail if the solution lies near the discontinuity.
Though discontinuous derivatives are not fatal, they may cause nonconvergence if there is a sizeable change in the derivative.

This documentation is an excerpt of the Aspen Plus 2006.5 online help. 2007 Aspen Technology.

Using Solver Reports for


Troubleshooting
The EO solvers generate reports with detailed information about the solution
process. These reports can be helpful in diagnosing convergence problems.
To display a solver report:

Select View | Solver Reports and click the report your want to view.

Top Commands for EO


Troubleshooting
If the EO problem fails to converge, there are some useful commands that
can be executed at the command line in the Control Panel to help diagnose
the problem.
Command

Description

EVALUATE
EQUATIONS

Evaluates all the equations in the problem

PRINT BLOCK
CONVERGENCE

Shows the root-mean-squared error for each block and


can identify the blocks with convergence difficulties

PRINT LARGEST
EQUATIONS

Shows the top ten equation residuals.

EXCLUDE BLOCK
blockid

Allows a specific block to be excluded (removed) from the


EO solution. It may be worthwhile to exclude one or more
blocks that have large errors to see if the remainder of the
flowsheet will converge.

EXCLUDE
EQUATION eqnid

Allows a specific equation to be excluded. Excluded one


equation requires that one free variable be fixed in order
to preserve net specification.

ANALYZE
JACOBIAN tol

Used to check the analytical jacobian against the


numerical. If there are large relative errors, there may be
a problem in the model.

PRINT FIXED

Used to print the values of variables that are fixed during


the current mode. This can be useful to check data entry.

PRINT
MEASUREMENTS

If measurements are configured for the problem, this


command will print a table of values. This can be useful to
check data entry.

PRINT ACTIVE
CONSTRAINTS

For bounded problems, this will show the variables that


are on their bounds which may be preventing the solution
from being reached.

The EO Variables grid can be effective for using Queries to determine if any
variables have converged to unrealistic values such as:

Negative flows

Negative compositions

Negative exchanger approach temperatures

This documentation is an excerpt of the Aspen Plus 2006.5 online help. 2007 Aspen Technology.

Troubleshooting EO Errors and


Warnings
Troubleshooting EO Errors and Warnings
Help is available for the following errors and warnings that can occur during
equation-oriented runs:

Error return due to an UNBOUNDED SOLUTION in the QP subproblem

Block vapor (or liquid) phase dropped

There is no variable named (name)

Rank deficient Jacobian in the second FACTORIZATION phase

EO Error: Unbounded Solution in the QP


Subproblem
Problem
This error occurs during an equation-oriented run:
+---------------------- ERROR ----------------------+
Error return due to an UNBOUNDED SOLUTION in the QP
subproblem. The search direction was large and no
bound was encountered.
Action : Check the EO Solver Report for diagnostic
messages.
+---------------------------------------------------+

Cause
This occurs when using the default DMO solver for equation-oriented mode.
This solver is unbounded, and may move very far from the actual solution
during the search since no bounds are enforced. Because of this, this error
may also be accompanied by other errors from models that cannot be solved
at these conditions.

Solution
You can help the solver by specifying your problem more tightly. For instance,
you can remove unnecessary flashes between a group of single-phase blocks
by specifying them as vapor-only or liquid-only as appropriate.
You can also try switching to a solver that enforces bounds, such as LSSQP.

This documentation is an excerpt of the Aspen Plus 2006.5 online help. 2007 Aspen Technology.

EO Information Message: Block Vapor


Phase Dropped
Problem
This message appears at the start of EO synchronization:
INFORMATION WHILE INSTANTIATING THE EQUATION-ORIENTED STREAM
BLOCK:
"(name)"
BLOCK VAPOR (or LIQUID) PHASE DROPPED.

Cause
This is generated by the enhancement introduced in Aspen Plus 2004.1 to
allow automatic phase dropping. When this option is enabled, Aspen Plus
automatically adjusts the allowed phases in each flash associated with a block
(outlet flash, mixed inlet flash, dew or bubble point flash) if any phases are
missing at initialization.

Solution
To prevent the appearance of this message, set the appropriate valid phases
for each feed stream in its Input | Flash Options sheet, and for each block
in its Valid phases field(s).
It is also possible to suppress the phase-dropping feature by setting Remove
missing phases to No on the EO Configuration | EO Options | Global |
Additional Options | Flash Options sheet. This is not recommended unless
the EO solutions are being driven into superheated or subcooled regions
(where phases would exist that are being suppressed by the phase-dropping
feature).

EO Warning: There is No Variable Named


(name)
Problem
During EO synchronization, these messages appear:
* WARNING
ERROR INITIALIZING VARIABLES IN TOP LEVEL HIERARCHY:
There is no variable named FEED_(component ID)_X
* WARNING
ERROR CREATING ALIASES IN TOP LEVEL HIERARCHY
EO-ALIAS RAISED THE FOLLOWING ERROR:
There is no variable named (stream ID).BLK.(component
ID)_MASS_FRAC

This documentation is an excerpt of the Aspen Plus 2006.5 online help. 2007 Aspen Technology.

Cause
These are generated when the non-zero components feature added in Aspen
Plus 2004.1 causes components to be dropped from certain streams. When
this option is enabled, Aspen Plus automatically reduces the component slate
by removing components not present at initialization. It does so with several
exceptions to avoid removing components which might appear in a block.

Solution
To prevent the appearance of these messages, specify component groups
throughout the simulation wherever certain components are missing. If you
do not want the components to be dropped, you could reduce the
Component tolerance on the EO Options sheet, or increase the flow of the
component above the component tolerance. You can also disable the Remove
Components option on any EO Options sheet to disable this feature in the
areas affected by that sheet.

EO Warning: WARNING: Rank deficient


Jacobian in the second FACTORIZATION
phase
This warning (perhaps leading to an eventual error due to a singular
Jacobian) can occur when a Calculator block being modeled by perturbation
uses the DMIN or DMAX function. If the inputs to the function are specified,
often this can pass through EO without any problem. But when the inputs are
calculated, it can create a singularity.
To resolve this problem, apply a smoothing function to the DMIN or DMAX
calculation. For example, to take the minimum and maximum of X1 and X2,
use:
DMIN = 0.50D0 * ( X1+X2 - DSQRT( (X1-X2)**2 + TOL**2 ) )
DMAX = 0.50D0 * ( X1+X2 + DSQRT( (X1-X2)**2 + TOL**2 ) )
Where TOL is the smoothing tolerance.

EO Troubleshooting Guide
EO Troubleshooting Guide
Because SM solves in a sequential-modular fashion one block at a time it
is often very straightforward to diagnose solution failures in this strategy. EO,
on the other hand, solves all the blocks simultaneously and thus it can be
difficult to pinpoint the exact cause of a failure. This document provides a
guide to diagnosing solution failures in EO. The guide is provided as
numbered steps, though they need not be followed rigorously.

This documentation is an excerpt of the Aspen Plus 2006.5 online help. 2007 Aspen Technology.

Be sure in each of these steps to reset the variable values after each failure.
This can be done by any of the following:

Re-initializing EO using Option 1 and re-solving SM.

Re-initializing EO using Option 3 to reset the variable values.

Export a variable file and re-load as needed. The variable file can be from a
previous successful solution. If none is available, the SM results can be
saved by exporting the file before the EO solution.
Once convergence is achieved, it is a good idea to exercise the flowsheet by
making changes to the operating conditions within the expected range of
operation. This will give an indication of the robustness of the specifications
as well as the modeling approach.
Be aware that the EO strategy is much more sensitive than SM. Thus,
flowsheets that operate well in SM may not always convert cleanly to EO.
However, if the problem runs well in EO, chances are its SM behavior will also
improve.

EO Troubleshooting Step 1. Ensure the


Problem is Properly Specified
DMO will not solve a problem that is either under-specified (too few fixed
variables) or over-specified (too many fixed variables) and will issue this
message:
!! DMOA: Number of equations = m do not match
Number of free dependent variables = nd
Number of free independent variables = ni
Number of fixed variables = nf
KOND (condition flag) = 4
Problem failed to converge
DMO will skip execution.
LSSQP will not solve a problem that is over-specified and will issue this
message:
!! NOPTA: Negative degree of freedom, NVAR = n NEQN = m
After GENSOLV KOND=4
LSSQP will also skip execution.
This usually means that the net specification of the problem has not been
maintained at zero. One or more blocks may have too few or too many fixed
variables. Check the specifications of the models. Use the PRINT BLOCK
STATISTICS command to check the overall degrees of freedom. For example:
---Block-- -Nvar- -Neqn- -Nfix- Nexcld -Ndof- NfreeI --Nnz- --Nz%B1
68
49
4
0
-1
0
195
6.2
F1
47
40
7
0
0
0
129
8.1
F2
47
40
7
0
0
0
129
8.1
---------- ------ ------ ------ ------ ------ ------ ------ -----Total
162
129
18
0
-1
0
453
Block B1 has -1 degrees of freedom (Ndof column) indicating that this block is
over-specified by one fixed variable.

This documentation is an excerpt of the Aspen Plus 2006.5 online help. 2007 Aspen Technology.

This is not a common occurrence since the EO structure is defined to prevent


poorly specified problems. However, user scripts can cause this to occur.

EO Troubleshooting Step 2. Use Creep Mode


in DMO
Sometimes a problem will not converge simply because it is very non-linear
and large changes are required. Like any Newton method, DMO may diverge
under these circumstances. One thing to try is to make much smaller
changes, i.e., use a homotopy method. Another is to use the DMO Creep
option to see if the problem will converge. This option causes DMO to use
smaller step sizes.
If DMO is issuing a message about a singularity, structural deficiency or
unbounded QP during the solution, then skip to step 5.
A typical case where creep is needed looks like this:
Residual
Objective
Objective
Overall
Model
Convergence Convergence Function Nonlinearity Nonlinearity
Iteration
Function
Function
Value
Ratio
Ratio
--------- ----------- ----------- ---------- ------------ -----------0
8.848D-01
0.000D+00 0.000D+00
9.693D-01
9.693D-01
1
5.862D-02
0.000D+00 0.000D+00
-9.860D-01
-9.860D-01
2
6.211D-01
0.000D+00 0.000D+00
-4.965D-01
-4.965D-01
3
1.252D+01
0.000D+00 0.000D+00
-1.885D+00
-1.885D+00
<Line Search ACTIVE> ==> Step taken 1.73D-01
4
1.225D+01
0.000D+00 0.000D+00
-1.947D+00
-1.947D+00
<Line Search ACTIVE> ==> Step taken 1.70D-01
5
1.044D+03
0.000D+00 0.000D+00
-1.120D+01
-1.120D+01
<Line Search ACTIVE> ==> Step taken 1.00D-01
6
7.795D+00
0.000D+00 0.000D+00
-1.838D+00
-1.838D+00
<Line Search ACTIVE> ==> Step taken 1.76D-01
7
8.813D-01
0.000D+00 0.000D+00
-9.229D-01
-9.229D-01
8
1.635D+00
0.000D+00 0.000D+00
-6.655D-01
-6.655D-01
<Line Search ACTIVE> ==> Step taken 3.00D-01
9
1.936D+00
0.000D+00 0.000D+00
-2.867D+00
-2.867D+00
<Line Search ACTIVE> ==> Step taken 1.29D-01
10
6.922D-01
0.000D+00 0.000D+00
-2.925D+00
-2.925D+00
11
7.150D-01
0.000D+00 0.000D+00
-1.048D+00
-1.048D+00
12
8.127D+00
0.000D+00 0.000D+00
-1.615D-01
-1.615D-01
<Line Search ACTIVE> ==> Step taken 4.30D-01
13
1.989D+01
0.000D+00 0.000D+00
-3.156D-01
-3.156D-01
<Line Search ACTIVE> ==> Step taken 3.80D-01
14
1.662D+02
0.000D+00 0.000D+00
-1.389D+01
-1.389D+01
<Line Search ACTIVE> ==> Step taken 1.00D-01
<Line Search ACTIVE> ==> Step taken 4.10D-02
15
1.525D+03
0.000D+00 0.000D+00
-2.510D+01
-2.510D+01
<Line Search ACTIVE> ==> Step taken 1.00D-01
<Line Search ACTIVE> ==> Step taken 2.14D-02

Worst
Model
------$B1HTR
$B1HTR
$B1HTR
$B1HTR
$B1HTR
$B1HTR
$B1HTR
$B1HTR
$B1HTR
$B1HTR
$B1HTR
$B1HTR
$B1HTR
$B1HTR
$B1HTR
$B1HTR

The residual will get worse as the iteration proceeds accompanied by many
line searches, indicating divergence. Also, the non-linearity ratio is negative,
indicating highly non-linear behavior. When creep is used for this case, the
output becomes:

This documentation is an excerpt of the Aspen Plus 2006.5 online help. 2007 Aspen Technology.

Residual
Objective
Objective
Overall
Model
Convergence Convergence Function Nonlinearity Nonlinearity
Iteration
Function
Function
Value
Ratio
Ratio
--------- ----------- ----------- ---------- ------------ -----------0
8.848D-01
0.000D+00 0.000D+00
9.828D-01
9.828D-01
<Line Search Creep Mode ACTIVE> ==> Step taken 1.00D-01
1
5.759D-01
0.000D+00 0.000D+00
9.941D-01
9.941D-01
<Line Search Creep Mode ACTIVE> ==> Step taken 1.00D-01
2
5.028D-01
0.000D+00 0.000D+00
9.956D-01
9.956D-01
<Line Search Creep Mode ACTIVE> ==> Step taken 1.00D-01
3
4.391D-01
0.000D+00 0.000D+00
9.962D-01
9.962D-01
<Line Search Creep Mode ACTIVE> ==> Step taken 1.00D-01
4
3.815D-01
0.000D+00 0.000D+00
9.966D-01
9.966D-01
<Line Search Creep Mode ACTIVE> ==> Step taken 1.00D-01
5
3.300D-01
0.000D+00 0.000D+00
9.970D-01
9.970D-01
<Line Search Creep Mode ACTIVE> ==> Step taken 1.00D-01
6
2.842D-01
0.000D+00 0.000D+00
9.973D-01
9.973D-01
<Line Search Creep Mode ACTIVE> ==> Step taken 1.00D-01
7
2.438D-01
0.000D+00 0.000D+00
9.976D-01
9.976D-01
<Line Search Creep Mode ACTIVE> ==> Step taken 1.00D-01
8
2.083D-01
0.000D+00 0.000D+00
9.969D-01
9.969D-01
<Line Search Creep Mode ACTIVE> ==> Step taken 1.00D-01
9
1.362D-01
0.000D+00 0.000D+00
9.976D-01
9.976D-01
<Line Search Creep Mode ACTIVE> ==> Step taken 1.00D-01
10
1.163D-01
0.000D+00 0.000D+00
9.778D-01
9.778D-01
11
5.553D-04
0.000D+00 0.000D+00
9.840D-01
9.840D-01
12
1.534D-06
0.000D+00 0.000D+00
9.993D-01
9.993D-01
13
7.331D-13
0.000D+00 0.000D+00

Worst
Model
-------$B1HTR
$B1HTR
$B1HTR
$B1HTR
$B1HTR
$B1HTR
$B1HTR
$B1HTR
$B1HTR
$B1HTR
$B1HTR
$B1HTR
$B1HTR

This case was successful using the default creep step of 0.1 and iterations of
10. More serious problems may require a smaller step size and/or more
iterations.

EO Troubleshooting Step 3. Use the


ANALYZE DOF Command
Use the command ANALYZE DOF to check if the problem is as expected. For
Simulation and Parameter Estimation modes, the command should return:
Problem is square
For Optimization and Reconciliation, the command should return the number
of degrees of freedom:
Problem has n degrees of freedom
The number returned should match the value expected. If not, check that the
degrees of freedom are properly defined.
A convenient method for showing the variables that are defined as degrees of
freedom is to use the commands
PRINT QUERY "SPEC=RECON"
and
PRINT QUERY "SPEC=OPTIM"

This documentation is an excerpt of the Aspen Plus 2006.5 online help. 2007 Aspen Technology.

EO Troubleshooting Step 4. Check Variable


Bounds
If bounds are used, they may prevent the solution from being reached.
Normally, DMO does not respect bounds in a square problem, though this
may be changed with a different line search method (Algorithm Square on
the Convergence | EO Conv Options | DMO Basic | Search sheet).
However, an optimization may fail if the bounds are too tight. LSSQP, on the
other hand, will respect bounds regardless of the mode.
Variables with active bounds may be found in the EO Variable grid by using a
query for the active bound attribute. Or they may be listed at the command
line with PRINT ACTIVE_BOUNDS.
They may also be found in the ATSLV file. For DMO, the message is
*** Variable 53 is above its UB: 3.93D-01 > 3.93D-01
Or check the ATACT file. At the bottom of the file is a table with the final
active bounds.
If using LSSQP, active bounds that affect the solution path will cause these
messages to be issued during the iterations:
Sum of residuals, original: 5.4550E-03 after trunc corr: 5.3809E03
Sum of residuals, original: 5.3814E-03 after trunc corr: 5.4509E03
It will usually end with a line search failure. Check the ATSLV file to see which
bounds are active. This can be found in the ATSLV file where the step size is
adjusted to satisfy the bounds:
Adjust D(B1.BLK.P_TEMP) from 0.63724E-04 to 0.76893E-09
LSSQP does not write to the ATACT file.
If the problem begins with violated bounds, DMO will issue a message like
this:
Information : Variable 53 B1.BLK.P_TEMP is initially
outside its UPPER bound.
Initial value = 3.9023970D-01 Upper bound = 3.7315000D-01
WARNING : This variable is not a FEASIBILITY type.
Its initial value will be moved to the UPPER bound.
WARNING : Potential INFEASIBILITY problems.
0 initial guesses moved to LOWER bounds.
1 initial guesses moved to UPPER bounds.
There may be no feasible solution due to BOUND restrictions on
other variables.
Its initial value will be moved to the UPPER bound. In LSSQP the message
appears like this:
!! NOPTA: Reset variable 57 (new index 11)

10

This documentation is an excerpt of the Aspen Plus 2006.5 online help. 2007 Aspen Technology.

B1.BLK.P_TEMP
from 117.09 to UB 100.00 C

EO Troubleshooting Step 5. Switch to


LSSQP
This solver can be more robust for a square problem (one with no degrees of
freedom) as it has a more conservative line search and will respect bounds. If
LSSQP solves the problem, it may indicate that the problem is very nonlinear. Extra bounds may be added if needed. If DMO is the preferred solver,
bounds can be respected for square problems by changing the line search
algorithm to Square.
Even if LSSQP solves, the problem may be very unstable. Change the
operating conditions and observe the convergence characteristics.
The singularity detection in LSSQP is more sensitive than that in DMO. If
there is a message regarding singularities, proceed to the next step.

EO Troubleshooting Step 6. Check if


Singularity Detected
If the problem has a very clear singularity, DMO may issue the following
message at one or more iterations:
*** WARNING: Structurally deficient Jacobian in ANALYSIS phase
...
Or at the solution DMO will issue this message:
+---------------------- ERROR ----------------------+
Error return from [DMO] due to a singular Jacobian
in the last iteration. Check largest residuals.
If small, the solution may still be correct.
+---------------------------------------------------+
ANALYZE DOF can indicate that there is a problem. For example:
Problem is structurally singular. 1 too many specifications.
The following equations are unassigned:
STR.B1.BLK.F2_MOLES
In this case, the offending equation is known.
The commands ANALYZE VARS and ANALYZE EQNS may also be used to help
localize the offending equations.
Additional information may be found in the ATSLV file. The DMO solver will list
the equations that were dropped due to the singularity. For example:
Dropped equations due to singularity (eqn/constant vars):
1: B1.BLK.INLET_MOLES

This documentation is an excerpt of the Aspen Plus 2006.5 online help. 2007 Aspen Technology.

11

LSSQP will issue a similar message to the console:


*** Jacobian is singular or near singular ***
*** Reduce n variables in m equations ***
And the ATSLV file may have something like this:
(Near) Dependent equations handled by QP are
141 STR.B1.BLK.F2_MOLES
Again the offending equation is known.
A singularity means that there are extra (redundant) equations. The solvers
will still try to converge the problem. To do so, variables are chosen as
degrees of freedom to help close all the residuals. Both solvers will list these
variables in the ATSLV file, though they are not as useful for diagnosing the
problem as the list of equations.
Once the offending equation is known, check any variable specifications that
may be associated with the equation. For example, is it related to the
material balance, energy balance or pressure balance? Then check the overall
model specifications for the appropriate balance. It may also be due to
operating conditions. Look for unusual values for variables such as a flow that
is zero is negative.

EO Troubleshooting Step 7. Check for a


Near-Singular Problem
Sometimes DMO can fail with the following message:
+---------------------- ERROR ----------------------+
Error return due to an UNBOUNDED SOLUTION in the QP
subproblem. The search direction was large and no
bound was encountered.
Action : Check the EO Solver Report for diagnostic
messages.
+---------------------------------------------------+
This can often be an indicator of a near-singular problem, where DMO did not
clearly detect the singularity.
Another indication is when DMO exhibits a convergence pattern like this:
Residual
Objective
Objective
Overall
Model
Convergence Convergence Function Nonlinearity Nonlinearity Worst
Iteration
Function
Function
Value
Ratio
Ratio
Model
--------- ----------- ----------- ---------- ------------ ------------ -------0
2.604D+00
0.000D+00 0.000D+00
9.992D-01
1.000D+00 SPLIT
1
2.693D+20
0.000D+00 0.000D+00
-2.025D+14
-2.134D+14 SPLIT
<Line Search ACTIVE> ==> Step taken 1.00D-01
<Line Search ACTIVE> ==> Step taken 1.00D-02
<Line Search ACTIVE> ==> Step taken 1.00D-03
<Line Search ACTIVE> ==> Step taken 1.00D-04
<Line Search ACTIVE> ==> Step taken 1.00D-05

12

This documentation is an excerpt of the Aspen Plus 2006.5 online help. 2007 Aspen Technology.

This indicates that the initial residual is relatively small, but the ill-conditioned
nature of the problem caused it to diverge.
Yet another indicator is very large shadow prices (1E10 or greater) in the
ATSLV file:
Index
======
159
170
150
3

Most Violated SCALED


Residuals
=======================================
SPLIT.BLK.RECYCLE_MOLES
SPLIT.BLK.H2SO44_MOLES
MIX.BLK.COLFD1_H2SO4
COL1.BLKEQN_CMASSBL_1_H2SO4

Residual
============
-6.51704D-05
6.42336D-05
-7.21017D-06
-6.93285D-06

Price
=============
4.13200D+24
4.13200D+24
4.68009D+24
-4.67878D+24

The above example shows that the unscaled residual for the stream mole flow
is very small, but because the shadow price is very large, the scaled residual
is large (leading to the residual convergence function of 1E20 in the previous
output). This would point to a problem with the flowsheet material balance.
Usually in cases like these LSSQP will detect the singularity and indicate the
offending equation. Other times it will not detect the singularity and yet solve
the problem. However, the flowsheet will not be robust to changes in the
operating conditions. If DMO appears singular but LSSQP solves the problem,
exercise the flowsheet with LSSQP to check the robustness of the model.
This is harder to diagnose since the solvers did not directly detect the
singularity. In this case, it is best to proceed to the following steps to help
localize the troublesome equations.

EO Troubleshooting Step 8. Disable EO


Configuration Input
Remove any EO Configuration input by disabling Spec Groups and
Connections you have specified. This input can sometimes lead to badly
defined problems. They may be turned off all at once and if the problem
converges turned on one at a time until the problematic input is discovered.
Often a specification swap is made between variables that have little effect on
one another and this can cause a near-singularity and non-convergence.
Also be sure to check the values entered in EO Input forms, as a bad value
can also lead to non-convergence.
Normally, if all the EO Configuration information is removed, then EO should
be solving the same problem as SM and thus EO should begin with nearzero residuals provided the SM solution was complete (loosely converged
recycle streams may cause non-zero residuals at the start of EO). If not, then
there may be an issue with the basic structure of the flowsheet. SM may not
have had a problem, but EO, being more sensitive, will fail. Use PRINT
LARGEST EQUATIONS to find the equations that are open. (See step 10 for
more information.)

This documentation is an excerpt of the Aspen Plus 2006.5 online help. 2007 Aspen Technology.

13

EO Troubleshooting Step 9. Exclude DesignSpecs and Calculators


Design-Specs and Calculators may work well in SM but in fact can sometimes
create very ill-conditioned problems in EO. Use the EXCLUDE BLOCK
command to remove these blocks from the EO problem. Again, the blocks
may be all excluded at once and if the problem converges turned on one at a
time.

EO Troubleshooting Step 10. Localize


Troublesome Blocks
Use PRINT LARGEST EQUATIONS to see the largest equations in the problem.
This will print the largest unscaled equations. If they are associated with a
single block, this block may be the cause of the problem. Note that the
magnitude of the scaled equations will be affected by the magnitude of the
variables involved. Thus, it is not unusual for the largest equations to be
associated with energy balances and enthalpies, which are evaluated in Joules
inside the models. The key is to compare the relative magnitude of the
equations with the magnitude of the variables involved. So an energy balance
with an error of 100.0 is not of concern, but a composition with an error of
0.1 is.
Recall that if all the EO Configuration is disabled, the initial residuals should
be very small, provided the SM solution was complete. Issuing this command
immediately after EO synchronization can therefore indicate any block that
has initial open residuals.
If the SM solution was not complete, such as the case with loosely converged
recycle streams, then the largest equations will begin with STR, which are the
stream connection equations. It may be that EO cannot converge the recycle
due to the manner in which it was specified.
Check the ATSLV file and compare the scaled and unscaled values of the
residuals. DMO will report each along with the shadow prices of the residuals.
If the shadow prices are very large (greater than 1E10) then there may be a
singularity that was not trapped by the solver. So even if the actual residual is
small, the scaled residual can be very large if the shadow price is large.
Another indication is if the initial residual in the console output is very large
(greater than 1E10). See step 7.
If it seems that one particular block is causing the problems, use the
EXCLUDE BLOCK command to remove the block from the EO solution and run
the problem again.
Another procedure to try is to exclude all the blocks then include one at a
time and solve each one alone. This procedure isolates badly specified blocks.
The following script shows how this process can be automated:
exclude block all
dmo.maxiter=10
set failed = []
for ib in &blocks do

14

This documentation is an excerpt of the Aspen Plus 2006.5 online help. 2007 Aspen Technology.

echo "solving block " . &ib


include block &ib
solve
exclude block &ib
if ( not &converged ) then
set failed = &failed . [&ib]
endif
endfor
echo &failed
The script will print to the terminal a list of blocks that failed to converge in
10 iterations.
If one particular block is not converging, examine the specifications of the
block. It may be the block itself contains an infeasibility or singularity that
was solved in SM but fails in EO. One example is the singularity created with
a TP specification on a pure component stream exactly at the boiling point.
If all the blocks solve individually, then the problem may only occur because
of the stream connections between the blocks. This may be an indication that
a recycle stream is not specified correctly. Try excluding one of the blocks in
the recycle to open the loop. If this converges, then the specification of the
recycle needs to be examined. Check the pressure configuration at least
one block within the recycle loop must have an outlet pressure specified.
Specifying only pressure drops will leave the loop pressure undetermined.
Similarly, check that the material flows are properly defined. Do not create a
situation where the all the inlet and outlet flows to a part of the flowsheet are
fixed.

EO Troubleshooting Step 11. Localize


Troublesome Equations
Sometimes an entire flowsheet will fail due to one equation that is causing
difficulties due to its non-linear behavior. This may be found in the ATSLV file.
For DMO:
Index

Worst Equation Non-Linearity Ratios

===== ========================================
491
590
589
511
502

$B1HTR.BLK.LMTD
$B1HTR.BLK.PT_9_LMTD
$B1HTR.BLK.PT_8_LMTD
$B1HTR.BLK.FC12_INTERP_PT_9_DUTY
$B1HTR.BLK.FC11_INTERP_PT_9_DUTY

Ratio

Deviation

============

============

-2.02771D+01
6.02861D+00
5.51072D+00
4.17770D+00
2.93968D+00

2.12771D+01
5.02861D+00
4.51072D+00
3.17770D+00
1.93968D+00

The Ratio should be near one. Large negative values, such as that shown
above, indicate that the equation is behaving in the opposite direction of that
predicted by the solver.
For LSSQP:
OBJECTIVE AND WORST MERIT FUNCTION CONTRIBUTORS
----------------------------------------------Penalty
Equation
Difference

Old
Value

New
Value

This documentation is an excerpt of the Aspen Plus 2006.5 online help. 2007 Aspen Technology.

Predicted
Value

15

=========================================== =========== =========== =========== ===========


Objective function
$B1HTR.BLK.FC12_INTERP_PT_6_DUTY
$B1HTR.BLK.PT_6_LMTD
$B1HTR.BLK.PT_5_LMTD
$B1HTR.BLK.PT_6_INC_UA
$B1HTR.BLK.PT_5_INC_UA

0.0
2.26721D-1
5.17216D-4
5.16741D-4
1.11661D-4
1.11381D-4

1.00000D+0
-1.40978D+4
-1.40875D-3
-1.41405D-3
-6.27624D+0
-6.26055D+0

1.00000D+0
2.26721D+5
2.39803D-2
2.40705D-2
1.11661D+2
1.11381D+2

1.00000D+0
1.8190D-11
-1.6098D-15
-3.6555D-15
-7.4269D-12
-6.4571D-12

The Penalty Difference should be near zero.


Note that these tables may be printed more than once for each iteration if the
solver is performing a line search. As the step size is reduced during the line
search, the non-linearity should improve.
If there seems to be one equation that is causing difficulties, it may be that
the model is moving to a region where the equations are ill-defined such as
a point where a flow is zero or negative. Determine which variables affect the
equation by entering the command:
PRINT JAC EQUATION equationid
This will list all the variables affecting the equation with their derivatives.
Examine the values of the variables using PRINT VARIABLES or look in the EO
Variables grid. If any seem unreasonable, then place bounds on the
appropriate variables (remember that if the case is square, DMO will not
respect bounds unless you change the line search algorithm to Square).
However, recall that bounds may lead to infeasible solutions. If so, then there
may be a problem with the flowsheet conditions.
If the variable values seem reasonable, then proceed to the next step.

EO Troubleshooting Step 12. Check Variable


Scaling
Sometimes an equation associated with a particular variable will have poor
behavior due to the magnitude of the variable. This may occur when the value
of the variable is very large (greater than 1E20) or very small (less than 1E10). The most common instances are:

The pressure drop parameter in the Heater model. In this case, change the
scale factor of the pressure drop parameter variable.

Very large or very small fugacities in a flash (common to almost all models).
In this case, the scale factors of the both the fugacity and composition may
need to be changed.
The scale factor may be changed from the command line with:
variableid.SCALE = value
or in the EO Input form. Enter a large value if the variable is very large or a
small value if the variable is very small. Begin with values on the order of 103
or 10-3 and adjust from there. Do not simply enter the magnitude of the
variable as the scale factor. The scale factor probably should not exceed 10+9
and 10-9.
The scaling for all the model variables can be checked by printing a file with
the variable values and scale factors. Use the command:
WRITE VARFILE [VALUE, SCALE] TO "SCALING.VAR"

16

This documentation is an excerpt of the Aspen Plus 2006.5 online help. 2007 Aspen Technology.

Load this file into Excel and compute a scaled value as:
ScaledValue = abs(value) / scale
Sorting this new column in ascending order can help localize poorly scaled
variables.
Generally, the most problematic scaling issues are associated with variable
values that are very large. It is not normally advisable to modify scale factors
for values that are very small, unless the solution to the particular EO
problem has a strong dependence on the exact values of the very small
variable values (such as in kinetic reaction mechanisms where reactive
intermediates are being modeled, and their concentrations are very small but
important).

EO Troubleshooting Step 13. Check the


Model Derivatives
Models or equations that will not solve and have poor non-linearity indicators
may have problems with their equation derivatives. One thing to check is the
accuracy of the analytic derivatives. In rare instances, they could be
incorrect. Even if not, this information may be helpful in pinpointing the
problem (such as pointing to variables with unreasonable values). Use the
ANALYZE JACOBIAN command to compare the analytic and numeric
derivatives. For example,
ANALYZE JACOBIAN 0.1
Will list all the derivatives whose analytic and numeric values differ by more
than 0.1 fraction of one another. Ignore the following differences:

Derivatives that are very small. These may be just noise effects.

Derivatives of physical properties with respect to compositions whose mole


fractions are very small negative values. There is a sign reversal due to the
forward differencing method used for numeric derivatives when the
magnitude of the composition is less than the perturbation size.

Derivatives of flash equations with respect to the vapor fraction where the
flash lies right on the phase boundary. There is a known discontinuity at the
phase boundary for the flash equations.
If there is some question about the accuracy of the analytic derivatives,
change to numeric derivatives:
blockid.DERIV_METHOD = NUMERIC

EO Troubleshooting Cases
EO Troubleshooting Cases
Case 1: EO problem is not incorporating the results of an SM Design-Spec,
optimization, or balance block.

This documentation is an excerpt of the Aspen Plus 2006.5 online help. 2007 Aspen Technology.

17

Case 2: EO problem is not using data specified on EO Input or EO Options


forms after a reinitialization or change in SM problem specifications.
Case 3: Using the Specification Vapor Fraction Equals 0 or 1

Using SM Flowsheet Operation Results in


EO
EO problem is not incorporating the results of an SM Design-Spec,
optimization, or balance block.

Cause 1
The SM flowsheet operation is manipulating a stream variable that is not a
feed stream to the process. The specification is overwritten by the results of
another block.

Solution 1
Change the specification of the flowsheet operation so it manipulates a feed
stream to the process.
Note: A feed stream inside a hierarchy block is not really a feed stream; the
attached stream outside the hierarchy block is feeding into it. In this case, the
variables of the stream inside the hierarchy block are set to match the values
of the corresponding stream outside the hierarchy block. A manipulation of
this stream should be placed outside the hierarchy block and should
manipulate the stream outside the hierarchy block.

Cause 2
The SM flowsheet operation is manipulating a variable that does not have a
fixed specification in EO.

Solution 2
Either add a spec group to make this variable fixed, or change the
specifications of the SM problem so that the variable manipulated is specified.

Cause 3
Some input variables cannot be updated by Input Reconciliation, so the
results of the SM flowsheet will not be carried over into EO.
Check the list of Input Reconciliation limitations to determine whether this is
the problem. The variables described cannot have their input values updated
as a result of such manipulations.

18

This documentation is an excerpt of the Aspen Plus 2006.5 online help. 2007 Aspen Technology.

Solution 3
Redesign the flowsheet operation so it does not depending on manipulating
such variables, or set explicit specifications in EO for the final values of the
SM flowsheet manipulation.

EO Data Specifications After Reinitialization


EO problem is not using data specified on EO Input or EO Options forms after
a reinitialization or change in SM problem specifications.
When you perform a reinitialization in an EO problem, you have four options
for the scope of this reinitialization. Some of these options may not use some
EO variable specifications made at the top level or hierarchy level.

Cause 1
If you choose Reinitialize equation oriented simulation with changes in
configuration, Flowsheet/Hierarchy level EO-Input and EO-Options may not be
used during initialization after specifying sequential-modular input changes at
the block level, and you also have specified equation-oriented variable values
or other attributes on the EO Input or EO Options forms at the top level or
at the level of a hierarchy block, these specifications will be ignored in this
type of initialization. This type of reinitialization may also be performed
implicitly when you change SM block specifications and rerun the problem in
EO.

Solution 1
If you want these specifications to always be invoked, specify them in the EO
Input form or the Block Options EO Options sheet within the block.

Cause 2
If you choose Rebuild equation oriented simulation and reinitialize with
current EO results after an SM input change resulting in the rebuild of a block,
EO Input variable value statements referencing the block at the hierarchy or
flowsheet levels will be overwritten by the restored variable value vector.

Solution 2
To do other forms of reinitialization, save the variable values in an external
file prior to performing the SM input changes and then import the saved
variable values after the re-initialization is complete. Use the export (

) and

import (
) EO variables buttons on the control panel to export and import
these files.

This documentation is an excerpt of the Aspen Plus 2006.5 online help. 2007 Aspen Technology.

19

Using the Specification Vapor Fraction = 0


or 1
It is difficult to converge a specification of vapor fraction = 0 or 1 in EO.
Instead of specifying 0 or 1, set the stream to single phase, if possible.
Alternatively, make the specification tighter by specifying how close you want
to get to 0 or 1. For instance, set the vapor fraction to 0.001 or 0.999.

20

This documentation is an excerpt of the Aspen Plus 2006.5 online help. 2007 Aspen Technology.

Vous aimerez peut-être aussi