Preparing Data

Preparing Test Data

Attune supports four file formats for importing test data: I-deas shape (.ash), Universal file (.uff, .unv), Nastran DMIG (.dmi, .dmig, .pch) and OP2 (.op2). The test data file contains the mode shape, frequency, and coordinate trace for each test shape. Any properly formatted I-deas shape file should be acceptable to Attune. Universal file import supports data sets 55 and 2414. In DMI or DMIG file format, Attune is expecting two matrices: a shape matrix containing the eigenvectors and the LAMA table output. LAMA is a Nastran data block containing eigenvalues, generalized mass, and stiffness. It is described in the Nastran DMAP Programmer’s Guide. Since Attune cannot know on import what name will be given to the matrices in the file, it will prompt the user to identify the matrix containing the shapes and eigenvalues. In OP2 files, Attune will read in any of the following datablocks: OUGV1, BOUGV1, OPHIG, or BOPHIG. These datablocks are generated by a DISPLACEMENT(PLOT) output request. All test shape data is expected to be in the same coordinate system as the analysis data.

See the section on the Test Tab of the Configuration Form for details on preparing test data for frequency-only correlation.

Preparing Analysis Data for Nastran

Attune accepts data from Siemens Simcenter Nastran or MSC.Nastran version 2001 or later. Attune supports analysis data produced by Nastran solution sequences 103 (Normal Modes) and 200 (Design Optimization). The Nastran data can be written to either punch or OP2 files. The table below lists what data is required and optional in the Nastran output. There are very few changes required in the Nastran input deck to produce the Attune-compatible output. An example deck for a normal modes solution sequence and an example deck for a design optimization solution sequence are shown at the end of this section.

Required Output for Attune

Data Set

Required Or Optional

Notes

Displacement Mode Shapes

Required.

Must be in “Global” CS.

Reduced Mass Matrix

Optional. Used for cross-orthogonality.

Use either provided DMAP alters to output mass.

Back Expansion Matrix

Optional.

FEM Geometry

May be required for mapping nodes. Optionally used for visualizing shapes.

Sensitivity Matrix

Required for optimization.

Use attune.dmap to output.

For SOL 103, no additions to the Nastran input are required. The user only needs to add the indicated lines if cross-orthogonality will be used as a metric for shape correlation or if a back-expansion matrix is desired.

Please observe the note in the table above concerning output of the displacement mode shapes. They must be output in the “global” coordinate system. The global coordinate system in Nastran is the name given to the union of all displacement coordinate systems (local, nodal coordinate systems). If output is sent to punch, no user intervention is required since punch output is always in the global coordinate system. If output is sent to OP2, the user must include a PARAM statement to set POST to -2 and OUGCORD to GLOBAL.

If the user does wish to use cross-orthogonality, the Attune DMAP must be included. The parameters, OUTFORM, MREDUC, REDMETH, DYNFREQ, NMODES, and OUTDRM control the behavior of the DMAP.

  • OUTFORM sets the output format for the matrices. It can be set to PUNCH or OP2.

  • MREDUC dictates whether the ASET or the USET will be used to reduce the mass matrix. MREDUC is NONE by default, meaning no mass matrix is output. If ASET is used, the mass matrix corresponding to the a-set will be output. If USET is used, the mass matrix will be reduced to a user-defined U1 set. The U1 set must be defined by the user with USET or USET1 cards and should be set equivalent to the TAM DOF. TAM means Test-Analysis Model. The TAM is the analysis model reduced to the test DOF. If USET is used instead of ASET, a reduced-mass matrix can be produced in the same DOF as the test without affecting the normal modes calculation. Note that rigid body modes may be included in the analysis but may be problematic in terms of characterizing the error. The user may wish to exclude the rigid body modes on the EIGRL card or by using OMODES.

  • REDMETH sets the reduction method used for creating the reduced-mass matrix and/or the back-expansion matrix. The choices are STATIC, DYNAMIC, IRS, MODAL, and HYBRID. STATIC is the default model reduction.

  • DYNFREQ sets the center frequency for the dynamic reduction.

  • NMODES sets the number of modes to be used for the modal and hybrid methods. The default is to use all modes.

  • OUTDRM controls whether the back-expansion matrix is output (by default, it is not). An example input file is provided in the Attune distribution (example/gpsc/gpsc103.dat).

