MD Nastran 2010 PAA User's Guide (Pre-Release)

MD Nastran 2010

PAA User’s Guide (Pre-Release)

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

MSC, MD, Dytran, Marc, MSC Nastran, MD Nastran, MSC Patran, MD Patran, OpenFSI, the MSC.Software corporate logo, 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. PAMCRASH is a trademark or registered trademark of ESI Group. SAMCEF is a trademark or registered trademark of Samtech SA. LS-DYNA is a trademark or registered trademark of Livermore Software Technology Corporation. ANSYS is a registered trademark of SAS IP, Inc., a wholly owned subsidiary of ANSYS Inc. ABAQUS is a registered trademark of ABAQUS Inc. All other brand names, product names or trademarks belong to their respective owners. 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.

Revision 0. June 25, 2010

MDNA:V2010:Z:Z:Z:DC-PAA

Corporate Europe Asia Pacific

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

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

1 Introduction

Overview of PAA Functionality 2

Generate a Part 4FMS and executive control section for a GENERATE run 4Component modal synthesis 6

Combine parts 7Combine one or more parts into an assembly 7

GRIDA - Associative Grid for PAA 7FMS and Executive Control for a COMBINE run 8Case control for a COMBINE run 8Bulk data for a COMBINE run 9

The static solution step 11FMS and executive control section for a Static SOLVE run 11Case control for a Static SOLVE run 11Bulk data for a Static SOLVE run 12

Solution for the real modes of an Assembly/Part 16FMS and executive control section for a real modes SOLVE run 16Case control for a real modes SOLVE run 16Bulk data for a real modes SOLVE run 16

Data Recovery 18FMS and executive control section for a recovery run 18Case control for a RECOVER run 18Bulk data for a RECOVER run 18

Exporting a Part 20FMS and executive control section for an EXPORT run 20Bulk data for an EXPORT run 20

Importing a part or data for a part 22FMS and executive control section for an IMPORT run 22Bulk data for an IMPORT run 22

Deleting a part or a data for a part 23FMS and executive control section for a DELETE_P run 23

MD Nastran PAA User’s Guide

iv

Bulk data for an DELETE run 23

Rapid Simulation-based Prototyping 24FMS and executive control section for an UPDTSP run 24Case control for an UPDTSP run 24Bulk data for an UPDTSP run 25

Examples 25

Chapter 1: IntroductionMD Nastran 2010 PAA User’s Guide

1 Introduction

Overview of PAA Functionality 2

Generate a Part 4

Combine parts 7

The static solution step 11

Solution for the real modes of an Assembly/Part 16

Data Recovery 18

Exporting a Part 20

Importing a part or data for a part 22

Deleting a part or a data for a part 23

Rapid Simulation-based Prototyping 24

MD Nastran PAA User GuideOverview of PAA Functionality

2

Overview of PAA FunctionalityPAA is a functionality in MD Nastran and is based on the concept of computationally reusable Parts. For purposes of this guide, a Part can be thought of as the finite element model (or matrices of that model that result after processing it) of a single component Part or of an Assembly of Parts. Using this definition everything is a Part, from the smallest component (for example, a bolt) to the complete assembled model (for example an airplane or a car).

All Parts are reusable. That is a bolt Part may be used in several different models, without the requirement to re-process the bolt for each model.

PAA processing is manual in the current system. There are no automatic restarts. The intent is to have an external program (a Model Manager) handle the logic involved in keeping the current database correct.

The concept of PAA is very similar to the process used in many NASA (and other) programs. That is, there is a single system integrator (person or company), who is in charge of the complete model and putting all of the finite element models together into a complete system model, and a series of component suppliers, each of whom is responsible for a single component or Assembly.

In this paradigm, each of the suppliers is responsible for their own model and the only one who sees the complete system model is the system integrator. However, when the system model is solved, the system integrator then passes results (either data recovery or boundary solutions) back to the suppliers and they are able to work independently with their models.

There are many variations to this process, but it is very common in both government and industry. The process often includes external contractors and suppliers, who might consider their component proprietary and not want to share the model data. In this case, PAA allows for secret Parts, where only the matrices and information needed to connect the Part to the rest of the model need be passed to others. The process even allows two-way secrecy, where neither the supplier nor the system integrator see the other's model, yet each is able to perform their analysis using the properties (mass, damping, stiffness, and loads) of the other's Parts.

Unfortunately, this process has always been a manual process with very little automation in it. Now, with the implementation of PAA, MSC is providing a better way to do it.

Component models may be provided to the system integrator as finite element models, or as matrices (with or without the model data), optionally with OTM (Output Transformation Matrices), that can be used to provide selective data recovery without having the actual model.

Special features of PAA include the ability to perform solutions at any level in the process tree with the ability to perform data recovery (using OTM if they are present) for any Part in the model. Solution results may be exported for independent work by suppliers. But a unique feature is RSP (Rapid Simulation-based Prototyping). Using this approach, any supplier may instantly see system level responses (even those in other Parts) caused by changes to their Part without having access to the system model.

Note: The PAA functionality in MD Nastran 2010 is Pre-release functionality and should not be used for production work.

3Chapter 1: IntroductionOverview of PAA Functionality

Superelements and Substructuring approximate components of this process, but neither is set up to be as complete a process tool as PAA is.

PAA also has the ability to EXPORT Parts from one computer (Secret, Semi-secret, more to follow) and use them on another computer.

This guide shows the steps in the PAA process and several examples.

In the 2010 demo system, there are 6 PAA-related SOL's. These solutions do not have a number, only a name:

GENERATE = create and reduce (if desired) a Part

COMBINE = create an Assembly using one or more Parts - NOTE: If desired, a physical model (bulk data) may be included in a COMBINE run. Using the GRIDA entry, bulk data entries may reference GRID points in upstream Parts (as long as those GRIDs still exist)

SLVSTAT = perform a static solution on a Part or Assembly

SLVMODES = calculate the modes of a Part or Assembly

RECOVER = perform data recovery using an existing solution

DELETE_P = delete a Part

EXPORT = export data for one or more Parts

IMPORT = import data for one or more Parts

UPDTSP = update solution Part with changes from another Part (used in RSP)

The SOL's may be run in any order desired and 'system' solutions (statics and normal modes for the demo system) may be performed at any step in the process. This guide has a separate section for each solution and several example problems at the end.

The current interface to PAA processing is through a DTI,COMMAND table. The format of this table is shown in an appendix. Examples are shown for each step in the process in the appropriate section. One very important requirement of the DTI,COMMAND is that character strings (for example a PARTNAME) can contain NO BLANK CHARACTERS in the string, except at the end. Also, the input lines with these are easiest entered using fixed format. The intent is to remove this limitation by providing the control using an external command file.

MD Nastran PAA User GuideGenerate a Part

4

Generate a PartPAA is designed to have each Part processed separately. This allows for more flexibility. Our recommendation (but not a requirement) is to put each Part into a separate database.

Each Part should have a separate, self-contained Nastran input file. This file should include the model of the Part and all loadings that might be applied to the Part.

Each Part must have a unique name assigned. The name is a 64-character string and must be unique among all Part names. This name is used as a qualifier (PARTNAME) in the database for all datablocks associated with this Part .

When generating a Part, the GENERATE Solution must be used. This allows static reduction or component modal synthesis, depending on the user requests.

FMS and executive control section for a GENERATE runFor a Generate run, the solution is GENERATE and it is recommended to assign the database files in your FMS section. The following shows the recommended style.

ASSIGN MASTER=PART_01.MASTER, DELETEASSIGN DBALL=PART_01.DBALL, DELETESOL GENERATECEND

This allocates the database files (if the files already exist it deletes the existing ones first - optional) and instructs the program to run the GENERATE solution.

Case control should contain a separate SUBCASE for any loads that might be applied on the Part.

At this point, you are simply defining the loadings and storing them as being associated with the Part, not applying them. The Case Control command, LOADNAME has been created for PAA. This command may be used in any SUBCASE to associate a user-provided name with a loading. In COMBINE and SOLVE runs, the bulk data entry, LOADCNAM, may be used to combine loadings using the LOADNAME.

The bulk data contains the complete bulk data description of the Part and the following:

DTI,COMMAND entries instructing the program to generate the Part. The following shows the common form of the DTI,COMMAND entries for a GENERATE run for a Part named Part_01_left_wing (note that underscore is used rather than a blank).

Note: There is no requirement for reduction on Parts. Although it is not required, it is recommended to perform component modal synthesis on the Part, even if the Part is only to be used in static solutions. For purposes of the demonstration system, if a reduction is to be done, ALL potential boundary points must be selected on ASET/BSET/CSET entries.

