[Dune] Local node numbering in Dune

Ganesh Diwan gcdiwan83 at gmail.com
Wed Apr 15 01:12:22 CEST 2015


I am confused because of what I see as the output of gridleaflist and what
the Intersectioniterator loop gives me. Please allow me to modify the
meshfile above so that I have more than one element. My mesh is now, say:

$MeshFormat
2.0 0 8
$EndMeshFormat
$Nodes
9
1 0 0 0
2 0.5 0 0
5 1 0 0
6 1 0.5 0
8 1 1 0
7 0.5 1 0
9 0 1 0
3 0 0.5 0
4 0.5 0.5 0
$EndNodes
$Elements
4
1 3 0 1 2 4 3
2 3 0 2 5 6 4
3 3 0 4 6 8 7
4 3 0 3 4 7 9
$EndElements


The local node numbering provided at
http://www.dune-project.org/doc/doxygen/dune-geometry-html/group___geometry_reference_elements.html
for a reference element matches with what I see as the outcome of
Dune::gridleaflist(*grid, "Grid_leaf_info ") and this is given below-

Grid_leaf_info level=0 (cube, 2)[2] index=0 gid=0 leaf=1 partition=interior
center=(0.25 0.25) first=(0 0)
Grid_leaf_info codim 2 subindex 0:0 1:1 2:2 3:3
Grid_leaf_info codim 1 subindex 0:0 1:1 2:2 3:3
Grid_leaf_info level=0 (cube, 2)[2] index=1 gid=1 leaf=1 partition=interior
center=(0.75 0.25) first=(0.5 0)
Grid_leaf_info codim 2 subindex 0:1 1:4 2:3 3:5
Grid_leaf_info codim 1 subindex 0:1 1:4 2:5 3:6
Grid_leaf_info level=0 (cube, 2)[2] index=2 gid=2 leaf=1 partition=interior
center=(0.75 0.75) first=(0.5 0.5)
Grid_leaf_info codim 2 subindex 0:3 1:5 2:6 3:7
Grid_leaf_info codim 1 subindex 0:7 1:8 2:6 3:9
Grid_leaf_info level=0 (cube, 2)[2] index=3 gid=3 leaf=1 partition=interior
center=(0.25 0.75) first=(0 0.5)
Grid_leaf_info codim 2 subindex 0:2 1:3 2:8 3:6
Grid_leaf_info codim 1 subindex 0:10 1:7 2:3 3:11

This is perfectly fine.
However when doing the mesh traversal using the IntersectionIterator I see
that the orientation of the faces is not the same as what I get from
gridleaflist.

Consider only the first element for which the IntersectionIteror gives me:
node 1 for face 0 is 0.5 0
node 2 for face 0 is 0.5 0.5

visiting face 1(simplex, 1)
node 1 for face 1 is 0 0.5
node 2 for face 1 is 0.5 0.5

visiting face 2(simplex, 1)
node 1 for face 2 is 0 0
node 2 for face 2 is 0 0.5

visiting face 3(simplex, 1)
node 1 for face 3 is 0 0
node 2m for face 3 is 0.5 0

>From gridleaflist and above output corresponding to the first element I
understand the face orientation is:


gridleaflist face orientation
 +-----------+
 |       3        |
 |                 |
 |  0          1 |
 |                 |
 |       2        |
 +-----------+


 I would expect them to be the same. Or did I miss something?






On Mon, Apr 13, 2015 at 2:20 PM, Jö Fahlke <jorrit at jorrit.de> wrote:

