On 31/05/16 10:08, Daniel Ruprecht wrote:
Hi Lawrence,
We set up the problem according to your info and it works initially.
However, as we move meshA, at the some point all the results from
solution_A.at(Xs, dont_raise=True)
become None's and we have absolutely no idea why this is happening -
it works for about 5 time steps and then it doesn't anymore. I
attached a small example reproducing the problem and a short video
showing what is happening.
To illustrate, we print out
solution_A.at((0.0, 2.2), dont_raise=True)
and the point is marked in the video. For the first three steps, the
result is the correct 5.0 (an arbitrary value we assign to the
solution on meshA at the moment) but after that it becomes None, even
though the point is still clearly ``in contact'' with meshA.
Any ideas what is happening here?
Yes. The point evaluation stuff doesn't currently deal with moving
meshes. We build an rtree for point queries, but only do that once.
So after a while, once you've moved the mesh the bounding boxes are in
the wrong place.
To fix this, every time you move the mesh, you can do:
del meshA.spatial_index
If you report a bug, we will track it and add a public API for
clearing the rtree.
A few comments on your code.
Please, where possible, use interpolation of UFL expressions (rather
than C strings) as described here:
http://firedrakeproject.org/interpolation.html#ufl-expressions
This gets you much better type checking.
Additionally, there's no need to do the WithGeometry dance for u_A,
you're not changing the mesh's coordinate function space, only its values.
Cheers,
Lawrence
_______________________________________________
firedrake mailing list
firedrake@imperial.ac.uk
https://mailman.ic.ac.uk/mailman/listinfo/firedrake