How about something like this:
1. Require additional Cell& cell argument to Function::eval
2. Add new class AutoCell handling this for users who don't want to
explicitly work with a BoundingBoxTree
class AutoCell : public Cell
{
public:
AutoCell(Mesh &mesh);
BoundingBoxTree tree;
}
AutoCell cell(mesh);
function.eval(values, x, cell);
3. If the mesh moves, a user can do something like:
cell.invalidate()
--
Anders
tis 23 juni 2015 kl 10:30 skrev Garth N. Wells <[email protected]>:
> On 22 June 2015 at 18:00, Anders Logg <[email protected]> wrote:
> > The challenge in moving the bounding box tree outside of the mesh is
> that it
> > has always been part of the mesh (it replaced an earlier data structure
> that
> > was there) so a user expects to be able to do
> >
> > v = Function(V)
> > print v(x)
> >
>
> This is fine for Expressions, but for a Function I don't think it's
> bad for the interface to make obvious to the user that they are
> performing a potentially expensive operation. If the user was required
> to pass the cell, all would be fine. It would also fix the issues with
> Function evaluations in parallel.
>
> > without needing to instantiate some cryptic BoundingBoxTree data
> structure.
> > Furthermore, a user expects that on subsequent calls v(x) is fast since
> the
> > tree has already been built.
> >
> > I don't see a way around automatic handling of building the search tree.
> Are
> > there some clever suggestions?
> >
>
> We have a fundamental problem/flaw that MeshGeometery is mutable and a
> Mesh owns a bounding box object. One of the two needs to give.
>
> Garth
>
>
> > Handling this for PointSource and MultiMesh is unproblematic. (But for
> > MultiMesh, I would rather want to move it myself.)
> >
> > --
> > Anders
> >
> >
> > mån 22 juni 2015 kl 17:54 skrev Marco Morandini <
> [email protected]>:
> >>
> >> >>> Besides, the mesh bounding_box_tree used to find the colliding mesh
> >> >>> entity is cached. I fear this could be a source of "strange"
> >> >>> results, because its use is here completely transparent to the
> >> >>> user, who may be unaware of the need to update it.
> >> >>>
> >> >>
> >> >> I really don't like magical caching. How about having
> >> >>
> >> >> PointSource::apply(GenericVector& b, Cell& c, double magnitude);
> >> >>
> >> >> The user is responsible for finding the cell, and thereby also
> >> >> responsible for handling meshes that move, etc.
> >> >>
> >> >> PointSource::apply(...) presently uses Mesh::bounding_box_tree(),
> >> >> which I would like to get rid of from Mesh since mesh geometry is
> >> >> mutable. If the search tools are not cached, the user takes
> >> >> responsibility for managing the bounding boxes.
> >> >
> >> > For the record, this issue is filed as
> >> > https://bitbucket.org/fenics-project/dolfin/issue/89
> >> >
> >>
> >> Right now Mesh::bounding_box_tree() is used by
> >>
> >> void PointSource::apply(GenericVector& b)
> >> void Function::eval(Array<double>& values, const Array<double>& x) const
> >>
> >> and
> >>
> >> MultiMesh ( + MultiMeshDirichletBC )
> >>
> >> It would be pretty easy to change PointSource and Function.
> >> But I think that, for MultiMesh, I should move the bboxes there, and
> >> leave MultiMesh::build() unchanged.
> >>
> >> I can go this route if there is consensus.
> >>
> >> Marco
> >>
> >>
> >>
> >> _______________________________________________
> >> fenics mailing list
> >> [email protected]
> >> http://fenicsproject.org/mailman/listinfo/fenics
> _______________________________________________
> fenics mailing list
> [email protected]
> http://fenicsproject.org/mailman/listinfo/fenics
>
_______________________________________________
fenics mailing list
[email protected]
http://fenicsproject.org/mailman/listinfo/fenics
