[MOAB-dev] canonical face connectivity from 10-nodded tet mesh

iulian at mcs.anl.gov iulian at mcs.anl.gov
Thu Jun 3 14:43:55 CDT 2010


Hello,
I have a question about Julien's problem
It seems that the order in  CN::UpConnMap is not consistent with the order 
in CN::mConnectivityMap, for a tetrahedron, at least
So, in mConnectivityMap, we do care about ordering, nodes are from 0,1,2,3, and the faces (for a tetra) are
{ {0,1,3}, {1,2,3}, {0,3,2}, {0,2,1} } },

edges are {{0,1}, {1,2}, {2,0}, {0,3}, {1,3}, {2,3}} }

When we get the nodes for HO faces, we retrieve the edges from the upConnMap, in that order; from that order we get the midnodes
for the HO elements
The order there is different, for the vertices and edges
 { // source dim 2
      { // target dim 0
        {3, 3, 3, 3}, // 3 vertices for all faces
        {{0,1,3}, {1,2,3}, {0,2,3}, {0,1,2}} }, // end target dim 0
      { // target dim 1
        {3, 3, 3, 3}, // 3 edges for all faces
        {{0,4,3}, {1,5,4}, {2,3,5}, {0,2,1}} }, // end target dim 1
...

I think that we should keep the orders consistent, 
   { // source dim 2
      { // target dim 0
        {3, 3, 3, 3}, // 3 vertices for all faces
        {{0,1,3}, {1,2,3}, {0,3,2}, {0,2,1}} }, // end target dim 0   
      { // target dim 1
        {3, 3, 3, 3}, // 3 edges for all faces
        {{0,4,3}, {1,5,4}, {3,5,2}, {2,1,0}} }, // end target dim 1

Also for faces, although there maybe the order is not that important (for face to face adjacency). 

Do I get these wrong?

Thanks,
Iulian

----- Original Message -----
From: "Julien Vignollet" <vignollet at civil.gla.ac.uk>
To: "Jason Kraftcheck" <kraftche at cae.wisc.edu>
Cc: moab-dev at mcs.anl.gov
Sent: Thursday, June 3, 2010 8:31:06 AM GMT -06:00 US/Canada Central
Subject: Re: [MOAB-dev] canonical face connectivity from 10-nodded tet mesh


Hi, 


Sorry it took me a little bit to get back, I had to install the new version of moab before getting the new update. It is now ok to load a 10-nodded tet mesh from gmsh (the fix on nodes 8 and 9 works) but there still seems to be a problem with the face numbering. As soon as I use the command get_adjacencies for the faces (see code at the bottom), moab creates invalid entries for the faces in the vtk file. It appears that nodes 4 and 5 of the faces are sometimes swapped: for example in the attached mesh, there are four faces on the top xz surface of the cube, two of them have canonical ordering, the other two have the last two nodes swapped. 


Julien 












PS: a reminder of the commands I'm using: 



MBRange elems, faces; 

const MBEntityHandle* conn; 
int num_nodes; 
double coord_node_face[6*3]; 


result = gMB->load_mesh("test_mesh.msh"); EE(gMB); 
result = gMB->get_entities_by_dimension(0, 3, elems); 
gMB->get_adjacencies(elems,2,true,faces,MBInterface::UNION); 



for (MBRange::iterator fit = faces.begin(); fit != faces.end(); fit++) { 
gMB->get_connectivity(*fit,conn,num_nodes); 
gMB->get_coords(conn,num_nodes,coord_node_face); 
if (coord_node_face[1]==0.5) [... call a function using face canonical connectivities...] 
} 

result = gMB->write_file("Vtk_file.vtk") 













On 1 Jun 2010, at 15:13, Jason Kraftcheck wrote: 



Julien Vignollet wrote: 


Thank you for your answers. Yes you are right, I actually meant nodes 8 and 9 (starting from 0). 







OK. Thanks. I've checked in the fix for the Gmsh reader. 

- jason 




More information about the moab-dev mailing list