Re: [Getfem-users] Problem importing gmsh mesh into getfem++

[Ron Daisy]

On Monday 02 October 2006 10:15, you wrote:
> Ron Daisy wrote:
> > Hello experts,
> >
> > I generated 3D mesh using gmsh, and imported it into my getfem++ program,
> > using the command,
> >
> > getfem::import_mesh("box.msh","gmsh",mesh);
> >
> >
> > I've go the following error when running the program:
> >
> > Error in getfem_mesh_im.cc, line 64 void
> > getfem::mesh_im::set_integration_method(bgeot::size_type,
> > getfem::pintegration_method): Incompatibility between integration method
> > IM_TETRAHEDRON(6) and mesh element GT_PK(2,1)
> >
> > What is the reason that getfem++ takes 2D mesh type from the imported
> > mesh - I generated it as 3D mesh in gmsh.
> >
> > Does any one have a working example of importing 3D gmsh mesh ?
>
> Hi Ron,
> If I recall correctly, the problem is that the gmsh files contains both
> the volumic mesh and the surface mesh of your object. Hence getfem has
> loaded all of them. If think there is an option in gmsh to save only the
> volumic mesh. Or you can also remove the 2D convexes from the getfem mesh:
>
> for (dal::bv_visitor_c cv(m.convex_index()); !cv.finished(); ++cv) {
>   if (m.trans_of_convex(cv)->dim() < 3) {
>      m.sup_convex(cv);
>   }
> }
>
> best regards,
> julien

Dear Julien,

Thanks for your help.

I finally found what the reason for the problem was. I didn't create a 
physical volume for the entire volume, thus gmsh didn't export all the 3D 
elements inside the volume (only the 2D elements on the surface for which I 
created physical surface). After changing this the getfem::import_mesh 
function showed 3D elements, as expected, and the integration compatibility 
problem disappeared.

Unfortunately, a new problem raised. I got floating point exception during the 
stiffness matrix assembling. Here is the program execution output:

$./prog param
MESH_TYPE=GT_PK(3,1)
FEM_TYPE=FEM_PK(3,1)
INTEGRATION=IM_TETRAHEDRON(6)
Number of dof : 8927
Assembling stiffness matrix
Floating exception

In this execution the mesh was imported from gmsh. It has to be noted that 
almost the same code (internal mesh generation and and an appropriate 
boundary condition assignment - for the same geometry) run without any 
problem and seems to produce meaningful results.

The only major difference I see is that in gmsh, the number of dof's is 8927 
while in the internally generated mesh I've got 68921 dofs. Is this might be 
the cause for rising the floating point exception?

I looked at the gmsh generated mesh and it seems to be quite coarse inside the 
volume (on the surface I managed to control its size, but couldn't do the 
same inside the volume).

Any way, I think that such kind of behavior (rising exception for logically 
correct input) should be corrected.

Many thanks,

Ron.