5Chapter 1: IntroductionGenerate a Part

Any boundary GRIDs/SPOINTs and the selected dof should be listed on ASET/ASET1, BSET/BSET1, and/or CSET/CSET1 entries.

The above entries instruct the program to perform the GENERATE step for part_01_left_wing.

Field 3 of the DTI,COMMAND entries must be the record number, starting with 0. The PARTNAME command(s) must be contiguous and start in record 1. Each entry must end with ENDREC. Field 4 on the first entry (Record 0) is the highest record number. In this case, 5.

Record 1 above provides the PARTNAME and an associated integer (in this case, 1) that is used in the DTI,COMMAND entries to select that Part. Multiple records providing PARTNAMEs may be used, however, all records containing the PARTNAMEs must occur before the associated PARTNAME (reference number) is used in the DTI,COMMAND.

Reduction in a GENERATE run

If a reduction is desired, then the desired boundary must be defined. This is accomplished (in the demo version, other options are coming) by using ASET/ASET1, BSET/BSET1, CSET/CSET1, BNDFIX/BNDFIX1, and/or BNDFREE/BNDFREE1 entries. The default reduction is Guyan reduction.

It is recommended to use AUTOMSET by adding;

PARAM,AUTOMSET,YES

To the bulk data in the input file.

If OTM are desired, they must be requested by the addition of a record in the DTI,COMMAND. An example of this record is:

DTI,COMMAND,6,REDUCE,OTM,ALL,ENDREC

Note: It is not required to keep all 6 dof at any boundary point.

Table 1-1

1 2 3 4 5 6 7 8 9

DT1 COMMAND 0 5 endrec

DT1 COMMAND 1 Partname 1 Part_01 left_wi ng Endrec

DT1 COMMAND 2 generate Part 1 Endrec

DT1 COMMAND 3 generate matrix all Endrec

DT1 COMMAND 4 generate store all Endrec

DT1 COMMAND 5 output Summary endrec

Note: The program will use all capital letters for the PARTNAME internally.

Note: While adding a record, the number of records (in record 0) must be updated.

MD Nastran PAA User GuideGenerate a Part

6

Component modal synthesisIf component modal synthesis (recommended when doing a reduction) is desired, in addition to defining the boundary, add the following entries:

PARAM,AUTOQSET,YESPARAM,METHCMRS,10EIGRL,10,XCXXX.XX,YYYY.YY,ZZZZ

The number on the METHCMRS and the SID on the EIGRL are not required to be 10, but the two must be the same number. It is up to you to determine the frequency range or number of modes for the EIGRL.

AUTOQSET tells MD Nastran to automatically generate the associated dof for the Q-set (component modes). This is not required, you may manually define the Q-set, but AUTOQSET is simpler and less error-prone.

When performing a reduction, unless you are creating a modal Part (one with no physical dof left after processing), you should define all potential boundary points/dof between the Assembly and the rest of the structure in this run by defining an A-set in a manner similar to the GENERATE run.

7Chapter 1: IntroductionCombine parts

Combine parts

Combine one or more parts into an assembly The COMBINE run is used to create an Assembly. One or more Parts, that have already been processed, may be combined to create the Assembly, plus a physical model for the Assembly may be included.

By default, connections between Parts are done automatically at coincident GRID points. There is an option to perform a manual attachment between Parts. Other options will be added in the future.

A special bulk data entry called the GRIDA is available in PAA for Assemblies. This entry creates an associative GRID, by pointing to a GRID in a Part that is being combined in the current run. This GRIDA may be referenced by all standard MD Nastran bulk data entries including, but not limited to, elements and constraints.

The format of the GRIDA entry is:

GRIDA - Associative Grid for PAA

Where:

Once again, the GRIDA is optional, but it is a convenient way to use a GRID from an already processed Part in your Assembly.

An alternate to the GRIDA is to place a GRID entry in the current bulk data that is coincident with the GRID in the Part you wish to use. The automatic connection logic will attach the Part GRID to the current one and it is now accessible in the current run using the ID from the GRID entry.

Note: Each Part is self-contained, so use of the same GRID id's in two or more Parts is allowed.

1 2 3 4 5 6 7 8 9

GRID GID ORIG_GID

PARTNAME (1:64)

Field Description Type

GID GRID id to be used in the current run.

Integer > 0

ORIG_GID GRID id part being referenced Integer > 0

PARTNAMEi Name of part ORIG_GID is in Character, C64, no internal blank spaces

MD Nastran PAA User GuideCombine parts

8

Additional bulk data entries may be used in COMBINE or SOLVE runs to combine loadings. These are the LOADCNAM, LOADCSUB, and LOADCLID. In the order of their occurrence, they can be used to combine loadings based on LOADNAME, SUBCASE id, of LOAD set id.

In a COMBINE run, the program creates an Assembly loading matrix, that contains a separate column for ALL loadings defined in ALL Parts that have gone into the Assembly. This matrix includes a separate column for each SUBCASE in the current input. Therefore, there is no need to create combinations at the Assembly level, unless you want to. The combinations may be easily defined at the SOLVE step. PAA also creates and updated LODS table, with information (Part id, LOADNAME, SUBCASE id, and LOAD set id) for each column in the loading matrix.

The default in COMBINE is to create the Assembly matrices, apply constraints, and store the Part. If you wish to perform a reduction on an Assembly, then the boundary points should be listed on ASET/BSET/CSET entries and component modal synthesis may be requested using similar entries to those used in a GENERATE run.

Once again, when performing a reduction, unless you are creating a modal Part (one with no physical dof left after processing), you should define all potential boundary points/dof between the Assembly and the rest of the structure in this run by defining an A-set in a manner similar to the GENERATE run.

FMS and Executive Control for a COMBINE run

The FMS should attach the database files for ALL Parts that are being combined and use a DBLOCATE command to locate the associated datablocks in each one. The combine step uses solution COMBINE. An example of the recommended FMS and executive control is:

ASSIGN MASTER='RUN03_SECTION3.MASTER', DELETEASSIGN DBALL ='RUN03_SECTION3.DBALL', DELETEASSIGN PART1='RUN01_SECTION1.MASTER'ASSIGN PART2='RUN02_SECTION2.MASTER'DBLOCATE LOGICAL=PART1 DATABLK=*DBLOCATE LOGICAL=PART2 DATABLK=*SOL COMBINE

The above example allocates the database files (and deletes any pre-existing copies) and attaches the database files for 2 Parts, that will be combined in this run.

Case control for a COMBINE run

The case control for a COMBINE run is similar to conventional case control. A SUBCASE should be provided for each NEW loading condition (including combinations of existing load cases) to be created during the current run. If there is no physical model involved in the Assembly (only pre-processed Parts are being combined), then only the basic case control is needed.

Note: a special feature of these entries is that all LOADCNAME, LOADCSUB, and LOADCLID entries with the same set id are combined, allowing load combinations based on any combination of LOADNAME, SUBCASE id, and LOAD id.

9Chapter 1: IntroductionCombine parts

If you wish to define load combinations using loads from the pre-existing Parts during a COMBINE run, SUBCASEs referencing LOADCNAM, LOADCLID, and LOADCSUB bulk data entries may be used. However, it is recommended to create loading combinations during the SOLVE run, so as to avoid duplicating (or doubling) loads by accident.

Bulk data for a COMBINE run

The DTI,COMMAND for a COMBINE run must tell the program which Parts are being combined and the name of the new Part (Assembly).

The above tells the program to create a new Part (Assembly) called SECTION3 by combining SECTION1 and SECTION2. The computational Parts (already processed - SECTION2 and SECTION1) will be combined with any current input to create the Assembly. The automatic connection between coincident GRIDs will be used - if you wish to attach the Parts manually, set OPTION to MANUAL.

Like in a GENERATE run, if a reduction is desired, the boundary must be defined by placing all desired boundary dof in the A-set. Also, entries similar to the following should be the bulk data to control the reduction:

PARAM,METHCMRS,1EIGRL,1,,,30PARAM,AUTOQSET,YESPARAM,AUTOMSET,YES

Note: In a DTI,COMMAND the PARTNAME entries must start in record 1 of the table and be contiguous.

1 2 3 4 5 6 7 8 9 10

DT1 COMMAND 0 8 endrec

DT1 COMMAND 1 partname 1 Section3 Endrec



DT1 COMMAND 4 Combine assembly 1 Endrec

DT1 COMMAND 5 Combine Comp1 Partid 2 Endrec

DT1 COMMAND 6 Combine Comp2 Partid 3 Endrec

DT1 COMMAND 7 Combine Option auto Endrec

