The following sections describe which specific MD Nastran entry types can currently be read into Patran.

The MD Nastran entries described in this document are the only entries read when importing a NASTRAN input file into Patran. All non-supported entries will be sent to the appropriate Direct Text Input data box for this job. When errors occur during the import of a supported entry type, the entry being processed may or may not be imported, depending on the severity of the problem encountered. An error message will be presented regardless of whether or not the offending entry is actually imported.

Any references from supported entries to entries that were not imported (either due to not being a supported entry type or due to serious import errors) will still be attempted. If this reference is required in Patran for the entry currently being processed, it too will fail to import. For example, if there is a serious error on a GRID entry which causes it to not imported, then all elements attached to that GRID will also fail to import.

This Patran function can read incomplete MD Nastran files (except where explicitly noted). However, if the BEGIN BULK command is missing, the program can get confused when trying to determine if a particular entry belongs to the case control or bulk data. If you experience any difficulties importing a file that does not have a BEGIN BULK command, add one to the top of the file. This should avoid any such confusion.

Data in the MD Nastran input deck that is not recognized by Patran, including comments are placed in the reject file. These rejected cards are also placed into the Direct Text Input (DTI) text boxes. If you turn ON the ability to write DTI into the various portions of the MD Nastran input deck, the rejected cards will be placed back into the input deck when it is written out again. Note that decks with large amounts of rejected cards and comments may place an unacceptable amount of data in these text boxes. If this is the case, you can limit the amount of data by setting the environment variable:

The following coordinate system definitions can be read into Patran.

Coordinate systems and GRIDs which are referenced as part of a CORD definition must be in the same input file. If these are not found in the input file, the definition will be rejected.

References to coordinate frames other than for new coordinate frame definitions can be resolved with coordinate frames previously found in the Patran database.

Due to limitations in the Patran definitions of coordinate systems, chained definitions (definitions based on other coordinate systems or grids) are modified during import. The resulting definitions are equivalent in global space, but are based on global cartesian coordinates rather than GRID references or coordinate locations in other systems. This change is carried through when a new NASTRAN input file is created. All coordinate systems will be created using CORD2 type definitions, and they will all reference global cartesian coordinates. These definitions will be different from, but equivalent to, the original definitions.

The MD Nastran GRID entry is read fully, except the SEID field. The CD and CP references are both maintained. The PS data is used to create a constraint set. The details of the created load set are defined in the load set import section.

GRDSET data is merged into the GRID data during import. The data will be retained, but will appear directly on the GRID entry when a new NASTRAN input file is generated.

SPOINTs are treated as GRIDs at the global origin. They are assumed to have their GRID CD and CP fields set to the basic system, and their PS field is set to permanently constrain degrees-of-freedom 2 through 6.

Coordinate frames referenced in the CP field must exist in the same input file. Coordinate frames referenced on the CD field can exist in either the same input file, or the Patran database prior to the import.

The following MD Nastran elements and element properties can be read into Patran.

Higher order elements (CQUAD8, CTRIA6, CTRIAX6, CHEXA, CPENTA, CTETRA) will generate linear elements in Patran if none of the mid-edge nodes are specified.

PSHELL properties can be imported as any one of five Patran property types. The MID1, MID2, MID3, 12I/T3, and TS/T property fields are used to determine which one to choose. If MID2 is -1 and MID3 is 0, then a Plane Strain property set is used. If MID2 and MID3 are both 0, then a Membrane property set is chosen. If MID1 and MID3 are 0, then a Bending property set is used. If MID1, MID2, and MID3 are all the same, and the MD Nastran defaults are used for 12I/T3 and TS/T, then a Homogeneous property set is used. If all else fails, then an Equivalent Section property set is chosen.

The BAROR and BEAMOR data is merged onto the CBAR and CBEAM entries using the proper MD Nastran conventions. The data is treated as if it had originally been defined on the CBAR and CBEAM entries. When a new NASTRAN input file is created, the data will remain with the CBAR and CBEAM entries. No BAROR or BEAMOR entries are generated.

If a field is required to store varying data, the field will have the same name as the property set, with the name of the specific property word appended to it. For example, if property set “pshell.101” has a varying thickness, the field will be named “pshell.101.Thickness”.

Nodes and coordinate frames referenced on elements or element properties must exist, but they do not need to be in the input file. They could also have been defined in the Patran database prior to the import.

If a material is referenced, but can not be found, a new material with no properties will be created. A message will be issued indicating the creation of this material.

If an element property set is referenced, but can not be found, a new property set with no properties will be created. A message will be issued indicating the creation of this property set.

In some cases, the data found on the element can not be defined in Patran in a single property set. In those cases, multiple property sets will be created to define the distinct definitions. The table below defines extensions to the Property Set Names shown in the previous table. If the values on the specified field changes, a new property set with the indicated extension will be created.

If all elements which reference a single PID can be stored in a single property set, then no extension will be added to the Property Set Name.

The following MD Nastran material definitions can be read into Patran.

The following MD Nastran MPC and rigid element definitions can be read into Patran.

MPCs in Patran are treated as elements and are not associated to load cases. As a result, all SUBCASE related data is lost. The MPCs are simply imported into the model and are no longer associated to a specific load case.

MPCs can reference SPOINTs instead of GRIDs. If this is detected, the corresponding component field will be set to 1 (UX) to be consistent with the import of SPOINTs.

The MPCADD command is not read since the MPCs are simply imported and no associated to a load case. The SID references on the MPC entry are also lost for the same reason. New MPC IDs are assigned to these elements during import.

The following MD Nastran Loads and Boundary Condition definitions can be read into Patran.

If a field is required to store varying data, the field will have the same name as the load set, with the name of the specific data word appended to it. For example, if load set “force.101” has a varying force magnitude, the field will be named “force.101.Force”.

Load cases are created in Patran from the SUBCASE definitions in the NASTRAN input file. Load sets not referenced by a SUBCASE definition are created as load sets in Patran, but are not associated to a load case. Load sets defined above the first SUBCASE command, plus any permanent single point constraint sets from the GRID entries, are associated to all load cases created during this import. If there is no case control data, then load sets will be created, but they will not be assigned to any load cases.

The SPCADD and LOAD entries are used in creating load cases in Patran, but the SID of these entries is lost. The SIDs on the individual SPCx, FORCE, MOMENT, GRAV, PLOADx, RFORCE, and TEMPx entries are used in creating the names of the load sets.

The name for the created load cases is derived from the subtitle of the SUBCASE. This is done for consistency with the forward PAT3NAS translation.

A job is created during the import. The name of the created job is the basename of the file being read.

MD Nastran allows load sets to be referenced in multiple places with different scale factors. This is not possible in Patran. Therefore, in some cases, multiple copies of the same load set need to be created with the only difference being the scale factor. The name of these load sets are modified to include the subcase ID to create unique names.

The following table types are supported during import of a NASTRAN input file. Note that some forms of the table commands are converted to an equivalent version supported by Patran.