[Dune] boundarySegmentIndex for ALUGRID_CUBE
Sahai, Amal
sahai2 at illinois.edu
Wed Aug 23 16:15:50 CEST 2017
Thanks a lot for explaining this. I guess as temporary fix, I can have a larger vector (maybe size = numBoundarysegments + 2*elements) storing the physical Ids.
Regards
Amal
________________________________________
From: Martin Nolte [nolte at mathematik.uni-freiburg.de]
Sent: Wednesday, August 23, 2017 10:07 AM
To: Sahai, Amal; dune at lists.dune-project.org
Subject: Re: [Dune] boundarySegmentIndex for ALUGRID_CUBE
No, you won't see them. They are silently skipped by the intersection iterator.
Best,
Martin
On 08/23/2017 04:04 PM, Sahai, Amal wrote:
> So the impact of adding those extra faces by the grid will not really be observed apart from say the boundary index segment? Am I correct in assuming that the user cannot really see those faces by going through all the intersection iterators obtained for a given element (codim=0) through the gridView.ibegin()/iend() method?
>
> Regards
> Amal
> ________________________________________
> From: Martin Nolte [nolte at mathematik.uni-freiburg.de]
> Sent: Wednesday, August 23, 2017 9:52 AM
> To: Sahai, Amal; dune at lists.dune-project.org
> Subject: Re: [Dune] boundarySegmentIndex for ALUGRID_CUBE
>
> Hi Amal,
>
> my comment was referring to the internal implementation of the 2d grid only.
> As a user, you do not see the 3d grid at all.
>
> Best,
>
> Martin
>
> On 08/23/2017 03:39 PM, Sahai, Amal wrote:
>> Hi Martin
>>
>> Thanks for the clarification. I have a couple of follow up questions. So, irrespective of the actual mesh provided, are all grids set up as 3-dimensional by the gridfactory in ALUGRID (with one layer of elements in the out of plane normal direction)? Are the two faces created by this extrusion also considered boundary faces, and visited by the intersection iterator? If this is the case, should I just treat every problem as being 3d in terms of the size of the solution vector and explicitly have boundary conditions for the new faces (for a 2d problem impose no-gradient across a face)?
>>
>> Regards
>> Amal
>> ________________________________________
>> From: Martin Nolte [nolte at mathematik.uni-freiburg.de]
>> Sent: Wednesday, August 23, 2017 1:47 AM
>> To: Sahai, Amal; dune at lists.dune-project.org
>> Subject: Re: [Dune] boundarySegmentIndex for ALUGRID_CUBE
>>
>> 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
>>
>
> --
> 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
>
--
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
More information about the Dune
mailing list