DT1 COMMAND 8 output Summary endrec

Note: If you set OPTION to MANUAL, NO GRIDs will be connected automatically and you must do any attachments manually!

MD Nastran PAA User GuideCombine parts

10

Once again, the values on the EIGRL are determined by you. For the example above, it is requesting 30 component modes. AUTOMSET is a recommended parameter.

If desired, a physical model may be included in a COMBINE run. The program will automatically connect GRIDs in the physical model to boundary GRIDs from upstream Parts (other options will be available in the future). Mapping for different displacement coordinate systems and accounting for a GRID having less than 6 dof (after reduction of a Part) are accounted for automatically.

There are two methods to create representations of upstream GRID points in the physical model , the GRIDA (mentioned above) and placing a GRID coincident to the upstream GRID. The GRIDA is preferred, simply because it is less likely to have mistakes (such as location errors that would prevent attachment to the upstream GRID). Once these entries are created in the BULK DATA, the new GRIDs can be used like any other GRID in the BULK DATA. The GRID id in the physical model may be any desired id, it is not required that it have the same id as that in the upstream Part.

Output on how the Parts were combined is available, if desired, by adding the following to the bulk data.;

PARAM,PRINTOPT,1

11Chapter 1: IntroductionThe static solution step

The static solution stepStatic analysis may be performed at any step in the process. It may be performed on any Part/Assembly in the model. This Part will be known as the solution Part for the current run and all RECOVER runs using this solution. When the static analysis is done, the effects of the physical Part and all upstream Parts (if it is an Assembly) will be included in the solution. No Parts which are downstream from the Solution Part are included in the solution (although they may be present on the database).

Applied loads used in the SOLVE step are determined by the CASE CONTROL in the current input file. Remember, the loading matrix contains a column for every load defined for every Part in the current solution Part/Assembly. You probably do not want to solve for each of these separately, so you need to tell the program that to solve for. See the sections on the CASE CONTROL and BULK DATA for a description of how to select the loads to solve for.

FMS and executive control section for a Static SOLVE runAssign MASTER=static_solution.MASTER $ pick a name you like

Assign solpart=solution_part.MASTER $ database containing Solution Part

Dblocate logical=solpart, datablk=*

SOL SLVSTAT

The database for the desired Part/Assembly must be attached (the recommended method is to use the FMS, similar to the above). The static solution for PAA is SLVSTAT.

Case control for a Static SOLVE runCase control for a static SOLVE run is similar to conventional case control, with the addition of the LOADNAME command.

The rules for PAA are somewhat different than those in conventional Nastran - during a SOLVE run.

1. If a SUBCASE has a LOAD command, the program will combine all loads on the current Part and all upstream Parts with that LOAD id, plus any load combinations defined by LOADCNAM, LOADCSUB, and LOADCLID entries (in the current Bulk Data) with that LOAD id.

2. If a SUBCASE does not have a LOAD command, but has a LOADNAME command, the program will combine all loadings found (for all Parts) that have been defined using the specified LOADNAME to get the applied load.

This means that the user must use caution in selecting LOAD id's when defining the case control, as all loadings defined in all Parts with the selected LOAD id will be combined to define the applied load. This

MD Nastran PAA User GuideThe static solution step

12

is why we don't recommend defining load combinations at the COMBINE level, as (if the same id was used as the individual LOADs) the logic could result in the applied loads being double the desired loads.

Output requests for the Solution Part may be included in the case control. Additional data recovery for the Solution Part and any other Parts are done in separate RECOVER runs.

Bulk data for a Static SOLVE runThe only BULK DATA that will be used in a SOLVE run are the 'DTI,COMMAND', LOADCNAM, LOADCSUB, and LOADCLID entries. All other processing on the solution Part must be done before the SOLVE run. These entries allow the combination of any/all loadings defined on the current (solution) Part and all upstream Parts. Once again, all loads defined by ALL of these entries with the same SID are combined plus any loads from any Part in the Assembly, that has the same SID, so loading combinations based on load id, LOADNAME, and SUBCASE id are possible.

This is different from superelements - in superelement processing, it is up to the user to make sure that all loadings that are to be combined occur in the same order for all superelements. So, for superelements, the program combines loadings based on the order in the loading matrix, without verifying LOAD id, SUBCASE id, or LOADNAME.

Note: the program does print the OLOAD SUMMARY table in the static SOLVE run, so it is possible to verify the loadings from this.

Note: It is possible to perform a static solution on a modal Part. For clarity, a modal Part is one that has gone through reduction (in either a GENERATE or COMBINE step) with no user-defined boundary (A-set) dof. When this is done, the only dof that remain after reduction are the modes.


The new entries are as follows:

Where:

Table 1-2 LOADCNAM - Define Solution Load Combinations by Load Name

1 2 3 4 5 6 7 8 9 10

LOADCNAM LID S

S1

LOADNAME (1:64)

PARTNAME (1:64)

S2

LOADNAME2 (1:64)

PARTNAME2 (1:64)

Etc.


LID Load Set ID. Selected by Case Control LOAD command Integer > 0

S Overall scale factor (Similar to LOAD Bulk Data) Real <> 0.

Si Scale factor applied to LOADNAME loads Real <> 0.

LOADNAMEi Name of Load for that Part Character, C64

PARTNAMEi Name of Part Character, C64

Table 1-3 LOADCLID Define Solution Combination Using Part Load Set ID

1 2 3 4 5 6 7 8 9 10

LOADCLID LID S

S1 LID1

PARTNAME1 (1:64)

S2 LID2

PARTNAME2(1:64)

Etc.

MD Nastran PAA User GuideThe static solution step

14

Where:

Where:

Once again, if Classic IFP is used, PARTNAME cannot contain embedded blanks.

Example of the DTI, COMMAND for the SOLVE static step:dti,command,0,9,endrecdti command 1partname 1section3endrecdti command 2partname 2section2endrecdti command 3partname 3section1endrecdti,command,4,solve,solpart,1,endrecdti,command,5,solve,solution,statics,endrec




Si Scale factor applied to Load id loads Real <> 0.

LIDi Load ID specified during GENERATE by LOAD or CLOAD Case Control Directive

Integer > 0


Table 1-4 LOADCSUB Define Solution Load Combination Using Subcase Number

1 2 3 4 5 6 7 8 9 10

LOADC-SUB LID S

S1 SUB!

PARTNAME1 (1:64)

S2 SUB2

PARTNAME2(1:64)

Etc.




Si Scale factor applied to SUBCASE loads Real <> 0.

SUBi Subcase Number specified during GENERATE or COMBINE run

Integer > 0



dti,command,6,reco1,partname,1,endrecdti,command,7,reco2,partname,2,endrecdti,command,8,reco3,partname,3,endrecDTI,COMMAND,9,OUTPUT,SUMMARY,endrec

First, note that the PARTNAMES must start with record 1 and be contiguous.

In this case, the solution Part is SECTION3. We select the static solution (for internal PAA processing). The RECOi (where I is an index) commands are instructions to prepare the information needed to gen-erate the information needed to perform data recovery on the associated Parts (SECTION1, SECTION2, and SECTION3). It does not instruct the program to perform data recovery (this is done in the RECOVER step). However, as mentioned earlier, data recovery is available for the solution Part during the SOLVE run.

The data required for data recovery may be EXPORTed after this run is complete. Each part used in the solution may have data recovery performed independently of all other Parts. This is ideal for a large system model, where a number of different groups (or subcontractors) are involved.

MD Nastran PAA User GuideSolution for the real modes of an Assembly/Part

16

Solution for the real modes of an Assembly/PartIt is possible to perform a real eigenvalue solution on any Part/Assembly at any time in the process. Once again, this is a unique feature of PAA. Superelements can only solve for the real modes of the residual structure.

As there are no loads applied during an eigenvalue extraction, the case control and bulk data are very simple for an eigenvalue solution using PAA. Only the METHOD command is required and an EIGR or

EIGRL entry to determine the method used for solving the eigenvalue problem. Of course, the

DTI,COMMAND is also required.

FMS and executive control section for a real modes SOLVE runAssign MASTER=solution_modes.MASTER $ pick a name you like

Assign solpart=solution_part.MASTER $ database containing Solution Part

Dblocate logical=solpart, datablk=*

SOL SLVMODES

The database for the desired Part/Assembly must be attached (the recommended method is to use the FMS, similar to the above). The real eigenvalue solution for PAA is SLVMODES.

Case control for a real modes SOLVE runThe case control for normal modes in PAA is simple, it needs only the METHOD command and any out-

put requests desired for the solution Part during this run. A sample case control for a real eigenvalue PAA solution follows:

