Comment 8 for bug 1155271

On Thu, 28 Mar 2013 14:07:08 -0000
Garth Wells <email address hidden> wrote:
> On 28 March 2013 21:58, Jan Blechta <email address hidden>
> wrote:
> > On Thu, 28 Mar 2013 04:18:08 -0000
> > Garth Wells <email address hidden> wrote:
> >> On 28 March 2013 06:27, Jan Blechta <email address hidden>
> >> wrote:
> >> > I guess this bug also affects mesh moving facility in
> >> > dolfin/ale/*
> >> > dolfin/mesh/MeshSmoothing
> >> > something else ?
> >> >
> >> > I guess something like
> >> > mesh.intersection_operator().clear();
> >> > should be added to the end of every routine which moves mesh by
> >> > writing to array std::vector<double>& x = mesh.geometry().x();
> >> > (which they do)
> >> >
> >>
> >> I suggested a while go that the intersection code should be removed
> >> from Mesh to keep Mesh simple (just a data structure, limited
> >> algorithms). The user can create an intersection object. This would
> >> fix this caching issue and make the user responsible for managing
> >> the updating/clearing of the intersection object if the user
> >> changes the Mesh.
> >>
> >> Issue with Jan's proposal is that it is very likely that code will
> >> be added in the future and the necessary clear() won't be added.
> >> This isn't good for code maintainability.
> >
> > Ok, I agree. Then I propose that an advice about a need of updating
> > intersection object is added to docstrings of mesh.geometry.x(),
> > mesh.coordinates(), mesh.move(), mesh.snap_boundary(),
> > mesh.smooth(), ALE::*, MeshSmoothing::*, HarmonicSmoothing::*, ...
> >
> > If this seems unmaintainable to you as well, do you have something
> > more clever? User has no clue that some backend objects needs some
> > special treatment. Yes, I know, it's written in
> > mesh.intesection_operator().clear() docstring but who reads it when
> > moving mesh?
> >
>
> So long Mesh data is mutable, there is no rock solid solution. By
> making a user construct a MeshIntersection object, at least the
> dependency of the MeshIntersection object on the mesh is explicit.

I see. So do you consider adding something like
  /// WARNING: Intersection operator might need updating
  /// after moving mesh. Consider calling
  /// mesh.mesh_intersection().clear()
to all relevant docstrings as suitable provisional solution?

>
> Some checks using hashes could be added, but the performance penalty
> is probably unacceptable.

I'm not sure but I would guess it is unacceptable for poisson-like
benchmarks but negligible for real problems.

Jan

>
> Garth
>
> > Jan
> >
> >>
> >> Garth
> >>
> >>
> >> > --
> >> > You received this bug notification because you are a member of
> >> > DOLFIN Core Team, which is subscribed to DOLFIN.
> >> > https://bugs.launchpad.net/bugs/1155271
> >> >
> >> > Title:
> >> > function does not evaluate as expected after modifying mesh
> >> > coordinates
> >> >
> >> > To manage notifications about this bug go to:
> >> > https://bugs.launchpad.net/dolfin/+bug/1155271/+subscriptions
> >>
> >
>