SOL 103
INCLUDE 'attune30.dmap'        % required only to output mass matrix
CEND
$
TITLE    = Test Case Normal Modes
SUBTITLE = MODES to 120 Hz
$
ANALYSIS = MODES
$
INCLUDE 'display_set.blk'
DISP (PUNCH) = 100              % can set to punch or op2, should agree with OUTFORM
$
METHOD = 120
BEGIN BULK
EIGRL        120           120.0
$ Model bulk data
INCLUDE 'fem.blk'
$ Define PARAMs
PARAM,OUTFORM,PUNCH             % not required, select punch or op2 output
PARAM,MREDUC,USET               % not required, use ASET or USET to reduce mass matrix
$
$  Define Aset DOF as U1 set    % required only to output mass matrix
INCLUDE 'fem_uset.blk'          % can use ASET or USET (U1)
ENDDATA

For SOL 200, the only required additional line in the input file is the INCLUDE for the Attune DMAP. The same DMAP is used for both SOL 103 and SOL 200. Attune will not support optimization or model updating without the inclusion of this DMAP alter. If the user wants to use cross-orthogonality as the mode shape metric, the user must include an ASET or USET as discussed above for SOL 103. An example input file is provided in the Attune distribution (example/gpsc/gpsc200.dat).

SOL 200
INCLUDE 'attune30.dmap'      % required to run optimization in Attune
CEND
$
TITLE    = Test Case DesOpt
SUBTITLE = MODES to 120 Hz
$
ANALYSIS = MODES
$
INCLUDE 'display_set.blk'
DISP (PUNCH) = 100              % can set to punch or op2, should agree with OUTFORM
DSAPRT(END=SENS) = ALL       % required to turn off optimization in Nastran
$
METHOD = 120
BEGIN BULK
EIGRL        120           120.0
$ Model bulk data
INCLUDE 'fem.blk'
$ Include design variables
INCLUDE 'fem_desvar.blk'        % design variables and properties do not need to be
INCLUDE 'fem_dvrel.blk'         % in separate files
$ Define PARAMs
PARAM,OUTFORM,PUNCH          % not required, select punch or op2 output
PARAM,MREDUC,USET           % not required, use ASET or USET to reduce mass matrix
$
$  Define Aset DOF as U1 set    % required only to output mass matrix
INCLUDE 'fem_uset.blk'       % can use ASET or USET (U1)
ENDDATA

Guidelines for Creating Design Variables for Nastran

Attune has the capability to create design variables for the user based on a SOL 103 input deck or to add design variables to an existing SOL 200 input. However, not all design variable options are supported by this interface. The user may instead wish to create design variables manually. In that case, the following guidelines are provided to assist the user in defining design variables.

The value of a designed property (material or physical) is given by the product of the value on the DESVAR card and the value on the DVPREL1 or DVMREL1 card. It is suggested that, at the beginning of the correlation process, the DVPREL1 or DVMREL1 card contain the nominal value of the designed property and that the DESVAR be set to 1.0. Since the change in DESVAR value is part of the objective function, if the DESVAR contained the nominal value, the importance of changes in designs would be affected by the magnitude of the nominal value. For example, a 1% change in modulus of elasticity (i.e., 100,000 psi) would be significantly more important to the objective function than a 1% change in the thickness of a shell (0.01 in) just because of the relative magnitudes of the changes. In this example, if the DESVAR cards for both the modulus and shell thickness had both been set to a nominal value of 1.0, a 1% change in either quantity would be weighted equally. Of course, the user can change the weighting by using the individual or overall design weight.

The DESVAR card may have three values (XLB, XUB, DELXV) after the initial variable value (XINIT). These values are used in defining the upper and lower bounds and limit as discussed in the section on the Design Variable Form. The lower and upper bounds (XLB and XUB, respectively) are permanent bounds on the design variable. The design variable will not be allowed to take a value outside those bounds. The limit (DELXV) specifies the fractional change in design variable value that is allowed within a particular optimization session. In other words, if DELXV were set to 0.1, Attune would interpret that to mean a range of ±10% on the DESVAR. A DESVAR can have all three values set or can have any combination of upper and lower bounds and limits that at least provides some limiting factor on either side of the initial value.

