In Frequency Response analysis, a number of forcing frequencies may be used. Similarly, a number of analysis time steps may be used in a transient analysis. Both of these analysis types have the potential to generate a huge amount of design response data. This could get quite expensive, as sensitivities (discussed inExample Problems) may need to be computed for all of these design responses.
Limiting the Number of Design Responses with OTIME and OFREQ
To keep this data to a minimum, the OFREQ and OTIME Case Control commands can be used to limit the number of design responses. For frequency response, design responses are only computed for those frequencies referenced by the OFREQ command. Otherwise, design responses will be computed for all forcing frequencies by default.
Note
Time steps can be stated explicitly in the ATTB field of the DRESP1 entry. If this value is not equal to any of the time values shown inFigure 2-25, then the nearest available reduced time step in the figure will be used.
For transient response, design responses are only computed for the output time steps. Output time steps are defined by the NOi fields on the TSTEP Bulk Data entry and may be further limited by the OTIME Case Control command. In the absence of any NOi or OTIME definitions, design responses are computed for all analysis time steps. Figure 2-25is a schematic that indicates the levels of time step reduction.
Figure 2-25. Output Time Step Reduction.
Similarly, for frequency response, if the value of a frequency in the ATTB field is not equal to any of the frequencies in the relevant frequency set for the applicable subcase, NX Nastran replaces the value in the ATTB field with the nearest frequency in the set.
Design responses can also be computed for a single forcing frequency, or for a single time step.
We may want to define a design response as a displacement average over time. Having identified a peak transient response, this technique could help us to reduce this overshot. (Often, as a design is modified, the transient peak will “move around” some from one design cycle to the next. Computing an average, rms, or other measure over time or frequency, will often yield more useful results.)
The following example illustrates the formation of an average displacement over five time steps.
This average is based on the z-component of displacement for grid 100.
$ Identify component displacements:
$DRESP1,ID, LABEL, RTYPE, PTYPE, REGION, ATTA, ATTB, ATT1, +
$+, ATT2, ...
$ Generate average displacement over time...
$DRESP2,ID, LABEL, EQID, REGION, , , , , +
$ ...using the equation input capability
$DEQATN EQUID F() = ...
DEQATN 200 AVERAGE(U1,U2,U3,U4,U5) = (U1+U2+U3+U4+U5)/5.
Note
If response values change sign, an RMS average may yield more useful results.
DRESP1 entries 11 through 15 identify the z-component of displacement at grid 100 for time steps .051, .052, .053, .054, and .055. Note that each entry defines a single displacement
component at a single grid for a single time step. The DRESP2 defines the second-level response by identifying each of these individual responses as input to a DEQATN entry. The resulting second-level response can either be used as an objective or constraint.
2.7 Defining the Objective Function
The objective function is a scalar quantity that is either minimized or maximized by the optimizer. You define the design objective using the DESOBJ (DESign OBJective) Case Control command. This command points to a design response defined on a DRESP1, DRESP2, or DRESP3 Bulk Data entry that must define a single scalar response only.
Formulating the Objective: Sensitivity with Respect to Design Variables
When formulating the design objective, there are a couple of scaling-related issues that should be kept in mind since they affect overall performance. First, the design problem should be posed so that the objective function has sufficient sensitivity with respect to each of the design variables.
This is a relative type of consideration and is somewhat difficult criteria to define in a general sense. However, the idea is as follows: Suppose a weight design objective is on the order of 1,000 kilograms. If a structural element in the model is on the order of 1.0E-3 kg or less and its volume is a function of a single design variable, then varying this quantity by 100% or more does not have any appreciable effect on the overall weight. It is probably a better idea either to link a number of these types of elements together and relate them all to a single independent variable (resulting in a larger weight change) or to eliminate these element groups entirely from the redesign process.
Prior to optimization, it is always advisable to perform a design sensitivity analysis first to ensure that the objective function has sufficient sensitivity with respect to the design variables.
Formulating the Objective: Magnitude
The second item to consider is the absolute value of the response selected to be the objective function. Care should be taken that this value is not too close to zero. Here again it is difficult to define what range of values is too small, but the absolute value of the objective should be greater than about 1.0 if possible. If this requirement is not met, there are a couple of ways in which this may pose problems.
Note
Does your design “converge” after only a single design cycle? If so, and your initial objective function value is on the order of 1.0E-2 or smaller, CONV2 (on the DOPTPRM entry) should be reduced.
For very small absolute values of the objective function, the default convergence criteria will not be satisfactory. The convergence criteria logic is detailed inConvergence Tests, but of interest here is the test on absolute change in the objective function. This default is 0.01, but can and should be changed using a DOPTPRM (Design OPTimization PaRaMeters) Bulk Data entry. With the default, if the objective function changes by less than 0.01 (absolute) from the previous design cycle and all constraints are satisfied, the process has converged. This may not be a reasonable test if the original objective function is small.
The optimizer itself may also run into numerical difficulties for small absolute values of the objective function. This situation may affect the optimizer’s estimates of an initial value of a for the one-dimensional search as well as the convergence criteria at the optimizer level. Again, the defaults can be changed using the DOPTPRM entry, although determining correct values for the override may not be easy. It may be far better to rescale the problem, multiply the objective by 100, or other such avoidance, rather than try to change the optimizer’s defaults.
Formulating the Objective: Sign Changes
If the objective function is a response, it is important that you know whether the response is expected to change signs for different designs that may be generated during the optimization.
For example, minimizing a positive displacement means driving it in the direction towards zero.
However, if the displacement changed sign during the optimization, then the same minimization would try to drive it towards negative infinity. In such cases, it may be better to use a device that would minimize the absolute value through a DRESP2 entry as applicable, such as the square root of the square or of the sum of the squares.
2.8 Defining the Constraints
Any first-or second-level response may be constrained simply by referencing it on a DCONSTR (Design CONSTRaint) Bulk Data entry. This entry defines the response to be constrained and its corresponding bounds.
To define constraints in NX Nastran, you need to
• Identify a first-level response (or group of responses) using a DRESP1 Bulk Data entry or write a second-level response (or group of second-level responses) using a DRESP2 or a DRESP3 Bulk Data entry. If the DRESP2 or DRESP3 entry references a DRESP1 entry, the DRESP1 entry can be a generic DRESP1 entry or a DREPS1 entry assigned to specific subcases with a DRSPAN Case Control command. If the DRESP2 or DRESP3 entry reference a DRESP1 entry that is assigned with a DRSPAN Case Control command, then all DRESP1 entries referenced by the DREPS2 or DRESP3 entries must be assigned with a DRSPAN command.
• Specify the response bounds by using a DCONSTR entry that references the DRESP1, DRESP2, or DREPS3 defined response or set of responses, for example, if it is defined over a frequency set.
• Select DCONSTR entry sets in the Case Control section using either the DESGLB command for “global” (DRSPAN related, therefore subcase dependent, or not DRSPAN related,
therefore subcase independent) responses or the DESSUB command for subcase-dependent responses. Responses or constraints become subcase-dependent when any related DRESP1 entries are referenced from a DCONSTR entry that is, in turn, referenced from a SESUB command belonging to a subcase, rather than assigned with a DRSPAN command. Therefore, you can reference the non-DRSPAN related responses from more than one subcase by using differently numbered DCONSTR entries that are referenced from DESUB commands from different subcases.
The DCONSTR entry bounds are used by NX Nastran to create a pair of normalized
constraints—one for the lower bound and one for the upper bound. For any given response, the bounds are a statement of the inequality relation
Equation 2-28.
where rjLis the lower bound on the j -th response and rjUis the corresponding upper bound.