dolfin team mailing list archive

[Andre Massing <massing@xxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi!

I am jumping a bit late into discussion, having been lost the Norwegian
mountains :)


On 08/12/2011 08:52 AM, Johan Hake wrote:
> Any objections to me merging this into trunk?

There  exists a blueprint

https://blueprints.launchpad.net/dolfin/+spec/bbtree-all-codim

which implementation would be include probably most of your
functionality. So it would be cool if we could discuss a
interface/implementation which meets your specific wished and
implemented functionality and the goals of the bluprint without
reproducing to much code. Very nice that somebody else is using and
working on similar functionality!

> 
> Will add unittest for all methods soonish.
> 
> The code now resides in:
> 
>   lp:~dolfin-core/dolfin/hake

I looked into the code, looks nice! I guess the wrapper you wrote could
be  simplified, generalized and merged into the IntersectionOperator
class by slightly generalizing the conctructor of the
IntersectionOperater class.

Right now a mesh has a (default) IntersectionOperator object, which has
a tree for all cells of a mesh.
We now want to provide additional IntersectionOperator objects
each of them having a tree for a subset of entities for some codim, as
Johan for instance has implemented, a subset of the boundary mesh.

All what the IntersectionOperator(Implementation) class constructor
actually does in the end is to pass an  iterator range to the bounding
box tree to be constructed. Therefor we just have
1) generalized the constructor that the IntersectionOperator is building
a tree for a *subset* of entities (*any* codim) of the mesh instead of
all cells.

2) to expose all search/distance related functions from the underlying
CGAL bbtree (simply by adding member function delegating it to the CGAL
tree)

3) think about what concrete instances we want to provide, since we are
using templates. The  question is also whether these still should be a
part of the mesh and finding a nice and not clumsy interface to keep
track of the different IntersectionOperator objects.

What do you think?


A short note about parallelization.  It is true that the common approach
for using the bbtrees is rather serially designed. I thought about this
a bit and at least for the search algorithms an idea would be to have a
bbtree for each mesh partition (as we have right now I guess) and to
merge these forrest than to a tree. The merged upper part of the tree
could be on one (or a few) processor(s) then. To reduce communication I
would suggest a hybrid breadth first / depth first search. That means a
breadth search on the one processor to find out which of the merged
trees might be involved. And then communicate the needed data to the
corresponding processors / mesh and to do the usual depth search first
search. That avoid the back and forth communication in the usual
recursive depth first search.
Of course that is just a rough thought and will need definitely some
work and some thoughts about scalability. But I am quite sure that we
could it get running in parallel.

- --
Andre

> 
> Also, what would the best way to make it work in parallel. The distance from 
> all vertices in a mesh to the closest boundary might not be easy to compute in 
> Parallel as some vertices residing in one mesh might have the closest distance 
> in the mesh on another processor.
> 
> I am inclined to think that this is a bad side effect a user need to be aware 
> of when using this function in parallel. But then I know someone who would 
> disagree ;)
> 
> Another thing is that the present implementation takes a GenericVector 
> representing the return values of the distances at each vertex. Somthing like:
> 
>   distances = Function(V)
> 
>   # Compute distance to Boundary for each vertex
>   distance_computation = DistanceToBoundaryComputation(mesh)
>   distance_computation.vertex_distances(distances.vector())
> 
> In vertex_distances() I check that the local size of the passed vector has the 
> same size as the mesh.num_vertices() this gives an error when running in 
> parallel:
> 
>  Expected a vector with the same local size as the number of vertices (1449) 
> in the mesh, got 1427
> 
>  Expected a vector with the same local size as the number of vertices (1457) 
> in the mesh, got 1441
> 
> I suspect that it has something to do with shared vertices. How do I access 
> the "correct" number of vertices of a mesh partition and how do I know which 
> one is only owned by local mesh?
> 
> I figure I have to look into ParallelData, which btw is not wrapped to Python.  
> We need to add it to dolfin_mesh.h. Will do later...
> 
> Johan
> 
> On Wednesday August 10 2011 14:02:34 Johan Hake wrote:
>> Hello!
>>
>> I have created a class, DistanceToBoundaryComputation, similar to
>> IntersectionOperator, which takes a Mesh or a FacetFunction and compute
>> distances between any point and the closest point to the Boundary or a
>> subset of the boundary given by the FacetFunction.
>>
>> I have published it together with two demos, cpp and python to illustrate
>> some of its functions.
>>
>>    lp:~johan-hake/dolfin/distance-to-boundary
>>
>> If the distances from each vertex is computed, will the result be similar
>> (not always equal) to the signed distance function, or the eikonal
>> equation, but it computes faster.
>>
>> I am not sure how this best can be integrated into the present dolfin. It
>> generates some data, like a BoundaryMesh, which it need to store, so it
>> might not be something we want to put into the Mesh class? If I use the
>> same lazy initialization that Andre used it might be possible.
>>
>> Please feel free to have alook at one of the demos to see it in action.
>>
>> Johan
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~dolfin
>> Post to     : dolfin@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~dolfin
>> More help   : https://help.launchpad.net/ListHelp
> 
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~dolfin
> Post to     : dolfin@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~dolfin
> More help   : https://help.launchpad.net/ListHelp

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJOSSRNAAoJEA79ggnbq9dmI4AH/ReiTL87vmXM/SINrdeiEZDl
0ZDB9dUBWmcLjU06AngZH3qX0Pa6NYfM+CeIe6DEEWz/VRZ4acFpEAxZYm2FH3uO
Alj10rOfmw2jjKgbqxM+bW/nwVcKKyh1c2kxy98xbCJm/2uFtEqW8GdLMe71DIkz
HHVlCx+7p02Bxl2LG5OHoUr/hMWri6no5yXCZuS/illzK1h/6uB+6mbrrZyQnWlQ
uxCQisec1nIhXs1sLLy26GHB9wVwIG6xV/AHVl+ItcSy0oMrd/+PX3d6iDPUPPVN
wwFRAW8payHYCz7uk160Iron0vk1HzTUC/IwV8oAdGijtgHfn1JA0R1pP9Fj6bE=
=9LcL
-----END PGP SIGNATURE-----