On 11/03/11 13:08, Karin&NiKo wrote:
Yes they are.
BTW, using incomplete second order elements is OK.
Hmm... In the version of MED we have here (MED 2.3.4) this is what's
defined in med.h:
typedef enum {MED_POINT1=1, MED_SEG2=102, MED_SEG3=103, MED_TRIA3=203,
MED_QUAD4=204, MED_TRIA6=206,MED_QUAD8=208,MED_TETRA4=304,
MED_PYRA5=305, MED_PENTA6=306, MED_HEXA8=308, MED_TETRA10=310,
MED_PYRA13=313, MED_PENTA15=315, MED_HEXA20=320,
MED_POLYGONE=400, MED_POLYEDRE=500, MED_NONE=0}
med_geometrie_element;
Should we switch to a newer version?
Nicolas
2011/3/11 Christophe Geuzaine <[email protected]
<mailto:[email protected]>>
On 11/03/11 09:47, Karin&NiKo wrote:
Dear Gmsh-ers,
I would like to report a bug that appears with gmsh 2.5.0 and
also in
the nightly build.
When trying to write the mesh generated by the attached script, a
segmentation fault occurs :
/opt/gmsh-2.5.1-svn-Linux/bin/gmsh -2 -format med -o carre-Q2.mmed
carre.geo
Please notice that :
- no problem occurs when using a first order mesh
- the unv format for the 2nd order mesh can be written but, when
read
back in gmsh, the mesh is wrong
Hi Nico - Indeed, it looks like 9-node quads I/O is not implemented
for MED (nor UNV). I don't remember why I did not implement this...
Are 9-node quads supported by MED?
Nicolas
_______________________________________________
gmsh mailing list
[email protected] <mailto:[email protected]>
http://www.geuz.org/mailman/listinfo/gmsh
--
Prof. Christophe Geuzaine
University of Liege, Electrical Engineering and Computer Science
http://www.montefiore.ulg.ac.be/~geuzaine
<http://www.montefiore.ulg.ac.be/%7Egeuzaine>
--
Prof. Christophe Geuzaine
University of Liege, Electrical Engineering and Computer Science
http://www.montefiore.ulg.ac.be/~geuzaine
_______________________________________________
gmsh mailing list
[email protected]
http://www.geuz.org/mailman/listinfo/gmsh