title = cantilever beam test of solvesubtitle = cantilever beam model - solve modesdisp = allmethod = 11

In this example, method 11 is chosen (with the requirement of an EIGR or EIGRL in the bulk data section) and output for the solution Part eigenvectors is requested.

Bulk data for a real modes SOLVE runThe only bulk data that will be used in a real modes SOLVE step is the EIGR/EIGRL selected in case

control and the DTI,COMMAND. The EIGR/EIGRL will select the eigenvalue solution method used

and how many modes will be found. The DTI,COMMAND is used to control the PAA process.

Example of the DTI,COMMAND for the real modes step:dti,command,0,9,endrec

17Chapter 1: IntroductionSolution for the real modes of an Assembly/Part

dti command 1partname 1section3endrecdti command 2partname 2section2endrecdti command 3partname 3section1endrecdti,command,4,solve,solpart,1,endrecdti,command,5,solve,solution,modes,endrecdti,command,6,reco1,partname,1,endrecdti,command,7,reco2,partname,2,endrecdti,command,8,reco3,partname,3,endrecDTI,COMMAND,9,OUTPUT,SUMMARY,endrec

This is similar to the DTI,COMMAND used for the static SOLVE step, except for the SOLUTION is now MODES.

Like in the previous static example, the DTI,COMMAND,RECOi lines request that the program write the information that will be required to perform data recovery on the 3 Parts (SECTION1, SECTION2, and SECTION3) on the database. After this run completes, the individual data can be EXPORTed for these Parts and sent to the people who developed the Parts for data recovery. Note that (except for the person performing data recovery on the solution part) none of the suppliers needs the solution Part data or even the process tree.

MD Nastran PAA User GuideData Recovery

18

Data RecoveryData recovery is done as a separate run (it is recommended, but not required, that a separate data recovery run be performed for each Part). There is only one solution (RECOVER) used to perform data recovery. The DTI,COMMAND, and the solution data itself determine the type of data recovery performed. One or more Parts may be processed in a RECOVER run (once again, it is recommended to perform data recovery on a single part in each RECOVER run). An important part of the input is the qualifiers (SPC,MPC, METHOD, and so on). These must match those which were set when the Part was created. Any existing solution may be used for data recovery

FMS and executive control section for a recovery runAssign master=run06_recover.master, delete $ new database for data recoveryAssign dball =run06_recover.dball, delete $ new database for data recovery

Assign solve = 'run04_solve.master' $ database with solution and Parts to be recovereddblocate logical=solve datablk=*SOL RECOVERThe above is an example of the FMS and executive control for a RECOVER run. Once again, RECOVER is the solution used for data recovery (for both statics and normal modes).

Case control for a RECOVER runThe case control for a RECOVER run must have the same qualifiers (SPC, MPC, ans so on) as were used when the Part was created (using GENERATE or COMBINE). This is required to find the correct datablocks on the database. The only other requirement is that the SUBCASEs should align with the SOLVE run (this is to get the correct output requests for each solution, the LOAD command is not required). Desired output requests should be entered in the case control as you would normally.

In addition, there number of SUBCASEs must match the number in the SOLVE run.

Bulk data for a RECOVER runThe only bulk data for a RECOVER run is the DTI,COMMAND, that is used to tell the program which

Part(s) data recovery is being performed on.

Example of the DTI,COMMAND for data recovery using a static solution:dti,command,0,7,endrecdti command 1partname 1section1endrecdti command 2partname 3section3endrecdti,command,3,recover,solution,static,endrecdti,command,4,recover,solpart,3,endrecdti,command,5,recover,reco1,part,1,endrecdti,command,6,recover,caseid,ordinal,endrecDTI,COMMAND,7,OUTPUT,SUMMARY,endrec

19Chapter 1: IntroductionData Recovery

Once again, the list of PARTNAMEs must occur first (starting with record 1) on the DTI,COMMAND entries. In this case, we are working with parts section1 and section3.

Record 3 is used to instruct the program that it is to perform data recovery for a static solution. If this were normal modes, the word static would be replaced with the word modes on this record.

The next record (4) tells the program that the Solution Part is Part 3 (section3). This is how the program determines which solution to use.

The following record (5) instructs the program to perform data recovery on Part 1 (section1) in this run. Once again, (although it is not required) it is recommended that a separate RECOVER run be performed for each Part

Record 6 is the recommended order for the data recovery.

Record 7 is optional, requesting an echo of how the DTI,COMMAND is interpreted by the program.

MD Nastran PAA User GuideExporting a Part

20

Exporting a PartThere are two ways to EXPORT Part data. One is a separate PAA solution for EXPORTing Part data, the other is to use DBUNLOAD. The PAA solution allows you to EXPORT selected data in either a binary or a machine-independent file. The format of the EXPORT file is identical to OUTPUT2, but the EXPORT process is different than OUTPUT2. There is a sister solution, IMPORT, that can read in the information and store it on a database. DBUNLOAD is a standard MSC.Nastran feature and can be used at any time to unload and load a database or subset of the database.

FMS and executive control section for an EXPORT runAssign OUTPUT2=PART_1.export, unit=41Assign partdb=export_part.MASTER $ database containing the Part to be

EXPORTedDblocate logical=partdb datablk=*SOL EXPORT

The above assigns the database containing the information to be EXPORTed and the file the selected data will be written to. The file is an OUTPUT2 file and the recommended name is partname.export (where partname is the PARTNAME being EXPORTed).

Bulk data for an EXPORT runThe only bulk data required for an EXPORT run is the DTI,COMMAND for PAA.

Sample format of the DTI,CAMMAND table for Export DTI,COMMAND,0,6DTI COMMAND 1 PARTNAME1 NAME_OF_PART_1 ENDRECDTI,COMMAND,2,EXPORT,PART1,NAME,1,ENDRECDTI,COMMAND,3,EXPORT,PART1,SELECT,SEMI,ENDRECDTI,COMMAND,4,EXPORT,FILE,UNIT,41,ENDREC (points to the ASSIGN statement)DTI,COMMAND,5,EXPORT,FILE,POSITION,0,ENDRECDTI,COMMAND,6,SOLPART,1 (only required for RECOVER data)

Currently there are following five ways to SELECT (record 3 ) the items for EXPORT:

1. SECRET (default) = export only the matrices and information necessary to include this Part in an Assembly.

2. SEMI = almost SECRET – in addition to SECRET, export GEOM1 and GEOM2 (necessary to display the Part, but no property or loading information is included)

3. SOLUTION = exports the datablocks (SOLN and UAPART) necessary to perform data recovery on a Part after a solution is done.

4. DATABLK = select the datablocks being EXPORTed a separate line using this option may be used in a single EXPORT for each datablock to be EXPORTed)

Note: There is no case control required for an EXPORT run

21Chapter 1: IntroductionExporting a Part

5. RECOVER = EXPORT solution data for the Part (needs SOLPART defined)

The FILE commands determine the file (OUTPUT2) that will be used, the initial file position (like the

OUTPUT2 DMAP position parameter) and the form (BINARY for now)

Data for more than one Part can be EXPORTed in a single run if desired.

MD Nastran PAA User GuideImporting a part or data for a part

22

Importing a part or data for a partThere is a separate PAA solution for IMPORTing Part data. This solution allows you to IMPORT selected data from either a binary or a machine-independent file (currently only binary). The format of the IMPORT file is identical to INPUTT2, but the IMPORT process is different than INPUT2. There is a sister solution, EXPORT, that creates the file used by IMPORT.

FMS and executive control section for an IMPORT runAssign INPUTT2=PART_1.export, unit=41Assign MASTER=import_part.MASTER $ whatever name you want to useSOL IMPORT

The above assigns EXPORT file containing the information to be IMPORTed and the database file the selected data will be written to. The file is an INPUTT2 file and the recommended name is part-name.export (where partname is the PARTNAME being IMPORTed).

Bulk data for an IMPORT runThe only bulk data required for an IMPORT run is the DTI,COMMAND for PAA.

Sample format of the DTI,COMMAND table for import

DTI,COMMAND,0,1

DTI,COMMAND,1,IMPORT,UNIT,17,ENDREC (points to the ASSIGN statement)

The only requirement in DTI,COMMAND for IMPORT is to specify the UNIT containing the datablocks to be IMPORTed. Currently IMPORT reads all datablocks from the file for the requested Part(s) and writes them into the database.

The FILE commands determine the file (INPUTT2) that will be used, the initial file position (like the OUTPUT2 DMAP position parameter) and the form (BINARY for now).

Note: There is no case control required for an IMPORT run

