next up previous contents index
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 VIII.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.

  1. A String containing the name of the main Nastran Bulk Data File.
  2. 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.
  3. 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.)
  4. 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.
  5. 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.
  6. 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 :

  1. A string containing the name of the file to which the Nastran cards are printed.
  2. A string corresponding to the opening mode for the file. Valid values are ``w'' and ``w+'' (for append mode).
  3. 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''.
  4. 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''.
  5. 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''.
  6. 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):

  1. A String containing the name of the file to which the Nastran card is printed.
  2. A String corresponding to the opening mode for the output file. Valid values are ``w'' and ``w+'' (for append mode).
  3. 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''.
  4. 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''.
  5. 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.
  6. An Array containing the fields to be printed. Possible types for the elements of this Array are Real, Integer and String:
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: 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:

  1. 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''.
  2. 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''.
  3. 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.
  4. An Array containing the fields to be printed. Possible types for the elements of this Array are Real, Integer and String:
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:

  1. 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''.
  2. An integer corresponding to the ID of the FEM item of which one searches the definition.
The method returns the definition in an Array:

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:


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.

III.1.1.5.1 ``getCoordSysCopy''

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.

III.1.1.5.2 ``addCoordSys''

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.

III.1.1.5.3 ``NastranDb.makeAllCoordSysWrt0makeAllCoordSysWrt0''

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:


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

Presently, only some of the result data blocks of the file can be read: 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:


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

III.1.1.8.1 ``getdXdbLcNames'' method

``NastranDb.getdXdbLcNamesgetdXdbLcNames'' 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:

  1. A String specifying the access path to the xdb file.
  2. 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.2 ``getdXdbScNames'' method

``NastranDb.getdXdbScNamesgetdXdbScNames'' 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:

  1. A String specifying the access path to the xdb file.
  2. 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.3 ``getdXdbResNames'' method

``NastranDb.getdXdbResNamesgetdXdbResNames'' singleton method returns an Array of String containing the Result type names to which Results found in an xdb file correspond. The arguments are:

  1. A String specifying the access path to the xdb file.
  2. 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.4 ``getdXdbLcScNames'' method

``NastranDb.getdXdbLcScNamesgetdXdbLcScNames'' singleton method returns an Array of two elements containing:

  1. An Array of Strings containing the list of load cases to which Results found in the xdb file correspond.
  2. An Array of Strings containing the list of sub-cases to which Results found in the xdb file correspond.
The arguments are:
  1. A String specifying the access path to the xdb file.
  2. 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.5 ``getdXdbLcScResNames'' method

``NastranDb.getdXdbLcScResNamesgetdXdbLcScResNames'' singleton method returns an Array of three elements containing:

  1. An Array of Strings containing the list of load cases to which Results found in the xdb file correspond.
  2. An Array of Strings containing the list of sub-cases to which Results found in the xdb file correspond.
  3. An Array of Strings containing the list of Result types to which Results found in the xdb file correspond.
The arguments are:
  1. A String specifying the access path to the xdb file.
  2. 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 ``getdXdbLcInfos'' 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:

  1. A String specifying the access path to the xdb file.
  2. 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:


III.1.1.8.7 ``printXdbDictionnary'' method

``NastranDb.printXdbDictionnaryprintXdbDictionnary'' singleton method prints the dictionnary of an XDB file. The arguments are:

  1. A String specifying the access path to the XDB file.
  2. A String specifying the access path to an output file.
  3. 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.

III.1.1.8.8 ``readXdb'' method

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:

  1. A String argument that corresponds to the name of the file from which Results are read.
  2. 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.
  3. 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.
  4. 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.
  5. 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:

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: 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 IX.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:

III.1.1.8.10 XDB tables activation

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:

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:

  1. ``NastranDb.enableXdbTablesenableXdbTables'' is used to re-enable an XDB Result table for XDB Result reading.
  2. ``NastranDb.disableXdbTablesdisableXdbTables'' is used to disable an XDB Result table for XDB Result reading.
  3. ``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 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.

III.1.1.9.1 Managing XDB file attachments

The method ``NastranDb.attachXdbattachXdb'' is used to attach an XDB file to the Nastran DataBase. This method has up to two arguments:

  1. The first argument is a String containing the name of the XDB file. (Full path name must be provided.)
  2. 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:

III.1.1.9.2 Extracting information of XDB file attachments

