[MOAB-dev] merge question

[Iulian Grindeanu]

Hello,


> >
> > The last phrase: "unless explicitly requested by application". Can
> > an application request to keep explicit adjacencies between
> > non-vertex entities?
> >
> 
> Yes, but only on an individual entity basis (i.e. it can't request
> that they always be created for entities created in
> the future).
> 

So how to create explicit adjacency between entities? 
Using virtual ErrorCode add_adjacencies(const EntityHandle from_handle, 
                                         const EntityHandle *to_handles,
                                         const int num_handles,
                                         bool both_ways);  ?

I see that this is actually calling AEntityFactory::add_adjacency(EntityHandle from_ent,
                                           EntityHandle to_ent,
                                           const bool both_ways)

> > Is there a relation between this "create_explicit_adjs" method used
> > in merging and this last phrase in the paragraph above?
> >
> 
> Not sure what you're asking here...

I didn't know that we can create explicit adjacencies between edges/faces, for example.

I thought that the merging logic needs to be careful about these explicit adjacencies (I was trying to make a connection between explicit adj in the Moab Guide paragraph and AEntityFactory::create_explicit_adjs method that is used only during merging). I think that there is no connection.

I still think that we should not create new a_entities during merging.

At the same time, when we merge only nodes, higher dimension entities are not merged, even if it would be possible. 
More specifically, in MergeMesh::merge_entities, (meshkit old design or new design), we merge nodes, but we do not merge edges or faces, even if possible. We do not identify "duplicated" faces or edges.

Also, the "update_sets" flag in MergeMesh::merge_entities method is not used at all, although it would be good to update existing sets that contain the merged (or worse, deleted) entities. Most of our set are "not tracked", and we do not know to which sets the merged entities belong.

Actually, I see this as a major headache for our merging operations. If we have interface sets (for parallel processing, coregen comes to mind), we need to properly update sets after merging (if we merge edges and faces). 


Maybe we should leave this as is, but then we should not delete the merged entities (nodes?). No, we want to delete the nodes, but we need to delete also the duplicated edges and faces


Another related problem: Let's say we have a neumann set, shared between 2 volumes. For one of the volumes it will be "positively" oriented, but for the other volume it will be reversed. The convention is to put the "reversed" entities in a subset with the sense tag, in the neumann set. 
I think we should have a different convention if the neumann set is shared, because the definition means we cannot share neumann sets between 2 volumes. Or am I understanding this wrong? (<moab>/doc/metadata_info.doc). 
"
Boundary Conditions (Dirichlet, Neumann)
(Data: Entity sets; Tag(s): DIRICHLET_SET/I, NEUMANN_SET/I)

Boundary conditions are often specified in terms of geometric model entities, similar to material types.  MOAB uses entity sets to store this information as well.  The DIRICHLET_SET and NEUMANN_SET tags are used to represent Dirichlet- and Neumann-type boundary condition sets, resp.  By convention, Neumann sets usually contain (indirectly) intermediate-dimension entities like edges in a 2D mesh or faces in a 3D mesh, while Dirichlet sets usually contain vertices.  In addition, Neumann sets are represented as sets of faces, rather than as sides of elements.  Faces can be ordered “forward” or “reverse” with respect to one of the bounding elements, depending on whether the right-hand normal points into or out of the element.  Forward-sense faces are added to the Neumann set.  Reverse-sense faces are put into a separate set; that set is tagged with the SENSE tag, with value = -1; and that reverse set is added to the Neumann set.
"

maybe the neumann sets can have a "pstatus" sort of flag (this problem appears even in serial processing)

Thanks,
Iulian