Since the approximations are only locally valid (seeApproximation Concepts in Design
OptimizationandEq. 1-6inStructural Optimization), limits must be placed on the amount by which the design is allowed to vary during the approximate optimization. In NX Nastran, move limits are imposed in terms of both allowable changes in design variables and allowable changes in properties.
Imposing move limits using design variables is natural since the approximate model is explicit in these quantities. However, move limits on designed properties must also be considered as well, since the analysis model is a function of these properties. Moreover, these designed properties may be nonlinear functions of the design variables (DVPREL2 relations). A 10% change in a given design variable may equate to a 100% or more change in an analysis model property.
Since these large design changes can easily invalidate the approximate model, move limits on properties must also be included.
During approximate optimization, each design variable is bounded from above and below by
Equation 3-89.
where xiLis the lower bound on the i-th design variable and xiUis the corresponding upper bound. These bounds are determined at the beginning of each design cycle according to
Equation 3-90.
where xi0is the initial value of the i-th design variable. The allowable percentage change in the design variable is supplied by DELXV on the DESVAR Bulk Data entry. This value is optional and if not supplied, defaults to DELX, which is provided on the DOPTPRM Bulk Data entry. The DELX default is 1.0, or a 100% change in all design variables.
Note
If a DELXV is not present, the global parameter DELX provides move limits for all design variables. If a DELXV is provided, then it takes precedence by providing a specific move limit for a given design variable.
We have a similar situation for designed properties where each is bounded from above and below by
Equation 3-91.
where pjLis the lower bound on the j-th property and pjUis the corresponding upper bound.
These bounds are based on percentage changes in the property value pj0at the outset of the approximate optimization. These bounds are computed as
Equation 3-92.
where DELP is the maximum allowable percentage change in the property. DELP is defined on the DOPTPRM entry and has a default of 0.2 for a 20% maximum property variation.
Note
Move limits on properties are applied to every property referenced by the design model.
There is no provision to make these limits property-dependent, that is, to apply a different DELP for different properties.
Eq. 3-90andEq. 3-92effectively form a “box” around the current design. This effect is shown inFigure 3-8where these move limits are shown for successive design cycles in a two design variable space. For the first cycle, the approximate optimum is found to lie at a corner of the box, where the objective is minimized and there are no active constraints. As a result of the second cycle, one of the constraints is slightly violated due to errors in the approximation. By the third cycle, a near optimal design has been found. Of course, the situation is usually more complex than in this simple design space. The intent ofFigure 3-8is merely to suggest some general features of the overall process.
Note
Even though the optimizer deals with an approximate model, note that the properties are always known precisely. That is, p j=p j[x] is explicitly given by the design variable-to-property relations DVPREL1 and DVPREL2, and these relations are made available to the optimizer.
Figure 3-8. Sequence of Approximations Avoiding Small Moves with DPMIN
The DELX default of 1.0 and the DELP default of 0.2 perform well in most cases, although these values may not always yield the greatest efficiency. If any of the design variables or properties are near zero, the move limits prescribed byEq. 3-90andEq. 3-92may tend to overly restrict design moves, and hence, the optimizer’s progress. This can not only waste valuable computational resources, but the convergence decision logic may be “trapped” into believing that the design process has converged, when in reality the optimizer had just been unnecessarily restricted. To avoid this, minimum move limits are defined for both design variables and properties.
If any design variable is near zero such that |xi0| · (DELX, DELXV) << 1, the minimum lower and upper limits are defined by
Equation 3-93.
where xiL(DELX, DELXV) and xiU(DELX, DELXV) are the lower and upper bounds from Eq. 3-90.
Note
The notation (DELX, DELXV) indicates that the default provided by DELX can be overridden if a DELXV is present. SeeEq. 3-90.
Likewise, minimum move limits on properties are defined as
Equation 3-94.
where pjL(DELP) and pjU(DELP) are the lower and upper bounds fromEq. 3-92.
Recall that lower and upper limits exist for each design variable as defined by the XLB and XUB fields on the DESVAR Bulk Data entry. Regardless of the values computed inEq. 3-90andEq.
3-93, move limits cannot be outside of these values. Considering all the effects, we have for the lower and upper bounds,
Equation 3-95.
For every designed property, we have a minimum lower bound PMIN and a maximum upper bound PMAX as defined on either a DVPREL1 or DVPREL2 entry. Considering these limits on properties leads to
Equation 3-96.
Figure 3-9illustrates the situation for a property that is initially close to zero. and are the move limits resulting fromEq. 3-92. Since these limits are overly restrictive, the limits based on DPMIN, or pjLand pjUare used instead. Although not shown in the figure, if PMIN is a numerically greater quantity than pjL, it becomes the lower bound as indicated byEq. 3-96.
PMAX may also become the upper bound as well, if it is less than pjU.
Figure 3-9. Move Limits on Properties Automatic Updates of Move Limits
Parameters related to design variables can be changed using the DOPTPRM entry (DELX and DXMIN) and the DESVAR entry (DELXV, XLB, XUB). The designed property limits can be controlled using the DOPTPRM entry (DELP, DPMIN) and the DVPREL1 or DVPREL2 entries (PMIN, PMAX). This set of constants is used to recompute the move limits for each design cycle.
At times, it may be necessary for the code to automatically adjust these move limits if the problem becomes numerically ill-conditioned. The situation might arise as follows: An approximate problem is constructed, from which the optimizer determines a corresponding approximate optimum. Perhaps some of the approximate constraints are critical for this design.
The responses are now evaluated by a finite element analysis, and it is determined that rather than just critical, these constraints are actually violated. Errors have thus been detected between the approximate and the true responses.
If this error continues from one design cycle to the next, it can be taken as an indication that the move limits are probably too wide. Continued constraint violations have an adverse effect on overall convergence. The move limit-controlling parameters are updated automatically in NX Nastran if the following criteria are satisfied:
• The current design cycle number is greater than or equal to three.
• There is at least one violated constraint (violated by more than 2%), and the level of constraint violation is increasing.
Under these conditions, DELP, DPMIN, DELX, and DXMIN are reduced by one-half of their current values. The reason for the first condition is that frequently the optimizer may violate the constraints somewhat as it makes favorable gains in the objective function in the first few cycles. However, if this condition continues, it may indicate that the problem is becoming ill-conditioned as a result of excessive move limits. A corresponding User Warning Message is printed as notification that this update has occurred (seeOutput Features and Interpretation).
If the job is to be restarted, an updated DOPTPRM entry with the new move limits should be included in the restart deck.
Note
Under no conditions does an update increase the move limits. The only type of update is a reduction by one-half. The move limits cannot be increased again unless the engineer intervenes and manually changes them.
Implementation of Move Limits
Move limits on independent design variables are applied directly. Since the optimizer will never propose a value for a design variable outside of its bounds, the lower and upper move limits computed fromEq. 3-90,Eq. 3-93, andEq. 3-95are simply input directly to the optimizer.
Note
Move limits on dependent design variables are imposed as equivalent constraints, similar to that of properties in Eq. 3-97below.
Move limits on properties, however, are implemented as equivalent constraints. For the j-th property in the design model, the equivalent lower and upper bound constraints are given by
Equation 3-97.
where the lower and upper bounds pjLand pjUare given byEq. 3-94andEq. 3-96.
Eq. 3-97is necessary because the optimizer modifies design variables and not properties. Of course, the property values are known from the DVPREL1 and DVPREL2 relations. For any given set of design variables, the optimizer can useEq. 3-97to determine whether or not the corresponding properties are within their allowable limits.
Relaxation of Move Limits
Since a small numerical constraint violation is allowed by the optimizer (by default), move limits on properties may not be satisfied with equality at their bounds. This is usually of little concern except when the design is at PMIN or PMAX inEq. 3-96. Occasionally, these bounds might be slightly violated in a numerical sense but usually this is of little consequence.
A puzzling situation may occur if the current design is infeasible. If this is the case, the
optimizer’s primary task is to reduce the level of constraint violation to find a feasible solution if one exists. Since the move limits on properties are implemented as equivalent constraints, the optimizer does not know the difference between response-type and move limit-type constraints.
Thus, by seeking to reduce the level of constraint violation, some of these move limits may be violated. For initial designs with highly violated constraints, it is not unusual to see analysis model properties vary by 25% or 30% even though the move limits may actually only be 20%.
This usually does not pose any practical difficulties, but if it does, the initial move limits can always be reduced accordingly using the DOPTPRM entry. (In rare instances this optimization feature may yield a physically meaningless property value (e.g., a negative plate thickness). In this case the analysis cannot proceed and a fatal message will be issued. The remedy, should this occur, is to restart with a reduced value of DELP on the DOPTPRM entry.)
Using Design Variable Bounds to Enforce Move Limits on Properties.
In contrast, the bounds on design variables are always honored by the optimizer. Since the design variables are the quantities that the optimizer varies directly (and thus has direct control over), their bounds are never exceeded. To implement bounds on properties that are critical from a design standpoint, it is recommended that a linear design variable to property relation (DVPREL1) be prescribed if possible with appropriate bounds on the design variable (stated on the DESVAR entry). Since the design variable bounds are always enforced, the corresponding property then never exceeds its lower and upper bounds. (An exception here is with respect to dependent design variable bounds, which are always treated as constraints.)