[Gmsh] visualization problem ?

[walter steffe]

Hello Christophe,

I have new data but still not the solution.

The problem is generated because some edges of the source and target
faces have a different number of mesh vertices.
In fact I have observed that the code enters in the following lines
(meshGFace.cpp: line 294)
    
if (get->mesh_vertices.size() != ges->mesh_vertices.size()) {
      Msg::Info("Error ....);
}

Because of this mismatch a vertex in the target surface is null and
the copyMesh function returns at line 344 and does not create all the
slave triangles.

I have added a few lines in my code to see when master and slave edges
have same number of vertices:

//following is an EmCAD function which calls GEdge:setMeshMaster() for
all relevant edge master slave couples:

setMasterEdges();

gm->mesh(1);

//Following check is PASSED:
for(GModel::eiter eit = gm->firstEdge(); eit != gm->lastEdge() ++eit){
        GEdge *ge=*eit;
        if (ge->meshMaster() != ge){
           GEdge *gem = dynamic_cast<GEdge*> (ge->meshMaster());
           assert(ge->mesh_vertices.size()==gem->mesh_vertices.size());
        }
      }

//following is an EmCAD function which calls GFace:setMeshMaster() for
all relevant face master slave couples:
 
setMasterFaces();
      
gm->mesh(2);

//Following check is FAILED:
for(GModel::eiter eit = gm->firstEdge(); eit != gm->lastEdge(); ++eit){
     GEdge *ge=*eit;
     if (ge->meshMaster() != ge){
           GEdge *gem = dynamic_cast<GEdge*> (ge->meshMaster());
           assert(ge->mesh_vertices.size()==gem->mesh_vertices.size());
     }
}

So it seems that the 2D meshing changes the 1D mesh for some edges and
so the conformances of master slave edges gets broken.

Used 2D algo is: ALGO_2D_MESHADAPT

Walter



On Thu, 2016-02-11 at 16:02 +0100, Christophe Geuzaine wrote:
> > On 11 Feb 2016, at 15:20, walter.steffe at alice.it wrote:
> > 
> > 
> > 
> >           I al already using the last stable version (gmsh 2.11.0)
> > 
> > I have investigated a little bit more and I have seen that the msh
file contains a few lines as the followings
> > 2 4 259
> > Affine -0.9999999999999994 1.110223024625157e-16 0 0
-1.110223024625157e-16 -0.9999999999999994 0 0 0 0 1 0 0 0 0 1
> > 64
> > 14624 23986
> > -1 23987
> > -1 23990
> > 
> > The problem is related with the -1 value associated with the tags of
some slave vertices.
> > I have used GDB with a breackpoint  inside of the function
writeMSHPeriodicNodes  (GModelIO_MSH.cpp line 574)
> > I have also used a break point condition  (v1->getIndex() < 0) in
order to spot the problematic data.
> > So I have discovered that the slave vertex is good (for what
concerns the geometrical position) but has an index= -1.
> > 
> > The problem now is that I do not know where the wrong index was
generated.
> > The slave vertex was created inside of the copyMesh(...) function:
> >   MVertex *vt =new MFaceVertex ...
> > But this function seems not to be the responsible for the index
value of -1 (the MFaceVertex constructor sets that value to 0).
> > 
> 
> The indexing is done in GModel::indexMeshVertices(). It looks like if
the vertices keep the -1 index, it's because they do not belong to
elements (triangles) that need to get saved !?
> 
> Let us know if you find the issue...
> 
> 
> > And why most of the slave indices were properly renumbered with the
exeption of those associated with face 4 (having master face=259) and a
few others ?
> >   
> > 
> > >I don't think so: the actual mesh is indeed incomplete. The problem
is most probably in the generation of the slave mesh. Quite a bit of
work has been going on on periodic meshes in recent releases: I would
try with the latest stable release to see if the problem >persists.
> > 
> > 
> > 
> > _______________________________________________
> > gmsh mailing list
> > gmsh at onelab.info
> > http://onelab.info/mailman/listinfo/gmsh
>