Download - MD Nastran 2011 & MSC Nastran 2011 Release Guide

MD Nastran 2011 &

MSC Nastran 2011

Release Guide

Worldwide Webwww.mscsoftware.com

DisclaimerMSC.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, 2011MDNA:2011:Z:Z:Z:DC-REL

CorporateMSC.Software Corporation2 MacArthur PlaceSanta Ana, CA 92707Telephone: (800) 345-2078FAX: (714) 784-4056

EuropeMSC.Software GmbHAm Moosfeld 1381829 MunichGERMANYTelephone: (49) (89) 43 19 87 0Fax: (49) (89) 43 61 71 6

Asia PacificMSC.Software Japan Ltd.Shinjuku First West 8F23-7 Nishi Shinjuku1-Chome, Shinjuku-Ku Tokyo 160-0023, JAPANTelephone: 0120-924-832 (toll free, Japan only)Mobile phone: 03-6911-1222Fax: (81) (3)-6911-1201

C o n t e n t sMD Nastran & MSC Nastran 2011 Release Guide

MD 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 OpenMDOTM 32

User Defined OpenMDOTM External Optimizer Service 43

5 Aeroelasticity

Improvements in Splining 48

MD Nastran & MSC Nastran 2011 Release Guide

iv

6 Elements

Rotordynamics Enhancements 54

MD Nastran Release Guide Preface

Preface

Preface to the MD Nastran 2011 Release Guide

List of Books

Technical Support

Internet Resources

MD Nastran 2011 Release GuidePreface to the MD Nastran 2011 Release Guide

vi

Preface to the MD Nastran 2011 Release GuideThis Release Guide contains descriptions for the MD Nastran 2011 version, and supersedes the MD Nastran 2010 Release Guide.

viiPreface

List of BooksBelow 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 Programmer’s Guide

• Reference Manual

User’s 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 User’s Guide

• EFEA Tutorial

• EBEA User’s Guide

MD Nastran 2011 Release GuideTechnical Support

viii

Technical SupportFor 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.

http://simcompanion.mscsoftware.com

http://www.mscsoftware.com/Contents/Services/Technical-Support/Contact-Technical-Support.aspx

ixPreface

Internet ResourcesMSC.Software (www.mscsoftware.com)

MSC.Software corporate site with information on the latest events, products and services for the CAD/CAE/CAM marketplace.

www.mscsoftware.com

MD Nastran 2011 Release GuideInternet Resources

x

Chapter 1: Overview of MD & MSC Nastran 2011 MD Nastran & MSC Nastran Release Guide

1 Overview of MD & MSC Nastran 2011

Overview

MD Nastran & MSC Nastran 2011 Release GuideOverview

2

OverviewMSC.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.

IFPStarStarting 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• External Optimization via OpenMDOTM (Ch. 4)

• User Defined OpenMDOTM 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).

3CHAPTER 1Contents

Elements• Rotordynamics Enhancements (Ch. 6).

More information can be found in Elements (Ch. 6).

Future Platform SupportMD 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.

MD Nastran & MSC Nastran 2011 Release GuideOverview

4

Chapter 2: Advanced Nonlinear (SOL 400) MD Nastran R3 Release Guide

2 Advanced Nonlinear (SOL 400)

Nonlinear Inertia Relief with Contact (SOL 400)

MD Nastran 2011 Release Guide Nonlinear Inertia Relief with Contact (SOL 400)

6

Nonlinear Inertia Relief with Contact (SOL 400)

IntroductionInertia 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).

BenefitsThe following feature is included in MD Nastran SOL 400.

Support inertial relief capability in SOL 400 with nonlinear material and contact analysis.

TheoryCase Control Parameter IRLOAD=QLIN causes a self-equilibrating quasi dynamic loading to occur.

User InputsThe 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

7CHAPTER 2Advanced Nonlinear (SOL 400)

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 DOF’s 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


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) SUBCASE’s.

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_irSOL 400CEND

