[Dune] Local node numbering in Dune
Ganesh Diwan
gcdiwan83 at gmail.com
Wed Apr 15 01:19:46 CEST 2015
I should have included how the face orientation looks from the
intersectioiterator. Sorry for being pedantic but perhaps this shows what
exactly the confusion is.
Given that the orientation can change depending upon the grid manager used,
should not both the orientations be the same once the mesh is read inside
Dune?
gridleaflist face orientation
intersectioiterator
orientation
+-----------+
+-----------+
| 3 |
| 1 |
| |
| |
| 0 1
|
| 2 0 |
| |
| |
| 2 |
| 3 |
+-----------+
+-----------+
Thank you!
Ganesh
On Wed, Apr 15, 2015 at 12:12 AM, Ganesh Diwan <gcdiwan83 at gmail.com> wrote:
> 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/2c455c00/attachment.htm>
More information about the Dune
mailing list