dolfin team mailing list archive

[Andre Massing <massing@xxxxxxxxx>]

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



On 11/09/2011 03:46 PM, Anders Logg wrote:
> On Wed, Nov 09, 2011 at 02:07:57PM -0600, Andre Massing wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>> 
>> Hi!
>> 
>> I have implemented 
>> https://blueprints.launchpad.net/dolfin/+spec/bbtree-all-codim
>> 
>> including some unittests, but there remain some questions.
>> 
>> 1. The name IntersectionOperator is kind of unfortunate and
>> cryptic. In the end it is just a wrapper for a bounding box tree
>> so I was thinking about renaming it to something more
>> descriptive, e.g. BoundingVolumeTree or BVTree...Any suggestions,
>> wishes, feelings that? That brings me to another point.
> 
> If it's a wrapper for a bounding box tree, then BoundingBoxTree
> would be suitable, but isn't it more than that? It's an interface
> for computing intersections between mesh entities.

Yes, but that is the primary existence reason for the tree, it makes
intersection detection feasible. But I agree, that assumes background
knowledge from the user, so IntersectionDetector (as you suggest) is
the better name.

> 
> The constructor of the IntersectionOperator class says
> 
> /// Create intersection detector for the mesh \em mesh.
> 
> So perhaps IntersectionDetector could work?

Yes I think so.

> 
>> 2. Since a bbtree is available for all entity dimension it might
>> be nice to have specialized, ready to use name for them
>> (especially with the python interface in mind and similar to what
>> we have for MeshEntity already)? For instance CellBVTree,
>> FacetBVTree are names popping up in my mind. Are they any
>> suggestions or preferences regarding this?
> 
> Is this something a user will typically see? So the specialized 
> functions may not be important, but we could perhaps add
> 
> CellIntersectionDetector
> 
> etc.
> 
>> 3. Johan suggested at some point to expose the distance
>> functions available in CGAL AABBTree
>> 
>> http://www.cgal.org/Manual/latest/doc_html/cgal_manual/AABB_tree_ref/Class_AABB_tree.html#Cross_link_anchor_1724
>>
>>
>> 
which I think is a good idea.  Any objections for adding that to
>> DOLFIN? As far as I know of intersection related operations haven
>> 't been mentioned in the book, so an interface renaming plus some
>> small  localized interface changes won't effect code examples in
>> the book.
> 
> Yes, that would be good. But I'm starting to think now that maybe
> this should all be merged into trunk and not 1.0.x (even the fixes
> you have made for InteresectionOperator/Detector). It's a
> substantial piece of code and it involves renaming of classes so it
> might introduce new bugs.
> 
> What do you think? Is it important to get it into 1.0.0? There will
> be many nice features in 1.1 so your code will be in good company.
> :-)

The actually change in the code to detect intersection for all
entities  is not really a big change, basically I added some
constructors which assures that the old code will work as before.
Plus that I have some unittest in place checking the basic functionality.
But your are the release manager :) If you want I can submit a merge
request, then you can have a look at it and decide whether you think
it is to invasive. What do you think?

- --
Andre

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

iQEcBAEBAgAGBQJOuvfAAAoJEA79ggnbq9dmJf4H/RWnRSTjOl+Y7OtHROl3JwGT
/WYdw8d8Os5k3vG65cCGid2R1YES4AMbOpuFCXiw9jTrXvZ08+1YhqqFD2/kkCib
PN8r6QfE39hEzHBJ2LXfUeLduJefGpK4ftZCdbDmjZ1Alf2dFIpSMCyFqELtDf0V
MAXtz9W9xl+5tgDWhKESQMSqOE/jQlu/bi8Y1v9RFC9766FfhZ6nT8ClhXGWebTd
Cxu18S2kHh0SVeqf47AnS0JYlJfQB39k41C1hOZtgyZMOAZjojej7UlRh2qzMGF7
VAEQYBspJJZCrEzp3IFz5Yn2qLZAgfiicwr7pDZtOuQqN6rxbfOYOPdEtQCUcM8=
=qCpZ
-----END PGP SIGNATURE-----