Note that since Attune can process multiple configurations simultaneously, design variables may be shared across configurations. Design variables must have unique identifiers for both ID and label. If a design variable is a member of multiple configurations, that design variable must have the same identifiers in all cases.

Preparing Analysis Data for Abaqus

Attune also supports analysis data produced by Abaqus version 6.5 or later. A design sensitivity analysis (DSA) is performed in Abaqus to generate the information utilized by Attune. An Abaqus model that is set up to perform a normal eigensolution must be modified slightly to perform the DSA. Design parameters (*PARAMETER and *DESIGN PARAMETER) need to be added to the model section of the input deck to identify the variables for the sensitivity calculations. The variable names must be 8 characters or fewer. In the step section of the input file, the user must specify that a DSA is to be performed on the step keyword (*STEP, DSA=YES). Finally, the user must request the design sensitivities be written to the output database (.odb) (*OUTPUT, HISTORY, *DESIGN RESPONSE). A portion of a sample input file with these keywords is shown below. The required data are copied from the Abaqus .odb file into a format specific to this application (*.a4a) by a Python script called toAttune.py. The Python script is included with the Attune distribution. It is located in the top-level directory of Attune and is compatible with Python version 2.2.3 or later. The Python script is dependent on modules provided by Abaqus. Therefore, the recommended method for running the script is to type the following at the command prompt:

abaqus python toAttune.py filename.odb
…
*SHELL SECTION, ELSET=PSHELL_10,
 MATERIAL=MAT_MID_1,
 DENSITY=0.001295
 <pshel10t>,
…
 *SHELL SECTION, ELSET=PSHELL_11,
 MATERIAL=MAT_MID_1
 <pshel11t>,
*parameter
pshel10t=1.00
pshel11t=0.25
*design parameter
pshel10t, pshel11t
…
*STEP, dsa=yes
*FREQUENCY, EIGENSOLVER=LANCZOS, NORMALIZATION=mass, SIM=no
20,
*output, history
*design response
*output, field
*node output
u,
*END STEP

The Abaqus data does not contain a reduced-mass matrix and therefore does not permit the use of cross-orthogonality in the correlation. In addition, Abaqus data contains only the diagonal elements of the sensitivities of the modal stiffness matrix. For this reason, the analysis mode shapes cannot be updated during an Attune session. Attune will still report the correlation of the shapes using cross-MAC, but only the frequencies will change when Abaqus data is used. By default, the state variables associated with cross-MAC are set to zero weight when Abaqus data is used. To find out how design changes affect mode shapes, the user will have to rerun Abaqus with the updated design.

Mass sensitivity data and rigid body mass properties are also not available from Abaqus.

Preparing Analysis Data for Salinas

Attune also supports analysis data from Salinas. Like Nastran, Salinas has the capability to do sensitivity analysis. If the user adds the Attune and AttuneNodeset specifiers to the SENSITIVITY block in the Salinas input file, Salinas produces a file with a .s extension that contains all the data Attune expects. The nodeset called out by the AttuneNodeset is defined in the Exodus file. The second file required for Salinas support is a “master input file.” This is a copy of the original sensitivity analysis input file, where the design variable definitions have been changed slightly so that Attune can automatically create updated .inp files. For example, a design property in Salinas input might look like:

Area = 4.0 +/- 0.01 percent

In the master input file, this line would be rewritten:

Area{Attune_P14=4.0} +/- 0.01 percent

The string in the braces identifies this parameter as the design variable P14. The design variable will be labeled in the Salinas output with a string that includes the element block number and property type (e.g., Element Block 10 area). Attune parses the master input file to determine the design variable’s initial value (4.0).

Example of Salinas .inpm file. This block defines the design variables for a BAR property.

BLOCK 2
// 14 elements of type BEAM. 2 nodes/element
// property card 'PBAR           2'
material=1
Area={ATTUNE_P14=4.0} +/- 0.01 %
I1={ATTUNE_P13=1.33} +/- 0.01 %
I2={ATTUNE_P12=1.33} +/- 0.01 %
J=2.667
orientation= 0. 0. 1.
END