Next: III.2 Samcef Preferences
Up: III. Solver Preferences
Previous: III.0 Introduction
Contents
Index
Subsections
III.1 Nastran Preferences
Most methods peculiar to the post-processing of Nastran finite element Results
and models are defined in class ``NastranDb'' that inherits the ``DataBase''
class. This class is described in section III.1.1. A list
of the methods defined in ``NastranDb'' class is given in
Table III.1.1.
Table III.1.1:
The different methods that have been defined in ``NastranDb''
class. See also the methods defined in generic DataBase class
(Table I.1.1).
userManual.Nastran.DB.methods.tab
(FeResPost list of classes is given in
Table 1
page .) |
(See also methods in userManual.DataBase.methods.tabgeneric DataBase class.) |
Method Name |
Description |
Example |
|
|
|
Creation and initialization methods |
NastranDb.newnew |
III.1.1 |
IV.2.2.1 |
NastranDb.initializeinitialize |
III.1.1 |
|
Reading model or Results |
NastranDb.readBdfreadBdf |
III.1.1.1 |
IV.2.2.1 |
NastranDb.readOp2readOp2 |
III.1.1.2, III.1.1.7 |
IV.2.4.1 |
NastranDb.getXdbLcNamesgetXdbLcNames |
III.1.1.8 |
|
NastranDb.getXdbScNamesgetXdbScNames |
III.1.1.8 |
|
NastranDb.getXdbResNamesgetXdbResNames |
III.1.1.8 |
|
NastranDb.getXdbLcScNamesgetXdbLcScNames |
III.1.1.8 |
|
NastranDb.getXdbLcScResNamesgetXdbLcScResNames |
III.1.1.8 |
IV.2.4.6 |
NastranDb.getXdbLcInfosgetXdbLcInfos |
III.1.1.8 |
IV.2.4.6 |
NastranDb.printDictionnaryprintDictionnary |
III.1.1.8 |
|
NastranDb.readXdbreadXdb |
III.1.1.8 |
IV.2.4.6 |
NastranDb.attachXdbattachXdb |
III.1.1.9 |
|
NastranDb.detachXdbdetachXdb |
III.1.1.9 |
|
NastranDb.removeAllAttachmentsremoveAllAttachments |
III.1.1.9 |
|
NastranDb.getNbrAttachmentsgetNbrAttachments |
III.1.1.9 |
|
NastranDb.getAttachmentNamesgetAttachmentNames |
III.1.1.9 |
|
NastranDb.checkAttachmentExistscheckAttachmentExists |
III.1.1.9 |
|
NastranDb.getAttachmentLcInfosgetAttachmentLcInfos |
III.1.1.9 |
|
NastranDb.getAttachmentNbrLoadCasesgetAttachmentNbrLoadCases |
III.1.1.9 |
|
NastranDb.getAttachmentLcNamesgetAttachmentLcNames |
III.1.1.9 |
|
NastranDb.getAttachmentLcScNamesgetAttachmentLcScNames |
III.1.1.9 |
|
NastranDb.getAttachmentLcScResNamesgetAttachmentLcScResNames |
III.1.1.9 |
|
NastranDb.getAttachmentNbrSubCasesgetAttachmentNbrSubCases |
III.1.1.9 |
|
NastranDb.getAttachmentScNamesgetAttachmentScNames |
III.1.1.9 |
|
NastranDb.getAttachmentNbrResultsgetAttachmentNbrResults |
III.1.1.9 |
|
NastranDb.getAttachmentResIdsgetAttachmentResIds |
III.1.1.9 |
|
NastranDb.getAttachmentResNamesgetAttachmentResNames |
III.1.1.9 |
|
NastranDb.getAttachmentResultsgetAttachmentResults |
III.1.1.9 |
|
NastranDb.getAttachmentResultsCombiligetAttachmentResultsCombili |
III.1.1.9 |
|
NastranDb.getAttachmentDesVarHistorygetAttachmentDesVarHistory |
III.1.1.9 |
IV.2.7 |
NastranDb.getAttachmentConstrDefinitionsgetAttachmentConstrDefinitions |
III.1.1.9 |
IV.2.7 |
NastranDb.getAttachmentConstrHistorygetAttachmentConstrHistory |
III.1.1.9 |
IV.2.7 |
NastranDb.getAttachmentObjectiveHistorygetAttachmentObjectiveHistory |
III.1.1.9 |
IV.2.7 |
NastranDb.getAttachmentDesRespHistorygetAttachmentDesRespHistory |
III.1.1.9 |
|
NastranDb.setStorageBufferMaxCapacitysetStorageBufferMaxCapacity |
III.1.1.9 |
|
NastranDb.getStorageBufferMaxCapacitygetStorageBufferMaxCapacity |
III.1.1.9 |
|
NastranDb.getAttachmentElementExtIdgetAttachmentElementExtId |
III.1.1.9 |
|
NastranDb.getAttachmentNodeInfogetAttachmentNodeInfo |
III.1.1.9 |
|
NastranDb.getAttachmentDictKeysgetAttachmentDictKeys |
III.1.1.9 |
|
NastranDb.getAttachmentDictionnarygetAttachmentDictionnary |
III.1.1.9 |
|
NastranDb.each_xdbRaweach_xdbRaw |
III.1.1.9 |
|
NastranDb.enableBulkCardsenableBulkCards |
III.1.1.7 |
|
NastranDb.disableBulkCardsdisableBulkCards |
III.1.1.7 |
|
NastranDb.getBulkCardsEnableInfosgetBulkCardsEnableInfos |
III.1.1.7 |
|
NastranDb.enableOp2ResElemsenableOp2ResElems |
III.1.1.7 |
|
NastranDb.disableOp2ResElemsdisableOp2ResElems |
III.1.1.7 |
|
NastranDb.getOp2ResElemsEnableInfosgetOp2ResElemsEnableInfos |
III.1.1.7 |
|
NastranDb.enableXdbTablesenableXdbTables |
III.1.1.8 |
|
NastranDb.disableXdbTablesdisableXdbTables |
III.1.1.8 |
|
NastranDb.getXdbTablesEnableInfosgetXdbTablesEnableInfos |
III.1.1.8 |
|
Coordinate system methods |
NastranDb.getCoordSysCopygetCoordSysCopy |
III.1.1.5 |
|
NastranDb.addCoordSysaddCoordSys |
III.1.1.5 |
|
NastranDb.makeAllCoordSysWrt0makeAllCoordSysWrt0 |
III.1.1.5 |
|
Group manipulation methods |
NastranDb.getNodesAssociatedToElementsgetNodesAssociatedToElements |
III.1.1.6 |
IV.2.5.3 |
NastranDb.getNodesAssociatedToRbesgetNodesAssociatedToRbes |
III.1.1.6 |
|
NastranDb.getElementsAssociatedToNodesgetElementsAssociatedToNodes |
III.1.1.6 |
IV.2.5.3 |
NastranDb.getRbesAssociatedToNodesgetRbesAssociatedToNodes |
III.1.1.6 |
|
NastranDb.getElementsAssociatedToMaterialsgetElementsAssociatedToMaterials |
III.1.1.6 |
|
NastranDb.getElementsAssociatedToPliesgetElementsAssociatedToPlies |
III.1.1.6 |
|
NastranDb.getElementsAssociatedToPropertiesgetElementsAssociatedToProperties |
III.1.1.6 |
|
Iterators |
NastranDb.each_coordSysIdeach_coordSysId |
III.1.1.11 |
|
NastranDb.each_elemIdeach_elemId |
III.1.1.11 |
IV.2.3 |
NastranDb.each_nodeIdeach_nodeId |
III.1.1.11 |
|
NastranDb.each_rbeIdeach_rbeId |
III.1.1.11 |
|
NastranDb.each_materialIdeach_materialId |
III.1.1.11 |
|
NastranDb.each_propertyIdeach_propertyId |
III.1.1.11 |
|
NastranDb.each_nodeOfElementeach_nodeOfElement |
III.1.1.11 |
IV.2.3 |
NastranDb.each_cornerNodeOfElementeach_cornerNodeOfElement |
III.1.1.11 |
|
Write methods |
NastranDb.writeBdfLineswriteBdfLines |
III.1.1.3 |
|
NastranDb.writeNastranCardwriteNastranCard |
III.1.1.3 |
IV.2.5.1 |
NastranDb.writeNastranCardswriteNastranCards |
III.1.1.3 |
IV.2.5.1 |
NastranDb.writeNastranCardToVectStrwriteNastranCardToVectStr |
III.1.1.3 |
|
NastranDb.writeNastranCardsToVectStrwriteNastranCardsToVectStr |
III.1.1.3 |
IV.2.2 |
Other methods (access to FEM definition and FEM modification) |
NastranDb.getNbrRbesgetNbrRbes |
III.1.1.12 |
|
NastranDb.getMpcNodesgetMpcNodes |
III.1.1.12 |
|
NastranDb.getMpcDependentNodesgetMpcDependentNodes |
III.1.1.12 |
|
NastranDb.getMpcIndependentNodesgetMpcIndependentNodes |
III.1.1.12 |
|
NastranDb.getElementPropertyIdgetElementPropertyId |
III.1.1.12 |
|
NastranDb.getNodeRcIdgetNodeRcId |
III.1.1.12 |
|
NastranDb.getNodeAcIdgetNodeAcId |
III.1.1.12 |
|
NastranDb.getNodeCoordsgetNodeCoords |
III.1.1.12 |
|
NastranDb.fillCardfillCard |
III.1.1.4 |
IV.2.2, IV.2.3 and IX.1.3 |
NastranDb.insertCardinsertCard |
III.1.1.4 |
|
NastranDb.insertCardsinsertCards |
III.1.1.4 |
IV.2.2 |
|
|
|
III.1.1 ``NastranDb'' class
A ``NastranDb'' object can be created by a statement using ``NastranDb.newnew'' method like:
db=NastranDb.new()
Method ``NastranDb.initializeinitialize'' initializes or clears a NastranDb object.
This class is a specialization of the FeResPost ``DataBase'' class.
The model can be defined by reading a bulk Data File, or an op2 file. (See
the corresponding methods below.)
III.1.1.1 Reading a BDF
The finite element model can be imported from a Nastran Bulk Data File
with method ``NastranDb.readBdfreadBdf''. The method has up to six arguments.
- A String containing the name of the main Nastran Bulk Data File.
- An Array of Strings containing the list of directories in which
files specified by ``include'' statements shall be searched. Its default
value is a void Array.
- The name of an extension that may be added to the file names
specified in include statements. Its default value is a void String. (This
argument corresponds to the
jidtype
in Nastran.)
- A Hash with String keys and values corresponding to the list
of ``symbols'' that can be used in ``include'' statements in the Bulk
Data Files. The default value is a void Hash.
- A Logical that specifies verbosity for the reading of the Nastran
Bulk Data File. Its default value is ``false''. This parameter is redundant
with ``Post.setVerbosityLevelsetVerbosityLevel'' of ``Post'' Module: to set the parameter to ``true''
is equivalent to set ``Post'' verbosity level to 1.
- A Logical that specifies whether the file contains only Bulk Data Section
lines. Its default value is ``false''. If the parameter is ``true'', the
``BEGIN BULK'' and ``ENDDATA'' lines are ignored, and all the input lines,
except comments, are interpreted. (See also the remarks below.)
Only the first argument of the method is mandatory. More information about
the method is given in section III.1.1.1. Examples
of valid ``NastranDb.readBdfreadBdf'' statements follow:
db.readBdf("../../MODEL/MAINS/unit_xyz.bdf",
[],"",{},true)
db.readBdf("Z:/RD/ALCAS/TESTSAT/MODEL/MAINS/unit_xyz.bdf",
[],"",{},true)
db.readBdf("//CALC01/TESTSAT/MODEL/MAINS/unit_xyz.bdf",
[],"",{},true)
db.readBdf("//CALC01/TESTSAT/MODEL/MAINS/unit_xyz.bdf",
[],"",{},true,true)
The format of Nastran cards defined in a bulk data file is
described in [Sof04b]. The user must take the
following limitations of the interface into account:
At the end of reading, the method issues an information message with a
list of cards that have been skipped.
The correct working of method ``NastranDb.readBdfreadBdf'' has not been tested for many of
the Nastran cards listed above. So, bugs are possible when testing
FeResPost for new finite element models. In order to reduce the severity
of such bugs, Four singleton methods defined in NastranDb class to
disable or (re-)enable some of the Nastran cards. See
section III.1.1.7 for the use of that
method. Note that the disabling of Nastran cards also influences the
``NastranDb.readOp2readOp2'' method when model entities are read.
III.1.1.2 ``OP2'' methods for reading a FEM
It is also possible to read a finite element model from an ``op2'' file
with ``NastranDb.readOp2readOp2'' method. The model stored in the file is imported into the
NastranDb if the second string argument of the method is ``Model'' or
``Model/Results''. The first String argument is the name of the ``op2''
file.
The format of these files is described in [Rey04]. One
describes in section III.1.1.2 the reading of
finite element entities, and in
section III.1.1.7 the reading of Results.
The reading of 32bits as well as 64bits ``op2'' files is possible. However there
is no advantage in reading 64bits version. Actually, these files are larger and may take
a longer time to read.
Note that the reading of ``op2'' files also checks the endianness of the file
and, if needed, does corrections to the binary data. For example, it can
switch the reading from little endians to big endians or reversely. This
allows ``op2'' files produced on a machine to be read on another machine
with different ``endianness'' so that the portability of results is improved.
Also, the 32/64 bits version is checked when the file is opened.
Finite element entities are read into the NastranDb with method
``NastranDb.readOp2readOp2'' if one specifies ``Model'' or ``Model/Results'' for the
entities to read. The finite element entities recognized by the method
corresponding to the Nastran cards supported by the ``NastranDb.readBdfreadBdf'' method
(see section III.1.1.1). The corresponding Data
Blocks in the ``op2'' file are ``GEOM1'', ``GEOM2'', ``GEOM3'',
``GEOM4'', ``EPT'' and ``MPT'' (see [Rey04]).
Note that one generally prefers to read FE entities from a Bulk Data File
than from an ``op2'' file because the data stored are sometimes ambiguous
in the ``op2'' file (orientation of material properties on 2D
elements,...). However, the reading of op2 files is faster than the
reading of BDF files.
The correct working of method ``NastranDb.readOp2readOp2'' has not been tested for many
of the Nastran cards listed above. So, bugs are likely to occur when
testing FeResPost for new finite element models. In order to reduce the
gravity of such bugs, The NastranDb class allows to disable or
enable some of the Nastran cards. See
section III.1.1.7 for the use of the
corresponding singleton methods. Note that the disabling of Nastran
cards also influences the ``NastranDb.readBdfreadBdf'' method.
III.1.1.3 Writing Bulk lines
Method ``NastranDb.writeBdfLineswriteBdfLines'' is used to output the model or part of the
model into a text file with a format compatible with Nastran BDF cards.
The method has 5 or 6 arguments :
- A string containing the name of the file to which the Nastran cards
are printed.
- A string corresponding to the opening mode for the file. Valid
values are ``w'' and ``w+'' (for append mode).
- A first format String argument specifying whether the fields in
the cards output are left or right aligned. This argument may have
three values: ``left'', ``right'' or a void String. If the String is
void, the format defaults to ``left''.
- A second format String argument specifying whether the fields in
the cards output are narrow or wide. This argument may have three
values: ``short'', ``wide'' or a void String. If the String is void,
the format defaults to ``short''.
- A third String argument corresponding to the type of entities
that must be printed. The method scans the String argument and
searches sub-strings that specify whether an entity type is to be
printed or not. The sub-strings that are searched are ``All'',
``CoordSys'', ``Nodes'', ``Elements'', ``RBEs'', ``MPCs'',
``Properties'', ``Materials''.
- The last argument is optional and corresponds to the Group for
which cards are to be printed. It can be a String or a Group argument.
If its type is String, then the corresponding Group defined in the
DataBase is considered. Note that ``Properties'' and ``Materials'' are
not printed if the Group argument is provided.
The ``NastranDb.writeBdfLineswriteBdfLines'' method must be used for debugging purposes only.
The user must keep in mind that some entities are not totally supported
and their output may be problematic.
One first singleton method may be used to output formatted Nastran cards. This
method can be used, for example, to produce Nastran cards for inclusion in a
Bulk Data File. The method name is ``NastranDb.writeNastranCardwriteNastranCard'' and has five or six arguments
(the ``output card name'' argument is optional):
- A String containing the name of the file to which the Nastran card
is printed.
- A String corresponding to the opening mode for the output file. Valid
values are ``w'' and ``w+'' (for append mode).
- A first format String argument specifying whether the fields in
the card output are left or right aligned. This argument may have three
values: ``left'', ``right'' or a void String. If the String is void,
the format defaults to ``left''.
- A second format String argument specifying whether the fields in
the card output are narrow or wide. This argument may have three
values: ``short'', ``wide'' or a void String. If the String is void,
the format defaults to ``short''.
- A String corresponding to the name of the output card. This name
cannot have more than 8 characters and should correspond to a valid
Nastran BDF card name. THIS ARGUMENT IS OPTIONAL.
- An Array containing the fields to be printed. Possible types for
the elements of this Array are Real, Integer and String:
- If the previous ``output card name'' argument is omitted (5 arguments), then the first element
of the Array must be a String corresponding to the output card name (Nastran card field 1).
- if the previous ``output card name'' argument is given (method is called with 6 arguments), then the
Array values start with Nastran card field 2 content.
Another singleton method called ``NastranDb.writeNastranCardswriteNastranCards'' allows to output several
Nastran cards. This method has the same arguments as ``NastranDb.writeNastranCardwriteNastranCard'' except
that the last argument is an Array of Arrays, each element of the ``big''
Array corresponding to one Nastran card. The other arguments are the same, which means:
- If the number of arguments of the method is 5, the first element of each ``card'' Array
must be a String corresponding to the Nastran card name.
- If the number of arguments is 6, then the output card name argument is given and common to
all the Nastran output cards. Then, the card name must not be included as first element of the different
Nastran card Arrays.
Remark that when ``NastranDb.writeNastranCardswriteNastranCards'' is called with 5 arguments, it is possible, with a single call, to output
different types of Nastran cards (``FORCE'', ``MOMENT'',...). This is not possible when the method is called with 6
arguments.
The use of ``NastranDb.writeNastranCardwriteNastranCard'' and ``NastranDb.writeNastranCardswriteNastranCards'' methods is clarified in
section IV.2.5.1.
Method ``NastranDb.writeNastranCardToVectStrwriteNastranCardToVectStr'' is similar to ``NastranDb.writeNastranCardwriteNastranCard''. It produces
a formatted BDF output but returns it in an Array of Strings, each String corresponding
to one line in the output. The three or four arguments of the method are as follows:
- A first format String argument specifying whether the fields in
the card output are left or right aligned. This argument may have three
values: ``left'', ``right'' or a void String. If the String is void,
the format defaults to ``left''.
- A second format String argument specifying whether the fields in
the card output are narrow or wide. This argument may have three
values: ``short'', ``wide'' or a void String. If the String is void,
the format defaults to ``short''.
- A String corresponding to the name of the output card. This name
cannot have more than 8 characters and should correspond to a valid
Nastran BDF card name. HERE AGAIN, THE ARGUMENT IS OPTIONAL.
- An Array containing the fields to be printed. Possible types for
the elements of this Array are Real, Integer and String:
- If the previous ``output card name'' argument is omitted (3 arguments), then the first element
of the Array must be a String corresponding to the output card name (Nastran card field 1).
- if the previous ``output card name'' argument is given (method is called with 4 arguments), then the
Array values start with Nastran card field 2 content.
As has been done for the ``NastranDb.writeNastranCardwriteNastranCard'' method, a ``NastranDb.writeNastranCardsToVectStrwriteNastranCardsToVectStr'' singleton
method is defined in the ``NastranDb'' class. A single call to the method allows the output of several
Nastran cards in an Array of Strings. The last argument of the method is an Array or Arrays.
III.1.1.4 Accessing FEM information or modifying the FEM
The ``NastranDb.fillCardfillCard'' method allows to retrieve an Array corresponding to the
a Nastran BDF card. The method has two arguments:
- A String corresponding to the type of entity of which one requires
the definition. Possible values of the argument are ``CoordSys'', ``Element'',
``Node'', ``RBE'', ``Property'' and ``Material''.
- An integer corresponding to the ID of the FEM item of which one searches
the definition.
The method returns the definition in an Array:
- The first element of the Array (corresponding to index 0), is a String
containing the name of the Nastran card.
- Elements 1 to 8 correspond to the first line in the card definition (small field format).
- Elements 9 to 16 correspond to the second line in card definition (small field format).
- For each line, the fields 1 and 10 are neglected, except for the first line in which
field 1 contains the name of the Nastran card.
Method ``NastranDb.insertCardinsertCard'' performs the reverse operation: it allows to update the ``NastranDb''
database by insertion of FEM entity (coordinate system, node, element, RBE, material...). The
method ``NastranDb.insertCardinsertCard'' has one argument: an Array containing the different fields of the card.
The conventions for the components of the Array are exactly the same as for the Array returned
by method ``NastranDb.fillCardfillCard'' discussed above. (This means that first element of the Array, of index 0,
is a String corresponding to the name of the Nastran card.)
Method ``NastranDb.insertCardsinsertCards'' corresponds to ``NastranDb.insertCardinsertCard'' but allows to insert several cards with a single call
to the method. The argument of the method is then an Array of Arrays.
Remarks about the insertion methods:
- We strongly advise to use ``NastranDb.insertCardsinsertCards'' method instead of ``NastranDb.insertCardinsertCard''
to limit the number of calls to the method. Indeed, at the end of each insertion,
FeResPost updates a large number of data structures in the ``NastranDb'' class, in this
can take some time. (These data structures correspond, for example, to containers
associating elements and properties, elements and materials, nodes and elements...)
Therefore, a good way to work would be to collect all the cards to be inserted in the model
in abig Array, and perform the insertion operation only once.
- If one inserts a FEM entity that already exists in the database, the pre-existing
entity is replaced by the new one. If an entity is defined twice in the argument cards,
only the last card will remain inserted in the database at the end.
III.1.1.5 ``CoordSys'' methods
The ``CoordSys'' class allows the manipulation of coordinate systems for
post-processing purpose. This class is presented in
Chapter I.2. One presents below the methods of
NastranDb class devoted to the manipulation of coordinate systems.
The ``NastranDb.getCoordSysCopygetCoordSysCopy'' method returns a CoordSys object which is a copy
of a coordinate system stored in the DataBase. The method has one integer
argument which is the index of the coordinate system.
Note that the CoordSys returned by the method may be a ``generic''
CoordSys as presented in Chapter I.2, or
a Nastran coordinate system.
The ``NastranDb.addCoordSysaddCoordSys'' method is used to add a coordinate system to the
DataBase. The argument of the method is the CoordSys object. In the
DataBase, the object is referenced by its index.
If a coordinate system with the same index already exists in the
NastranDb, it is replaced by the new coordinate system. In that case, the
user is responsible for all the modifications involved in the finite
element model by the possible modification of the NastranDB coordinate
system. Therefore, it is considered as a good practice not to modify a
coordinate involved in the finite element model definition.
Note that the coordinate system index must be a strictly positive
integer. Also, the CoordSys inserted by the method may be a ``generic''
CoordSys as presented in Chapter I.2, or
a Nastran coordinate system.
This method updates the definition wrt 0 (most basic coordinate system) of
all the coordinate systems stored in a NastranDB. This operation is
necessary when a coordinate system of the NastranDB has been modified,
because the definitions of other coordinate systems wrt 0 may be affected.
III.1.1.6 Construction of Groups by associations
The list of ``NastranDb'' methods returning Groups defined by association follows:
- ``NastranDb.getElementsAssociatedToNodesgetElementsAssociatedToNodes'' returns a Group containing the
list of elements associated to the nodes of the Group argument.
- ``NastranDb.getElementsAssociatedToMaterialsgetElementsAssociatedToMaterials'' returns a Group containing the
list of elements associated to the material(s) given as argument(s). The
argument is an integer or an Array of integers corresponding to the
material IDs of the elements inserted in the list.
- ``NastranDb.getElementsAssociatedToPropertiesgetElementsAssociatedToProperties'' returns a Group containing the
list of elements associated to the property (properties) given as
argument(s). The argument is an integer or an Array of integers
corresponding to the property IDs of the elements inserted in the list.
- ``NastranDb.getElementsAssociatedToPliesgetElementsAssociatedToPlies'' returns a Group containing the list
of elements associated to the ply (plies) given as argument(s). The
argument is an integer or an Array of integers corresponding to the ply
IDs of the elements inserted in the list. The ply Ids are the global ply
identifiers referenced by PCOMPG Nastran data cards (Nastran model).
- ``NastranDb.getNodesAssociatedToElementsgetNodesAssociatedToElements'' returns a Group containing the list
of nodes associated to the elements of the Group argument.
- ``NastranDb.getNodesAssociatedToRbesgetNodesAssociatedToRbes'' returns a Group containing the list of
nodes associated to the MPCs of the Group argument.
- ``NastranDb.getRbesAssociatedToNodesgetRbesAssociatedToNodes'' returns a Group containing the list of
MPCs associated to the nodes of the Group argument.
III.1.1.7 ``OP2'' methods for reading Results
Several methods allow the reading of results from an ``op2'' file or to
tune the behavior of reading this file. These methods are described below.
The reading of 32bits as well as 64bits ``op2'' files is possible. However there
is no advantage in reading 64bits version. Actually, these files are larger and may take
a longer time to read.
Note that one strongly advises to attribute an integer ID, and a name to each sub-case
defined in Nastran BDF file. For example, in the following example, the sub-case integer
ID is 201, and its name is ``ORBIT_ONE_MS2_X'':
SUBCASE 201
SUBTITLE=ORBIT_ONE_MS2_X
SPC=702001
LOAD=601001
- ``NastranDb.readOp2readOp2'' method is used to read FEM entities
or Results into the DataBase from an ``op2'' file generated by Nastran.
This method is also discussed in
section III.1.1.2 for the reading of
finite element model. Here, one discusses more precisely the reading of
Results.
The method has 6 arguments:
- A String that corresponds to the file from which model or Results
are read.
- A String that corresponds to the entities that are being read.
Possible values of the second argument are "Model/Results", "Model"
and "Results". Generally, only the third possible argument is used.
- A ``LcNames'' argument that corresponds to the list of load cases
for which the Results are read. The argument may be:
- A Single String corresponding to the name of one load case.
- An Array of Strings corresponding to the list of load cases
for which Results are read.
If this argument is omitted, or if the Array argument contains no
elements, the Results of ALL load cases are read.
- A ``ScNames'' argument that corresponds to the list of subcases
for which the Results are read. The argument may be:
- A Single String corresponding to the name of one subcase.
- An Array of Strings corresponding to the list of subcases for
which Results are read.
If this argument is omitted, or if the Array argument contains no
elements, the Results of ALL subcases are read.
- A ``ResNames'' argument that corresponds to the list of
Results identifiers for which the Results are read.
The argument may be:
- A Single String corresponding to the Result ID.
- An Array of Strings corresponding to the list of Result IDs
for which Results are read.
If this argument is omitted, or if the Array argument contains no
elements, ALL Results are read.
- A ``PostParam'' integer argument corresponding to the parameter
``POST'' in Nastran Bulk Data File. Possible values of the parameter:
- ``-1'' (for Patran output),
- ``-2'' (for EDS I-DEAS output),
- ``-6'' (EDS Unigraphics output).
The default value of this argument is ``-1'' (op2 created for Patran).
Note that readOp2 will not work with the values ``-4' and ``-5''
which are valid POST parameters for Nastran.
The third, fourth, fifth and sixth arguments can be omitted. Note that
Ruby identifies the type of arguments by their order of appearance in the
list. So, if ``LcNames'' argument is omitted, but ``ScNames'' or
``ResNames'' argument is used, the ``LcNames'' must be a void Array
(``[]''). Examples of possible calls to ``NastranDb.readOp2readOp2'' method follow:
...
db.readOp2("../../EXEC/orbit_unit_xyz.op2","Results")
...
db.readOp2("../../EXEC/orbit_unit_xyz.op2","Results",\
"GRAV_X")
...
db.readOp2("../../EXEC/orbit_unit_xyz.op2","Results",\
["GRAV_X"])
...
db.readOp2("../../EXEC/orbit_unit_xyz.op2","Results",\
["GRAV_X", "GRAV_Y"])
...
db.readOp2("../../EXEC/orbit_unit_xyz.op2","Results",\
[],[],"Stress Tensor")
...
db.readOp2("../../EXEC/orbit_unit_xyz.op2","Results",\
[],[],["Stress Tensor", "Shell Forces", Shell Moments"])
...
db.readOp2("../../EXEC/orbit_unit_xyz.op2","Results",\
["GRAV_X", "GRAV_Y"],"Statics",\
["Stress Tensor", "Shell Forces", Shell Moments"])
...
db.readOp2("../../EXEC/orbit_unit_xyz.op2","Results",\
[],[],[],-2)
...
- Six singleton methods allow to disable or (re-)enable some
entities when importing model or result entities from Nastran op2 or bdf
files, or to check the status of the bdf cards or Results:
- ``NastranDb.enableBulkCardsenableBulkCards'' is used to re-enable some Nastran card
when reading model entities from a Nastran bdf or op2 file.
- ``NastranDb.disableBulkCardsdisableBulkCards'' is used to disable some Nastran
card when reading model entities from a Nastran bdf or op2 file.
- ``NastranDb.getBulkCardsEnableInfosgetBulkCardsEnableInfos'' returns a Hash with String keys and Boolean
values that associates the enabled/disabled status to the different BDF card names.
- ``NastranDb.enableOp2ResElemsenableOp2ResElems'' is used to re-enable ``result element
types'' when reading Results from an op2 file.
- ``NastranDb.disableOp2ResElemsdisableOp2ResElems'' is used to disable ``result
element types'' when reading Results from an op2 file.
- ``NastranDb.getOp2ResElemsEnableInfosgetOp2ResElemsEnableInfos'' returns a Hash with String keys and Boolean
values that associates the enabled/disabled status to the different BDF card names for
results reading from op2 files.
The four enable/disable methods take one String, or an Array of Strings
argument. The Strings correspond to the names of the entities that must be
disabled or enabled. The ``enable info'' methods have no argument.
Other methods devoted to enable or disable composite
layered Results are defined in the generic ``DataBase'' class. These
methods are presented in
section I.1.3.2.
These enable/disable methods can be set to filter the results importation in order to reduce
the computation time, or the memory usage. The methods can also be used to prevent FeResPost
in the hopefully rare case when a bug occurs in the program for the reading of a particular element,
or the reading of the corresponding Results from an op2 file.
Presently, only some of the result data blocks of the file can be read:
- The ``OUG'' block corresponds to displacements, velocities,
accelerations, temperatures...
- The ``OGPFB1'' block corresponds to Grid Point Forces.
- The ``OES'' blocks correspond to strains or stresses. The names of
blocks that can be read are: ``OSTR1'', ``OSTR1C'', ``OES1C'' and
``OES1X''.
- The ``OPG1'' block corresponds to applied loads at nodes.
- The ``OEF'' blocks correspond to results in composite parts of the
structure, or to forces in surfacic or 1D elements. The names of
blocks that can be read are: ``OEFIT'' and ``OEF1C''.
- The ``OQG'' blocks correspond to MPC or SPC forces.
The correspondence between the Nastran output requests and the DMAP data
blocks written in the ``op2'' file is given in
Tables III.1.3 to
III.1.10. Also one gives in the Tables
the type names of Results generated in the NastranDb by ``NastranDb.readOp2readOp2'' method.
The solution sequences for which Results can be read from an ``op2'' are:
- SOL 101: linear static or thermal analysis,
- SOL 103: linear eigen-values analysis,
- SOL 105: buckling analysis,
- SOL 106: non-linear static analysis,
- SOL 129: non-linear transient analysis,
- SOL 159: transient thermal analysis,
- SOL 400: non-linear static or transient analysis (corresponds to the SOL106 and SOL129 analyses).
III.1.1.8 ``XDB'' methods for extracting XDB information
Several methods allow the reading of Result entities or characteristics stored in
an xdb file. Real Results as well as Complex ones can be read from xdb
files. This last format of Results can for example be read from a Nastran
``xdb'' result file corresponding to a SOL107, SOL108 or SOL111.
The reading of 64bits XDB files, as well as 32bits XDB files is possible. Note however that
the results that are read are stored in 32bits integer/real values so that there is no advantage in
using 64bits XDB files with FeResPost. (It probably slows down the XDB access.)
The use of Nastran "DBCFACT=4" parameter is supported. This parameter generates
XDB files with BBBT index
(Binary Blocked Balanced Tree Method of entry key storage),
instead of Hash storage. The default Nastran seems to be "DBCFACT=0" and corresponds to an Hash
Key (HK) of key storage.
Remark: one strongly advises to attribute an integer ID, and a name to each sub-case
defined in Nastran BDF file. For example, in the following example, the sub-case integer
ID is 201, and its name is ``ORBIT_ONE_MS2_X'':
SUBCASE 201
SUBTITLE=ORBIT_ONE_MS2_X
SPC=702001
LOAD=601001
For all the methods listed in this section, the first argument is a String
containing the path to the XDB file. The methods do not require the XDB file to be
attached to the Nastran database. However the corresponding methods exist for XDB result files
that have been attached to a database. (The corresponding methods with XDB attachments
are described in section III.1.1.9.)
``NastranDb.getXdbLcNamesgetXdbLcNames'' singleton method returns an Array of String containing the list of load cases to
which Results found in an xdb file correspond. The arguments are:
- A String specifying the access path to the xdb file.
- A Boolean value specifying whether one forces the swap of endianness when
reading the XDB file.
The second argument is optional.
``NastranDb.getXdbScNamesgetXdbScNames'' singleton method returns an Array of String containing the list of sub-cases to
which Results found in an xdb file correspond. The arguments are:
- A String specifying the access path to the xdb file.
- A Boolean value specifying whether one forces the swap of endianness when
reading the XDB file.
The second argument is optional.
``NastranDb.getXdbResNamesgetXdbResNames'' singleton method returns an Array of String containing the Result type names to
which Results found in an xdb file correspond. The arguments are:
- A String specifying the access path to the xdb file.
- A Boolean value specifying whether one forces the swap of endianness when
reading the XDB file.
The second argument is optional.
``NastranDb.getXdbLcScNamesgetXdbLcScNames'' singleton method returns an Array of two elements containing:
- An Array of Strings containing the list of load cases to which Results found
in the xdb file correspond.
- An Array of Strings containing the list of sub-cases to which Results found
in the xdb file correspond.
The arguments are:
- A String specifying the access path to the xdb file.
- A Boolean value specifying whether one forces the swap of endianness when
reading the XDB file.
The second argument is optional.
``NastranDb.getXdbLcScResNamesgetXdbLcScResNames'' singleton method returns an Array of three elements containing:
- An Array of Strings containing the list of load cases to which Results found
in the xdb file correspond.
- An Array of Strings containing the list of sub-cases to which Results found
in the xdb file correspond.
- An Array of Strings containing the list of Result types to which Results found
in the xdb file correspond.
The arguments are:
- A String specifying the access path to the xdb file.
- A Boolean value specifying whether one forces the swap of endianness when
reading the XDB file.
The second argument is optional.
III.1.1.8.6 ``getXdbLcInfos'' method
``NastranDb.getXdbLcInfosgetXdbLcInfos'' singleton method returns information about the load cases and sub-cases
for which Results are stored in a xdb file. The arguments are:
- A String specifying the access path to the xdb file.
- A Boolean value specifying whether one forces the swap of endianness when
reading the XDB file.
The second argument is optional.
The method returns an
Array of Arrays. Each element of the Array contains the information for
one load case and sub-case identification:
- A String corresponding to the name of the load case.
- A String corresponding to the name of the sub-case. (As defined
for modal analyses, non-linear analyses...).
- A third String argument (unused so far).
- The first integer ID of the corresponding Results (usually,
the load case ID).
- The second integer ID of the corresponding Results (usually, a mode
ID, or a step ID...).
- The first real associated value (frequency, real eigen-value, real
part of a complex eigen value or continuation parameter...).
- The second real associated value (imaginary part of a complex
eigen-value).
III.1.1.8.7 ``printXdbDictionnary'' method
``NastranDb.printXdbDictionnaryprintXdbDictionnary'' singleton method prints the dictionnary of an XDB file. The arguments are:
- A String specifying the access path to the XDB file.
- A String specifying the access path to an output file.
- A Boolean value specifying whether one forces the swap of endianness when
reading the XDB file.
The second and third arguments are optional. If the second argument is omitted or a void String,
the dictionnary is printed on standard output.
This method has been added for debugging purpose: it helps to identify the XDB tables
that are read, and those which are not.
The ``NastranDb.readXdbreadXdb'' method is used to read Results into the DataBase from an
``xdb'' file generated by Nastran. (Only Results can be read from a Nastran
``xdb'' file.) The method has up to four arguments:
- A String argument that corresponds to the name of the file from
which Results are read.
- A String or an Array of Strings corresponding to the names of load
cases for which Results are imported into the DataBase. If the Array is
void or the parameter is omitted, all load cases in xdb result files are
considered when results are read.
- A String or an Array of Strings corresponding to the names of
subcases for which Results are imported into the DataBase. If the Array is
void or the parameter is omitted, all sub-cases in xdb result files are
considered when results are read.
- A String or an Array of Strings corresponding to the identifiers of
Results for which Results are imported into the DataBase. If the Array is
void or the parameter is omitted, all Results of xdb result files are
considered when results are read.
- A Boolean value specifying whether one forces the swap of endianness when
reading the XDB file.
All parameters, except the first one, can be omitted. Then the
method assumes that a void Array has been passed as argument.
Presently the support of ``xdb'' Results reading is more limited than the
corresponding support for ``op2'' reading. Results that can be read are:
- Nodal displacements (translations and rotations),
- Nodal temperatures,
- SPC forces and moments,
- MPC forces and moments,
- Grid Point Forces,
- Element forces and moments,
- Element stresses,
- Element strains,
- Element Strain and kinetic energies, and energy loss.
- Composite ply stresses and strains.
Composite failure indices do not seem to be output in the xdb
file. Only a few elements are supported. However, the most important ones
are read:
- 0D elements: CONM1 and CONM2 (for kinetic energy),
- 1D elements: CBAR, CBEAM, CGAP, CELAS1, CELAS2, CELAS3, CELAS4,
CROD, CBUSH and CFAST.
- 2D elements: CTRIA3, CQUAD4, CTRIA6, CQUAD8, CQUADR and CTRIAR.
- 3D elements: CHEXA, CPENTA and CTETRA.
The different characteristics of imported Results correspond to the
characteristics of corresponding Results read from ``op2'' files.
Note however, that Complex Results can also be read from xdb files. Generally,
the complex Results are the same as the real Results. More information can be found
in section X.C.2.
Four methods devoted to the enabling or disabling composite
layered Results are defined in the generic ``DataBase'' class. These
methods are presented in
section I.1.3.2.
III.1.1.8.9 A note on ``endianness''
MSC.Nastran is distributed with ``TRANS'' and ``RECEIVE'' tools that allow to exchange XDB files
on machines with different ENDIAN conventions. This is sometimes necessary, for example, when Patran and Nastran
are run on different machines. On the other hand, FeResPost allows the identification of endianness in XDB
files (in most cases). In some cases, the user must ``force'' the choice.
The different methods devoted to XDB files access allow to specify a force on
swap endianness. When the corresponding parameter is set to ``TRUE'', FeResPost
considers that the endianness of binary XDB file does not correspond to the
endianness of the machine on which FeResPost executes. Then, a swap of endianness
is performed when the binary file is read.
If the ``SwapEndianness'' parameter is set to false, no modification of endianness is
done when the file is read.
If the ``SwapEndianness'' parameter is not given, FeResPost checks the endiannes of the file
and, if needed, does corrections to the binary data that are read. The test is done as follows:
- FeResPost reads five of the first words in the XDB file. (Words 5, 8, 11, 12 and 15,
index 0 corresponding to the first word at beginning in the file.)
- Each of these words is supposed to correspond to a positive integer value smaller than 65536.
Hence, only the two less significant bytes of the words should be different than zero.
- The test is done on the five integers and for each one, one attempts to guess if the endianness
is ``big'' or ``little''. The result for word 15 determines which kind of endianness is adopted. This
word seems to correspond to ``DATA BASE OPEN MODE FLAG'' and has been selected because one assumes
that it always has a very small value.
- if the five words do not lead to the same conclusion, a warning message is issued. (This might
help the user to identify the source of the problem.)
Three singleton methods allow to activate or deactivate the reading of Results from XDB files.
More precisely, the XDB results are presented in different tables that correspond to:
- The type of Result (stresses, forces, displacements,...),
- The type of element (CBAR, CQUAD4...),
- The format (real, complex,...).
Each type of Table can be enabled or disabled separately. This can be useful to filter the importation of
Results. Also, if there is a FeResPost bug in the reading of a given Result table, the disabling
of this table allows to continue to work with the other results while the development team works
to fix the problem.
The three singleton methods devoted to XDB table activation are:
- ``NastranDb.enableXdbTablesenableXdbTables'' is used to re-enable an XDB Result table for XDB Result reading.
- ``NastranDb.disableXdbTablesdisableXdbTables'' is used to disable an XDB Result table for XDB Result reading.
- ``NastranDb.getXdbTablesEnableInfosgetXdbTablesEnableInfos'' returns a Hash with String keys and Boolean
values that associates the enabled/disabled status of the different XDB tables. (This method also
gives you the names of the different XDB tables that can be read from XDB files.)
The two enable/disable methods take one String, or an Array of Strings
argument. The Strings correspond to the names of the entities that must be
disabled or enabled. The ``enable info'' method has no argument.
III.1.1.9 Attaching ``XDB'' files to a Nastran DataBase
Since version 3.4.0, FeResPost allows a random access
to XDB result files. This method is more efficient than the methods that import XDB Results
into the DataBase, and extracting copies of these Results. A peculiar case in which the
random access methods will be more efficient is when only some small parts of the
XDB file are of interest to the programmer.
The principle of random access is the same as the attachment of XDB files to
a Patran DataBase:
- The XDB file is attached to the DataBase.
- Its content (lists of load cases, sub-cases and Results) is identified.
- The Results that are needed are then read from the file.
The different methods called to perform these operations are described in the following sub-sections.
These methods correspond more or less to the methods described in
section III.1.1.8.
The method ``NastranDb.attachXdbattachXdb'' is used to attach an XDB file to the Nastran DataBase. This
method has up to two arguments:
- The first argument is a String containing the name of the XDB file. (Full path name
must be provided.)
- The second argument is an optional Boolean parameter specifying whether the
endianness must be swapped when XDB file content is read. If the parameter is not
given, the endianness of the file is automatically detected. Note however that this check
might fail. (See also page
for more
information.)
Several other methods are used to manage the Xdb attachments to a DataBase:
- ``NastranDb.detachXdbdetachXdb'' is used to delete an XDB attachment. The method has one String
argument corresponding to the name of the XDB file.
- ``NastranDb.removeAllAttachmentsremoveAllAttachments'' removes all the XDB file attachments to a DataBase.
This method has no argument.
- ``NastranDb.getNbrAttachmentsgetNbrAttachments'' has no argument and returns the number of XDB files
attached to the DataBase.
- ``NastranDb.getAttachmentNamesgetAttachmentNames'' has no argument and returns an Array of Strings
containing the list of XDB files attached to the DataBase.
- ``NastranDb.checkAttachmentExistscheckAttachmentExists'' has one String argument containing the XDB file name, and
returns ``True'' if the XDB file is Attached to the DataBase, and ``False'' otherwise.
The following methods extract information related to the Results stored in an XDB file
attached to the DataBase:
- ``NastranDb.getAttachmentLcInfosgetAttachmentLcInfos'' returns information on load cases
and sub-cases of Results found in the attached XDB file. The information is returned in an
Array. (More information about the content of this Array is given in the description of
method ``NastranDb.getXdbLcInfosgetXdbLcInfos''
page
.)
- ``NastranDb.getAttachmentNbrLoadCasesgetAttachmentNbrLoadCases'' returns the number of load cases found
in an XDB file.
- ``NastranDb.getAttachmentLcNamesgetAttachmentLcNames'' returns an Array of Strings corresponding to the
load case names found in the XDB file.
- ``NastranDb.getAttachmentLcScNamesgetAttachmentLcScNames'' returns an Array containing two elements.
The first element is an Array of String containing the load case names found in the
XDB file. The second element is an Array of String containing the sub-case names found in
the XDB file.
- ``NastranDb.getAttachmentLcScResNamesgetAttachmentLcScResNames'' returns an Array of three elements. Each element
is an Array of Strings. The first element is the list of load case names. The second element is
the list of sub-case names. The last element is the list of Result names.
All these methods have a single String argument containing the name of the XDB file
that must have been previously attached to the DataBase. On the other hand, the following
methods have one or two arguments:
- ``NastranDb.getAttachmentNbrSubCasesgetAttachmentNbrSubCases'' returns the number of sub-cases found
in an XDB file.
- ``NastranDb.getAttachmentScNamesgetAttachmentScNames'' returns an Array of Strings corresponding to the
sub-case names found in the XDB file.
- ``NastranDb.getAttachmentNbrResultsgetAttachmentNbrResults'' returns the number of Result names identified in the
XDB attached file.
- ``NastranDb.getAttachmentResIdsgetAttachmentResIds'' returns an Array of Integers corresponding to the identifiers
of the Results found in the XDB file.
- ``NastranDb.getAttachmentResNamesgetAttachmentResNames'' returns an Array of Strings corresponding to the names
of the Results found in the XDB file.
The first argument is the name of the XDB file that must have been previously attached to the
DataBase. The second argument is optional and corresponds to the name of a load case
found in the attached XDB file. If the argument is not provided, all the load cases are investigated to
build the list of sub-cases or Result names or IDs. If the argument is provided, only the sub-cases or
Results of the corresponding load case are considered. If the provided load case does not exist in
XDB attachment an error message is issued.
The method ``NastranDb.getAttachmentResultsgetAttachmentResults'' is used to read Results from the XDB file.
The Results are directly returned by the method to the caller in a Hash object.
They are not inserted in the DataBase from which the method is called.
The method has minimum four arguments:
- A String corresponding to the name of XDB file attachment from which Results
are read. (This file must have been previously attached to the DataBase.)
- A String corresponding to the name of the load case for which Results
are read.
- A String or an Array of Strings corresponding to the names of sub-cases
for which Results are read.
- A String or an Array of Strings corresponding to the names of Results
for which Results are read.
The other arguments are optional and correspond to the specification of target
entities for which Results are read. Actually, the reading operation from an
XDB combines the reading and some of the extraction operations described in
section I.4.2. For example:
- The fifth argument can be a ResKeyList object. Then the Results are extracted on the keys
of the ResKeyList object.
- The fifth argument can be a Result object. Then the Results are extracted on the keys
of the Result object.
- Extractions can be performed on Groups. Then one specifies the target by a ``Method''
String argument and a ``GrpTarget'' Group argument. The possible values of the ``Method''
argument are listed in section I.4.2.1. (Description
of ``Result.extractResultOnEntitiesextractResultOnEntities'' method in the Result class.) When Results are extracted on Groups,
one can also specify a list of layers for which values are extracted. This argument is optional.
(See below.)
- One can also specify a list of layers by providing a parameter which is an Array of String
or Integer values. Note however that the filtering on layers is done only when Results for which
several layers can be read. For example, this parameter does not influence the reading
of MPC Forces, Shell Forces...
- One can also specify a list of sub-layers by providing a parameter which is an Array of String
or Integer values. Note that this last parameter influences only the reading of laminate stresses or strains.
The reading of solid or shell element stresses and strains is not affected by this parameter.
If only four parameters are provided in the call to ``NastranDb.getAttachmentResultsgetAttachmentResults'' method,
all the pairs of key-values found in the XDB file are inserted in the list of returned Results.
Only lists below the list of valid calls to ``NastranDb.getAttachmentResultsgetAttachmentResults'':
h=db.getAttachmentResults(xdbName,lcName,scNames,resNames,
method,grpTarget[,layers[,subLayers]])
h=db.getAttachmentResults(xdbName,lcName,scNames,resNames,
resTarget)
h=db.getAttachmentResults(xdbName,lcName,scNames,resNames,
rklTarget)
h=db.getAttachmentResults(xdbName,lcName,scNames,resNames
[,layers[,subLayers]])
When Results are extracted from an XDB attachment on a Group, the ``Method'' argument
may influence the efficiency of Results extraction. When possible, a real random access is performed,
otherwise, entire tables must be read to ensure that all eligible Result values are loaded.
For example:
- For element Results like element stresses or element forces the ``Elements'', ``ElemCenters'',
``ElemCorners'' and ``ElemNodes'' extraction methods allow the use of a random access algorithm. On
the other hand, the ``Nodes'' and ``NodesOnly'' methods are associated to an algorithm that sweeps
sequentially the entire corresponding Result tables of XDB file.
- For nodal Results, the efficient extraction methods are ``Nodes'', ``ElemNodes'' and ``NodesOnly''.
They allow the use of a random access algorithm for the extraction of values from each suitable
table.
It is the responsibility of the post-processing programmer to try to provide the arguments in order to select
the most efficient algorithm for Results extraction.
Note that ``Grid Point Forces'' are always sorted by nodes. This is true for the applied loads, the MPC/SPC
forces and moments, as well as for the internal forces and moments. (Even though these last contain
forces by elements and nodes.) This mean that for the selection of extraction algorithm, ``Grid Point Forces''
should always be considered as nodal Results.
As several Result types, and sub-case names can be given as argument to
``NastranDb.getAttachmentResultsgetAttachmentResults'' method, this method can return several Results. This is
why Results are returned in a Hash:
- The Hash keys are Array of three Strings corresponding to the name of
the load case, the name of the sub-case, and the Result type name respectively.
- The Hash values are the Results.
For example, the list of extracted Result sizes can be printed with the following statements:
h=db.getAttachmentResults(xdbFileName,lcName,scNames,resNames,"Nodes",grp)
h.each do |id,res|
lcName=id[0]
scName=id[1]
resName=id[2]
size=res.Size
STDOUT.printf("%s - %s - %s : %d\n",lcName,scName,resName,size)
#~ Util::printRes(STDOUT,"brol",res)
end
The method ``NastranDb.getAttachmentResultsCombiligetAttachmentResultsCombili'' is used to extract linear combinations of
elementary Results found in one or several XDB files. As for method ``NastranDb.getAttachmentResultsgetAttachmentResults''
the Results are directly returned by the method to the caller. They are not inserted
in the DataBase from which the method is called. This method is more or
less a combination of the methods ``NastranDb.getAttachmentResultsgetAttachmentResults'' and ``DataBase.buildLoadCasesCombilibuildLoadCasesCombili''
of the generic DataBase class.
Practically, the main difference between ``NastranDb.getAttachmentResultsgetAttachmentResults'' and
``NastranDb.getAttachmentResultsCombiligetAttachmentResultsCombili'' is that the first argument is no longer an Xdb file
name. This argument is removed. Instead, one provides a ``Combili'' argument that
describes the linear combination corresponding to extracted Results. This ``Combili'' argument
is the second argument. The first argument is the ``LcName'' argument corresponding
to the load case name attributed to the generated Results. This load case name is not supposed
to correspond to any load case name found in the attached XDB file(s).
The method has minimum four arguments:
- A String corresponding to the name of the load case for which Results
are read.
- A ``Combili'' Array containing the description of the linear combination of
elementary load case Results. The Array is an Array of Arrays. Each secondary Array
contains three elements:
- A Real value corresponding to the factor in the linear combination.
- A String corresponding to the name of the XDB file from which
elementary Results are read. This file must have been previously
attached to the Nastran DataBase.
- A String corresponding to the name of the load case for which
Results are extracted.
- A String or an Array of Strings corresponding to the names of sub-cases
for which Results are read.
- A String or an Array of Strings corresponding to the names of Results
for which Results are read.
The other arguments are optional and correspond to the specification of target
entities for which Results are read. Actually, the reading operation from an
XDB combines the reading and some of the extraction operations described in
section I.4.2. For example:
- The fifth argument can be a ResKeyList object. Then the Results are extracted on the keys
of the ResKeyList object.
- The fifth argument can be a Result object. Then the Results are extracted on the keys
of the Result object.
- Extractions can be performed on Groups. Then one specifies the target by a ``Method''
String argument and a ``GrpTarget'' Group argument. The possible values of the ``Method''
argument are listed in section I.4.2.1. (Description
of ``Result.extractResultOnEntitiesextractResultOnEntities'' method in the Result class.) When Results are extracted on Groups,
one can also specify a list of layers for which values are extracted. This argument is optional.
(See below.)
- One can also specify a list of layers by providing a parameter which is an Array of String
or Integer values.
If only four parameters are provided in the call to ``NastranDb.getAttachmentResultsCombiligetAttachmentResultsCombili'' method,
all the pairs of key-values found in the XDB file are inserted in the returned Results.
Only lists below the list of valid calls to ``NastranDb.getAttachmentResultsCombiligetAttachmentResultsCombili'':
h=db.getAttachmentResultsCombili(lcName,combili,scNames,resNames,
method,grpTarget[,layers[,subLayers]])
h=db.getAttachmentResultsCombili(lcName,combili,scNames,resNames,
resTarget)
h=db.getAttachmentResultsCombili(lcName,combili,scNames,resNames,
rklTarget)
h=db.getAttachmentResultsCombili(lcName,combili,scNames,resNames
[,layers[,subLayers]])
The Hash object returned by the method has a structure identical to the
one returned by ``NastranDb.getAttachmentResultsgetAttachmentResults'' and can be manipulated the same
way.
It is possible to obtain some of the Nastran optimization (SOL200) results from an XDB attachment.
Four methods have been defined in NastranDb class:
- ``NastranDb.getAttachmentDesVarHistorygetAttachmentDesVarHistory'' returns the history of design variables and has three parameters:
- ``xdbFileName'', a String corresponding to the name of the attached XDB file.
- ``iSteps'', an Array of integers corresponding to the list of steps for which one wishes to obtain results.
- ``iDesVarIds'', an array of integers corresponding to the list of design variable IDs for which one wishes to obtained the results.
Parameters 2 and 3 are optional and can be omitted or replaced by a ``nil'' argument or a void Array. If they are not defined, all the steps or
design variables are returned in the results.
The method returns a N*3 array. For each line, the three columns correspond to:
- The first element is an integer corresponding to the optimization step ID.
- The second element is an integer corresponding to identifier of the design variable.
- The third element is a float containing the design variable value.
- ``NastranDb.getAttachmentConstrDefinitionsgetAttachmentConstrDefinitions'' returns the definition of constraints and has two arguments:
- ``xdbFileName'', a String corresponding to the name of the attached XDB file.
- ``iConstrIds'', an array of integers corresponding to the list of constrain IDs.
Parameters 2 is optional and can be omitted or replaced by a ``nil'' argument.
The method returns a N*6 array. For each line, the three columns correspond to:
- The first element is an integer corresponding to an internal ID for the considered constrain equation.
- The second element is an integer, the Nastran Design Constrain ID.
- The third element is an integer corresponding to the internal response ID.
- The fourth element is an integer corresponding to RTYPE. (I dot not know what is is.)
- The fifth element is an integer corresponding to the LUFLAG. Its value is 1 or 2 (">" or ">").
- The sixth element is a float corresponding to the bound.
- ``NastranDb.getAttachmentConstrHistorygetAttachmentConstrHistory'' returns the history of constrains and has three parameters:
- ``xdbFileName'', a String corresponding to the name of the attached XDB file.
- ``iSteps'', an Array of integers corresponding to the list of steps for which one wishes to obtain results.
- ``iIRIds'', an array of integers corresponding to the list of internal response IDs for which one wishes to obtained the results.
Parameters 2 and 3 are optional and can be omitted or replaced by a ``nil'' argument. If they are not defined, all the steps or
design responses are returned in the results.
The method returns a N*3 array. For each line, the three columns correspond to:
- The first element is an integer corresponding to the optimization step ID.
- The second element is an integer corresponding to identifier of the design response.
- The third element is a float containing the design response value.
- ``NastranDb.getAttachmentObjectiveHistorygetAttachmentObjectiveHistory'' returns the history of constrains and has two parameters:
- ``xdbFileName'', a String corresponding to the name of the attached XDB file.
- ``iSteps'', an Array of integers corresponding to the list of steps for which one wishes to obtain results.
Parameter 2 is optional and can be omitted or replaced by a ``nil'' argument. If it is not defined, all the steps
are returned in the results.
The method returns a N*3 array. For each line, the three columns correspond to:
- The first element is an integer corresponding to the optimization step ID.
- The second element is a float corresponding to the value of objective.
- The third element is an integer containing the identifier of an internal response.
- The fourth element is a float containing the value of the maximum constraint equation (corresponding to the previous internal response).
- ``NastranDb.getAttachmentDesRespHistorygetAttachmentDesRespHistory'' returns the history of design responses and has three parameters:
- ``xdbFileName'', a String corresponding to the name of the attached XDB file.
- ``iSteps'', an Array of integers corresponding to the list of steps for which one wishes to obtain results.
- ``iDesRespIds'', an array of integers corresponding to the list of design responses IDs for which one wishes to obtained the results.
Parameters 2 and 3 are optional and can be omitted or replaced by a ``nil'' argument. If they are not defined, all the steps or
design variables are returned in the results.
The method returns a N*3 array. For each line, the three columns correspond to:
- The first element is an integer corresponding to the optimization step ID.
- The second element is an integer corresponding to identifier of the design response.
- The third element is a float containing the design response value.
So far, the reading of optimization results is experimental and might be changed in future version.
In order to reduce the number of accesses to disk, it may be
useful to store some of the blocks read from binary result files into memory.
FeResPost provides an algorithm that allows to store the blocks
most recently read for later usage. Two singleton methods of the
``NastranDb'' class allow the to tune the capacity of the buffer area:
- ``NastranDb.setStorageBufferMaxCapacitysetStorageBufferMaxCapacity'' sets the capacity of storage.
The method has one arguments: a real value containing the size in Megabytes
of the buffer.
- ``NastranDb.getStorageBufferMaxCapacitygetStorageBufferMaxCapacity'' returns the storage buffer current total capacity.
The returned value is a real that corresponds to the capacity in Megabytes of the
buffer. The method has no argument.
Note that all buffers are now common to all the methods that provide random access to XDB
result files. In particular, the method is used in management of the binary file access for XDB
attachment or reading. This means that if one Result file attached to one DataBase
is more used, the storage will contain a majority of buffers for this Result file and progressively
delete the other buffers.
The default capacity for storage buffer is 0Mb. Note that the two methods described above
can be called from any class derived from the generic ``DataBase'' class.
III.1.1.9.6 ``Raw'' access to XDB file content
So far, the XDB access methods that have been described allow the extraction
of Results only when the corresponding programming has been done in FeResPost
source code. Sometimes, this limitation can be frustrating. For that reason,
several methods allowing a ``low level'' or ``raw access'' to XDB content have
been added.
Before listing these methods, one gives some information about the XDB content:
- The XDB file is a binary file divided in pages. Each page has a fixed size specified by
a given number of words. (This number of words per page is given in the file by the first word of the file.)
A word may correspond to 4 or 8 bytes depending whether the XDB file is output in single or double precision.
- The XDB file contains different tables corresponding to finite element model, results,...
A ``dictionnary'' allows to identify and retrieve the different tables stored in an XDB file.
In FeResPost, each XDB table is identified with a `` String-Integer key'':
- The String corresponds to the type of the table.
(For example ``FBARR'' for the Real CBAR element forces.)
- As several tables of the same type can be defined in an XDB file, FeResPost also
uses an integer index that allows to retrieve the right one.
Each table contains fields that can be distributed into several pages. A field corresponds
for example to the forces and moments on one CBAR element, and for a given load case and sub-case.
The naming conventions for the table types are given in MSC.Access Manual [Nas05].
The dictionnary keys allow to retrieve information from the dictionnary that can be used to retrieve
the table content. This information is given in an Array of 22 integers that correspond for example to
- The index of the first page containing the table,
- The index of the last page of the table,
- The size of the fields in the table (15th element of the table,
or element of index 14 when the indices numbering starts with 0),
- The number of fields,
- The minimum and maximum key IDs,
- The number of pages of the table...
(For the reading operations, one generally needs the field size.) You may find more information on
the meaning of these 22 integers in MSC.Access Manual [Nas05].
The access to dictionnary is done
by calling ``NastranDb.getAttachmentDictKeysgetAttachmentDictKeys'' and ``NastranDb.getAttachmentDictionnarygetAttachmentDictionnary'' methods.
- When results associated to elements are read from an XDB file, the
values are associated to a key that corresponds to the element ID. However, this
integer does not correspond to the Nastran integer ID of the element. Instead, there is
in the XDB file, an ``EQEXINE'' table that contains the correspondence
between the XDB IDs and the Nastran element IDs:
- The first argument of the method is the Access element type which
does not correspond to the Nastran element type. A table of correspondence between
the XDB Access element types and Nastran element types is given in section
``Differences from MSC.Nastran'' (sub-section of ``BLOCK DATA DESCRIPTIONS'')
of the MSC.Access manual [Nas05]. Part of the Access element
IDs is given in the source code in method ``xdb::getAccessType''
(File ``NASTRAN/xdb/xdb_equiv.cpp'').
- The second argument of the method is the XDB element ID. For each type of element, Nastran
generates a sequential XDB numbering starting at 1. The ``EQEXINE''
table allows to retrieve the corresponding Nastran element ID.
Method ``NastranDb.getAttachmentElementExtIdgetAttachmentElementExtId'' allows to retrieve the Nastran element ID, if you know
the type of the element, and its internal ID.
- Similarly, the XDB file also contains an ``EQEXING'' table that allows
to retrieve node information. The Access internal node ID numbering starts at 1 and is also
sequential. Each node internal ID is associated to three ``external'' integers:
- The Nastran ``external'' ID of the node that appears in the GRID card definition.
- The node type is always ``1'' in the tests we have done. (We presume it corresponds
to usual Nastran GRIDs.)
- The Analysis Coordinate System of the GRID. This information is useful as it allows
to associate the vectorial results components to a coordinate system.
Method ``NastranDb.getAttachmentNodeInfogetAttachmentNodeInfo'' is used to retrieve this information when reading nodal results.
The `NastranDb'' class methods that give a ``raw'' access to XDB attachment content are:
III.1.1.10 GMSH outputs
The method ``DataBase.writeGmshMeshwriteGmshMesh'' defined in DataBase Class exports nodes,
elements and RBEs into the mesh file. RBEs are exported with a negative
integer ID. The three tags attributed to the elements are the property ID
(twice) and the laminate ID. This means that the three tags have
sometimes the same value.
III.1.1.11 Iterators
A first group of iterators iterate on finite element entities of the finite
element model stored in the DataBase.
- ``NastranDb.each_coordSysIdeach_coordSysId'' iterates on the integer identifiers of
coordinate systems.
- ``NastranDb.each_elemIdeach_elemId'' iterates on the integer identifiers of elements.
- ``NastranDb.each_nodeIdeach_nodeId'' iterates on the integer identifiers of nodes.
- ``NastranDb.each_rbeIdeach_rbeId'' iterates on the integer identifiers of
rigid body elements.
- ``NastranDb.each_propertyIdeach_propertyId'' iterates on the integer identifiers of
properties.
- ``NastranDb.each_materialIdeach_materialId'' iterates on the integer identifiers of
materials.
The elements produced by the iterator are single integers. Each of these iterators has
0, 1 or 2 arguments. The two optional arguments are the integer bounds considered for
the iteration: ``IdMin'' and ``IdMax''.
Two iterators loop on the nodes defining an element:
- ``NastranDb.each_nodeOfElementeach_nodeOfElement'',
- ``NastranDb.each_cornerNodeOfElementeach_cornerNodeOfElement''.
These two iterators have one integer argument corresponding to
the index of the element. The return the integer indices of nodes.
III.1.1.12 Other methods
Several other methods allow to obtain model information.
- ``NastranDb.getNbrRbesgetNbrRbes'' returns the number of rigid body elements in stored
finite element model. This method has no argument.
- ``NastranDb.getMpcNodesgetMpcNodes'' returns the number of dependent and independent nodes defining an MPC.
The argument of the method is the MPC integer ID.
- ``NastranDb.getMpcDependentNodesgetMpcDependentNodes'' returns the number of dependent nodes of an MPC.
The argument of the method is the MPC integer ID.
- ``NastranDb.getMpcIndependentNodesgetMpcIndependentNodes'' returns the number of independent nodes of an MPC.
The argument of the method is the MPC integer ID.
- ``NastranDb.getElementPropertyIdgetElementPropertyId'' has an integer argument corresponding to the element ID and
returns the corresponding property ID.
- ``NastranDb.getNodeRcIdgetNodeRcId'' has an integer argument corresponding to the node ID and
returns the corresponding reference coordinate system ID.
- ``NastranDb.getNodeAcIdgetNodeAcId'' has an integer argument corresponding to the node ID and
returns the corresponding analysis coordinate system ID.
- ``NastranDb.getNodeCoordsgetNodeCoords'' returns the coordinates of a node. This method has one
or two arguments:
- The first argument is an integer corresponding to the node ID.
- The second argument is an integer or a string that corresponds to the
coordinate system in which the coordinates are expressed. The argument is an
integer, or the ``AsIs'' string. Note that if the argument is missing, the
``AsIs'' coordinate system is considered.
III.1.2 Nastran Result characteristics
When a Result object is read from an ``op2'' or an ``xdb'' file, integer
and/or real identifiers are associated to the object. These identifiers
depend on the solution sequence to which the Results correspond:
- For SOL 101: IntId[0] corresponds to the sub-case identifier, and
IntId[1] is the load set number.
- For SOL 103: IntId[0] corresponds to the sub-case identifier, and
IntId[1] is the mode number. RealId[0] is the real eigenvalue. The
corresponding eigen-frequency is given by
. (Note however that this
eigen-frequency is left undefined for the Grid Point Forces.)
- For SOL 105: IntId[0] corresponds to the sub-case identifier, and
IntId[1] is the mode number. RealId[0] is the real eigenvalue,
corresponding to the critical load. (Note however that this critical load
is left undefined for the Grid Point Forces.)
- For SOL 106: IntId[0] corresponds to the sub-case identifier, and
IntId[1] corresponds to the step index in the sub-case. RealId[0] is the
value of the continuation parameter for which the Results have been saved
in the ``op2'' file.
The ``load case name'' identifier associated to read or accessed results correspond
to the ``SUBTITLE'' associated to the SUBCASE defined in Nastran data file. If this
SUBTITLE is not define, the SUBCASE ID is used to generate a default load case
identifier as follows:
lcName="Load Case "+ID
Finally, the results found in the op2 file are presented by blocks
corresponding to the different ``result element types''. Unfortunately, those
element types do not correspond exactly to the element bdf cards presented
in section III.1.1.1. The supported
result element types are: ``ROD'', ``BEAM'', ``TUBE'', ``SHEAR'',
``CONROD'', ``ELAS1'', ``ELAS2'', ``ELAS3'', ``ELAS4'', ``DAMP1'',
``DAMP2'', ``DAMP3'', ``DAMP4'', ``VISC'', ``MASS1'', ``MASS2'', ``MASS3'',
``MASS4'', ``CONM1'', ``CONM2'', ``PLOTEL'', ``QUAD4'', ``BAR'', ``GAP'',
``TETRA'', ``BUSH1D'', ``QUAD8'', ``HEXA'', ``PENTA'', ``BEND'', ``TRIAR'',
``TRIA3'', ``TRIA6'', ``QUADR'', ``TETRANL'', ``GAPNL'', ``TUBENL'',
``TRIA3NL'', ``RODNL'', ``QUAD4NL'', ``PENTANL'', ``CONRODNL'', ``HEXANL'',
``BEAMNL'', ``QUAD4LC'', ``QUAD8LC'', ``TRIA3LC'', ``TRIA6LC'', ``BUSH'', ``FAST'',
``QUAD144'', ``QUADRNL'', ``TRIARNL'', ``ELAS1NL'', ``ELAS3NL'', ``BUSHNL'',
``QUADRLC'' and ``TRIARLC''. (More information on the result element types
can be found in [Rey04].)
Here again, some of the element result types can be disabled or
enabled (section III.1.1.1). The
arguments given to the enabling or disabling methods correspond to a
String object, or an Array of Strings, the values of Strings corresponding to
some of the Result element types given just above.
The negative node values corresponding to Results on specific Nastran
elements are summarized in Table III.1.2.
(This Table is a complement to
Table I.4.2.) These keys can be used when
Results are read from ``OP2'' or ``XDB'' files. Note that the ``CbarGrdA'' and
``CbarGrdB'' are used only to associate values to CBAR end nodes when the definition
of CBAR element has not been found in the DataBase.
Table III.1.2:
Correspondence between special nodes for element Results and
their integer ids (peculiar to Nastran solver).
For Nastran CSHEAR element |
"F4to1" |
-201 |
"F2to1" |
-202 |
"F1to2" |
-203 |
"F3to2" |
-204 |
"F2to3" |
-205 |
"F4to3" |
-206 |
"F3to4" |
-207 |
"F1to4" |
-208 |
"kickOn1" |
-211 |
"kickOn2" |
-212 |
"kickOn3" |
-213 |
"kickOn4" |
-214 |
"shear12" |
-221 |
"shear23" |
-222 |
"shear34" |
-223 |
"shear41" |
-224 |
For Nastran CBEAM element |
"CbeamSt1" |
-101 |
"CbeamSt2" |
-102 |
"CbeamSt3" |
-103 |
"CbeamSt4" |
-104 |
"CbeamSt5" |
-105 |
"CbeamSt6" |
-106 |
"CbeamSt7" |
-107 |
"CbeamSt8" |
-108 |
"CbeamSt9" |
-109 |
For Nastran CBAR element |
"CbarGrdA" |
-151 |
"CbarGrdB" |
-152 |
The correspondence between the Nastran output requests and the DMAP data
blocks written in the ``op2'' file is given in
Tables III.1.3 to
III.1.12. Note that in all the
examples presented in Part IV, the results are
printed in the ``op2'' file with ``SORT1'' option. This means that no test
has been done with ``SORT2'' option.
Table III.1.3:
Correspondence between the Nastran output cards and the
``op2'' result data blocks. (Displacements read from OUG data blocks.)
Nastran |
``op2'' |
Generated |
Statement |
Data Block |
Result |
DISPL |
OUG |
``Displacements, Translational''
``Displacements, Rotational''
``Displacements, Scalar'' |
VELO |
OUG |
``Velocities, Translational''
``Velocities, Rotational''
``Velocities, Scalar'' |
ACCEL |
OUG |
``Accelerations, Translational''
``Accelerations, Rotational''
``Accelerations, Scalar'' |
Table III.1.4:
Correspondence between the Nastran output cards and the
``op2'' result data blocks. (Applied loads read from OPG data blocks.)
Nastran |
``op2'' |
Generated |
Statement |
Data Block |
Result |
OLOAD (3) |
OPG |
``Applied Loads, Forces''
``Applied Loads, Moments'' |
Table III.1.5:
Correspondence between the Nastran output cards and the
``op2'' result data blocks. (MPC and SPC forces read from OQG data
blocks.)
Nastran |
``op2'' |
Generated |
Statement |
Data Block |
Result |
MPCFORCES (3) |
OPG |
``MPC Forces, Forces''
``MPC Forces, Moments''
``MPC Forces, Scalar'' |
SPCFORCES (3) |
OPG |
``SPC Forces, Forces''
``SPC Forces, Moments''
``SPC Forces, Scalar'' |
|
OPG |
``Reaction Forces, Forces'' ( 1)
``Reaction Forces, Moments'' ( 1)
``Reaction Forces, Scalar'' ( 1) |
Table III.1.6:
Correspondence between the Nastran output cards and the
``op2'' result data blocks. (Grid point forces read from OGF data blocks.)
Nastran |
``op2'' |
Generated |
Statement |
Data Block |
Result |
GPFORCES (3) |
OGF |
``Grid Point Forces, Internal Forces''
``Grid Point Forces, Internal Moments''
``Grid Point Forces, MPC Forces'' ( 3)
``Grid Point Forces, MPC Moments'' ( 3)
``Grid Point Forces, SPC Forces'' ( 3)
``Grid Point Forces, SPC Moments'' ( 3)
``Grid Point Forces, Reaction Forces'' ( 1)
``Grid Point Forces, Reaction Moments'' ( 1)
``Grid Point Forces, Applied Forces'' ( 3)
``Grid Point Forces, Applied Moments'' ( 3)
``Grid Point Forces, Total Forces''
``Grid Point Forces, Total Moments'' |
Table III.1.7:
Correspondence between the Nastran output cards and the
``op2'' result data blocks. (Strains read from OES data blocks and
corresponding to ``STRAIN'' output requests..)
Nastran |
``op2'' |
Generated |
Statement |
Data Block |
Result |
STRAIN |
OES |
``Strain Tensor'' ( 4,
2))
``Beam Axial Strain for Axial Loads''
``Beam Axial Strain for Bending Loads''
``Beam Axial Strain for Total Loads'' ( 8)
``Beam Shear Strain for Torsion Loads''
``Beam Deformations'' ( 13)
``Beam Velocities'' ( 13)
``Gap Forces'' ( 14)
``Gap Deformations'' ( 14)
``Gap Slips'' ( 14)
``Spring Scalar Strain''
``Bush Forces Strain Tensor'' ( 11 and 12)
``Bush Moments Strain Tensor'' ( 11 and 12)
``Bush Plastic Strain'' ( 11 and 12)
``Curvature Tensor'' ( 4,
7)
``Shear Panel Strain, Max''
``Shear Panel Strain, Average''
|
Table III.1.8:
Correspondence between the Nastran output cards and the
``op2'' result data blocks. (Stresses read from OES data blocks and
corresponding to ``STRESS'' output requests.)
Nastran |
``op2'' |
Generated |
Statement |
Data Block |
Result |
STRESS |
OES |
``Stress Tensor'' ( 1 in section III.1.2.2)
``Beam Axial Stress for Axial Loads''
``Beam Axial Stress for Bending Loads''
``Beam Axial Stress for Total Loads'' ( 8)
``Beam Shear Stress for Torsion Loads''
``Beam Forces'' ( 11 and 12)
``Beam Moments'' ( 11 and 12)
``Beam Deformations'' ( 13)
``Beam Velocities'' ( 13)
``Gap Forces'' ( 14)
``Gap Deformations'' ( 14)
``Gap Slips'' ( 14)
``Spring Scalar Stress''
``Bush Forces Stress Tensor'' ( 11 and 12)
``Bush Moments Stress Tensor'' ( 11 and 12)
``Bush Stress, Axial'' ( 13)
``Bush Strain, Axial'' ( 13)
``Bush Plastic Strain'' ( 13)
``Shear Panel Stress, Max''
``Shear Panel Stress, Average''
|
Table III.1.9:
Correspondence between the Nastran output cards and the
``op2'' result data blocks. (Nonlinear stresses read from OES data blocks and
corresponding to ``NLSTRESS'' output requests.)
Nastran |
``op2'' |
Generated |
Statement |
Data Block |
Result |
NLSTRESS |
OES |
``Nonlinear Stress Tensor'' ( 5)
``Nonlinear Strain Tensor'' ( 5)
``Nonlinear Effective Plastic Strain'' ( 5)
``Nonlinear Effective Creep Strain'' ( 5)
``Nonlinear Spring Scalar Strain''
``Nonlinear Spring Scalar Stress''
``Nonlinear Beam Axial Strain for Axial Loads''
``Nonlinear Beam Axial Stress for Axial Loads''
``Nonlinear Beam Axial Strain for Total Loads''
``Nonlinear Beam Axial Stress for Total Loads''
``Nonlinear Beam Forces''
``Nonlinear Beam Moments''
|
Table III.1.10:
Correspondence between the Nastran output cards and the
``op2'' result data blocks. (Element forces
read from OEF data blocks or other ``FORCE'' output.)
Nastran |
``op2'' |
Generated |
Statement |
Data Block |
Result |
FORCE (2,
13) |
OEF |
``Shell Forces''
``Shell Moments'' ( 6)
``Beam Forces'' ( 9,
10)
``Beam Moments'' ( 9,
10)
``Beam Warping Torque''
``Beam Deformations''
``Beam Velocities''
``Gap Forces'' ( 14)
``Gap Deformations'' ( 14)
``Gap Slips'' ( 14)
``Spring Scalar Forces''
``Bush Plastic Strain''
|
Table III.1.11:
Correspondence between the Nastran output cards and the
``op2'' result data blocks. (Element forces read from OEE data blocks or
``ESE'', ``EKE'' and ``EDE'' output.)
Nastran |
``op2'' |
Generated |
Statement |
Data Block |
Result |
ESE |
OEE |
``Element Strain Energy''
``Element Strain Energy (Density)''
``Element Strain Energy (Percent of Total)''
|
EKE |
OEE |
``Element Kinetic Energy''
``Element Kinetic Energy (Density)''
``Element Kinetic Energy (Percent of Total)''
|
EDE |
OEE |
``Element Energy Loss''
``Element Energy Loss (Density)''
``Element Energy Loss (Percent of Total)''
|
Table III.1.12:
Nastran Results for thermal calculations.
Nastran |
``op2'' |
Generated |
Statement |
Data Block |
Result |
TEMPERATURE |
OUG |
``Temperature'' |
FLUX |
OEF |
``Temperature Gradient'' |
FLUX |
OEF |
``Conductive Heat Flux'' |
One can make a few remarks about the information given in
Tables III.1.3 to
III.1.12:
- ``Reaction Forces'' Results are obtained by merging the
contributions of MPC and SPC forces. This result has been added to
harmonize Nastran and Samcef importation of Results.
- The Nastran ``CELASi'' and ``CDAMPi'' elements produce scalar
forces or moments that are stored in ``Beam Scalar Forces'' Results.
- ``Applied Loads'' are available both with the ``OLOAD'' and
``GPFORCE'' Nastran statements. The first one provides forces and
moments on nodes. The second one produces the same Results at
element corners.
A similar remark can be done for ``MPC Forces'' and ``SPC Forces''.
- The shear components of strain tensor output by Nastran are the
angular deformations:
. When these results are
imported in a NastranDb, the corresponding components are divided by two
in such a way that a ``physical'' tensor is stored into the NastranDb.
The same remark applies for the non-diagonal components of the curvature
tensor (shell elements).
The ``STRAIN'' Nastran output statement with ``FIBER'' option outputs
the strain tensor at Z1 and Z2, but do not produce the curvature tensor.
- The Nonlinear stresses and strains are available for CHEXA, CPENTA, CTETRA,
CQUAD4 and CTRIA3 elements. Plastic deformation results are produced for non-linear results
only.
- When shell bending moments are imported from Nastran finite element
results, the sign of each component is changed. This has been done to
ensure that a positive component of the bending moment results in a
positive values of the corresponding strain tensor component on the upper
face of the shell.
- When Nastran shell curvature Results are imported, two modifications are
brought to the components:
- The signs of all the components are changed,
- The shear components of the tensor are divided by two.
- ``Axial Strain'' or ``Axial Stress'' for ``Total Loads'' and CBAR
elements are produced by combined axial loads to bending loads. This has
been done to harmonize CBAR Results with CBEAM Results. For CBEAM
Results, Stresses or Strains are recovered on the extremities only.
- Nastran ``beam'' type elements (CBAR, CBEAM, CBEND, CBUSH,...) do not
output vectorial or tensorial forces or moments. Instead, the different
components are expressed in different coordinate systems (axial, plane 1 and
plane 2). When importing these Results, a conversion into tensorial format
is done as follows:
- For CBAR elements, ``Beam Forces'' are always produced at the center
of elements, and ``Beam Moments'' at the two end nodes.
- Bush result types for OEF and OES outputs depend on the kind
of BUSH elements to which they correspond:
- Nastran ``CBUSH'' elements for linear analyses produce
vectorial or tensorial results in OEF and OES blocks.
- Nastran ``CBUSH'' elements for non-linear analyses produce
vectorial or tensorial results in OES blocks. No results are
produced in OEF blocks.
The element forces and moments are stored in ``Beam Forces''
and ``Beam Moments'' tensorial Results.
- The result types generated for CFAST elements are the same as
for CBUSH elements.
Note that FeResPost cannot determine the CFAST
element coordinate system when grids A and B are coincident. This
may cause problems when transformation of reference coordinate systems
are required. (This is the case when gmsh outputs of results are requested.)
Note also that Patran also seems to experience some
difficulties to calculate CFAST element axes.
- Nastran ``CBUSH1D'' elements produce scalar results in OEF and
OES blocks. By this we means that each type of result has only one
single component. However, the scalar force is stored in ``Beam Forces''
tensorial result. Most components of the tensor are zero:
No bending moments are produced by ``CBUSH1D'' elements.
- Nastran ``CGAP'' elements produces various results.
These Results are read from OES or OEF data blocks. These Results
are tensorial and:
- Gap forces results are stored in ``Gap Forces'' tensorial
Result. The value of the axial component is multiplied by ``-1.0'',
because it is a compression component.
- Gap deformations are stored in ``Gap Deformations'' tensorial
Result. Here again the value of the axial component is multiplied by ``-1.0''.
- ``Gap Slips'' is identical to ``Gap Deformations'' except
that the axial component is set to ``0.0''.
- Various Nastran elements refer scalar points instead of grids.
Nevertheless, Nastran considers the scalar point as a kind of element
rather than as a kind of grid. This is, in our opinion, an unfortunate
choice! FeResPost considers SPOINT objects as a peculiar type of GRID.
This has implications for the definition of keys when importing Results
with from Nastran op2 files. One hopes that this will not lead to
problems!
III.1.2.2 Composite Results
This section is more specifically devoted to the composite Results
(failure indices). Failure indices can be imported from ``op2'' files only.
The different Results that can be imported from Nastran are summarized
in Table III.1.13.
One can make a few remarks about the information given in those Tables:
- Since version 3.4.2, the stress tensor in plies is produced in ``Mid'' sub-layer
only. This means that the out-of-plane shear stress that Nastran calculates at bottom
skin of each ply is displaced at mid-thickness of the ply. This is an approximation.
(This out-of-plane shear stress can be used to calculate inter-laminar shear stress
in composite.)
Note also that, as out-of-plane shear stresses represent interlaminar
stresses, the components are expressed in laminate axes rather than in one of
the plies coordinate system. This means that, even though stress tensor
values are assumed to be given in ply axes, the out-of-plane shear stresses
are given in laminate axes. This is an additional reason to be careful when using
these components.
- When Nastran composite strains are read, values are produced for Mid
thickness of each ply only.
- The remarks done about the conversion of angular shear strain
components to tensorial shear strain components are of course also valid
for layered strain Results.
- Failure indices can be read from ``op2'' files only. Corresponding
Results do not seem to be stored in ``xdb'' files.
The indices given in Table III.1.13
refer to the remarks above.
Four methods devoted to the enabling or disabling of composite layered
Results are defined in the generic ``DataBase'' class. These methods are
presented in section I.1.3.2.
Table III.1.13:
Correspondence between the Nastran output cards and
composite stresses and strains
Nastran |
``op2'' |
Generated |
Statement |
Data Block |
Result |
STRAIN |
OES |
``Strain Tensor'' (2,
3) |
STRESS |
OES |
``Stress Tensor'' (1) |
The correspondence between the failure indices read from Nastran ``op2''
files and Results produced by CLA classes is as in Table III.1.14.
Table III.1.14:
Correspondence between the Nastran failure indices imported
from ``op2'' files and the failure criteria defined in CLA module.
Nastran Result |
CLA criterion ID |
section |
``Composite Failure Index, Tsai-Hill'' |
``TsaiHill_c'' |
II.1.10.11 |
``Composite Failure Index, Tsai-Wu'' |
``TsaiWu'' |
II.1.10.14 |
``Composite Failure Index, Hoffman'' |
``Hoffman'' |
II.1.10.16 |
``Composite Failure Index, Maximum Strain, CompMax'' |
``MaxStrain'' |
II.1.10.6 |
``Composite Failure Index, Interlaminar Shear Stress'' |
``Ilss'' |
II.1.10.25 |
III.1.3 Interaction with CLA classes
When a PCOMP or a PCOMPG property card is translated into a ClaLam object
by a call to ``NastranDb.getClaDbgetClaDb'' method, the value of LAM parameter is not
taken into account. This means that the values of this parameter set to
``MEM'', ``BEND'', ``SMEAR'' or ``SMCORE'' is without effect. There is
one exception to this rule: the value ``SYM'' is taken into account in
PCOMP property cards. (But not in PCOMPG cards for which this parameter
value is illegal.)
Next: III.2 Samcef Preferences
Up: III. Solver Preferences
Previous: III.0 Introduction
Contents
Index
FeResPost User Manual Version 4.4.2 (2018/01/01)