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

[iulian at mcs.anl.gov]

Hello,
With the change suggested, the bug seems to be fixed. 
Should I commit it or not? 
Also, it seems that in VisIt, a model that contains just one tetra, and all its faces, oriented outward the tetra, cannot be shown.
Does anybody know how to display it?
If I delete a face at a time (from the vtk file), they start to show up.
Thanks,
Iulian
----- Original Message -----
From: "Jason Kraftcheck" <kraftche at cae.wisc.edu>
To: iulian at mcs.anl.gov
Cc: moab-dev at mcs.anl.gov
Sent: Thursday, June 3, 2010 3:08:38 PM GMT -06:00 US/Canada Central
Subject: Re: [MOAB-dev] canonical face connectivity from 10-nodded tet mesh

It seems rather strange that CN::mUpConnMap duplicates almost everything
from CN::mConnectivityMap (everything except for the entity type for faces
of a region element.)  Might it not be a better solution to just use
mUpConnMap for everything?

But if we do choose to keep the information in both arrays and wish to
require that it be consistent, then code should be added to
test/mbcn_test.cc to ensure that the values are consistent for all element
types.

- jason



iulian at mcs.anl.gov wrote:
> 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 
> 
> 


-- 
"A foolish consistency is the hobgoblin of little minds" - Ralph Waldo Emerson

-------------- next part --------------
A non-text attachment was scrubbed...
Name: out.vtk
Type: application/octet-stream
Size: 1613 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/moab-dev/attachments/20100603/3b0622bf/attachment.obj>