[Gmsh] Help with rewrite of mesh I/O layer
Olivier Bounhoure
olivier at club-internet.fr
Sun Sep 10 00:36:50 CEST 2006
Hello,
I would like to propose some help about Nastran syntax:
On Thu, Aug 31, 2006 at 05:31:32PM -0400, Christophe Geuzaine wrote:
> Laurent CHAMPANEY wrote:
> >
> >
> > Christophe Geuzaine a écrit :
> >> Hi all - We are currently rewriting Gmsh's mesh module, including the
> >> input/output layer, and I have a few questions for all of you who
> >> use the UNV ("IDEAS Universal Mesh") mesh file format:
> >>
> >> * What should we put in the "physical property", "material" and "color"
> >> fields? Right now we just put the "elementary" region everywhere, and 7
> >> (!) in the color field.
> >>
> > "Physical property" is a way to link an element to a physical property
> > (beam section, plate thickness, ...) and "material" to material
> > property (young's modulus, density, ...) than can be defined elsewhere
> > in the .unv file.
> > Those informations will be used for the matrix construction, but they
> > can also be used for selecting the parts of the mesh to be visualized. I
> > think than you can use the same reference the two fields than would be
> > related to the "physical" definition in gmsh.
>
> Sounds good to me. But if we do this, should we still also define the
> "Groups of nodes" groups for each physical?
>
>
> >
> > Color codes are just used for screen presentation. The color codes are
> > attached.
> >
> >> * Should we treat the physical groups like in the native MSH file
> >> format, i.e., if physical groups are defined, only save the elements
> >> that belong to a physical group? Right now we always save all the
> >> elements.
> >>
> > I think than you can save only the physical groups.
> >> * I don't have access to any program that can read UNV files. Does
> >> anyone on this list with access to such a program want to volunteer to
> >> test a alpha-quality version of the new import/export code?
> >>
> >>
> > I will check
> >
> >> Thanks,
> >>
> >> Christophe
> >>
> > Laurent
> >> PS: While we're at it, are there any mesh file formats that we should
> >> implement besides MSH, UNV, MESH (INRIA) and STL? Due to changes in the
> >> database, we've had to remove the P3D and the GREF formats.
> >>
> > Nastran Bulk Data file format is used a lot...
> >
>
> OK. I've implemented a first version of the I/O routines for the Nastran
> Bulk Data File format by reverse engineering some BDF files I found on
> the web.
>
> Do you know what all the possible element types are in that format (I've
> added support for CTRIA3, CTRIA6, CQUAD4, CTETRA, CHEXA and CPENTA)?
I know there are some other elements (I don't have the docs right now so
I cannot be more precise) like 10 nodes tetras, 20 nodes hexas,
axisymetric elements and rigid body elements. For the last ones, they
are not real elements but are very usefull so it would be great to map
them against something... RBE2 are the "traditional" rigid body elements
and RBE3 are "soft interface" elements.
There are also CBEAM and CBAR which are beam elements and CROD which
are... rod elements. CELAS are spring elements, CBUSH are bushing
elements.
>
> Also, do you know how the fields should be written to disk? I've seen
> several different number formats in the BDF files I came across on the
> web (%f, %e, fixed width, ...).
Nastran bulk data is case insensitive.
Comments are denoted by a dollar sign ($) in the first column.
There are three formats for Nastran cards: small fields, large fields
and free fields.
The first one is made of "cards" (lines) which are divided in 10 fields.
Each field is 8 caracters wide. In this fields, you can wright everywere
you want but with no embeded blanks (I used to write text left
justified and numbers right justified but it is not at all mandatory).
Real numbers (and of course complex components) can be written
integrally with all digits or using an exponential notation. In the
first case, the decimal point is mandatory. When using exponential
notation, you can use E or D as a symbol to "*10^".
The large field format adresses the problem of double precision: fields
from 2 to 9 are written on two lines. So you have the field one which
is 8 caracters wide, fields from 2 to 5 which are 16 caracters wide and
field 6 which is 8 caracters wide. You must declare that you use a
large format by appending a star (*) after the card name.
Here is an example:
$---1--][---2--][---3--][---4--][---5--][---6--][---7--][---8--][---9--][--10--]
GRID 123 4 3.25 4.56 2. 8
$---1--][-------2------][-------3------][-------4------][-------5------][---6--]
GRID* 123 4 3.25 4.56
$---1--][-------2------][-------3------][-------4------][-------5------][---6--]
2. 8
The two cards give the same node.
There is an issue with the continuation fields. Field 10 and field one
of the continuation lines can be given an ID. But Nastran can deal with
symbols (like stars) or blank fields and automatically put an ID on the
following lines.
The last format is the free field format and you can just write the
fields seperated by commas. The precision can be whatever you want.
I think (I did it) that writting a program that writes free field format
is really easy (something like "GRID,%d,%d,%g,%g,%g,%d,%d,%d\n" can be
the output format for your nodes). But writting a parser that can read
every Nastran syntax possible can be rather long...
Anyway, what you really need to do it is the "Quick Reference Guide",
the syntax reference for Nastran users.
>
>
>
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > gmsh mailing list
> > gmsh at geuz.org
> > http://www.geuz.org/mailman/listinfo/gmsh
>
>
> --
> Christophe Geuzaine
> Assistant Professor, Case Western Reserve University, Mathematics
> http://www.case.edu/artsci/math/geuzaine
>
> _______________________________________________
> gmsh mailing list
> gmsh at geuz.org
> http://www.geuz.org/mailman/listinfo/gmsh
>
I've just realized that this post is too long and not enough precise to
be really usefull... I post it anyway.
Olivier
PS: I agree with the other post that Abacus would be an intersting I/O
format for exchange with CalculiX (and its doc describes the format ;)