[Gmsh] Segmentation fault when writing 2D order 2 mesh
Christophe Geuzaine
cgeuzaine at ulg.ac.be
Sun Mar 13 10:32:55 CET 2011
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 <cgeuzaine at ulg.ac.be
> <mailto:cgeuzaine at ulg.ac.be>>
>
> 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
> gmsh at geuz.org <mailto:gmsh at geuz.org>
> 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