The finite element model can be imported from a Nastran Bulk Data File with method “readBdf”. 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 “setVerbosityLevel” 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 “readBdf” 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:
Only ASCII characters should appear in the path specifying the BDF file. The path to BDF file should contain no special character like accentuated letters (“é”, “è”, “î”, “ò”, “ù”...) or other “strange” characters corresponding to other languages (Polish, Greek, Russian, Chinese, Arabic...). This rule is also valid for the sub-files read via an include statement.
Actually, this is more a recommendation that a rule because on some platforms, special characters seem to be supported. Tests have demonstrated good performance on LINUX system, but Failure of BDF reading on Windows when path to file contains special characters.
Generally, only the lines between “BEGIN BULK” and “ENDDATA” are interpreted. (These words can also be lowercase.) In that case, all the lines before “BEGIN BULK” statement are ignored, and if no “BEGIN BULK” statement appears in the file, no line is interpreted.
If the “BulkOnly” Logical parameter is set to “true”, the lines in the file are assumed to correspond to lines if the Bulk Data Section of Nastran input. Then, lines “BEGIN BULK” and “ENDDATA” are ignored.
Generally, the “readBdf” method is called only once after the NastranDb object creation to initialize the finite element model. However, additional files might help to add FEM entities to the model. (For example, additional nodes used for the post-processing.)
When a FEM entity that is supposed to be defined only once in a model, is read several times, or already is defined in the DataBase before the call to “readBdf” method, only the last entity is kept.
One advises to limit the number of calls to the “readBdf” method because the method can be time consuming. Indeed, at the end of each call, 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 read all the BDF files by a single call to “readBdf”, the file being read including different sub-files.
The method accepts the reading of cards in short format fields, large format fields, and free format fields. But for free format field, the separator must be a comma (“,”), and the card must be written on one single line.
Recognized Nastran cards are:
The “GRID”, “POINT”, “SPOINT” and “EPOINT” cards.
The following element cards: “CBAR”, “CBEAM”, “CBEND”, “CBUSH”, “CBUSH1D”, “CDAMP1”, “CDAMP2”, “CDAMP3”, “CDAMP4”, “CDAMP5”, “CELAS1”, “CELAS2”, “CELAS3”, “CELAS4”, “CFAST”, “CGAP”, “CHEXA”, “CMASS1”, “CMASS2”, “CMASS3”, “CMASS4”, “CONM2”, “CONROD”, “CPENTA”, “CPYRAM”, “CQUAD”, “CQUAD4”, “CQUAD8”, “CQUADR”, “CROD”, “CSHEAR”, “CTETRA”, “CTRIA3”, “CTRIA6”, “CTRIAR”, “CTUBE”, “CVISC” and “PLOTEL”.
The following rigid body elements: “RBE1”, “RBE2”, “RBE3”,“RROD” and “RBAR”.
The multipoint constraints cards: “MPC” and “MPCADD”.
The following coordinate system cards: “CORD1C”, “CORD1R”, “CORD1S”, “CORD2C”, “CORD2R”, “CORD2S” and “CORD3G”.
Note however that the support for “CORD3G” coordinate system is limited. In particular, Transformation from/to this type of coordinate system are not possible. Actually, the support is limited to the reading of the “CORD3G” card from Nastran BDF file (no reading from OP2), and the correct identification of the CS type in such a way that an exception can be thrown if unsupported CS transformation is attempt.
The following property cards: “PBAR”, “PBARL”, “PBEAM”, “PBEAML”, “PBUSH”, “PCOMP”, “PCOMPG”, “PDAMP”, “PDAMP5”, “PDAMPT”, “PELAS”, “PELAST”, “PFAST”, “PGAP”, “PMASS”, “PROD”, “PSHEAR”, “PSHELL”, “PSOLID”, “PTUBE” and “PVISC” are totally supported. The cards“PBEND”, “PBUSH1D”, “PBUSHT”, “PLPLANE” and “PLSOLID” are only partially supported1 .
Four material cards are totally supported: “MAT1”, “MAT2”, “MAT8” and “MAT9”. Some other material cards are only partially supported: “CREEP”, “MATS1”, “MATT1”, “MATT2”, “MATT8”, “MAT3”, “MATT3”, “MAT4”, “MAT5”, “MATT4”, “MATT5”, “MATT9”, “MAT10”, “MAT11” and “MATHP”.
The “include”, “rfinclude” or “rfalter” statement lines are taken into account, but with some limitations:
The include statements must obviously comply with Nastran “include” syntax. Note however that the rule that one first attempt an include of a file starting from the Nastran working directory is not implemented. (How could one determine in which directory the Nastran command has been run?) instead, the first include directory that is tested is the current working directory of FeResPost.
when strings are quoted, use single quotes, and not double ones.
When variations of base file names are tested, the “UNIX” rules are followed. (See MSC.Nastran manual.)
The logical symbols in path names are interpreted. However no extensive tests have been done to check that the programming is correct.
Comments in file names may lead to problems.
Quoted strings that span on several lines may lead to problems.
The blank character is not completely supported so that its use should be avoided in the definition of include file names.
Only ASCII characters should appear in the path specifying the BDF file. The “Verbosity” parameter of “readBdf” method can be used to make sure that the generated include paths comply with this rule. Again, this is more a recommendation that an imposition as special characters seem to be well supported on some platforms.
The examples given in “RUBY/EX01” directory should help the reader to identify the kinds of include statements that are accepted by FeResPost. (See section IV.2.2.1.)
In case of problems, we suggest:
To be “defensive” and “reasonable” when using “include” statements in its bulk Data Files.
To check that the “include” statements comply with Nastran rules and the recommendations given above.
To set the “verbosity” argument to true to debug FeResPost (or the Nastran model).
To report any problem with a small example, so that we can debug FeResPost if necessary.
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 “readBdf” 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.8 for the use of that method. Note that the disabling of Nastran cards also influences the “readOp2” method when model entities are read.