[Gmsh] visualization problem ?

[walter steffe]

Hello Christophe,

Many thanks for your help but now I have understood that the problem is
inside of my code (and not in the gmsh library).

In order to force slave master relationship among faces I am using 
GEntity::setMeshMaster(GEntity* gMaster,const std::vector<double>& tfo).

The corresponding edges associated with a couple of faces must be
related by a master slave relationship or at least must have a common
master. The function GEntity::setMeshMaster does not check for this
condition.

The fact of having a common master can be seen as an equivalence
relationship.

My code assumes that there is a set (or better a group) of invariant
transforms which defines the periodic structure. 
Before assigning the master slave conditions my code starts by
identifying the nearby edges which are related by the basic transforms.
Then it is necessary to form the equivalence classes which comprise
edges related by any composition of the basic transforms.
All edges in the same equivalence class is then associated with the same
master edge and with a different composite transform.

The procedure I am using to identify these equivalence classes and
related transforms needs to be fixed.

Walter


On Sat, 2016-02-13 at 19:11 +0100, walter steffe wrote:
> 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
> > 
> 
> 
> 
> _______________________________________________
> gmsh mailing list
> gmsh at onelab.info
> http://onelab.info/mailman/listinfo/gmsh