III.1.1.1 Reading a BDF
The finite element model can be imported from a Nastran Bulk Data File with method “readBdf”. 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 “setVerbosityLevel” 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 “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 supported .
- 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.