III.1.1.3 Superelements

Since version 5.0.5 of FeResPost, Nastran superelements are partially supported. More precisely, PART and external superelements are supported. (See [Hex22] for a definition of the different types of superelements.) The support is limited to the reading of models containing superelements from BDF or op2 files, and to the reading of corresponding Results from op2, xdb or hdf5 files. The purpose of FeResPost is not to generate models, superelements, or manage the assembly of a model divided in several partitions.

The following Nastran BDF cards or instructions related to super elements are supported:

• The “BEGIN SUPER ...” or “BEGIN BULK SUPER ...” statements that mark the limits between the different parts of the model.
• The “SEBULK" cards that allow the replication of an existing superelement.

Other cards related to the management of superelements are unsupported: “SELABEL”, “SELOC”, “SECONCT”, “SEEXCLD”, “SEMPLN’, “SETREE”’...

A finite element model can also be read from a Nastran op2 file, even though this is not recommended. The reading of op2 file identifies the different partitions and builds the corresponding superelement databases.

When a model containing several partitions is read, the corresponding NastranDb object contains sub-databases corresponding to the different superelements. Each database is a distinct NastranDb object. The main database is the “master” database. The sub-databases correspond to the different partitions. Several methods allow to obtain a superelement database from the master database. Also, it is possible to retrieve the master database from a superelement NastranDb object. Each database, including the master database, is identified by a positive integer SEID. For master database SEID=0.

To ease the management of NastranDb objects, a reference counter is added to the C++ nastran::database class. It ensures that the master database and the superelement databases are destroyed at the same time when all references to any of the database for a given model have been freed.

The following methods of the NastranDb class are related to the management of superelements:

• Integer attribute “SEID” returns the superelement integer ID of a given NastranDb object.
• Integer attribute “RefCounter” returns the number of references to a NastranDb object. More precisely, it gives the number of references to the different NastranDb objects of a given model, as a single counter monitors the number of references to master database and associated superelement databases. Normally, this attribute is used for debugging purpose only.
• Integer attribute “NbrSuperElements” returns the number of superelements stored in NastranDb. The master database is not considered as a superelement.
• Method “getMaster” returns the master database of a given superelement NastranDb object. (The NastranDb object from which the method is called must correspond to a superelement.)
• Method “getSuperElementIdFromPos” returns the superelement integer SEID at a give position in the list of superelements associated to the master database. The superelement databases are stored in order of increasing SEID in the list of superelements. if $N$ superelements are stored in the master database, the postion argument must be between 0 and $N-1$.
• Method “getSuperElementFromId” returns a NastranDb object corresponding to the superelement specified by its SEID. If no superelement with specified SEID is found in the master database, nil is returned.
• Method “getSuperElementFromPos” returns a NastranDb object corresponding to the superelement specified by its position in the lsit of superelements. If no superelement with specified SEID is found in the master database, nil is returned.
• Method “removeResultsAllSE” erases the Results stored in the master and superelement databases. Arguments of the method are the same as those of removeResults method in DataBase class. Method has two String arguments corresponding to the method of selection of Results and to an identifier respectively. The “Method” argument has three possible values: “CaseId”, “SubCaseId” or “ResId”. It specifies whether the Results to be deleted are identified by their load case name, their subcase name or their Result type name. The second String argument corresponds to the identifier of Results to be deleted.
• Method “removeAllResultsAllSE” removes all the Results stored in master and superelement databases.

The behaviour of ther methods is affected by the presence of superelements:

• “readBdf” identifies the partition of model and manages the master and superelement DataBases. The same is true for the “readOp2” method when it is used to read a model. (This is not a recommended practice, however.)
• Methods that read results into the DataBase identify whether Results are related to the master DataBase (residual structure) or to one of the superelement DataBases. Results are then stored into the master DataBase and into the superelement DataBases. FeResPost manages the correspondence between Results and and the DataBases. Methods of the NastranDb class concerned by this behaviour are “readOp2”, “readOp2FilteredResults”, “readXdb” and “readHdf”. Methods “removeResultsAllSE” and “removeAllResultsAllSE” described above have been defined to ease the cleaning of Results from the different DataBases in one single operation.
• The Result files attachement methods “attachXdb” and “attachHdf” are meant to be called from the master DataBase. They allow however to access Results related to the different superelements. (See below.) Similarly, the two methods “detachXdb” and “detachHdf” are called from the master DataBase.
• The methods that read results to a Hash object return the results corresponding to the DataBase on which the method is called (master DataBase or one of the superelement DataBase). Methods concerned by this are:
  • “readXdb2H”, “getAttachmentResults”, “importAttachmentResults”,
    “getAttachmentResultsCombili”, “getAttachmentElementExtId”, and
    “getAttachmentNodeInfo” for the XDB files.
  • “readHdf2H”, “getHdfAttachmentResults” and “readHdfAttachmentResults” for the HDF files.

  The other XDB or HDF attachment methods are not affected by the presence of superelements. Many of these methods can be called from the master DB or from one of the superelements. (For example: checkAttachmentExists, getAttachmentNames, getAttachmentWordsSize...)

• Groups are managed per database. This means that one manages groups separately with master DB and each superelement database. For example, for the reading of Groups from Patran session files, readGroupsFromPatranSession must be called separately for each database and with distinct session files.

Examples discussed in section IV.2.11 should clarify the management of models and Results with superelements, and the information provided here.