ANALYSIS = NLSTATIRLOAD=QLINEAR $ this card is removed in af_noir.dat

SPC=20

9CHAPTER 2Advanced Nonlinear (SOL 400)

LOAD = 400

DISP=allSTRESS=allSPCF=all

BEGIN BULK$ Determinate-SPCSPC1 20 2 1SPC1 20 23 101SPC1 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


10

Figure 2-4 SPCF – af_ir vs. af_noir

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

MD Nastran & MSC Nastran 2011 Release GuideACMS

12

ACMS

IntroductionAutomated 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

BenefitsPerformance improvements range from 25% to a 5X speedup, depending on the analysis scenario.

Technical DiscussionEnhancements 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 Nastran’s 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.

13CHAPTER 3Contents

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 enhancementSOL: 111Number of grid points: 1.2 millionG-size DOF: 7.3 millionNumber of structure modes: 3600Number of forcing frequencies: 320

MD Nastran & MSC Nastran 2011 Release GuideACMS

14

Case 2: example of damping enhancementSOL: 111Number of grid points: 1.4 millionG-size DOF: 8.6 millionNumber of structure modes: 7200Number of forcing frequencies: 700

Case 3: SPCD interaction with frequency dependenceSOL: 111Number of grid points: 680,000G-size DOF: 5.4 millionNumber of forcing frequencies: 500

15CHAPTER 3Contents

Enhanced Math Kernel Library

IntroductionNastran 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.

BenefitsPerformance 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.

Technical DiscussionComputational 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).

InputThere are no input changes associated with this enhancement.

OutputThere are no output changes associated with this enhancement.

Guidelines and LimitationsBenefits are most pronounced for the X86-64 CPU architecture.

MD Nastran & MSC Nastran 2011 Release GuideEnhanced Math Kernel Library

16

Test CasesTest 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: 101G-size DOF: 15 million

Case 2: Lanczos eigensolution (serial)SOL: 103G-size DOF: 1.6 millionNumber of modes: 1000

17CHAPTER 3Contents

Product Dependencies

None.

GUI Support

This is not applicable.

Additional Information and References

MD Nastran & MSC Nastran 2011 Release GuideAutomatic SMEM Allocation

18

Automatic SMEM Allocation

IntroductionNastran 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.

BenefitsThe 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.

Technical DiscussionThere 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.

Exec Tables

SMEM

MEM

19CHAPTER 3Contents

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=maxAssume that ‘estimate’ produces an estimate of 1GB (1000MB) for the analysis. Execution would be equivalent to the following command:

nastran myinput mem=6400mb smem=5400mb2. 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=i83. 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

MD Nastran & MSC Nastran 2011 Release GuideAutomatic SMEM Allocation

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 CasesA typical model was used to demonstrate the nonlinear performance.

Case 1: nonlinear static analysis with contactSOL: 400Number of grid points: 26,000Number of cycles: 45

21CHAPTER 3Contents

Thermal Performance Enhancements in SOL 400The 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 modelThis 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

MD Nastran & MSC Nastran 2011 Release GuideThermal Performance Enhancements in SOL 400

22

Figure 3-1 CPU and wall time comparison

Figure 3-2 Performance gains using iterative solver

23CHAPTER 3Contents

Figure 3-3 Disk brake transient thermal analysis

Figure 3-4 Disk brake


24

Figure 3-5 Temperature versus time plot

25CHAPTER 3Contents

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


26

Figure 3-7 CPU and wall time comparisons

Figure 3-8 Performance gains using iterative solver

27CHAPTER 3Contents

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


28

Figure 3-11 Sphere cavity

29CHAPTER 3Contents

How to invoke the iterative solver in SOL 400:SOL 400CENDECHO = SORT$! Case Control SectionIC=1SUBCASE 1STEP 1$LBCSET STEP1.1 DefaultLbcSet$! Step name : Thermal Steady State ANALYSIS = HTRAN SPC = 132DLOAD=200