23Chapter 1: IntroductionDeleting a part or a data for a part

Deleting a part or a data for a partThere is a separate solution to delete selected Part(s) or data for one or more Parts from the current data-base. This solution is DELETE_P (someone else got DELETE first). This solution is COMMAND-

driven. The input file for this solution requires only the FMS, Executive Control, and a DTI,COMMAND

set in BULK DATA.

FMS and executive control section for a DELETE_P runAssign MASTER=solution_part.MASTERSOL DELETE_P

For a DELETE_P run, the only FMS required is to assign the database you wish to delete the Part(s) from and to select the solution (DELETE_P).

Bulk data for an DELETE runThe only bulk data required for a DELETE run is the DTI,COMMAND instructing the program what to

delete.

Sample formar of the DTI,COMMAND for a DELETE rundti,command,0,6,endrecdti command 1partname 1part10x endrecdti command 2partname 2part01 endrecdti command 3partname 3part02 endrecdti,command,4,delete,part,2,endrecdti,command,5,delete,part,1,endrecdti,command,6,delete,part,3,endrec

The above would delete all datablocks associated with PART01, PART02, and PART10X from the cur-rent database.

MD Nastran PAA User GuideRapid Simulation-based Prototyping

24

Rapid Simulation-based PrototypingThe Rapid Simulation-based Prototyping (RSP) is the most complex and powerful application of PAA. In this process, any Part in the process tree may be updated and the modified solution obtained without the requirement that all Assemblies between the modified Part and the Solution Part be processed. This approach does use an approximation (that the load paths between the changed Part and the Solution Part are not changed), but preliminary results have been excellent.

RSP is a four step process;

1. The modified Part be re-processed (it is easiest to do this with a new PARTNAME).

2. Update the Solution Part (once again, preferably with a new PARTNAME for the updated solution Part) to account for the change (this uses SOL UPDTSP).

3. Performing the updated solution.

4. Data recovery.

The only step in this process that is new is the UPDTSP step, which is documented here – an example of RSP is shown later.

FMS and executive control section for an UPDTSP runIn order to run UPDTSP run, the database for the original Part (for this example PART2), the updated Part (PART2A), and the original Solution Part (PART3) are required.

assign master='updtsp.master', delete $ new databaseassign dball ='updtsp.dball', delete $ new databaseassign oldsoln='run03_part3.master'dblocate logical=oldsoln, datablk=*, copyassign part2a='run08_part2a.MASTER'dblocate logical=parta,datablk=*, copysol updtsp

In the above, updtsp.master and updtsp.dball are the new (updated) solution Part database.

Run03_part3.master is the master database for the original Solution Part (and also for PART2 – if PART2 was in a different database, it would have to be attached also).

Run08_part2a.MASTER is the master database for the updated Part

Case control for an UPDTSP runThe case control for the UPSTSP fun MUST have the correct qualifiers set to match the other runs (a current limitation). Otherwise, there is no requirement for the case control in this run.

25Chapter 1: IntroductionRapid Simulation-based Prototyping

Bulk data for an UPDTSP runThe only bulk data used for an UPDTSP run is the DTI,COMMAND with the appropriate commands.

dti,command,0,9dti command 1 partname 1part2 endrecdti command 2 partname 2part2a endrecdti command 3 partname 3part3 endrecdti command 4 partname 4part3a endrecdti,command,5,updtsp,oldpart,1,endrecdti,command,6,updtsp,newpart,2,endrecdti,command,7,updtsp,oldspart,3,endrecdti,command,8,updtsp,newspart,4,endrecDTI,COMMAND,9,OUTPUT,SUMMARY,endrec

Records 1-4 are the PARTNAMEs used in this run

Part2 = original Part that is being changed = oldpart

Part2a = updated version of part2 = newpart

Part3 = original Solution Part = oldspart

Part3a = updated Solution Part (created in this run) = newspart

Records 5-8 are used to tell the program how the Parts are to be used.

Record 9 is optional and requests a summary printout of the command data as used in this run.

No other input data is needed for this step.

Once the UPDTSP run is completed, the updated Solution Part may be solved and data recovery can be performed on any Part above it in the process tree.

Examples

Sample 1 - a simple cantilever beam

For this example, a simple cantilever beam model, modeled using BAR elements is used. Both statics and normal modes are solved.

The model is divided into 3 Parts, Section1, Section2, and Section3. Section3 will be an Assembly and will be the Solution Part.

The process tree is a simple single-level tree.


26

In order to prepare the model for solution, three runs are required, GENERATE is used for Parts 1 and 2, and COMBINE is used for Part 3. Although it is not necessary to perform a reduction, we will perform a reduction at each step


Section 1 has boundary points 1 and 3, section 2 has boundary point 6..

Although not shown in the model of Section3, Section1 and Section2 are included in it, as it is an Assembly.

Input files for this example are:

Run01_section1_generate.dat - GENERATE section1 Run02_section2_generate.dat – GENERATE section2Run03_section3_combine.dat – use COMBINE to create Assembly section3Run04_solve_statics.dat – static solution of Assembly (section3)Run05_recover_static1.dat – statics data recovery on section1Run06_recover_static2.dat – statics data recovery on section2Run07_solve_modes.dat – solve for modes of Assembly (section3)Run08_recover_modes1.dat – normal modes data recovery on section1Run09_recover_modes2.dat – normal modes data recovery on section2

Generate Section1

We have the following input file to GENERATE Section 1. The FMS section assigns the database files .

assign master='run01_section1.MASTER', deleteassign dball ='run01_section1.DBALL', deleteSOL generatecendtitle = cantilever beam demonstration problemsubtitle = run 1 - generate part 1disp(plot) = allstress(plot) = allsubcase 1loadname = gravity xload = 1subcase 2loadname = gravity yload = 2begin bulk$ Keep GRIDs 1 and 3 - 1= to be constrained$, 3 = attachment pointaset1,123456,1,3$$ perform component modal synthesis$param,methcmrs,1

Note: GRID 1 is to be constrained for our cantilever. This could be done in Section1 or Section3. For this example, the constraint will be applied in Section 3. Section3 contains GRID points 1, 3, 4, 5, and 6. GRID point 1 in Section3 is there simply to show that we can connect Section1 at GRIDs 1 and 3, then constrain GRID 3 in Section3.

Note: PAA runs should always be done with SCR=NO.


28

eigrl,1,,,10param,autoqset,yes$dti,command,0,8dti command 1 partname 1section1endrecdti,command,2,generate,part,1,endrecdti,command,3,generate,matrix,all,endrecdti,command,4,generate,store,all,endrecdti,command,5,reduce,partname,1,endrecdti,command,6,reduce,transmat,make,otm,endrecdti,command,7,reduce,otm,all,endrecDTI,COMMAND,8,OUTPUT,SUMMARY,endrec$param,grdpnt,0$grav,1,,386.0886,1.,grav,2,,386.0886,0.,1.$grid,1,,0.,0.,0.grid,2,,10.,0.,0.grid,3,,20.,0.,0.$cbar,1,1,1,2,0.,1.,0.cbar,2,1,2,3,0.,1.,0.$pbar,1,1,1.,11.,12.,1.mat1,1,10.+6,,.3,.1param,wtmass,.00259ENDDATA

In order to GENERATE a Part, the GENERATE solution is selected.

In the case control it is recommended that all loadings that might be applied on the Part must be defined in the GENERATE run for efficiency. Note the LOADNAME command - this allows you to associate a name with each SUBCASE. Later, these names may be used to define loading combinations.

The model of the Part is in the bulk data. Once again with all loadings that might be applied on the Part.

The DTI,COMMAND entries are required to tell the program what is to be done in this run. In this case, we are going to generate and reduce Section1. Also, OTM have been requested. When OTM are requested, the case control must contain the all output requests that might be made using the OTM. OTM are currently available for displacements, element stresses, element forces, and SPC forces. In this model, OTM for displacement and stress output have been requested. The plot option requests that they be calculated, but not printed in the f06 file.

Reduction is optional in the GENERATE run. If reduction is to be done, then ALL boundary dof must be listed on ASET/ASET1, BSET/BSET1, and/or CSET/CSET1 entries. The entries selected determine how the boundary dof are treated during component modal synthesis (cms - if requested). If cms is not requested, all of the above entries are treated the same.

If cms is desired, then the bulk data must contain PARAM,METHCMRS, an EIGR or EIGRL (referenced by METHCMRS) and a Q-set definition (PARAM,AUTOQSET, YES is the easiest way to do this). For this model, 10 component modes have been requested.


Generate Section2

We have the following input file to GENERATE Section2. It is similar to the input to GENERATE Section1.

