MD Nastran 2011 & MSC Nastran 2011 Release Guide

MD Nastran 2011 &
MSC Nastran 2011

Release Guide
Main Index
Worldwide Web
www.mscsoftware.com
Disclaimer
MSC.Software Corporation reserves the right to make changes in specifications and other information contained
in this document without prior notice.
The concepts, methods, and examples presented in this text are for illustrative and educational purposes only,
and are not intended to be exhaustive or to apply to any particular engineering problem or design. MSC.Software
Corporation assumes no liability or responsibility to any person or company for direct or indirect damages resulting
from the use of any information contained herein.
User Documentation: Copyright 2011 MSC.Software Corporation. Printed in U.S.A. All Rights Reserved.
This notice shall be marked on any reproduction of this documentation, in whole or in part. Any reproduction or
distribution of this document, in whole or in part, without the prior written consent of MSC.Software Corporation is
prohibited.
This software may contain certain third-party software that is protected by copyright and licensed from
MSC.Software suppliers. PCGLSS 6.0, Copyright 1992-2005, Computational Applications and System
Integration Inc. All rights reserved. PCGLSS 6.0 is licensed from Computational Applications and System
Integration Inc. METIS is copyrighted by the regents of the University of Minnesota. A copy of the METIS product
documentation is included with this installation. Please see A Fast and High Quality Multilevel Scheme for
Partitioning Irregular Graphs. George Karypis and Vipin Kumar. SIAM Journal on Scientific Computing, Vol. 20,
No. 1, pp. 359-392, 1999.
MSC, MD, Dytran, Marc, MSC Nastran, MD Nastran, Patran, MD Patran, the MSC.Software corporate logo,
OpenFSI and Simulating Reality are trademarks or registered trademarks of the MSC.Software Corporation in the
United States and/or other countries.
NASTRAN is a registered trademark of NASA. LS-DYNA is a trademark or registered trademark of Livermore
Software Technology Corporation. All other trademarks are the property of their respective owners.
Revision 0. April 26, 2011
MDNA:2011:Z:Z:Z:DC-REL
Corporate
MSC.Software Corporation
2 MacArthur Place
Santa Ana, CA 92707
Telephone: (800) 345-2078
FAX: (714) 784-4056
Europe
MSC.Software GmbH
Am Moosfeld 13
81829 Munich
GERMANY
Telephone: (49) (89) 43 19 87 0
Fax: (49) (89) 43 61 71 6
Asia Pacific
MSC.Software Japan Ltd.
Shinjuku First West 8F
23-7 Nishi Shinjuku
1-Chome, Shinjuku-Ku
Tokyo 160-0023, JAPAN
Telephone: 0120-924-832 (toll free,
Japan only)
Mobile phone: 03-6911-1222
Fax: (81) (3)-6911-1201
Main Index
Cont ent s
MD Nastran & MSC Nastran 2011 Release Guide
Table of Contents
Preface to the MD Nastran 2011 Release Guide vi
List of Books vii
Technical Support viii
Internet Resources ix
1 Overview of MD & MSC Nastran 2011
Overview 2
2 Advanced Nonlinear (SOL 400)
Nonlinear Inertia Relief with Contact (SOL 400) 6
3 Numerical Methods and High Performance Computing
ACMS 12
Enhanced Math Kernel Library 15
Automatic SMEM Allocation 18
Thermal Performance Enhancements in SOL 400 21
4 Optimization
External Optimization via OpenMDO
TM
32
User Defined OpenMDO
TM
External Optimizer Service 43
5 Aeroelasticity
Improvements in Splining 48
MD Nastran 2011
Release Guide
Main Index

