[Dune] Use of partition iterators

[Steffen Müthing]

> Am 21.09.2015 um 11:37 schrieb Ganesh Diwan <gcdiwan83 at gmail.com>:
> 
> Hi Steffen
> 
> Thank you. Yes, that works but with that I was able to visit only the boundary domain and not the interface between the partitions. A small change
> 
> isIt->boundary()) || ( isIt->neighbor() && isIt->inside().partitionType() == Dune::InteriorEntity && isIt->outside().partitionType() == Dune::GhostEntity   // this visits and not skips
> 
> now visits all the vertices sitting on the partition boundary which could either be part of partition interface or the domain boundary.

That’s good to hear - as I said, I never tested that code, so I might have mixed up that check…

Best
Steffen

> 
> Regards
> Ganesh
> 
> On Wed, Sep 16, 2015 at 8:18 PM, Steffen Müthing <steffen.muething at iwr.uni-heidelberg.de> wrote:
> Hi Ganesh,
> 
> 
> > Am 16.09.2015 um 19:14 schrieb Ganesh Diwan <gcdiwan83 at gmail.com>:
> >
> > Sorry to bother you again,
> >
> > If I set the iterator for vertices same as above, I am able to extract the border vertices but this obviously misses the domain boundary.
> > I.e. it->partitionType()==Dune::BorderEntity gives me the shared vertices between the partition boundaries but not those on the domain boundary.
> 
> if you want to find the set of all vertices that are situated on the surface of the interiorBorder partition, the easiest way is probably to go through the
> cells and their intersections:
> 
> for (const auto& cell : cells(gv,Partitions::interiorBorder))
> {
>   auto& ref_el = Dune::ReferenceElements<double,dim>::general(cell.geometry().type());
>   for (const auto& is : intersections(gv,cell))
>   {
>     // this skips all intersections that are not either on the domain boundary or have a neighbor
>     // that is not in the interior partition
>     if ((!is.boundary()) || (is.neighbor() && is.outside().partitionType() == Dune::InteriorEntity))
>       continue;
>     for (int i = 0; i < ref_el.size(is.indexInInside(),1,dim); ++i)
>     {
>       auto local_vertex_index = ref_el.index(is.indexInInside(),1,i,dim);
>       // here, you get every vertex that lies on the surface of the interiorBorder partition
>       auto vertex = cell.template subEntity<dim>(local_vertex_index);
>       // if you only need the index of that vertex, it is faster to do the following:
>       auto vertex_index = gv.indexSet().subIndex(cell,local_vertex_index,dim);
>     }
>   }
> }
> 
> That code isn’t tested, but it should be broadly correct. Note, however, that it can (and probably) will visit vertices multiple times!
> 
> Cheers,
> Steffen
> 
> >
> > Thank you
> > Ganesh
> >
> > On Wed, Sep 16, 2015 at 5:30 PM, Ganesh Diwan <gcdiwan83 at gmail.com> wrote:
> > Hi
> > Thank you for your replies.
> >
> > It appears that I can iterate through only the Ghost and InteriorEntity for codim 0 for a given partition. This is OK as I am concerned about the elements that are truly interior to a partition.
> > I however need more information: how to extract all the vertices and edges (marked as blue in grid-howto) only on the border of the partition using this?
> >
> > The border of partition must include the domain boundary if any (If I understand correctly, as per howto some of the edges/vertices can be of partitiontype interior and be on the domain boundary- aptly therefore marked red).
> >
> > As of now, I am able to extract only the domain boundary edges in the partition this way.
> >
> >     const Dune::PartitionIteratorType pit_all=Dune::All_Partition  ;
> >     typedef typename GridType::template Codim<0>::template Partition<pit_all>::LeafIterator AllElementIterator;
> >     typedef typename GridView::IntersectionIterator IntersectionIterator;
> >
> >     int all_ElmCount = 0;
> >     for (AllElementIterator it = grid.template leafbegin<0,pit_all>(); it!=grid.template leafend<0,pit_all>(); ++it) {
> >         if (it->partitionType() == Dune::GhostEntity)
> >             continue;
> >         IntersectionIterator isIt = gv.ibegin(*it);
> >         const IntersectionIterator &isEndIt = gv.iend(*it);
> >         int numedges_on_domain_boundary = 0;
> >         std::cout << "coe: " << it->geometry().center() << std::endl;
> >         for (; isIt != isEndIt; ++isIt) {
> >             if(isIt->boundary()) ++ numedges_on_domain_boundary;
> >         }
> >         std::cout << "edges on domain boundary = " << numedges_on_domain_boundary << std::endl;
> >         ++all_ElmCount;
> >     }
> >
> >
> > One way to probe the border entities, I thought was to follow test-parallel-ug.cc code:
> >
> > typedef Dune::MultipleCodimMultipleGeomTypeMapper<GridView, LayoutWrapper<0>::template Layout>
> >     MapperType;
> >     MapperType mapper(gv);
> >
> >
> > and then probe the entity as:
> >
> > for (AllElementIterator it = grid.template leafbegin<0,pit_all>(); it!=grid.template leafend<0,pit_all>(); ++it) { // element loop 2001
> >         int numberOfSubEntities = it->template count<1>();
> >         std::cout << "no of subentities = " << numberOfSubEntities << std::endl;
> >         for (int k = 0; k < numberOfSubEntities; k++)
> >         {
> >             typedef typename GridView::template Codim<0>::Entity Element;
> >             typedef typename Element::template Codim<0>::EntityPointer EntityPointer;
> >             const EntityPointer entityPointer(it->template subEntity<1>(k)); // <<========= compilation error occurs here
> >             entityIndex[mapper.map(*entityPointer)]   = mapper.map(*entityPointer);
> > }
> > }
> >
> > But I have problem compiling this where I define the EntityPointer, the error is:
> >
> >  error: no matching function for call to ‘Dune::EntityPointer<const Dune::UGGrid<2>, Dune::UGGridEntityPointer<0, const Dune::UGGrid<2> > >::EntityPointer(Dune::Entity<0, 2, const Dune::UGGrid<2>, Dune::UGGridEntity>::subentity_return_info<1>::type)’
> >     const EntityPointer entityPointer(it->template subEntity<1>(k));
> >
> >
> > Thank you,
> > Ganesh
> >
> > On Tue, Sep 15, 2015 at 5:38 PM, Markus Blatt <markus at dr-blatt.de> wrote:
> > On Tue, Sep 15, 2015 at 02:42:47PM +0200, Jö Fahlke wrote:
> > >
> > > To unify things, and to make using the vertices() and elements() functions
> > > easier, recently a new scheme for naming partitions was introduced[4].  The
> > > new scheme makes it possible to name name all possible combinations, even
> > > though not all combinations are supported or are even meaningful in the
> > > context of entity iterators or communication.
> >
> > Isn't that against the principles DUNE ("one algorithm to use them
> > (grids) all"?)?
> >
> > Can one query what combinations are supported by a grid?
> >
> > Markus
> > --
> > Join us at the DUNE User Meeting Sept. 28-29, 2015, Heidelberg, Germany
> > http://users.dune-project.org/projects/dune-user-meeting-2015/wiki
> >
> > Dr. Markus Blatt - HPC-Simulation-Software & Services http://www.dr-blatt.de
> > Hans-Bunte-Str. 8-10, 69123 Heidelberg, Germany
> > Tel.: +49 (0) 160 97590858
> >
> >
> > _______________________________________________
> > Dune mailing list
> > Dune at dune-project.org
> > http://lists.dune-project.org/mailman/listinfo/dune
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.dune-project.org/pipermail/dune/attachments/20150924/a28edb55/attachment.sig>