[Gmsh] Help with rewrite of mesh I/O layer
Christophe Geuzaine
cag32 at case.edu
Sun Sep 10 04:56:58 CEST 2006
Hi Olivier - Thanks for your message. The I/O code for reading and
writing BDF files is ready and I'm looking for beta-testers. If you have
some time to kill you could give this version a try (updated every night):
http://geuz.org/gmsh/src/gmsh2-nightly-source.tgz
WARNING: this code is still undergoing big changes almost daily. Also,
all the meshing algorithms are not reinterfaced yet. (For example this
version will NOT mesh in 3D, there is no extrusion meshing, etc.). But
the I/O layer and the graphics are ready for testing.
The current version supports reading and writing meshes in MSH (Gmsh),
UNV (I-deas), BDF (Nastran), STL, MESH (Medit) et Inventor/VRML1. If I
get the specs I would also like to add support for Ansys and Abacus.
Let me know if you discover any incompatibilities with your files.
Thanks!
Christophe
Olivier Bounhoure wrote:
> 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 ;)
>
> _______________________________________________
> 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