iv
6 Elements
Rotordynamics Enhancements 54
Main Index
MD Nastran Release Guide Preface
Preface
Preface to the MD Nastran 2011 Release Guide
List of Books
Technical Support
Internet Resources
Main Index
MD Nastran 2011 Release Guide
vi
This Release Guide contains descriptions for the MD Nastran 2011 version, and supersedes the MD
Nastran 2010 Release Guide.
Main Index
vii
Preface
List of Books
Below is a list of some of the Nastran documents. You may find any of these documents from
MSC.Software at www.simcompanion.mscsoftware.com.
Installation and Release Guides
Installation and Operations Guide
Release Guide
Guides
Reference Books
Quick Reference Guide
DMAP Programmers Guide
Reference Manual
Users Guides
Getting Started
Linear Static Analysis
Dynamic Analysis
MD Demonstration Problems
Thermal Analysis
Superelements
Design Sensitivity and Optimization
Implicit Nonlinear (SOL 600)
Explicit Nonlinear (SOL 700)
Aeroelastic Analysis
User Defined Services
EFEA Users Guide
EFEA Tutorial
EBEA Users Guide
Main Index
Technical Support
viii
Technical Support
For technical support phone numbers and contact information, please visit:
http://www.mscsoftware.com/Contents/Services/Technical-Support/Contact-Technical-Support.aspx
Support Center (http://simcompanion.mscsoftware.com)
Support Online. The Support Center provides technical articles, frequently asked questions and
documentation from a single location.
Main Index
ix
Preface
Internet Resources
MSC.Software (www.mscsoftware.com)
MSC.Software corporate site with information on the latest events, products and services for the
CAD/CAE/CAM marketplace.
Main Index
Internet Resources
x
Main Index
Chapter 1: Overview of MD & MSC Nastran 2011 MD Nastran & MSC Nastran Release Guide
1
Overview of MD & MSC Nastran
2011
Overview
Main Index
Overview
2
Overview
MSC.Software is pleased to introduce you to the exciting new technologies in MD Nastran 2011 & MSC
Nastran 2011, the premier and trusted CAE solution for aerospace, automotive, defense, and
manufacturing industries worldwide. This release includes new features and enhancements in Nonlinear
Inertia Relief with Contact, Numerical Methods and High Performance Computing, Optimization using
OpenMDO, Splining Improvements, and enhancements in Rotordynamics.
IFPStar
Starting with the MD Nastran 2011 and MSC Nastran 2011 releases, IFPStar will be the default input file
processor for Nastran. The IFPStar component provides more accurate verification of input files and their
conformance with the QRG. It also provides enhanced error messages, as well as a complete list of the
bulk data entries used in your model in the input file summary section.
Advanced Nonlinear (SOL 400)
Nonlinear Inertia Relief with Contact (SOL 400) (Ch. 2).
More information can be found in Advanced Nonlinear (SOL 400) (Ch. 2).
Numerical Methods and High Performance Computing
(Performance)
ACMS (Ch. 3)
Enhanced Math Kernel Library (Ch. 3)
Automatic SMEM Allocation (Ch. 3)
Thermal Performance Enhancements in SOL 400 (Ch. 3)
More information can be found in Numerical Methods and High Performance Computing (Ch. 3).
Optimization
TM
(Ch. 4)
TM
External Optimizer Service (Ch. 4)
More information on these optimization enhancements can be found in Optimization (Ch. 4).
Aeroelastic Enhancements
Improvements in Splining (Ch. 5)
More information on these aeroelastic enhancements can be found in Aeroelasticity (Ch. 5).
Main Index
3
CHAPTER 1
Contents
Elements
Rotordynamics Enhancements (Ch. 6).
More information can be found in Elements (Ch. 6).
Future Platform Support
MD Nastran and MSC Nastran will no longer be delivered on the SGI IRIX platform; MSC Nastran 2010
is available on SGI IRIX.
The Linux 32 bit platform will be discontinued starting in the year 2012.
Main Index
Overview
4
Main Index
Chapter 2: Advanced Nonlinear (SOL 400) MD Nastran R3 Release Guide

2
Nonlinear Inertia Relief with Contact (SOL 400)

Main Index

6
Introduction
Inertia relief is a technique to simulate self-equilibrating quasi dynamic loading in static analyses. It is
now available in MD Nastran for SOL400 with nonlinear material and contact analysis but under the
restriction of small displacement/rotations (PARAM,LGDISP=-1).
Benefits
The following feature is included in MD Nastran SOL 400.
Support inertial relief capability in SOL 400 with nonlinear material and contact analysis.
Theory
Case Control Parameter IRLOAD=QLIN causes a self-equilibrating quasi dynamic loading to occur.
User Inputs
The Case Control Command, IRLOAD, will activate this capability for SOL 400. It is only available to
SOL 400 and will be ignored in other solution sequences.
Selects nonlinear inertia relief set for SOL 400
Format:
Example:
IRLOAD=QLINEAR
IRLOAD
Nonlinear Inertia Relief Selection (SOL 400 only)
Field Contents
QLINEAR Inertia Load Calculation with small displacement (Quasi-Linear) is activated in SOL
400.
NONE No Inertia Relief (Default)
IRLOAD=
QLINEAR
NONE
)
`

Main Index
7
CHAPTER 2
Remark:
1. This command is active only in SOL 400 and its use requires a set of STATIC supports that
constrain all six rigid body motions.
2. IRLOAD=QLINEAR, which has to be applied above to all SUBCASES, is a global case control
command and activates the inertia load calculations in SOL 400 for all applied static loads. In
nonlinear static analyses (ANALYSIS=NLSTAT), it also activates the inertia relief analysis with
small displacement. When IRLOAD=QLINEAR with large displacement (PARAM,LGDISP -1),
a fatal error message will be issued. Also superelements in conjunction with
IRLOAD=QLINEAR will cause a fatal error.
IRLOAD=NONE (default) deactivates the inertia load calculations.
3. IRLOAD=QLINEAR is ignored by perturbation analyses in SOL 400.
Outputs
Standard Nastran outputs.
Guidelines and Limitations
The guidelines and limitations can be considered in the following two groups:
1. From the general view point of Nonlinear Inertia Relief in SOL 400
a. The current implementation is restricted to the requirement that all six rigid body
motions be constrained. Thus no mechanisms or symmetry boundaries are allowed.
b. This approach is only valid for models whose geometry does not change during loading, such
as SOL 400 with LGDISP=-1 (Default).
c. The Inertia Relief analysis does not support superelements.
d. The rigid body mass matrix must be non-singular. This problem will not occur for regular line,
surface, or solid elements with proper mass density but may occur from CONM2 type inputs
when not all translational DOFs have the corresponding mass.
e. IRLOAD=QLINEAR is a global case control command and activates the inertia load
calculations in SOL 400 for all applied static loads and therefore must occur above the STEP
level.
f. IRLOAD=QLINEAR is ignored by the perturbation analyses in SOL 400.
g. The tradition Parameter, INREL, is ignored in the nonlinear chaining and multi-physics
analyses but supported in the multidiscipline with linear analysis.
2. When Inertia Relief is used with the 3D Contact, the following contact settings are recommended:
a. IGLUE=2 (see BCTABLE in QRG) and NLGLUE=1 (see BCPARA in QRG) general glue
contact for Node-to-Surface contact. These settings are used to avoid the possibility of more
than 6 rigid body modes during the contact analysis. An IGLUE=0 is to be avoided as this has
a greater possibility of causing more than 6 rigid body modes during the contact analysis.
b. JGLUE=1 (see BCTABLE in QRG) allow separation (optional)
c. IBSEP=2 (see BCPARA in QRG) if there are high order elements with separation
Main Index

8
d. The Contact discussed here is Node-to-Surface Contact. The Segment-to-Segment Contact
may be supported in the future but it is not is the scope of this project.
e. In addition, when running nonlinear inertia relief with Contact, chattering should be avoided
if possible. Since this is usually a modeling issue the following suggestions are also
recommended
Try ICSEP>0 instead of ICSEP=0 (see BCPARA in QRG)
Adjust BIAS and ERROR (see BCPARA and BCTABLE in QRG)
Try smaller MAXSEP and NODSEP (see BCPARA in QRG)
Fatal error messages will be issued when
1. IRLOAD=QLINEAR is given for some (but not all) SUBCASEs.
2. IRLOAD=QLINEAR is used with large displacement (PARAM,LGDISP -1)
3. IRLOAD is used with superelements.
Example
The following 2 models are identical except that one has inertia relief (IRLOAD=QLIN), af_ir.dat, and
another does not, af_noir.dat.
Figure 2-1 Inertia Relief test model - airfoil with cutout
ID MSC, af_ir
SOL 400
CEND
ANALYSIS = NLSTAT
IRLOAD=QLINEAR $ this card is removed in af_noir.dat
SPC=20
Main Index
9
CHAPTER 2
LOAD = 400
DISP=all
STRESS=all
SPCF=all
BEGIN BULK
$ Determinate-SPC
SPC1 20 2 1
SPC1 20 23 101
SPC1 20 123 104
The results of DISP, LOAD, SPCF are showed in the following figures. Note that there are 15 orders of
magnitude difference on the spcforces between af_ir and af_noir.
Figure 2-2 Displacements af_ir vs. af_noir
Figure 2-3 Loads af_ir vs. af_noir
Main Index

10
Figure 2-4 SPCF af_ir vs. af_noir
Main Index
Chapter 3: Numerical Methods and High Performance Computing MD Nastran & MSC Nastran 2011
Release Guide

3
Numerical Methods and High
Performance Computing
ACMS
Enhanced Math Kernel Library
Automatic SMEM Allocation

Main Index
ACMS
12
ACMS
Introduction
Automated Component Modal Synthesis (ACMS) was implemented in Nastran in 2001 using Nastran
Superelements. In 2004, ACMS was made available in the matrix domain. This section describes recent
improvements to the computational performance of ACMS. These improvements apply to the following
modeling scenarios:
Use of structural damping (K4)
Combined use of SPCD enforced motion and frequency dependent analysis
Benefits
Performance improvements range from 25% to a 5X speedup, depending on the analysis scenario.
Technical Discussion
Enhancements were made to detect and exploit modeling practices which lead to a structural damping
specification resulting in a low-rank [K4] matrix. This leads to a faster reduction of [K4] to modal
coordinates with no loss of accuracy. In addition, it can lead to the increased applicability of Nastrans
Fast Frequency Response algorithm (FASTFR). For large frequency ranges that produce a significant
modal dimension, the use of FASTFR dramatically increases the speed of the resulting modal frequency
response analysis.
The interaction between enforced motion DOF specified via SPCD input and frequency dependent
elements was improved by removing redundant operations, resulting in reduced run times required for
these cases. This allows users continued access to the SPCD method of enforced motion, which is more
precise than the old Large Mass method.
Input
There are no input changes associated with these enhancements.
Output
There are no output changes associated with these enhancements.
Users should not set PARAM,FASTFR,YES to force fast frequency response. The automatic selection
logic should make the correct choice.
Known Issues in Beta
None.
Main Index
13
CHAPTER 3
Contents
Test Cases
Several large, real world models will be used to demonstrate these performance improvements.
Hardware used in the examples below is 2500MHz Intel Harpertown CPUs, 32GB main memory, Linux
2.6.9-42.ELsmp.
Case 1: example of K4 damping enhancement
SOL: 111
Number of grid points: 1.2 million
G-size DOF: 7.3 million
Number of structure modes: 3600
Number of forcing frequencies: 320
Main Index
ACMS
14
Case 2: example of damping enhancement
SOL: 111
Number of grid points: 1.4 million
Number of structure modes: 7200
Case 3: SPCD interaction with frequency dependence
SOL: 111
Number of grid points: 680,000
Main Index
15
CHAPTER 3
Contents
Introduction
Nastran employs a highly tuned set of mathematical kernels that provide high performance for
computationally intensive tasks. Most of these kernels consist of multi-threaded matrix algebra
operations especially tuned for Nastran. These kernels are implemented as external objects for ease of
portability, testing and extensibility. In addition, the external implementation allows for easy integration
with vendor-supplied Basic Linear Algebra Subroutine kernels as well (BLAS). The name of this library
is libMSCblas.
MSC has enhanced its application code to take greater advantage of libMSCblas. Additionally, the multi-
threaded Shared Memory Parallel (SMP) scalability has been improved.
Benefits
Performance improvements range from up to 100% for the following tasks:
Lanczos eigensolution
Matrix factorization for symmetric real and complex systems
Mixed mode (real times complex) matrix multiplication
Performance benefits are especially evident for large problems.
Computational efficiency has been increased for modern cache based architectures such as X86-64 from
Intel and AMD. Benefits apply equally to the LP64 and ILP64 floating point models (i4 mode and i8
mode).
Input
There are no input changes associated with this enhancement.
Output
There are no output changes associated with this enhancement.
Benefits are most pronounced for the X86-64 CPU architecture.
Main Index
16
Test Cases
Test cases come from customers. The model data may not be transmitted outside MSC.
Hardware used in the examples below is 2500MHz Intel Harpertown CPUs, 32GB main memory, Linux
2.6.9-42.ELsmp.
Case 1: static analysis of large solid model (direct solution)
SOL: 101
G-size DOF: 15 million
Case 2: Lanczos eigensolution (serial)
SOL: 103
Number of modes: 1000
Main Index
17
CHAPTER 3
Contents
Product Dependencies
None.
GUI Support
This is not applicable.
Additional Information and References
Main Index
18
Introduction
Nastran employs a disk resident database to hold temporary information generated during an analysis.
This database consists of blocks which reside in database partitions. The Scratch Memory feature
(SMEM) allocates blocks for the SCRATCH database partition in main memory instead of on the disk to
reduce the amount of I/O, hence reducing the wall time associated with an analysis.
MSC has automated the specification of SMEM to take advantage of large memory computer systems
which are used for single job streaming. Nastran will use all available memory and automatically allocate
memory for SMEM.
Benefits
The amount of memory used for SMEM will be computed automatically. For many analysis jobs, this
will result in a significant reduction in the amount of disk I/O required. This will result in improved
elapsed time performance for the analysis.
There is no new functionality introduced. The enhancement is to ease the specification of SMEM for
Nastran. Previous specification rules for SMEM are not changed.
The total amount of memory reserved for Nastran is set by the mem= command line keyword
(MEM). Nastran will divide this area into three memory regions shown below:
By default, the amount of memory reserved for SMEM is just large enough to contain database dictionary
entries. The SMEM region may be increased most conveniently by using the smem= command line
option:
nastran myinput mem=Xgb smem=Ygb
Note that the SMEM region is a subset of the total MEM; that is, X must be greater than Y. For more
information about specifying SMEM, and memory specification in general, please refer to the
smemory entry in Appendix B of the Installation and Operations Guide.
ExecTables
SMEM
MEM
Main Index
19
CHAPTER 3
Contents
The new functionality introduced now is the value of max for the mem= command line option
(i.e. mem=max). When mem=max is specified on the command line, the following operations
take place:
1. The amount of physical memory available on the computer system is determined (physical).
2. The maximum allocatable memory is determined. This is typically 80% of the available memory.
See the memorymax keyword description in the Installation and Operations Guide. The default
value for memorymax is 0.8*physical.
3. The MEM value is set to the value of memorymax.
4. The estimate utility is invoked to provide an estimate of the memory required by Nastran to
perform the analysis. This is called Open Core.
5. SMEM is set to the difference between memorymax and Open Core.
Examples
1. The computer system has 8GB (8000MB) of physical memory and memorymax is the default
value of 0.8. For the following command:
nastran myinput mem=max
Assume that estimate produces an estimate of 1GB (1000MB) for the analysis. Execution
would be equivalent to the following command:
nastran myinput mem=6400mb smem=5400mb
2. The computer system has 96GB (96000MB) of physical memory and memorymax is the default
value of 0.8. For the following command:
nastran myinput mem=max mode=i8
3. Assume that estimate produces an estimate of 1GB (1000MB) for the analysis. Execution would
be equivalent to the following command:
nastran myinput mem=76800mb smem=71800mb mode=i8
Note that mode=i8 is required to access memory greater than 8GB
Input
The value of max is now allowed on the memory specification of the nastran command.
Output
When mem=max is specified, the estimate utility runs automatically. The amount of SMEM to be
used for the analysis is printed as in the following example:
*** USER INFORMATION MESSAGE (pgm: nastran, fn:
estimate_job_requirements)
Estimated smem=192588
Estimated DOF=6012
Estimated memory=6144.0MB
Estimated disk=1.2MB
Main Index
20
Note that the amount of memory devoted to SMEM is printed in the unit of GINO BLOCKs.
The mem=max functionality is limited to SOL 101 and SOL 400. If mem=max is specified for a
different solution, a warning message is issued and the run proceeds with mem=estimate.
The mem=max functionality is not operational for Distributed Memory Parallel (DMP) runs.
Note that in order to take advantage of memory above 8GB (8000MB) one must run the ILP64 version
of Nastran by specifying mode=i8 on the command line.
Test Cases
A typical model was used to demonstrate the nonlinear performance.
Case 1: nonlinear static analysis with contact
SOL: 400
Number of grid points: 26,000
Number of cycles: 45
Main Index
21
CHAPTER 3
Contents
Thermal Performance Enhancements in SOL 400
The iterative solver has been shown to be very efficient solving large thermal models with solid
elements. However, the iterative solver was only available in nonlinear steady state thermal analysis
(SOL 153), and not available in transient thermal analysis (SOL 159).
Now the iterative solver is available in SOL 400 with analysis=hstat (nonlinear steady state thermal) and
analysis=htran (nonlinear transient thermal analysis).
The following two examples demonstrate the CPU performance improvements using the iterative solver
running a transient thermal analysis.
Case 1: Disk Brake model
This disk brake model has 644594 CHEXA elements and 642 PENTA elements.
THERMAL BOUNDARY CONDITIONS:
1. We have convection to time-varying ambient temperatures in which the convection coefficient is
function of temperatures
2. We ran the analysis using the NLSTEP with adaptive time steps up to 3000 sec.
This job was run using memory=8GB, and was run on a Linux64 machine:
As we can see, using the iterative solver is about 3.3 times faster.
CPU time
Direct method 6698.5
Iterative solver 2028.4
Main Index
22
Figure 3-1 CPU and wall time comparison
Figure 3-2 Performance gains using iterative solver
Main Index
23
CHAPTER 3
Contents
Figure 3-3 Disk brake transient thermal analysis
Figure 3-4 Disk brake
Main Index
24
Figure 3-5 Temperature versus time plot
Main Index
25
CHAPTER 3
Contents
CASE 2: Spherical cavity inside a chamber:
This second model is electronic components inside a chamber subject to solar heating and view factor
radiation.
Figure 3-6 Model
This job ran using MEM= 1GB
Test deck CPU time Increase in performance
Turn_on_heat1 2547.7
Turn_on_heat1_smatrix 322.7 sec. 8 times speed up in performance
Main Index
26
Figure 3-7 CPU and wall time comparisons
Figure 3-8 Performance gains using iterative solver
Main Index
27
CHAPTER 3
Contents
THERMAL BOUNDARY CONDITIONS:
This model has solar heating on the outside chamber and it has radiation to the sky, and radiation from
the concrete ground. In the interior we have electronic power dissipating energy on the spherical cavity,
and we have all the interior surfaces involved in radiation view factor exchange. Additionally we have
convection cooling on the inside of the enclosure, and thermal contact between non-matching mesh.
Figure 3-9 Chamber temperature
Figure 3-10 Transient thermal run
Main Index
28
Figure 3-11 Sphere cavity
Main Index
29
CHAPTER 3
Contents
How to invoke the iterative solver in SOL 400:
SOL 400
CEND
ECHO = SORT
$! Case Control Section
IC=1
SUBCASE 1
STEP 1
$LBCSET STEP1.1 DefaultLbcSet
$! Step name : Thermal Steady State
ANALYSIS = HTRAN
SPC = 132
DLOAD=200
smethod=matrix
$ LOAD = 133
NLSTEP = 6
Main Index
30
THERMAL(SORT2,PLOT)=ALL
$ SPCFORCES(SORT1,PRINT,REAL)=ALL
$ FLUX(PRINT)=ALL
BEGIN BULK
Selects iterative solver method and parameters.
Format:
Example:
SMETHOD = ELEMENT $ selects element-based iterative solver defaults.
SMETHOD = MATRIX $ selects matrix based iterative solver defaults.
SMETHOD = 1000 $ specifies ID of ITER Bulk Data entry to select
iterative.
Remarks:
1. The matrix-based iterative solver is available in SOLs 101, 106, 108, 111, 153, and 400 and
allows use of all features.
2. The element-based iterative solver is only available in SOLs 101, 200 and 400. SMETHOD must
be placed above all SUBCASEs in this case. It is intended primarily for very large solid element
models and does not handle p-elements. See the ITER Bulk Data entry for a list of restrictions.
3. For SOL 600, the iterative solver is activated using the MARCSOLV PARAM.
For more information on SMETHOD, please see SMETHOD (p. 492) in the MD/MSC Nastran Quick
Reference Guide.
SMETHOD
Iterative Solver Method Selection
Describer Meaning
ELEMENT Selects the element-based iterative solver with default control values.
MATRIX Selects the matrix-based iterative solver with default control values.
n Sets identification of an ITER Bulk Data entry (Integer > 0).
SMETHOD
ELEMENT
n
MATRIX
)

`

