dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

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 about
> 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.

The constructor of the IntersectionOperator class says

  /// Create intersection detector for the mesh \em mesh.

So perhaps IntersectionDetector could work?

> 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. :-)

--
Anders