Hi Peter, thanks for your quick reply!
> A quick (and dirty) solution would be to evaluate and perform the communication non-uniquely and pick out one of the received values at the end. See also VectorTools::evaluate_at_points() and the flag VectorTools::EvaluationFlags::insert: although intentionally not documented this function will take the first value of the process with the lowest rank. I have not yet looked in such a detail at the functions, but if I have the solution values again on multiple processes I need to decide again on each process. However, let me first take a closer look at the functions, I just realized that there is also a `ConsensusAlgorithm` namespace which might offer some remedies. > Anyway, I am happy to discuss how to implement the needed feature. The code that would need to be touched is: https://github.com/dealii/dealii/blob/654b14481eeff7e744297025ea2078ab115611ac/source/grid/grid_tools.cc#L5905-L5909, i.e., a consistent modification of send_components and recv_components. I am happy to write a draft if you want. All in all, I don't need a mature solution right now and having something more compact inside the library would be of course highly appreciated. I could contribute something in this direction, if that's what you were thinking of. Let me add that it will probably take more time than you think. Looking forward to the draft. David peterr...@gmail.com schrieb am Mittwoch, 12. Mai 2021 um 12:30:21 UTC+2: > Hi David, > > > I want to evaluate each point out of the cloud only once in case of a > distributed triangulation. > > A quick (and dirty) solution would be to evaluate and perform the > communication non-uniquely and pick out one of the received values at the > end. See also VectorTools::evaluate_at_points() and the flag > VectorTools::EvaluationFlags::insert: although intentionally not documented > this function will take the first value of the process with the lowest rank. > > > I would probably need to go a step further and implement a consensus > algorithm in order to decide only for one specific process, which seems not > trivial to me. > > You are right. One would need an additional communication step (with or > without CA) to make the evaluation/communication more efficient. I was > thinking about introducing an additional flag to the constructor of > RemotePointEvaluation, but have not implemented it yet, since in our use > cases we either need the average values (DG) or we set up the communication > pattern in every time step due to some very dynamic systems (multi phase > flow). > > Anyway, I am happy to discuss how to implement the needed feature. The > code that would need to be touched is: > https://github.com/dealii/dealii/blob/654b14481eeff7e744297025ea2078ab115611ac/source/grid/grid_tools.cc#L5905-L5909, > > i.e., a consistent modification of send_components and recv_components. I > am happy to write a draft if you want. > > Hope this helps, > Peter > On 12.05.21 09:08, 'David' via deal.II User Group wrote: > > Dear all, > > I'm currently looking for a way to evaluate my global solution on an > arbitrary cloud of points and stumbled across the (new) class > `Utilities::MPI::RemotePointEvaluation<dim>`. In general, the class does > exactly what I want with one particular exception; I want to evaluate each > point out of the cloud only once in case of a distributed triangulation. If > I understand it correctly this property is fulfilled in case the boolean > function `is_map_unique()` returns true, but I don’t see any option to > filter or tell the class that I actually want the map to be unique. > > Assuming that the class cannot handle this case I tried to pre-filter the > vertices by hand: For me, the most natural choice to fulfill the unique > evaluation of the points is to assign them to a process, so that I only > work on ‘locally owned vertices’. I compute a bounding box using the > iterator filter `LocallyOwnedCell()`, filter the received cloud of points > on the process and finally plug them into the `RemotePointEvaluation`. > However, this does not work in case points of the cloud are located at the > boundary of the bounding box, because they will technically be part of both > bounding boxes of the involved processes. I would probably need to go a > step further and implement a consensus algorithm in order to decide only > for one specific process, which seems not trivial to me. > > Before starting now to implement a more advanced solution I would like to > ask if there is an obvious way I’m not aware of. Is it possible to enforce > a unique evaluation using one of the ‘PointEvaluation’ classes or is it > possible to let deal.II decide for an owner of an arbitrary vertex? I have > also seen the function ‘find_active_cell_around_point()’ which might help, > but it might end up in similar problem as well. > > Thanks in advance and best regards, > > David > > > -- > The deal.II project is located at http://www.dealii.org/ > For mailing list/forum options, see > https://groups.google.com/d/forum/dealii?hl=en > --- > You received this message because you are subscribed to the Google Groups > "deal.II User Group" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to dealii+un...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/dealii/c29fcdf5-59bf-450f-9de6-d9f9bddd3c68n%40googlegroups.com > > <https://groups.google.com/d/msgid/dealii/c29fcdf5-59bf-450f-9de6-d9f9bddd3c68n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/cb140fdb-12fb-4178-9037-d33d7f8bb5cen%40googlegroups.com.