smethod=matrix$ LOAD = 133 NLSTEP = 6


30

THERMAL(SORT2,PLOT)=ALL$ SPCFORCES(SORT1,PRINT,REAL)=ALL$ FLUX(PRINT)=ALLBEGIN 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).

SMETHODELEMENT

n

MATRIX

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

4 Optimization

External Optimization via OpenMDOTM

User Defined OpenMDOTM External Optimizer Service

MD Nastran & MSC Nastran 2011 Release GuideExternal Optimization via OpenMDOTM

32

External Optimization via OpenMDOTM

IntroductionIn 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.

BenefitsThe 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.

MethodOpenMDO 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.

33CHAPTER 4Contents

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).


34

Figure 4-2 Optimizer Role in MD Nastran Optimization

Mathematical ModelA general formulation of structural optimization problems can be stated as follows:

(4-1)

where f is the objective function of design variables X, gj is the constraint, and m is the number of

inequality constraints. The design variable X has lower bound XL and upper bound XU. 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

gj X 0 j 1 2 ...,m =

xiL

xi xU

i i 1 2 ...,n =

35CHAPTER 4Contents

(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 APIThe 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&D’s 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 X


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 User’s Guide (Ref 5). Providers of external algorithms are not required to follow all of these definitions explicitly.

37CHAPTER 4Contents

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.


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.

39CHAPTER 4Contents

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 optimization progresses.

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 optimization progresses.

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


40

Over-Riding OpenMDO Default ParametersOpenMDO 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

41CHAPTER 4Contents

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.


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.


43CHAPTER 4Contents

User Defined OpenMDOTM External Optimizer ServiceThe 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).

InputFor 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

SUBCASE 1

ABALYSIS = STATICS

.

Bulk data

BEGIN BULK

.

DOPTPRM OPTCOD ALLDOT METHOD 1

.

MD Nastran & MSC Nastran 2011 Release GuideUser Defined OpenMDOTM External Optimizer Service

44

OutputThere 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.

45CHAPTER 4Contents

Table 4-5 Intermediate Complexity Wing Optimization Results

Guidelines and LimitationsThe 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 SupportThere is no GUI support for OpenMDO.

References1. MD Nastran 2010 - SCA Framework User’s Guide (DEV)

2. MD Nastran 2010 Design Sensitivity and Optimization User’s 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 User’s 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

MD Nastran & MSC Nastran 2011 Release GuideUser Defined OpenMDOTM External Optimizer Service

46

Chapter 5: Aeroelasticity MD Nastran & MSc Nastran 2011 Release Guide

5 Aeroelasticity

Improvements in Splining

MD Nastran & MSC Nastran 2011 Release GuideImprovements in Splining

48

Improvements in Splining

IntroductionThe 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.

BenefitsImproved 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.

49CHAPTER 5Contents

User InputsThe 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.

Guidelines and LimitationsThe 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)


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%

51CHAPTER 5Contents

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


52

Chapter 6: Elements MD Nastran & MSC Nastran 2011 Release Guide

6 Elements

Rotordynamics Enhancements

MD Nastran & MSC Nastran 2011 Release GuideRotordynamics Enhancements

54

Rotordynamics EnhancementsStarting 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

http://www.virginia.edu/romac/

55CHAPTER 6Contents

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 ELEMUDSRARRAY = real values from the ELEMUDSCIARRAY = character data from the ELEMUDSKXX,KYX,KXY,KYY,CXX,CYX,CXY,CYY = coefficients to be passed back from the user serviceLEN_IARRAY, LEN_RARRAY, LEN_CARRAY - length of the associated arraysELID - current element idERROR_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

MD Nastran & MSC Nastran 2011 Release GuideRotordynamics Enhancements

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 {

SpeedLoadCase Data {

Download - MD Nastran 2011 & MSC Nastran 2011 Release Guide

Top Related