[Dune] boundarySegmentIndex for ALUGRID_CUBE

[Martin Nolte]

Hi Amal,

thanks for the example. This is indeed a bug in the 2d implementation, which
internally builds up a 3d grid (by extruding it in the third dimension). This
way, your unit square has two additional faces. Unfortunately, those are not
numbered last.

I added a bug report on the issue tracker. This one is a bit tricky, so it can
take some time.

Best,

Martin

On 08/22/2017 09:46 PM, Sahai, Amal wrote:
> I realized that the attached file might be blocked by certain email clients. My .msh file looks pretty simple and contains the following lines:
> 
> $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
> 5
> 1 1 2 1 1 4 1
> 2 1 2 2 2 1 2
> 3 1 2 3 3 2 3
> 4 1 2 4 4 3 4
> 5 3 2 0 0 4 1 2 3
> $EndElements
> ~
> 
> 
> Regards
> Amal
> ________________________________________
> From: Sahai, Amal
> Sent: Tuesday, August 22, 2017 3:37 PM
> To: Martin Nolte; dune at lists.dune-project.org
> Subject: RE: [Dune] boundarySegmentIndex for ALUGRID_CUBE
> 
> I'm attaching the .msh file that I used to test this example. I have a pretty simple program (This code is based on fem-dg/algorithm/gridinitializer.hh). I'm creating an ALUGrid for cubic elements using the gmsh reader:
> 
>         // Create GridFactory and then read mesh
>         Dune::GridFactory< GridImp > factory;
> 
>         // Stored Physical Ids (first tag) for boundary and elements
>         std::vector<int>  bIdToPhysical, eindexToPhysical;
> 
>         Dune::GmshReader< GridImp >::read(factory,filename, bIdToPhysical, eindexToPhysical,true,true);
> 
>         // read grid with given file name
>         gridptr = factory.createGrid();
> 
> 
> I wanted to check out the boundary indices so I created the following loop:
> 
>         // Grid View for the leaf
>         typedef typename GridImp :: LeafGridView GridView;
> 
>         // get grid view on leaf part
>         GridView gridView = gridptr->leafGridView();
> 
>         // element iterator type
>         typedef typename GridView::template Codim<0>::Iterator LeafIterator;
> 
>         // intersection iterator type
>         typedef typename GridView::IntersectionIterator IntersectionIterator;
> 
>         std::vector<int> count;
> 
>         LeafIterator endit = gridView.template end<0>();
>         for (LeafIterator it = gridView.template begin<0>(); it!=endit; ++it)
>           {
>             // run through all intersections with neighbors and boundary
>             IntersectionIterator isend = gridView.iend(*it);
>             for (IntersectionIterator is = gridView.ibegin(*it); is!=isend; ++is)
>               {
>                 // If given intersection is on a boundary
>                 if(!is->neighbor() && is->boundary())
>                   if(factory.wasInserted(*is))
>                     {
>                       std::cout << "Boundary Segment Index : "  << is->boundarySegmentIndex()  << "\t"
>                                 << "Factory Insertion Index : " << factory.insertionIndex(*is) << "\n";
> 
>                       count.push_back(is->boundarySegmentIndex());
>                     }
>              }
>           }
> 
> 
> The boundary Segment index makes no sense (non-continuous and is much larger than numBoundarySegments.
> 
> Regards
> Amal
> ________________________________________
> From: Dune [dune-bounces at lists.dune-project.org] on behalf of Martin Nolte [nolte at mathematik.uni-freiburg.de]
> Sent: Tuesday, August 22, 2017 12:50 PM
> To: dune at lists.dune-project.org
> Subject: Re: [Dune] boundarySegmentIndex for ALUGRID_CUBE
> 
> Hi Amal,
> 
> that would be a bug. Could you create a small example program and file a bug
> report on the dune-alugrid issue tracker?
> 
> Best,
> 
> Martin
> 
> On 08/22/2017 06:02 PM, Sahai, Amal wrote:
>> Does a call to intersection.boundarySegmentIndex() not work correctly for ALU grid with cubes/quads? I was expecting a continuous range of indices with a maximum value that is equal to grid.numBoundarySegments() - 1, but this is not what I am observing. I did not experience this behavior while running an ALU grid with tet/triangular elements (and the boundary segment index was recovered correctly).
>>
>> Is this a known problem and are their ways to circumvent this? How does one go about attaching data (physical Ids recovered from the gmsh reader) to intersections for an ALU grid? Is there an alternative unique index I can use for this purpose?
>>
>> Regards
>> Amal
>> _______________________________________________
>> Dune mailing list
>> Dune at lists.dune-project.org
>> http://lists.dune-project.org/mailman/listinfo/dune
>>
> 
> --
> Dr. Martin Nolte <nolte at mathematik.uni-freiburg.de>
> 
> Universität Freiburg                                   phone: +49-761-203-5630
> Abteilung für angewandte Mathematik                    fax:   +49-761-203-5632
> Hermann-Herder-Straße 10
> 79104 Freiburg, Germany
> 
> _______________________________________________
> Dune mailing list
> Dune at lists.dune-project.org
> http://lists.dune-project.org/mailman/listinfo/dune
> 

-- 
Dr. Martin Nolte <nolte at mathematik.uni-freiburg.de>

Universität Freiburg                                   phone: +49-761-203-5630
Abteilung für angewandte Mathematik                    fax:   +49-761-203-5632
Hermann-Herder-Straße 10
79104 Freiburg, Germany