[Dune] attaching data to intersections
Jurgis Pods
jurgis.pods at iwr.uni-heidelberg.de
Thu Jun 6 14:18:58 CEST 2013
Hi Arya,
there is a mail by Jö Fahlke from May 16 2011 from this mailing list,
where it is explicitly explained how to obtain an index for an arbitrary
intersection, in response to a question similar to yours. Let me just
quote this mail:
Am Mon, 16. May 2011, 11:27:09 +0200 schrieb Benjamin Faigle:
> if i understood it right, the method
> grid.localIdSet().id(const EntityType &e)
> should return a unique ID for every sort of entities, be it
> elements, vertices or intersections. It works out pretty well with
> elements, as shown for example in the Dune Grid Howto
> IdType idf = idset.id (* ep );
>
> However, if I try the same with an *intersection, I get the error message:
> ...dune-grid/dune/grid/common/indexidset.hh:394:43: error:
> ‘codimension’ is not a member of ‘Dune::IntersectionIterator<const
> Dune::UGGrid<2>, Dune::UGGridLeafIntersectionIterator,
> Dune::UGGridLeafIntersection>’
>
> I am using dune 2.0.
> I am sorry if it is just an incredibly silly question, and many
> thanks for your help,
Only entities have ids. Intersections are not entities!
All grids have entities of codimension dim (vertices) and codimension 0
(elements), and all have intersections. Some grids have entities of other
codimensions as well. Even if a grid has entities of codimension 1, these are
not the same as entities. Most obvious differences:
* Intersections know the neighbouring cells, codim 1 entities don't.
* Intersections have an orientation, codim 1 entities don't.
* Codim 1 entities have indices and ids and can be used to obtain array
indices from a mapper (even if the grid does not support codim 1 entity
objects!) For intersections, indices, id's and maps are not provided by
core Dune, though it is possibly to build such things yourself.
* In non-conforming grids you may have the following situation:
+-------+---+---+
| | b | d |
| a +---+---+
| | c | e |
+-------+---+---+
Elements b, c, d and e all have four codim 1 subentities and four
corresponding intersections. Element a also has four codim 1 subentities,
but it has five intersections. The codim 1 entity to the right of b is the
same as the codim 1 entity to the left of d. You have three codim 1
entities to the right of a however: on covering the whole of a's right
border, and two smaller one each covering the upper and the lower half of
a's border, respectively.
If you know you have a conforming grid, you have a correspondance between
intersections and codim 1 entities (ignoring the orientation of the
intersections). In that case you can usually get away by using the id of the
corresponding codim 1 entity as the id of the intersection (even if the grid
does not support codim 1 entities as independent objects. Use
grid.globalIdSet().subId(e, i.indexInInside(), 1);
where i is the intersection and e is the codim 0 entity i was obtained from.
If you don't have e readily available, you can use
grid.globalIdSet().subId(*i.inside(), i.indexInInside(), 1);
instead.
Bye,
Jö.
I hope this helps.
Best,
Jurgis
On 06.06.2013 14:01, Arya Fallahi wrote:
> Dear Jurgis and Steffen,
>
> Following your discussion, I thought of asking you my question since
> the problem Jurgis has mentioned is somehow close to mine. I have
> written yesterday to dune but have received no feedback yet.
>
> I am indeed not completely aware about the kind of data Jurgis is
> going to attach to intersections but what I need to do is as follows:
>
> I am using .msh format produced by gmsh to prepare my grid and the
> tags attached to the entities. In a specific analysis, I need to find
> intersections with specific tags. These tags for any kind of elements
> are supported by .msh and also by dgf format and ALUGrid. What I need
> to do is to call the tags of intersections from dune. The same thing
> as what intersect->boundaryId() does is needed. However, boundaryId()
> gives the tags if and only if the intersection is of boundary type
> i.e. intersect->boundaryId() = true. I have read the dune tutorial in
> detail and also searched through out the class documentation but could
> not find how the tags can be retrieved if intersect->boundaryId() =
> false. Do you know if this is supported or implemented at all in dune?
>
> Thank you in advance for your help,
>
> Arya
>
>
> On Thu, Jun 6, 2013 at 1:24 PM, Jurgis Pods
> <jurgis.pods at iwr.uni-heidelberg.de
> <mailto:jurgis.pods at iwr.uni-heidelberg.de>> wrote:
>
> Hi Steffen,
>
> thanks for the hint! I actually got it to work, it turned out that
> my problem actually was that I used dune-multidomaingrid the wrong
> way!
>
> [Begin Off-topic]
> When defining the multidomain grid like this:
>
> typedef
> Dune::MultiDomainGrid<HostGrid,Dune::mdgrid::FewSubDomainsTraits<HostGrid::dimension,2,Dune::mdgrid::CellAndVertexCodims>
> > Grid;
>
>
> and then calling for an IntersectionIterator 'iit' the following:
>
> gv.indexSet().subIndex(*iit->inside(), iit->indexInInside(), 1)
>
>
> on the multidomain gridview, everything goes well. But when
> calling this on a *subdomain* gridview:
>
> subgv.indexSet().subIndex(*iit->inside(), iit->indexInInside(), 1)
>
>
> the program would exit and complain with
>
> Dune reported error: GridError
> [invoke:/home/jpods/workspace/dev/dune-multidomaingrid/dune/grid/multidomaingrid/indexsets.hh:92]:
> codim not supported
>
>
> Apparently, the lesson learned is to only use the subIndex()
> method on the multidomain gridview.
> [End Off-topic]
>
> Thanks again!
> Jurgis
>
>
> On 06.06.2013 10:13, Steffen Müthing wrote:
>
> Hi Jurgis,
>
> you don't need actual face entity objects to do this, you just
> need their indices (and those should be provided by
> all DUNE grids, if I understand the grid paper correctly - you
> are fine at least, because YaspGrid definitely provides
> indices for faces). If your grid does not support face
> entities, you can still get their indices with the help of the
> cell
> entity if you know the embedding of the face in the cell
> (usually from Intersection::indexInInside() ). You can even get
> the indices of the face's subentities. Take a look at
> IndexSet::subIndex() for the details.
>
> That said (and slightly off-topic for this list), I don't have
> the slightest idea if IntersectionIndexSet still works. That thing
> was only ever really used by Sven's mimetic FD code, and that
> hasn't been maintained for quite a while now. YMMV
> (it's definitely broken in PDELab master, though)...
>
> Steffen
>
> Am 05.06.2013 um 14:58 schrieb Jurgis Pods:
>
> Hi Steffen,
>
> this approach (using PDELab's IntersectionIndexSet) will
> not work on grids which do not support codim-1 entities,
> will it? Does this mean I have to use an IdSet in this case?
>
> Jurgis
>
>
> On 07.11.2012 22 <tel:07.11.2012%2022>:21, Steffen Müthing
> wrote:
>
> Hi Marco,
>
> as long as your grid has a conforming macro grid
> (which is true for every Dune grid I know),
> you can always associate the data with the face
> belonging to the more-refined
> entity (the one with the higher level), or with the
> face belonging to the cell with
> the lower index (if the levels are the same). To get
> the index of that face, you can
> use the subIndex() method of the IndexSet with the
> cell and the value of indexInInside()
> or indexInOutside() from the intersection.
>
> In PDELab, there is an IntersectionIndexSet that does
> something like that. Perhaps you
> can simply use that, or you can use it as inspiration
> for your own implementation… ;-)
>
> Steffen
>
>
> Am 07.11.2012 um 18:03 schrieb Marco Cisternino:
>
>
> Hi Duners,
> I need to attach data to intersections. I would
> like to avoid redundance of data (using a mapper
> to elements and attaching a stl container to store
> values on its intersections) and time consumption
> to access data (using a stl map).
> I wonder if something like a mapper is available
> for intersections. Choosing the right layout for a
> MCMG mapper would not work, I guess, on non
> conforming grid, doesn't it?
> Thank you very much, again.
>
> Marco
>
>
> --
> Marco Cisternino
> Optimad Engineering s.r.l.
>
> www.optimad.it <http://www.optimad.it>
> marco.cisternino at optimad.it
> <mailto:marco.cisternino at optimad.it>
>
> +3901119719782 <tel:%2B3901119719782>
>
>
> _______________________________________________
> Dune mailing list
>
> Dune at dune-project.org <mailto:Dune at dune-project.org>
> http://lists.dune-project.org/mailman/listinfo/dune
>
> Steffen Müthing
> Universität Stuttgart
> Institut für Parallele und Verteilte Systeme
> Universitätsstr. 38
> 70569 Stuttgart
> Tel: +49 711 685 88429 <tel:%2B49%20711%20685%2088429>
> Fax: +49 711 685 88340 <tel:%2B49%20711%20685%2088340>
> Email:
> steffen.muething at ipvs.uni-stuttgart.de
> <mailto:steffen.muething at ipvs.uni-stuttgart.de>
>
>
>
>
>
> _______________________________________________
> Dune mailing list
>
> Dune at dune-project.org <mailto:Dune at dune-project.org>
> http://lists.dune-project.org/mailman/listinfo/dune
>
> Steffen Müthing
> Universität Stuttgart
> Institut für Parallele und Verteilte Systeme
> Universitätsstr. 38
> 70569 Stuttgart
> Tel: +49 711 685 88429 <tel:%2B49%20711%20685%2088429>
> Fax: +49 711 685 88340 <tel:%2B49%20711%20685%2088340>
> Email: steffen.muething at ipvs.uni-stuttgart.de
> <mailto:steffen.muething at ipvs.uni-stuttgart.de>
>
>
>
> _______________________________________________
> Dune mailing list
> Dune at dune-project.org <mailto:Dune at dune-project.org>
> http://lists.dune-project.org/mailman/listinfo/dune
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dune-project.org/pipermail/dune/attachments/20130606/1e863b71/attachment.htm>
More information about the Dune
mailing list