The following methods extract information related to the Results stored in an XDB file attached to the DataBase:

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

III.1.1.9.3 Extracting Results From XDB file attachments

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:

  1. 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.)
  2. A String corresponding to the name of the load case for which Results are read.
  3. A String or an Array of Strings corresponding to the names of sub-cases for which Results are read.
  4. 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: 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: 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:

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:

  1. A String corresponding to the name of the load case for which Results are read.
  2. 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:
  3. A String or an Array of Strings corresponding to the names of sub-cases for which Results are read.
  4. 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: 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.

III.1.1.9.4 Getting optimization data from XDB

It is possible to obtain some of the Nastran optimization (SOL200) results from an XDB attachment. Four methods have been defined in NastranDb class:

  1. ``NastranDb.getAttachmentDesVarHistorygetAttachmentDesVarHistory'' returns the history of design variables and has three parameters: 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:

  2. ``NastranDb.getAttachmentConstrDefinitionsgetAttachmentConstrDefinitions'' returns the definition of constraints and has two arguments: 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:

  3. ``NastranDb.getAttachmentConstrHistorygetAttachmentConstrHistory'' returns the history of constrains and has three parameters: 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:

  4. ``NastranDb.getAttachmentObjectiveHistorygetAttachmentObjectiveHistory'' returns the history of constrains and has two parameters: 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:

  5. ``NastranDb.getAttachmentDesRespHistorygetAttachmentDesRespHistory'' returns the history of design responses and has three parameters: 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:

So far, the reading of optimization results is experimental and might be changed in future version.

III.1.1.9.5 Storage buffers for XDB result files random access

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:

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:

  1. 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.
  2. 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'': 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 (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.
  3. 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: Method ``NastranDb.getAttachmentElementExtIdgetAttachmentElementExtId'' allows to retrieve the Nastran element ID, if you know the type of the element, and its internal ID.
  4. 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:
    1. The Nastran ``external'' ID of the node that appears in the GRID card definition.
    2. The node type is always ``1'' in the tests we have done. (We presume it corresponds to usual Nastran GRIDs.)
    3. 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.

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:

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.


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:

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

III.1.2.1 General Results

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''
MPCFORCES
SPCFORCES
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:

  1. ``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.

  2. The Nastran ``CELASi'' and ``CDAMPi'' elements produce scalar forces or moments that are stored in ``Beam Scalar Forces'' Results.

  3. ``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''.

  4. The shear components of strain tensor output by Nastran are the angular deformations: $ \gamma_{ij}=2\epsilon_{ij}$ . 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.

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

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

  7. When Nastran shell curvature Results are imported, two modifications are brought to the components:

  8. ``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.

  9. 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:

       $\displaystyle \mbox{\boldmath$F$}$$\displaystyle =\left( \begin{array}{ccc} F_{xx} & F_{xy} & F_{xz} \\ F_{... ...} & V_{2} \\ V_{1} & 0 & 0 \\ V_{2} & 0 & 0 \end{array} \right)\ , $

       $\displaystyle \mbox{\boldmath$M$}$$\displaystyle =\left( \begin{array}{ccc} M_{xx} & M_{xy} & M_{xz} \\ M_{... ... & M_{1} \\ -M_{2} & 0 & 0 \\ M_{1} & 0 & 0 \end{array} \right)\ . $

  10. For CBAR elements, ``Beam Forces'' are always produced at the center of elements, and ``Beam Moments'' at the two end nodes.

  11. Bush result types for OEF and OES outputs depend on the kind of BUSH elements to which they correspond: The element forces and moments are stored in ``Beam Forces'' and ``Beam Moments'' tensorial Results.

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

  13. 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:

       $\displaystyle \mbox{\boldmath$F$}$$\displaystyle =\left( \begin{array}{ccc} F_{xx} & 0 & 0 \\ 0 & 0 & 0 \\ 0 & 0 & 0 \end{array} \right)\ . $

    No bending moments are produced by ``CBUSH1D'' elements.

  14. Nastran ``CGAP'' elements produces various results. These Results are read from OES or OEF data blocks. These Results are tensorial and:

  15. 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:

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

  2. When Nastran composite strains are read, values are produced for Mid thickness of each ply only.

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

  4. 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 up previous contents index
Next: III.2 Samcef Preferences Up: III. Solver Preferences Previous: III.0 Introduction   Contents   Index
FeResPost 2017-05-28