assign master='run02_section2.MASTER', deleteassign dball ='run02_section2.DBALL', deleteSOL generatecendtitle = cantilever beam model demonstration problemsubtitle = run 2 - generate part 2disp(plot) = allstress(plot) = allsubcase 1loadname = gravity xload = 1subcase 2loadname = gravity yload = 2begin bulk$ boundary definitionaset1,123456,6$$ perform component modal synthesis$param,methcmrs,1eigr,1,mgiv,,,10spoint,10001,thru,10010qset1,0,10001,thru,10010$dti,command,0,8dti command 1 partname 1section2endrecdti,command,2,generate,part,1,endrecdti,command,3,generate,matrix,all,endrecdti,command,4,generate,store,all,endrecdti,command,5,reduce,partname,1,endrecdti,command,6,reduce,transmat,make,otm,endrecdti,command,7,reduce,otm,all,endrecDTI,COMMAND,8,OUTPUT,SUMMARY,endrec$param,grdpnt,0grav,1,,386.0886,1.,grav,2,,386.0886,0.,1.$grid,6,,50.,0.,0.grid,7,,60.,0.,0.grid,8,,70.,0.,0.grid,9,,80.,0.,0.$cbar,6,1,6,7,0.,1.,0.cbar,7,1,7,8,0.,1.,0.cbar,8,1,8,9,0.,1.,0.pbar,1,1,1.,11.,12.,1.mat1,1,10.+6,,.3,.1param,wtmass,.00259


30

ENDDATA

For this Part, GRID 6 is the boundary.

The run uses a manual Q-set definition, rather than the automatic method used in the run that generated Section1. This is not required, however, as we intend to perform RSP on this Part later, it is a good idea to use a manual Q-set definition. RSP requires that the original Part and its replacement MUST have identical boundaries. This means that they must both have the same number of Q-set dof, in addition to the physical boundaries being identical.

For this model, 10 component modes have been requested.

Combine Section1 and Section2 with the physical model of Section3 to create Section3

We have the following input file to COMBINE Section1 and Section2 with the physical model for Section3 to create Section3. It is not required to have a physical model for a 'combined Part', but it is allowed.

assign master='run03_section3.master', deleteassign dball ='run03_section3.dball', deleteassign part04 = 'run01_section1.MASTER'assign part06 = 'run02_section2.MASTER'dblocate logical=part04 datablk=*dblocate logical=part06 datablk=*SOL combinecendtitle = cantilever beam demonstration problemsubtitle = run 3 - combine parts 1 and 2 to create part 3spc = 10subcase 1loadname = gravity xload = 1subcase 2loadname = gravity yload = 2begin bulk$ set to request information from the COMBINE stepparam,printopt,1$ constrain the model - for this run, put a coincident GRID to$ grid 1 from part 1 - and constrain itspc1,10,123456,1grid,1,,0.,0.,0.$ boundary definitionaset1,123456,3,6

Note: It is not required to select all 6 dof on a boundary GRID. However, any dof not selected will not be available for attachment to downstream Parts.

Note: The same LOADNAMEs and LOAD id's have been used in this run as in the one for Section1. This can make it easier to combine loadings later.


$ cms requestparam,methcmrs,1eigrl,1,,,1param,autoqset,yes$dti,command,0,8,endrecdti command 1partname 1section3endrecdti command 2partname 2section1endrecdti command 3partname 3section2endrecdti,command,4,combine,assembly,1,endrecdti,command,5,combine,comp1,partid,2,endrecdti,command,6,combine,comp2,partid,3,endrecdti,command,7,combine,option,auto,endrecdti,command,8,output,summary,endrecgrav,2,,386.0886,0.,1.grav,1,,386.0886,1.grid,3,,20.,0.,0.grid,4,,30.,0.,0.grid,5,,40.,0.,0.grid,6,,50.,0.,0.cbar,3,1,3,4,0.,1.,0.cbar,4,1,4,5,0.,1.,0.cbar,5,1,5,6,0.,1.,0.pbar,1,1,1.,11.,12.,1.mat1,1,10.+6,,.3,.1param,wtmass,.00259

Once again, for convenience, the same LOADNAMEs and LOAD id's have been used in this run as in the one for Section1 and Section2.

The program will automatically connect any GRIDs in the current input with any coincident boundary GRIDs from the upstream Parts.

For this Part, GRID 6 is the boundary. Although a reduction is not required, we are performing one for demonstration purposes. CMS has also been requested for 10 modes.

GRID 1 is added to the input for Section3 so that we can apply our constraint on it. Notice that there are no elements connecting to it, rather we will depend on the automatic connection logic to connect it and GRID 3 to Section1 and connect GRID 6 to Section2.

PARAM,PRINTOPT,1 is added to request information on how the Parts are being attached in the COMBINE step. During a COMBINE step, the program starts with any GRIDs and SPOINTs in the current input, then internally creates GRIDs and SPOINTs to represent the upstream Part boundaries. The ids for these internally generated GRIDs and SPOINTs start above the highest GRID/SPOINT id in the current input.

Note: If cms were requested without any physical dof in the A-set, you would be creating a modal Part, one that has no physical dof after processing. Modal Parts can be used in both statics and normal modes.


32

The DTI,COMMAND entries instruct the program to combine Section1 and Section2 with the physical model to create Section3.

Solve Statics

We have the following input file to perform a static solution on Assembly Part Section3. This uses solution SLVSTAT.

assign master='run04_solve.master', deleteassign dball ='run04_solve.dball', deleteassign part03 = 'run03_section3.master'dblocate logical=part03 datablk=*dbdict select(name,partname,mpc,spc)$SOL slvstat$cendtitle = cantilever demonstration problemsubtitle = perform static solutiondisp = allstress = allspc = 10 $ spc set used in COMBINE runsubcase 1loadname = gravity xload = 1subcase 2loadname = gravity yload = 2begin bulk$dti,command,0,9,endrecdti command 1partname 1section3endrecdti command 2partname 2section2endrecdti command 3partname 3section1endrecdti,command,4,solve,solpart,1,endrecdti,command,5,solve,solution,static,endrecdti,command,6,solve,reco1,partname,1,endrecdti,command,7,solve,reco2,partname,2,endrecdti,command,8,solve,reco3,partname,3,endrecDTI,COMMAND,9,OUTPUT,SUMMARY,endrec$enddata

This file is called run04_solve_statics.dat

Note that the SPC set is identical to that used in the COMBINE run, that crated Section3. Although no new constraints are being applied, the datablocks for Section3 are store with the qualifier SPC=10, so if we wish to use them, we must be careful to match the qualifiers that were used to create them.

The case control instructs the program to solve for 2 loading conditions. In this run, we take advantage of having used the same LOAD id in each prior run. A SLVSTAT run will automatically combine ALL loadings with the same LOAD id as that in the current subcase.


The LOADNAME commands in this run are not used to determine how to combine the loadings, as there are LOAD commands. If there were no LOAD commands, the program would automatically combine all loads with the LOADNAME in each subcase.

The DTI,COMMAND entries request the solution of Section3, and that the boundary solutions be found for all Parts.

The SOLVE step automatically performs any requested data recovery on the Solution Part. Data recovery for any other Parts must be done using the RECOVER solution.

Data Recovery for Statics

We have the following input file to perform a data recovery on Section2 using the static solution from the previous run. The solution to perform data recovery is RECOVER. The same solution is used for both statics and normal modes.

assign master=run06_recover.master, deleteassign dball =run06_recover.dball, deleteassign solve = 'run04_solve.master'dblocate logical=solve datablk=*$SOL recover$cendtitle = cantilever beam demonstration problemsubtitle = run 6 - statics data recovery on Part 2$disp = allstress = all$subcase 1loadname = gravity xload = 1subcase 2loadname = gravity yload = 2begin bulk$dti,command,0,7,endrecdti command 1partname 1section2endrecdti command 2partname 3section3endrecdti,command,3,recover,solution,static,endrecdti,command,4,recover,solpart,3,endrecdti,command,5,recover,reco1,part,1,endrecdti,command,6,recover,caseid,ordinal,endrecDTI,COMMAND,7,OUTPUT,SUMMARY,endrec$ENDDATA

This input file is called run06_recover_static2.dat

Note that the SPC set is identical to that used in the GENERATE run, that created Section2. Once again we must be careful to match the qualifiers that were used when the Part was created.


34

The case control instructs the program to perform data recovery for the two subcases. The LOAD and LOADNAME commands are not required, as that information is contained in the boundary solution datablocks.