Main Index
Chapter 4: Optimization MD Nastran & MSC Nastran 2011 Release Guide
4
Optimization

TM

TM
External Optimizer Service
Main Index
TM
32
TM
Introduction
In MD Nastran, there are two MSC proprietary general purpose optimizers: MSCADS and IPOPT. In the
MD Nastran 2011 release MSC has created a Simulation Component Architecture (SCA) plug-in to allow
users access to other commercially available optimization codes or their own optimization codes. MSC
refers to this SCA plug-in capability as OpenMDO.
Benefits
The OpenMDO interface provides a convenient method to use the power of the MD Nastran Solver, the
MD Nastran design sensitivity calculations, and approximation technology with an alternative optimizer.
This can benefit both commercial users and researchers who may want to use or test their own optimizers.
OpenMDO also provides a method for users to plug-in other commercial optimizers.
MSC has partnered with VR&D (Vanderplaats Research & Development, Inc ) who have agreed to
implement the published OpenMDO APIs. These interfaces are delivered in the form of a library and
SCA catalog entry that enables the communication between MD Nastran and VR&D's DOT/BIGDOT.
Method
OpenMDO is based on the Simulation Component Architecture (SCA) framework (Ref 1). It allows
MD Nastran SOL200 (Optimization Solution) to communicate with an external optimizer code to send
the objective, constraint functions, and their gradients to the optimizer and get a new design from the
optimizer. MD Nastran optimization loop with SCA OpenMDO component as shown in Figure 4-1.
With OpenMDO, SOL200 first calls an OpenMDO memory estimate function in the DOM9 module to
allocate memory and initialize optimizer control parameters, arrays, and work arrays. SOL200 provides
some default values to OpenMDO optimizer control parameters that are discussed below. Then, SOL200
calls the external optimizer. The external optimizer must return information parameter INFO, error
parameter ERROR=IPRM(18), and NGT (number of critical constraints) =IPRM(20) to DOM9 to
perform function or gradient evaluations or terminate. These parameters are discussed as part of the
OpenMDO API section below.
Main Index
33
CHAPTER 4
Contents
Figure 4-1 Flow Chart of MD Nastran with External Optimizers
In DOM9 (Design Optimization Module), the external optimizer is used to solve a SOL200
approximation problem. MD Nastran employs a number of techniques, collectively referred to as
Approximation Concepts, to make design optimization possible for large finite element models. Design
variable linking, reduced basis vectors, constraint screening, load case deletion, and approximate model
are discussed in Ref 2. These approximation concepts all play a role in reducing the computational cost
of the design task. MD Nastran uses formal approximations (such as Taylor Series expansion) to avoid
the high cost associated with repeated finite element analyses during design optimization. As shown in
Figure 4-2, the optimizer interacts with the approximate model when it requires information. Given a set
of design variables, the optimizer needs information on the function values (the value of the objective
and the values of the constraints) and the gradient values (gradient of the objective with respect to the
design variables and the gradient of the active/violated constraints with respect to the design variables).
Main Index
TM
34
Figure 4-2 Optimizer Role in MD Nastran Optimization
Mathematical Model
A general formulation of structural optimization problems can be stated as follows:
(4-1)
where f is the objective function of design variables X, g
j
is the constraint, and m is the number of
inequality constraints. The design variable X has lower bound X
L
and upper bound X
U
. n is number of
design variables.
It is known that mathematical programming can directly deal with equality constraints. However,
equality constraints are seldom true for engineering design. MD Nastran SOL200 does not directly deal
with equality constraints. Instead, if such equality constraints are needed, it is only necessary to add
additional inequality constraints of the form
minimize f(X) objective
subject to inequality contraints
side constraints
g
j
X ( ) 0 j , s 1 2 ...,m , , =
x
i
L
x
i
x
U
i
i , s s 1 2 ...,n , , =
Main Index
35
CHAPTER 4
Contents
(4-2)
In other words, two equal and opposite inequality constraints will force the function to become an
equality. Therefore, we will consider only inequality constraints in our proposed OpenMDO API.
MD Nastran SOL200 has the design sensitivity analysis capability to calculate the gradients of structural
responses with respect to design variables. OpenMDO API mainly supports gradient based mathematical
programming methods that require the gradients of the objective and constraints with respect to design
variables. OpenMDO API can also be used for non-gradient based mathematical programming methods
where gradients are not used but still computed in SOL200.
OpenMDO API
The Equation (1) form is a standard optimization problem statement. However, it is known that there is
no standard optimization API in industry. Different optimization codes have different calling interfaces.
For example, VR&Ds DOT and BIGDOT have different interfaces. VR&D has a routine called
ALLDOT that supports both DOT and BIGDOT interfaces. Users can call ALLDOT with METHOD =
1, 2, 3 or 4. METHODS 1, 2 and 3 have the same meaning as for DOT. METHOD = 4 will invoke
BIGDOT.
Since DOT/BIGDOT is a major optimizer and widely used in Auto and Aerospace industry, MD Nastran
OpenMDO uses the ALLDOT calling statement as our OpenMDO API with a little modification. Other
third party optimizer vendors and MD Nastran clients can modify their source code to support our
OpenMDO API since OpenMDO API provides necessary and sufficient data for gradient based
optimizers.
The OpenMDO API is defined by :
OpenMDO _Runoptimizer(INFO, METHOD ,IPRINT, NDV, NCON, X, XL, XU ,OBJ, MINMAX, G,
RPRM, IPRM, WK, NRWK, IWK, NRIWK, ROPTION, IOPTION)
All arguments are defined in Table 4-1. Two optimization control parameter arrays IPRM and RPRM are
discussed in the next paragraph. Two others arrays, real ROPTION and integer IOPTION, are optional.
The size of these two arrays is obtained from Open_estimatememeory. The SOL200 DOM9 module is
the calling program for the external optimizers. DOM9 initializes the entire Roption and Ioption
arrays to zero before calling OpenMDO_runoptimizer. Users cannot change those values by
any Nastran bulk data entry, they can only be defined in the external optimizer. The use of these
two arrays is left to the needs of the provider of the external optimization algorithm.
The OpenMDO optimizer must have all the calling arguments described in Table 4-1 even if there are
arguments that are unused.
( )