> Am Mon, 13. Apr 2015, 10:33:49 +0100 schrieb Ganesh Diwan:
> > Date: Mon, 13 Apr 2015 10:33:49 +0100
> > From: Ganesh Diwan <gcdiwan83 at gmail.com>
> > To: Ganesh Diwan <gcdiwan83 at gmail.com>, Oliver Sander
> >  <sander at igpm.rwth-aachen.de>, DUNE Liste <dune at dune-project.org>
> > Subject: Re: [Dune] Local node numbering in Dune
>
> I'm not sure what the inconsistency is you are concerned about.  These
> numbers
> look OK to me.  Maybe these two observations will help to clear the
> confusion
> up:
>
> - You are printing the corners of intersections.  Intersections are not
>   subentities of the referenceelements of their neighboring elements, so
> their
>   orientation is somewhat arbitrary, may depend on the grid manager used,
> and
>   may even depend on how that particular grid was constructed.  To
> transform
>   from the local coornate system of an intersection to the local coordinate
>   system of its inside (outside) element, use is->geometryInInside()
>   (is->geometryInOutside()).
>
> - The intersection iterator can visit the intersections in arbitrary order.
>   There is however a special number that you can request:
> is->indexInInside().
>   Basically, this tells you the number of the codim-1-subentitiy of the
>   inside-element that coincides with the intersection.  For non-conforming
>   grids, multiple intersections of the same inside element can have the
> same
>   indexInInside():
>
>     +-----------+-----+
>     |     3     |     |
>     |          1|     |
>     |0          +-----+
>     |          1|     |
>     |     2     |     |
>     +-----------+-----+
>
>   There are five intersections in the larger element, two of which have
>   indexInInside()==1.
>
>   There is also a corresponding is->indexInOutside().
>
> If that does not clear things up, please point us to a particular a number
> from the output that you think is wrong, tell us what you think it should
> be
> instead, and why yoh think so.
>
> Regards,
> Jö.
>
> > I'm sorry, you appear to have included the wrong version of
> MeshTraversal in
> > > your mail.  At least I cannot see how it could have produced the output
> > > above,
> > > since it does not contain the string "my face".
> > >
> >
> > My apologies for the confusion. I should have pasted the precise output
> > from my code, here it is:
> >
> >
> > //
> >
> -------------------------------------------------------------------------------------------------
> > dimension of the grid is: 2
> > visiting element 1(cube, 2)
> > visiting face 1(simplex, 1)
> > node 1 for face 1 is 1 0
> > node 2 for face 1 is 1 1
> > visiting face 2(simplex, 1)
> > node 1 for face 2 is 0 1
> > node 2 for face 2 is 1 1
> > visiting face 3(simplex, 1)
> > node 1 for face 3 is 0 0
> > node 2 for face 3 is 0 1
> > visiting face 4(simplex, 1)
> > node 1 for face 4 is 0 0
> > node 2 for face 4 is 1 0
> > //
> >
> -------------------------------------------------------------------------------------------------
> > // end of output from MeshTraversal
> >
> > I hope it is clear now, please write if it is not. Also please see the
> mesh
> > data in gmsh format which I am using as input to the code above-
> >
> > $MeshFormat
> > 2.2 0 8
> > $EndMeshFormat
> > $Nodes
> > 4
> > 1 0 0 0
> > 2 1 0 0
> > 3 1 1 0
> > 4 0 1 0
> > $EndNodes
> > $Elements
> > 9
> > 1 15 2 0 1 1
> > 2 15 2 0 2 2
> > 3 15 2 0 3 3
> > 4 15 2 0 4 4
> > 5 1 2 0 1 1 2
> > 6 1 2 0 1 2 3
> > 7 1 2 0 1 3 4
> > 8 1 2 0 1 4 1
> > 9 3 2 0 6 1 2 3 4
> > $EndElements
> >
> >
> > Many thanks for your help,
> > Ganesh
> >
> >
> >
> >
> > On Fri, Apr 10, 2015 at 9:27 PM, Jö Fahlke <jorrit at jorrit.de> wrote:
> >
> > > Am Fri, 10. Apr 2015, 14:09:09 +0100 schrieb Ganesh Diwan:
> > > > Date: Fri, 10 Apr 2015 14:09:09 +0100
> > > > From: Ganesh Diwan <gcdiwan83 at gmail.com>
> > > > To: Oliver Sander <sander at igpm.rwth-aachen.de>, DUNE Liste
> > > >  <dune at dune-project.org>
> > > > Subject: Re: [Dune] Local node numbering in Dune
> > > > X-No-Auth: unauthenticated sender
> > > > X-No-Relay: not in my network
> > > > X-Envelope-From: <gcdiwan83 at gmail.com>
> > > >
> > > > Hi Oliver
> > > >
> > > > When I loop through the element(s), I see that Dune returns element
> faces
> > > > that are in conflict with what the link above says. To be specific I
> get
> > > > my face 2 as Dune reference element face 0,
> > > > my face 0 as Dune reference element face 1,
> > > > my face 3 as Dune reference element face 2,  and
> > > > my face 1 as Dune reference element face 3,
> > > >
> > > > Clearly I am doing something wrong!
> > >
> > > I'm sorry, you appear to have included the wrong version of
> MeshTraversal
> > > in
> > > your mail.  At least I cannot see how it could have produced the output
> > > above,
> > > since it does not contain the string "my face".
> > >
> > > (In case I misunderstood and MeshTraversal was not meant to produce
> that
> > > output, please clarify how you obtained the numbers after "my face" and
> > > "Dune
> > > reference element face".)
> > >
> > > Regards,
> > > Jö.
> > >
> > > > I have:
> > > >
> > > > typedef Dune::ALUGrid<2, 2, Dune::cube, Dune::nonconforming>
> GridTypeALU;
> > > > std::auto_ptr<GridTypeALU> mygrid( GmshReader<GridTypeALU>::read(
> > > > "./grids/hhgex.msh", true, true ) );
> > > > MeshTraversal (*mygrid); //
> > > >
> > > > and then I have MeshTraversal as:
> > > >
> > > > template<class G>
> > > > void MeshTraversal(G& grid) {
> > > >     //first we extract the dimensions of the grid
> > > >
> > > >     const int dim = G::dimension;
> > > >     std::cout << "dimension of the grid is: " << dim << std::endl;
> > > >     const int dimworld = G::dimensionworld;
> > > >     typedef typename G::ctype ct;
> > > >     typedef typename G::LeafGridView GridView;
> > > >
> > > >     typedef typename GridView::template Codim<0>::Iterator
> LeafIterator;
> > > >     typedef typename GridView::IntersectionIterator
> IntersectionIterator;
> > > >
> > > >     GridView gridView = grid.leafView();
> > > >     // get grid view on leaf part
> > > >
> > > >     LeafIterator endit = gridView.template end<0>();
> > > >
> > > >     int count = 0;
> > > >     //
> > > >     for (LeafIterator it = gridView.template begin<0>(); it != endit;
> > > ++it)
> > > > {
> > > >
> > > >         count++;
> > > >         Dune::GeometryType gt = it->type();
> > > >         //
> > > >         std::cout << "visiting element " << count << gt << std::endl;
> > > >
> > > >         IntersectionIterator isend = gridView.iend(*it);
> > > >
> > > >         int countface = 0;
> > > >         for (IntersectionIterator is = gridView.ibegin(*it); is !=
> isend;
> > > >                 ++is) {
> > > >             countface++;
> > > >             Dune::GeometryType gfacet = is->type();
> > > >             std::cout << "visiting face " << countface << gfacet <<
> > > > std::endl;
> > > >             std::cout << "node 1 for face" << countface << " is "
> > > >                     << is->geometry().corner(0) << std::endl;
> > > >             std::cout << "node 2 for face" << countface << " is "
> > > >                     << is->geometry().corner(1) << std::endl;
> > > >             //
> > > >         }
> > > >     }
> > > >     std::cin.get();
> > > > }
> > > >
> > > >
> > > >
> > > > On Wed, Apr 8, 2015 at 3:57 PM, Ganesh Diwan <gcdiwan83 at gmail.com>
> > > wrote:
> > > >
> > > > > Thankyou!
> > > > >
> > > > > Ganesh
> > > > >
> > > > > On Wed, Apr 8, 2015 at 3:56 PM, Oliver Sander <
> > > sander at igpm.rwth-aachen.de>
> > > > > wrote:
> > > > >
> > > > >> Am 08.04.2015 um 16:50 schrieb Ganesh Diwan:
> > > > >> > Dear List
> > > > >> >
> > > > >> > It appears that after reading the grid from a Gmsh format file
> > > inside
> > > > >> Dune,
> > > > >> > the local dofs 2 and 3 i.e. node number 3 and 4 are swapped.
> This is
> > > > >> inside
> > > > >> > dune-grid//dune/grid/io/file/gmshreader.hh
> > > > >> >
> > > > >> > Is there a specific reason this is done? Is there a way to tell
> > > Dune to
> > > > >> use
> > > > >> > the same node numbering as in Gmsh file and not to alter it?
> > > > >>
> > > > >> Hi Ganesh,
> > > > >> Dune has one fixed numbering for the local node numbers of all
> > > reference
> > > > >> elements
> > > > >> (see
> > > > >>
> > >
> http://www.dune-project.org/doc/doxygen/dune-geometry-html/group___geometry_reference_elements.html
> > > > >> )
> > > > >>
> > > > >> These numberings differ from the ones used by gmsh, and hence the
> gmsh
> > > > >> reader
> > > > >> needs to do some node swapping.
> > > > >>
> > > > >> Best,
> > > > >> Oliver
> > > > >>
> > > > >> >
> > > > >> > Thankyou
> > > > >> > Ganesh
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> > _______________________________________________
> > > > >> > Dune mailing list
> > > > >> > Dune at dune-project.org
> > > > >> > http://lists.dune-project.org/mailman/listinfo/dune
> > > > >> >
> > > > >>
> > > > >>
> > > > >>
> > > > >> _______________________________________________
> > > > >> Dune mailing list
> > > > >> Dune at dune-project.org
> > > > >> http://lists.dune-project.org/mailman/listinfo/dune
> > > > >>
> > > > >>
> > > > >
> > >
> > > > _______________________________________________
> > > > Dune mailing list
> > > > Dune at dune-project.org
> > > > http://lists.dune-project.org/mailman/listinfo/dune
> > >
> > >
> > > --
> > > Jorrit (Jö) Fahlke, Institute for Computational und Applied
> Mathematics,
> > > University of Münster, Orleans-Ring 10, D-48149 Münster
> > > Tel: +49 251 83 35146 Fax: +49 251 83 32729
> > >
> > > Interpunktion, Orthographie und Grammatik der Email ist frei erfunden.
> > > Eine Übereinstimmung mit aktuellen oder ehemaligen Regeln wäre rein
> > > zufällig und ist nicht beabsichtigt.
> > >
>
> > _______________________________________________
> > Dune mailing list
> > Dune at dune-project.org
> > http://lists.dune-project.org/mailman/listinfo/dune
>
>
> --
> Jorrit (Jö) Fahlke, Institute for Computational und Applied Mathematics,
> University of Münster, Orleans-Ring 10, D-48149 Münster
> Tel: +49 251 83 35146 Fax: +49 251 83 32729
>
> If God had intended Man to Smoke, He would have set him on Fire.
> -- fortune
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dune-project.org/pipermail/dune/attachments/20150415/edd4244e/attachment.htm>


More information about the Dune mailing list