The DTI,COMMAND entries request data recovery for Section2 and state that the solution Part was Section3 (It is necessary to specify the Solution Part, as PAA allows solutions to be performed at any level in the process tree) and the solution type is statics. As the DTI,COMMAND does not request the use of the OTM we created earlier, conventional data recovery will be used.

Solve Modes

We have the following input file to solve Section3 for normal modes. This input file is called run07_solve_modes.dat.

assign master='run07_solve.master', deleteassign dball ='run07_solve.dball', deleteassign part03 = 'run03_section3.master'dblocate logical=part03 datablk=*$SOL slvmodes

diag 8,15,56$cendtitle = cantilever beam demonstration problemsubtitle = run 7 - normal modes solution$disp = allstress = allspc = 10subcase 1method = 1begin bulk$eigrl,1,,,10$dti,command,0,9,endrecdti command 1partname 1section3endrecdti command 2partname 2section2endrecdti command 3partname 3section1endrecdti,command,4,solve,solpart,1,endrecdti,command,5,solve,solution,modes,endrecdti,command,6,solve,reco1,partname,1,endrecdti,command,7,solve,reco2,partname,2,endrecdti,command,8,solve,reco3,partname,3,endrecDTI,COMMAND,9,OUTPUT,SUMMARY,endrec$ENDDATA

Solution SLVMODES is used.

Note that, once again, the SPC set is identical to that used in the COMBINE run, that created Section3.


The case control instructs the program to use EIGRL 10 to control the eigenvalue solution and calculate stresses and eigenvectors for the Solution Part.

The DTI,COMMAND entries tell the program that Section3 is the Solution Part, the solution is normal modes, and boundary solutions should be found for Section1, Section2, and Section3.

Data recovery for Section1 and Section2 require using RECOVER (similar to the previous example).

Sample 2 - Performing RSP on the model from sample 1

For this example, we will modify Section2 (and call the new Part 'part2a') of the previous model. The modification consists of adding a single offset GRID point with a concentrated mass. The GRID will be connected by a spring in the Y-direction and an RBAR will connect the other 5 dof to the tip GRID.

$ add mass and spring at tipgrid,10000,,80.,1.,0.celas2,10001,1.,10000,2,9,2conm2,10002,10000,,1.rbar,10003,9,10000,123456,,,13456$

The modifications to the input file for Section2 to create part2a are shown at the right:

In addition, the new Part name of 'part2a' is used in the file to identify the new Part. The change modifies the stiffness, mass, and loadings of the Part.


Run01_section1_generate.dat - GENERATE section1


Run03_section3_combine.dat - use COMBINE to create Assembly section3

Run04_solve_statics.dat - static solution of Assembly (section3)

Run05_recover_static1.dat - statics data recovery on section1

Run06_recover_static2.dat - statics data recovery on section2

Run07_solve_modes.dat - solve for modes of Assembly (section3)

Run08_recover_modes1.dat - normal modes data recovery on section1

Run09_recover_modes2.dat - normal modes data recovery on section2

Run10_part2a_generate.dat - generate modified section2 = part2a

Run11_update_solpart.dat - update Assembly (section3=>part3a)

Run12_solve_updated_statics.dat - static solution on updated Assembly(part3a)

Run13_recover_updated-static1.dat - statics data recovery on section1 using updated solution


36

Run14_recover_updated_static2.dat - statics data recovery on part2a

Run15_solve_update_modes.dat - solve updated Assembly(part3a) for normal modes

Run16_recover_updated_modes1.dat - normal modes data recovery on section1 using updated solution

Run17_recover_updated_modes2.dat - normal modes data recovery on part2a

Runs 1-9 are identical to sample 1.

Generate Part2A

The input file is similar to the file used to generate Section2. The changes are in the Partname, the model input, and the database names. Also, a manual Q-set definition is used to be sure that the boundary has the same number of dof as the original Part. This input file is called run10_part2a_generate.dat

Once again, this is a requirement of RSP. The replacement Part must have the same boundary dof as the original Part it is replacing.

assign master='run10_part2a.MASTER', deleteassign dball ='run10_part2a.DBALL', deleteSOL generatecendtitle = cantilever beam model demonstration problemsubtitle = run 10 - generate updated part 2adisp = allstress = allsubcase 1loadname = gravity xload = 1subcase 2loadname = gravity yload = 2begin bulk$ add mass and spring at tipgrid,10000,,80.,1.,0.celas2,10001,1.,10000,2,9,2conm2,10002,10000,,1.rbar,10003,9,10000,123456,,,13456aset1,123456,6param,methcmrs,1eigr,1,mgiv,,,10spoint,10001,thru,10010qset1,0,10001,thru,10010dti,command,0,8dti command 1 partname 1part2a endrecdti,command,2,generate,part,1,endrecdti,command,3,generate,matrix,all,endrecdti,command,4,generate,store,all,endrecdti,command,5,reduce,partname,1,endrecdti,command,6,reduce,transmat,make,otm,endrecdti,command,7,reduce,otm,all,endrecDTI,COMMAND,8,OUTPUT,SUMMARY,endrec


param,grdpnt,0grav,1,,386.0886,1.,grav,2,,386.0886,0.,1.grid,6,,50.,0.,0.grid,7,,60.,0.,0.grid,8,,70.,0.,0.grid,9,,80.,0.,0.cbar,6,1,6,7,0.,1.,0.cbar,7,1,7,8,0.,1.,0.cbar,8,1,8,9,0.,1.,0.pbar,1,1,1.,11.,12.,1.mat1,1,10.+6,,.3,.1param,wtmass,.00259ENDDATA

RSP - Update Solution Part

In this run, the original Part (Section2) is replaced by the updated Part (Part2a). PAA modifies the load matrix for the Solution Part (Section3) to include any new/changed loadings and updates the other matrices for the changes in stiffness/ mass/ damping. The input file is called run11_update_solpart.dat.

In order to do this, the databases associated with the Solution Part, original Part, and updated Part are attached. In this case, the database from run 3 contains both the original Part and the Solution Part. The database from run 10 contains the updated Part.

assign master='run_11_update_solpart.master', deleteassign dball ='run_11_update_solpart.dball', deleteassign oldsoln='run03_section3.master'dblocate logical=oldsoln, datablk=*, copyassign part2a='run10_part2a.MASTER'dblocate logical=part2a,datablk=*, copy$sol updtsp$cendtitle = cantilever beam demonstration problemsubtitle = run 11 update solution part$spc = 10subcase 1loadname = gravity xload = 1subcase 2loadname = gravity yload = 2begin bulk$dti,command,0,9dti command 1 partname 1section2endrecdti command 2 partname 2part2a endrecdti command 3 partname 3section3endrecdti command 4 partname 4part3a endrecdti,command,5,updtsp,oldpart,1,endrecdti,command,6,updtsp,newpart,2,endrec


38

dti,command,7,updtsp,oldspart,3,endrecdti,command,8,updtsp,newspart,4,endrecDTI,COMMAND,9,OUTPUT,SUMMARY,endrec$ENDDATA

Solution UPDTSP is used to update the solution Part matrices/tables based on the modifications. A different PARTNAME is used for the updated solution Part, so that the original one is still available (not required, but recommended). In this case, the original solution Part is Section3 and the updated solution Part is Part3a.

The case control in this run is used to set qualifiers, so it is best to have it be a copy of the case control from the run that created the solution Part.

RSP - Solve updated model for statics

This run is similar to the run to solve the original solution Part, only the solution Part is now Part3a and Section2 has been replaced by Part2a. For this input file, only the FMS and the Partnames in the DTI,COMMAND have been changed from the original static solution input.

assign master='run12_solve.master', deleteassign dball ='run12_solve.dball', deleteassign part3a = 'run_11_update_solpart.master'dblocate logical=part3a datablk=*SOL slvstat$cendtitle = cantilever demonstration problemsubtitle = perform static solutiondisp = allstress = allspc = 10 $ spc set used in COMBINE runsubcase 1loadname = gravity xload = 1subcase 2loadname = gravity yload = 2begin bulk$dti,command,0,9,endrecdti command 1partname 1part3a endrecdti command 2partname 2part2a endrecdti command 3partname 3section1endrecdti,command,4,solve,solpart,1,endrecdti,command,5,solve,solution,static,endrecdti,command,6,solve,reco1,partname,1,endrecdti,command,7,solve,reco2,partname,2,endrecdti,command,8,solve,reco3,partname,3,endrecDTI,COMMAND,9,OUTPUT,SUMMARY,endrec$enddata


The input to solve for normal modes is changed in a similar manner, as are the input files for data recovery, so they are not shown.

Sample 3 - Demonstrate EXPORT and IMPORT

