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.