0 g -
j
s X
Main Index
TM
36
There are three important parameters: information parameter INFO, optimizer error flag
ERROR=IPRM(18), and the number of critical constraints NGT=IPRM(20) (Array IPRM is described in
Table 4-3). They are used to guide SOL200 DOM9 to respond the optimizer shown in Figure 4-3.
OBJ and array G are used to store the values of the objective and constraints. IWK stores active and
violated constraint ID and WK store the gradients of the objective and active/violated constraints.
Figure 4-3 The Interaction Between SOL200 DOM9 and External Optimizers
Table 4-1 OpenMDO API
Note: The following definitions (Table 4-1-Table 4-4) are from the DOT Users Guide (Ref 5).
Providers of external algorithms are not required to follow all of these definitions
explicitly.
Main Index
37
CHAPTER 4
Contents
Parameter Definition
INFO Information parameter. Before calling OPENMDO the first time, set INFO=0. When control
returns from OPENMDO to the calling program, INFO will normally have a value of 0, 1, or 2
If INFO= 0, the optimization is complete (or terminated with an error message). If INFO= 1,
ask SOL200 to evaluate the objective, OBJ, and constraint functions, G(j), j=1,NCON If
INFO= 2, ask SOL200 to provide gradient information.
NOTE: If IPRM(18)>0 return from OPENMDO, a Fatal Error has occurred
METHOD Optimization method in OpenMDO to be used. OpenMDO can have more than one algorithms
IPRINT Print control parameter.
IPRINT = 0 no output.
IPRINT = 1,2,3,4,5,6,7, various level debug prints required by external optimizers
NDV Number of design variables contained in vector X.
NCON Number of constraint values contained in array G. NCON=0 is allowed.
X(NDV) Vector containing the design variables. On the first call to OPENMDO, this is the user's best
guess of the design. On the final return from OPENMDO (INFO=0 is returned), the vector X
contains the optimum design and vector G contains the corresponding constraint values.
XL(NDV) Array containing lower bounds on the design variables, X. If no lower bounds are imposed on
one or more of the design variables, the corresponding component(s) of XL must be set to a
large negative number, say -1.0E+15
XU(NDV) Array containing upper bounds on the design variables, X. If no upper bounds are imposed on
one or more of the design variables, the corresponding component(s) of XU must be set to a
large positive number, say 1.0 E+15.
OBJ Value of the objective function corresponding to the current values of the design variables
contained in X. On the first call to OPENMDO, OBJ need not be defined. OPENMDO will
return a value of INFO=1 to indicate that the user must evaluate OBJ and call OPENMDO
again. Subsequently, any time a value of INFO=1 is returned from OPENMDO, the objective,
OBJ, must be evaluated for the current design and OPENMDO must be called again. OBJ has
the same meaning as F(X) in the mathematical problem statement given in Equation 1.
MINMAX Integer parameter specifying whether the minimum (MINMAX=0,-1) or maximum
(MINMAX=1) of the objective function is to be found.
G(NCON) Array containing the NCON inequality constraint values corresponding to the current design
contained in X. On the first call to OPENMDO, the constraint values need not be defined.
On return from OPENMDO, if INFO=1, the constraints must be evaluated for the current X and
OPENMDO must be called again. If NCON=0, array G must be dimensioned to 1 or larger, but
no constraint values need to be provided.
Main Index
TM
38
Table 4-2 Scalar Parameters Stored in RPRM Array
RPRM(20) Array containing the real (floating point numbers) control parameters. SOl200 provides some
default values. Users can use other values than the defaults (Table 4-2).
IPRM(20) Array containing the integer control parameters. As with the RPRM array. SOl200 provides
some default values. Users can use other values than the defaults (Table 4-3).
Note IPRM(18) and IPRM(20) must be returned to SOL200.
WK(NRWK) User provided work array for real (floating point) variables. Array WK is used to store internal
scalar variables and arrays used by OPENMDO. If the user has not provided enough storage,
OPENMDO will print the appropriate message and terminate the optimization.
First NDV elements in WK store gradients of the objective. Next NDV*NGT elements store
the gradients of the critical constraints only (i.e., the first NDV is for the objective, the second
NDV is for the first critical constraint, ). The number of critical constraints NGT is given in
IPRM(20). The critical constraints are identified in the first NGT elements of the IWK array.
NRWK Dimensioned size of work array WK. NRWK should be set quite large, starting at about 1000
for a small problem. If NRWK has been given too small a value, an error message will be
printed and the optimization will be terminated.
IWK(NRIWK) User provided work array for integer (fixed point) variables. Array IWK is used to store
internal scalar variables and arrays used by OPENMDO. If the user has not provided enough
storage, OPENMDO will print the appropriate message and terminate the optimization. The
first NGT elements of IWK store critical constraints
NRIWK Dimensioned size of work array IWK. Increase the size of NRIWK as the problem grows
larger. If NRIWK is too small, an error message will be printed and the optimization will be
terminated.
Roption(sizeRO) Array containing real (floating point numbers) parameter. SOL200 initializes the entire array
to 0.0 before calling OpenMDO methods. Size of the array is from memory estimate.
Ioption(sizeIO) Array containing integer parameters. SOL200 initializes the entire array to zero. Size of the
array is from memory estimate.
Location Name Default Value Definition
1 CT -.03 A constraint is active if its numerical value is more
positive than CT. CT is a small negative number.
2 CTMIN 0.003 A constraint is violated if its numerical value is more
positive than CTMIN.
3 DABOBJ MAX[0.0001*ABS(F0),1.
0E-20]
Maximum absolute change in the objective between
ITRMOP consecutive iterations to indicate convergence
in optimization.
Main Index
39
CHAPTER 4
Contents
Table 4-3 Scalar Parameters Stored in IPRM Array
4 DELOBJ 0.001 Maximum relative change in the objective between
ITRMOP consecutive iterations to indicate convergence.
5 DOBJ1 0.1 Relative change in the objective function attempted on the
first optimization iteration. Used to estimate initial move
in the one-dimensional search. Updated as the
optimization progresses.
6 DOBJ2 0.2*ABS(F0) Absolute change in the objective function attempted on
the first optimization iteration.
7 DX1 0.01 Maximum relative change in a design variable attempted
on the first optimization iteration. Used to estimate the
initial move in the one-dimensional search. Updated as the
8 DX2 0.2*ABS[X(I)] Maximum absolute change in a design variable attempted
on the first optimization iteration. Used to estimate the
initial move in the one-dimensional search. Updated as the
9 NOT Used
Location Name Default Value Definition
Location Name Default Definition
1 IGRAD 1 Specifies the gradients are calculated bySOL200 IGRAD=1
2 ISCAL NDV Design variables are rescaled every ISCAL iterations. Set ISCAL
= -1 to turn off scaling.
3 ITMAX 100 Maximum number of iterations allowed at the optimization level.
4 ITRMOP 2 The number of consecutive iterations for which the absolute or
relative convergence criteria must be met to indicate convergence
at the optimizer level.
5 IWRITE 6 File number for printed output.
6 NGMAX NCON Maximum number of constraints retained for gradient
calculations.
7 IGMAX 0 If IGMAX=0, only gradients of active and violated constraints are
calculated. If IGMAX>0, up to NGMAX gradients are calculated,
including active, violated, and near active constraints.
8 JTMAX 50 Maximum number of iterations allowed for subproblems if
applicable
Main Index
TM
40
Over-Riding OpenMDO Default Parameters
OpenMDO provides a variety of internal parameters (real array RPRM(20) and integer array IPRM(20)
that affect the efficiency and reliability of the optimization process. If each of these parameters can be
used in the external optimizer, the default value is used unless the user overrides the parameter by
Nastran bulk data entry DOPTPRM. For example, METHOD, IPRINT, IGMAX, CT, CTMIN that are
described in MD & MSC Nastran Quick Reference Guide [Ref. 3]. In addition, users can override more
default values of parameters described in Table 4-2 and Table 4-3 that are not documented in the Nastran
Quick Reference Guide, but can be input on the DOPTPRM bulk data entry. These additional parameters
are DABOBJ, DELOBJ, DOBJ1, DOBJ2, DX1, DX2, IPRINT1, IPRINT2, ITMAX, ITRMOP,
ITRMST, JTMAX, JPRINT.
Supplying Gradients
OpenMDO is mainly developed for gradient-based optimizers. Based on NGT and critical constraints ID
(in IWK), DOM9 calculates the gradients of the objective and critical constraints, and stores the gradients
in the real array WK. If the external optimizer does not support the critical (active/violated) constraint
9 ITRMST 2 The number of consecutive iterations for which the absolute or
relative convergence criteria must be met to indicate convergence
in the subproblems if applicable.
10 JPRINT 0 If JPRINT>0, IPRINT is turned on during subproblem. This is for
debugging only.
11 IPRNT1 0 If IPRNT1=1, print scaling factors for the X vector.
12 IPRNT2 0 If IPRNT2=1, print miscellaneous search information.
If IPRNT2=2, turn on print during one-dimensional search
process. This is for debugging only.
13 JWRITE 0 File number to write iteration history information to. This is
useful for using postprocessing programs to plot the iteration
process. This is only used if JWRITE>0.
18 IERROR 0 Fatal error parameter returned by OPENMDO. Normally = 0.

IERROR = 1 indicates WK or IWK dimension is too small.
IERROR = 2 indicates some XL(I) is greater than XU(I). ERROR
= 3 or 4 indicates that storage for constraint gradients is too small.
IERROR = 5 indicates that a violated constraint has a zero
gradient. Therefore, no feasible design can be found.
19
20 NGT
Location Name Default Definition
Main Index
41
CHAPTER 4
Contents
concept, users can set NGT=NCON, and store all constraints in IWK. Then DOM9 computes the
gradients of objective and all constraints and stores in WK. IWK and WK are discussed in Table 4-1.
Last, but importantly, we need know memory requirements of external optimizers to allocate memory in
DOM9. Before calling OpenMDO_runoptimizer, SOL200 DOM9 calls a memory estimate function to
determine needed array sizes. This routine may request the values of NDV, NCON, MAXINT, XL and
XU and permits calculation of a value for NGMAX, that is
OpenMDO_estimatememory_cpp (NDV, NCON,
* METHOD,NRWKMN,NRWKD,NRWKMX, NRIWK,NSTORE,
* NGMAX, XL, XU, SIZEIO, SIZERO, MAXINT, IERR)
The arguments in OpenMDO_EstimateMemory are described in Table 4-4.
Table 4-4 Memory Estimate Parameters
NDV Input: Number of design variables contained in vector X.
NCON Input: Number of constraint values contained in array G. NCON=0 is allowed.
METHOD Input: Optimization method in OpenMDO to be used. OpenMDO can have more than one
algorithms
XL(NDV) Input: Array containing lower bounds on the design variables, X. If no lower bounds are imposed on
one or more of the design variables, the corresponding component(s) of XL must be set to a large
negative number, say -1.0E+15
XU(NDV) Input Array containing upper bounds on the design variables, X. If no upper bounds are imposed
on one or more of the design variables, the corresponding component(s) of XU must be set to a large
positive number, say 1.0 E+15.
NGMAX Input/Output: Maximum number of constraints retained for gradient calculations. SOL200 input
NGMAX=0 that must be reset by external optimizers.
MAXINT Input: Maximum integer number.
NRWKMN Output: Minimum value of NRWK (the number of rows in the WK array, described in Table 4-1). If
the value of NRWK provided to OpenMDO is less than NRWKMN, the optimization will be
terminated with an error message.
NRWKD Output: Desired value of NRWK.
NRWKMX Output: Maximum value of NRWK.
NRIWK Output: The number of rows in the IWK array. If the array size of IWK provided to OpenMDO is
less than NRIWK, the optimization will be terminated
NSTORE Output: Extra computer memory request. Not used in SOL200 and can be set to zero.
Main Index
TM
42
SIZEIO Output: Desired size of array IOPTION. Must set >=1
SIZERO Output: Desired size of array ROPTION. Must set >=1
IERR Output: >1 the optimization will be terminated.
Main Index
43
CHAPTER 4
Contents
TM
The OpenMDO API creates an IDL interface file OpenMDO.idl that has two components:
OpenMDO_estimate memory and OpenMDO_run_optimizer. A service definition language file
OpenMDO.sdl, component definition language file OpenMDO.cdl file, and implementation file
OpenMDO.cpp can be found in ../SCA/MDSolver/Util/OpenMDO. All those files, along with the source
structure are included in an MD Nastran delivery. Users need to complete OpenMDO.cpp
implementation for the two methods and use the SDK command scons to build the OpenMDO SCA
component files, including the service catalog file SCAServiceCatalog.xml. Detail instructions can be
found in the MD & MSC Nastran User Defined Services OpenMDO (Ref.4).
Input
For a user to run an optimization SOL200 job using the OpenMDO interface, a SCA service must be
defined in the file management section in the Nastran input file by a CONNECT Service statement. The
connection between the SCA service and SOL200 is done by defining an optimizer code OPTCOD on
DOPTPRM bulk data entry which is tagged with the SCA service identifier in the CONNECT Service
statement. As shown below, an input file Connect Service statement references an external OpenMDO
service called 'ExternalOptimizer.OpenMDO'. The word ALLDOT (Optimizer code in DOPTPRM
and service identifier in CONNECT Service statement) connects SOL200 with
'ExternalOptimizer.OpenMDO' service
File management CONNECT SERVICE ALLDOT ExternalOptimizer.OpenMDO
Executive control
SOL200
END
Case Control
DESOBJ=10
DESSUB=20
SUBCASE1
ABALYSIS=STATICS
.
Bulk data
BEGINBULK
.
DOPTPRMOPTCODALLDOTMETHOD1
.
Main Index
TM
44
Output
There are no outputs that are affected by external optimizers with the exception that the external
optimizer can have new output when using the IPRINT>0 parameter on the DOPTPRM entry.
Example
Intermediate Complexity Wing (ICWSE01.dat)
This intermediate complexity wing shown in Figure 4-4 was solved using MSCADS and IOPT in MD
Nastran 2010. In this Section, ALLDOT (DOT and BIGDOT) is used as an external optimizer to solve
this problem.
Figure 4-4 Intermediate Complexity Wing Model
This composite structure is modeled with 62 CQUAD4 elements, 55 CSHEAR elements, 39 CROD
elements, and 39 CONM2 elements. Two static load cases are imposed along with a normal modes
subcase. The objective is to minimize the weight. There are 153 sizing design variables and 414 stress
and failure index constraints and lower and upper bounds on the first fundamental frequency. To use
ALLDOT, a parameter OPTCOD=ALLDOT is added on Bulk Data Entry DOPTPRM such as
CONNECT SERVICE ALLDOT ALLDOT.OpenMDO
...
...
...
DOPTPRM APRCOD 2 DESMAX 30 DELP 0.50 DPMIN 0.001
delx 0.49 p1 1 p2 12 OPTCOD ALLDOT
METHOD 1
MEHTOD=1 is the DOT's MMFD method, METHOD=4 is the BIGDOT algorithm.
Table 4-5 shows the DOT and BIGDOT results for this example and all results are comparable.
Main Index
45
CHAPTER 4
Contents
Table 4-5 Intermediate Complexity Wing Optimization Results
The output from external optimizers may not be written to MD Nastran *.f06 file. It is machine
dependent. To enforce the external optimizer output into MD Nastran *.f06 file, users can use a printf06
utility delivered with SDK to replace Fortran Write statements (see detail in User Defined OpenMDO
Ref.4).
GUI Support
There is no GUI support for OpenMDO.
References
1. MD Nastran 2010 - SCA Framework Users Guide (DEV)
2. MD Nastran 2010 Design Sensitivity and Optimization Users Guide, The MSC Software
Corporation, 2010
3. MD Nastran 2011 Quick Reference Guide, The MSC Software Corporation.
4. MD Nastran 2011 User Defined Services
5. DOT Users Guide, Version 5.X, Vanderplaats Research & Development, Inc., 2001. See
page 33.
Initial Value Optimum
DOT
(MMFD)
Optimum
BIGDOT
Optimum
Ipopt
Optimum
MSCADS
(MMFD)
Objective 1.6892+2 1.9893+2 1.9570+2 1.9282+2 1.9624+2
Max Con 5.8425+2 1.4267-03 1.5355-04 5.5370-03 2.7015-03
# Cycles 14 20 20 14
Main Index
TM
46
Main Index
Chapter 5: Aeroelasticity MD Nastran & MSc Nastran 2011 Release Guide
5
Aeroelasticity
Improvements in Splining
Main Index
48
Introduction
The MD R2 release of Nastran had a number of enhancements in the aeroelastic splining capability.
These included introduction of the METH=RIS (Radial Interpolation Spline) on the SPLINE4 and
SPLINE5 entries and a SPRELAX bulk data entry that enables "relaxation" of the spline behavior of one
spline based on displacements of an adjacent spline. For the MD/MSC Nastran 2011.1 release, these
features are being further enhanced by:
1. Implementation of an automated partitioning concept that breaks a single SPLINE4 using
METH=RIS into a number of smaller splines.
2. The ability to restrict the relaxation to the DISP (displacement) instance of the spline while not
applying it to the FORCE (force) instance.
Benefits
Improved performance for Large Models SPLINE4 entries with METH=RIS
There is a nascent capability within Nastran to apply the aeroelastic capabilities to aerodynamic models
that use CFD techniques. Unlike the panel methods that have been the workhorse of Nastran
aeroelasticity, these CFD models can have thousands and even a million aerodynamic grids. This presents
a challenge to the splining methods that were developed with that thought that no more than several
hundred grids would be splined. Originally, it was believed that the RIS method, which specifies a region
over which the spline is to act would provide satisfactory performance even when the spline itself is over
a wide area. However, the equilibrium equations that underlay the spline techniques force the
participation of all the grids in spline calculations and can result in poor performance. A remedy for this
is to break a single spline into a number of smaller splines using techniques put forth by Prof. Holger
Wendland (Ref. 1)
1. Wendland, Holger, Fast Evaluation of Radial Basis Functions: Methods Based on Partition of
Unity, Contained in: Approximation Theory X: Wavelets, Splines and Applications, Chui,
Schumaker and Stockler (eds), Vanderbilt University Press, Nashville, TN, 2002 (pp. 473-483)
With a smaller set of grids for each spline, the required matrix operations are applied to smaller matrices.
Equally important, the resulting spline matrices are less dense so that subsequent matrix operations (such
as partitioning and multiplies) are faster and require less disk space.
Limitation of Relaxation to the DISP Spline
It can be shown that the relaxation techniques invoked via the SPRELAX bulk data entry cannot be
guaranteed to preserve the moments acting on the model (forces are preserved). The severity of this
shortcoming has not been quantified, but it seems prudent to provide the user with a way of applying the
relaxation to only the DISP spline but not the FORCE spline. The second enhancement does this.
Main Index
49
CHAPTER 5
Contents
User Inputs
The MDLPRM bulk data entry has the following additional parameters:
Outputs
There are no new .f06 outputs as a result of these enhancements. If the RELAXF MDLPRM parameter
is set, the FORCE spline will be affected, resulting in changes in the forces transferred from the aero
model to the structure. For splines applied to many structural grids, the use of the NSGRDS4 MDLPRM
parameter, with or without the accompanying PEXTS4 MDLPRM parameter, will reduce the CPU time
spent in the GI module and in subsequent postprocessing and in the amount of disk space required by the
run without degrading the quality of the results.
The performance enhancements are limited to the SPLINE4 with METHOD=RIS. This was done
because the applications which surfaced this performance issues used this option.
The utility of the spline partitioning is limited to large models where a single spline involves thousands
of structural grids. Limited study has been made for the best value of NSGRDS4, with a value of 200
seeming to be a good compromise between specifying a small value that would necessitate many small
splines and could affect the quality of the results and specifying a large value which would result in
minimal improvement in the performance. The PEXTS4=10.0 default is recommended, but
experimentation could be performed to see if a different value provides improved quality in the results.
Note that PEXTS4 is only used in conjunction with NSGRDS4. Further, if NSGRDS4 is greater than the
number of structural grids associated with the spline, no partitioning occurs.
Name Description, Type and Default Values
NSGRDS4 Number of structural grids to be used in dividing a SPLINE4 using the RIS spline
method. The spline will be divided into NGRIDS/NSGRDS4 regions, where
NGRIDS is the number of grids listed on the associated SET1 entry. (Integer > 0,
default=0. If NGRIDS < NSGRDS4, or NSGRDS4 is not specified, no divisions will
occur.)
RELAXF If there are SPRELAX entries, RELAXF=1 will result in the GI module outputting
the GPGK datablock without relaxation while the GDGK datablock will include the
relaxation effects.
=0 (Default) Relaxation is applied to all splines
=1 Relaxation is only applied to the splining of displacements.
PEXTS4 Used in conjunction with NSGRDS4. After partitioning the spline, each of the
smaller splines will be extended by PEXTS4 in each direction (top, bottom, left and
right). The value is expressed in percent so that PEXTS4=10.0 would extend the four
boundaries by 10%. Real (0.0<PEXTS4<100.0, default=10.0)
Main Index
50
The RELAXF MDLPRM parameter is provided to allow users to experiment with the relaxation
behavior.
Examples
The primary application of the partitioning concept has been made to a client provided model that is
proprietary. Selected results are presented here:
The model was run using a system MD Nastran 2010.1 and with MD & MSC Nastran 2011.1. The
command line for both runs specified mem=8gb, sscr=300gb and buffsize=65537. CPU and I/O
resources expended for steps in the processing include:
It is seen that there is significant speedup in the actual creation of the splines (GI) but that some of this
speedup is given back in the blending step because of the complexity of now blending blended matrices.
Overall there is a 50% speedup in the creation of the splines and an 80% speedup in the postprocessing
Number of structural grids (GRID entries) 59738
Number of aerodynamic grids (AEGRID entries) 367337
Number of aerodynamic elements (AETRIA3 entries) 732737
Number of SPLINE4 Entries 20
Number of Blends (SPLBLND2 entries) 20
Number of Relax entries (SPRELAX entries) 7
Number of SPLINRB entries 8
Task MD 2010.1 MD 2011.1 Speedup (percent)
I/O
(GBS)
CPU (SECS I/O (GBS) CPU (SECS I/O (%) CPU (%)
Preprocessing up
to GI
0.2 21 0.28 20 -40.00% 4.76%
Create Initial
Splines
417 4642 110 390 73.62% 91.60%
Spline Blending 428 1635 221 2694 48.36% -64.77%
Total Time in GI 845 6277 331 3084 60.83% 50.87%
Postprocessing 1628 6461 277 1270 82.99% 80.34%
Total 2473.2 12759 608.28 4374 75.41% 65.72%
Main Index
51
CHAPTER 5
Contents
operations. This is explained by the fact that the resulting spline matrix is much less dense as shown in
the following table:
By reducing the density of the final spline matrix by 84.5%, there is a corresponding reduction in the
amount of disk space required and in the matrix operations (such as partitioning, transpose and multiply)
that occur subsequent to the GI module. It is to be noted that in a typical scenario, the spline would be
created once in a study and then reused many times for different operations such as splining new mode
sets of creating new loads due to a new CFD analysis.
Three small decks are provided in the tpl to simply show the input of the data:
1. Asm3plt1 - a simple plate model with 121 structural grids and 441 aero grids. A single spline
connects all aero and structural grids. The job is run with NSGRDS4=50 and PEXTS4=20. The
results are essentially identical to plate01 in the test library.
2. Asm3plt4 - The same simple plate model as asm3plt1 but now 4 splines with overlap and
blending connect all aero and structural grids. The job is run with NSGRDS4=20 and no
PEXTS4. The results are essentially identical to plate01 in the test library.
3. Asm3rlxf - A variation of tpl deck wing07 with MDPRM RELAXF set to 1. This results in
separate force and displacement splines. Answers were independently checked to verify that the
force spline that is output is identical to what is produced when separate FORCE and DISP
splines are created and the DISP spline has relaxation applied to it and the FORCE spline does
not.
Parameter MD 2010.1 MD 2011.1 Improvement
Density of the GPGK Matrix 1.08E-02 1.67E-03 84.54%
SCRATCH Disk Space (GB,
Highwater)
278 45.6 83.60%
SCRATCH 300 Space (GB,
Highwater)
169 40.7 75.92%
NSGRDS4 n/a 200
Main Index
52
Main Index
Chapter 6: Elements
6
Elements
Rotordynamics Enhancements
Main Index
54
Starting with MD Nastran 2011, the user is allowed to provide their own SCA-object to calculate the
properties of CBUSH2D elements. In addition, it is possible to use the ROMAC (University of Virginia
ROtating Machinery And Controls laboratory, http://www.virginia.edu/romac/) THPAD routine (which
must be obtained from ROMAC) to calculate the properties of a tilting pad journal bearing.
The user interface for the user-defined properties of a CBUSH2D consists of the associated PBUSH2D
and an ELEMUDS entry, which defines the data which is to be passed to the user routine. In addition, the
sca service must be attached to the run using the CONNECT SERVICE statement.
The format of the ELEMUDS - MD Only (p. 1790) in the MD/MSC Nastran Quick Reference Guide is:
Allows the user to provide element property routines for use with enhanced MD Nastran nonlinear
elements in MD Nastran SOL 400 only.
Format:
Examples:
In FMS Section of MD Nastran input stream:
CONNECT SERVICE ELEMENT SCA.MDSolver.Util.Ums
In Bulk Data:
PID is the property id, PTYPE is the property entry type (in this case, PBUSH2D), GROUP is the service
name, UNAME is the user subroutine name, and DEPEN is the flag which determines whether the
ELEMUDS - MD Only
Element Property User Defined Service or Subroutine
1 2 3 4 5 6 7 8 9 10
ELEMUDS
PID PTYPE GROUP UNAME DEPEN
INT IDATA1 IDATA2 IDATA3 IDATA4 IDATA5 IDATA6 IDATA7
IDATA8 IDATA9 ... ... IDATAn
REAL RDATA1 RDATA2 RDATA3 RDATA4 RDATA5 RDATA6 RDATA7
RDATA8 RDATA9 ... ... RDATAn
CHAR CDATA1 CDATA2 ... ... CDATAn
ELEMUDS
17
PBUSH2D ELEMENT
USELEM
ELEMUDS
17
PBUSH2D ELEMENT
USELEM
REAL .00134 1.467+4 .03
INT 8 3
Main Index
55
CHAPTER 6
Contents
properties are frequency-dependent or not (only available in SOL's 108, 111, 128, and 400 currently). If
the properties are frequency-dependent, then the word FREQ should be entered in the DEPEN field.
An example of the input to use a user-defined property is:
In the above, element 2020 references PBUSH2D,1000. The ELEMUDS entry with the same id (1000)
as the PBUSH2D instructs the program to use the user-provided service TESTC to calculate the element
properties when a CBUSH2D references PBUSH2D 1000, and the properties will be frequency-
dependent.
On the ELEMUDS, the lines which start with INT, REAL, and CHAR are used to provide integer, real,
and character input respectively to the user subroutine. The start of a FORTRAN subroutine to use the
data passed to the user subroutine might be:
Where:
FREQVA - RDATA1 on the first call (nominal value) and the current frequency
value (if the element is frequency dependent)
IARRAY = INT values from the ELEMUDS
RARRAY = real values from the ELEMUDS
CIARRAY = character data from the ELEMUDS
KXX,KYX,KXY,KYY,CXX,CYX,CXY,CYY = coefficients to be passed back from the
user service
LEN_IARRAY, LEN_RARRAY, LEN_CARRAY - length of the associated arrays
ELID - current element id
ERROR_CODE = error code to be returned to Nastran.
SUBROUTINE EXT_CBUSH2D (FREQVA, IARRAY, ARRAY, CIARRAY, KXX, KYX, KYY,
& CXX, CYX, CXY, CYY, LEN_IARRAY, LEN_RARRAY, LEN_CARRAY,
& ELID, ERROR_CODE
Main Index
56
The user subroutine may write to the f06 file and provides the stiffness and damping coefficients for the
element. NOTE - it is not required that the stiffness and damping coefficients be symmetric, but if they
are not symmetric, the associated matrix may cause runs in solutions which depend on symmetric
element matrices (statics, normal modes, for example) to fail.
If you wish to use the ROMAC THPAD, then the ELEMUDS should have the word "THPAD" in the
UNAME field and you must have the ROMAC THPAD routine attached as a service. In this case, input
for the THPAD routine is provided using the THPAD - MD Only, 3261 bulk data entry with the same ID
as the ELEMUDS and PBUSH2D.
The data on this entry is the data required by the ROMAC THPAD code. The final NCASE lines are
values for each speed which you wish to provide data for. The program will use the first set to calculate
the nominal properties of the element and (if you are using a frequency-dependent element in a solution
which supports it), the program will interpolate between the speed values provided to calculate the values
which will be passed to the THPAD to calculate the frequency-dependent element properties.
Pad Data {
SpeedLoad
Case Data {
Main Index

MD Nastran 2011 & MSC Nastran 2011 Release Guide

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

MD Nastran 2011 & MSC Nastran 2011 Release Guide

Uploaded by

Copyright:

Available Formats

MD Nastran 2011 &

MSC Nastran 2011

Preface to the MD Nastran 2011 Release Guide

Nonlinear Inertia Relief with Contact (SOL 400)

Enhanced Math Kernel Library

Automatic SMEM Allocation

External Optimization via OpenMDO

User Defined OpenMDO

18 IERROR 0 Fatal error parameter returned by OPENMDO. Normally = 0.

You might also like

MD Nastran 2011 &amp; MSC Nastran 2011 Release Guide

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

MD Nastran 2011 &amp; MSC Nastran 2011 Release Guide

Uploaded by

Copyright:

Available Formats

MD Nastran 2011 &

MSC Nastran 2011

Preface to the MD Nastran 2011 Release Guide

Nonlinear Inertia Relief with Contact (SOL 400)

Enhanced Math Kernel Library

Automatic SMEM Allocation

External Optimization via OpenMDO

User Defined OpenMDO

18 IERROR 0 Fatal error parameter returned by OPENMDO. Normally = 0.

You might also like

MD Nastran 2011 & MSC Nastran 2011 Release Guide

MD Nastran 2011 & MSC Nastran 2011 Release Guide