This sample is simply a modified version of sample 1, with EXPORT and IMPORT implemented during the process to emulate multiple engineers, working on a secret project, where the model data cannot be shared between groups.

Now, all runs for section1 are done by one company and will appear in blue in the table below, runs for section2 are done by another company and will appear in orange, while runs for section3 (the Assembly) are done by a third company and will appear in purple. No company will see any model data for any other company's Part. Only the reduced matrices, information needed to connect Parts, and results data are passed between companies. No model data is shared (except for the boundary information).



Run01a_section1_export.dat - EXPORT section1

Run01b_section1_import.dat - import section1


Run02a_section2_export.dat -EXPORT section2

Run02b_section2_import.dat - import section2

Run03_section3_combine.dat - use COMBINE to create Assembly section3

Run04_solve_statics.dat - static solution of Assembly (section3)

Run04a_export_static_solution1.dat - export static solution for section1

Run04b_export_static_solution2.dat - export static solution for section2

Run05a_import_static1.dat - statics data recovery on section1

Run05b_recover_static1.dat - statics data recovery on section1

Run06a_import_static2.dat - statics data recovery on section2

Run06b_recover_static2.dat - statics data recovery on section2

Selected files are described below.

Run01a_section1_export.dat

This file exports the matrices and boundary information for section1 in a machine-independent format. The SECRET option is chosen, that means that only the information needed to connect the Part to an Assembly is transmitted, no model information (elements, materials, ans so on.) is transmitted.


40

This input file is very simple, the FMS is used to attach the database for section1, and dblocate the datablocks in that database.

assign section1='run01_section1.MASTER'dblocate logical=section1$assign output2=section1.op2, unit=41, formatted, delete$sol p_export$cendtitle = cantilever beam demonstration problemsubtitle = run 1a - export part 1 - secret$begin bulk$dti,command,0,7dti command 1 partname 1section1endrecdti,command,2,export,part1,name,1,endrecdti,command,3,export,part1,select,secret,endrecdti,command,4,export,file,unit,41,endrecdti,command,5,export,file,method,ascii,endrecdti,command,6,export,file,position,0,endrecDTI,COMMAND,7,OUTPUT,SUMMARY,endrec$ENDDATA

An FMS ASSIGN statement is used to allocate the file the data will be EXPORTed to. In this case, 'section1.op2' and it will be formatted (machine-independent).

The solution is P_EXPORT.

The case control has no required commands. In this case, simply a title and subtitle are provided to describe the run.

The DTI,COMMAND is used to select the Part to be exported (section1), the UNIT (41) the data will be written to and the data (SECRET) to be EXPORTed.

Run01b_section1_import.dat

This run is used by the system integrator (person with section3) to IMPORT the data for section1.

assign master='run01b_import.master', deleteassign dball ='run01b_import.dball', deleteassign inputt2=section1.op2, unit=41, formatted$SOL p_import$cendtitle = cantilever beam demonstration problemsubtitle = run 2b - import secret parts 1 and 2$begin bulk$


dti,command,0,3dti,command,1,partname,1,section1,endrecdti,command,2,import,unit,41,endrecdti,command,3,import,oper1,all,partname,1,endrec$$ENDDATA

The FMS section is used to allocate the database files and attach the file used to EXPORT the data for section1 (section1.op2) as unit 41.

The solution is P_IMPORT.

There are no required case control commands for IMPORT, however in this case, we have used the title and subtitle to identify the run.

The bulk data consists of the DTI,COMMAND, instructing the program to IMPORT the data found in unit 41. All datablocks found on this file will be IMPORTed and stored on the database.

Similar runs are done for section2. Run03 is almost identical to the previous versions, only the FMS section is different, attaching the databases created by the IMPORT runs and using DBLOCATE to get the data from them.

Run04 is identical to the previous examples

Run04a_export_static_solution1.dat

This run is used by the system integrator to EXPORT solution data for section1.

assign solution='run04_solve.master'dblocate logical=solution datablk=*$assign output2=part_1_results_ascii.op2, unit=41, formatted, delete$SOL P_EXPORT$cendtitle = cantilever demonstration problemsubtitle = export static solution for section1begin bulk$$dti,command,0,10dti command 1 partname 1section1endrecdti command 2 partname 2section2endrecdti command 3 partname 3section3endrecdti,command,4,export,part1,name,1,endrecdti,command,5,export,part1,solpart,3,endrecdti,command,6,export,part1,select,solution,endrecdti,command,7,export,file,unit,41,endrecdti,command,8,export,file,method,binary,endrecdti,command,9,export,file,position,0,endrecDTI,COMMAND,10,OUTPUT,SUMMARY,endrec


42

$$enddata

The FMS section is used to attach the database files and allocate the file used to EXPORT the solution data for section1 as unit 41.

The solution is P_EXPORT.

There are no required case control commands for EXPORT, however in this case, we have used the title and subtitle to identify the run.

The bulk data consists of the DTI,COMMAND, instructing the program to EXPORT the solution data for sectiona1.

A similar run is done for section2.

Run05a_import_static1.dat

This run is used by the contractor working with section1 to import the solution data.

assign master='run05a_import_soln.master', deleteassign dball ='run05a_import_soln.dball', delete$assign inputt2=part_1_results_ascii.op2, unit=41, formatted$SOL p_import$cendtitle = cantilever beam demonstration problemsubtitle = run 5a - statics boundary solution for section1begin bulk$$dti,command,0,7dti command 1 partname 1section1endrecdti command 2 partname 2section3endrecdti,command,3,import,oper1,all,partname,1,endrecdti,command,4,import,oper1,all,solpart,2,endrecdti,command,5,import,unit,41,endrecDTI,COMMAND,6,OUTPUT,SUMMARY,endrecDTI,COMMAND,7,OUTPUT,import,endrec$$ENDDATA

The FMS section is used to allocate the database files and attach the file used to IMPORT the solution data for section1 as unit 41.

The solution is P_IMPORT.

Once again, there are no required case control commands for IMPORT, however in this case, we have used the title and subtitle to identify the run.


The bulk data consists of the DTI,COMMAND, instructing the program to IMPORT the solution data for section1.

Run05b_recover_static1.dat

This run is used by the contractor working with section1 to perform data recovery.

assign master=run05b_recover.master, delete, tempassign dball =run05b_recover.dball, delete, temp$assign solution = 'run05a_import_soln.master'dblocate logical=solution datablk=*$assign part01='run01_section1.MASTER'dblocate logical=part01$SOL recover$cendtitle = cantilever beam demonstration problemsubtitle = run 5b - statics data recovery on Part 1disp = allstress = all$subcase 1loadname = gravity xload = 1subcase 2loadname = gravity yload = 2begin bulk$dti,command,0,7,endrecdti command 1partname 1section1endrecdti command 2partname 3section3endrecdti,command,3,recover,solution,static,endrecdti,command,4,recover,solpart,3,endrecdti,command,5,recover,reco1,part,1,endrecdti,command,6,recover,caseid,ordinal,endrecDTI,COMMAND,7,OUTPUT,SUMMARY,endrec$ENDDATA

The FMS section is used to allocate temporary database files and attach the database created by the IMPORT run and the database used by the GENERATE run for section1.

The solution is RECOVER.

The Case Control for this run contains the output requests for the solution.

If the system integrator has not provided a description of the solutions, printing out the SOLN table from the database provides a solution description. Each record of the SOLN table contains the LOADNAME used in the solution run for the associated SUBCASE, plus information on loads from the current Part (section1) used in this solution and their scale factors.


44

When in doubt, you may use a single SUBCASE with your output requests and the program will use those output requests for all loading conditions.

The bulk data consists of the DTI,COMMAND, instructing the program for data recovery - this is identical to run05 in the previous examples.

Run06a and run06b are similar runs for section2.

MSC.Fatigue Quick Start Guide

I n d e xMD Nastran PAA User’s Guide

CCase control, 11Combine parts, 7

DData Recovery, 18Deleting a part or a data for a part, 23

EExamples, 25EXPORT

EXPORT selected information for one or more Parts, 20, 21, 22

Exporting a Part, 20

FFMS and executive control section, 4

GGenerate a Part, 4

IIMPORT

IMPORT data for one or more Parts, 20, 22, 23, 27

Importing a part or data for a part, 22

OOverview of PAA Functionality, 2

RRapid Simulation-based Prototyping, 24

SSolution for the real modes of an Assembly/

Part, 16

solution PartPart on which a Solution is performed, 15,

16, 17

TThe static solution step, 11

MD Nastran PAA User’s Guide

46

Documents

MD Nastran 2010 PAA User's Guide (Pre-Release)