On 21/11/2014 21:40, Garth N. Wells wrote:
On 21 Nov 2014, at 12:29, Chris Richardson <[email protected]>
wrote:
-------- Original Message --------
Subject: Re: [FEniCS] eval in parallel
Date: 21/11/2014 12:27
From: Chris Richardson <[email protected]>
To: "Garth N. Wells" <[email protected]>
On 21/11/2014 11:57, Garth N. Wells wrote:
On Fri, 21 Nov, 2014 at 11:52 AM, Mikael Mortensen
<[email protected]> wrote:
On 20 Nov 2014, at 13:08, Jan Blechta <[email protected]>
wrote:
On Thu, 20 Nov 2014 11:33:26 +0100
Mikael Mortensen <[email protected]> wrote:
On 20 Nov 2014, at 10:54, Chris Richardson <[email protected]>
wrote:
There has been some discussion on bitbucket about how to best
support evaluation and interpolation in parallel.
At present, user code like this:
mesh = UnitSquareMesh(10, 10)
Q = FunctionSpace(mesh, "CG", 1)
F = Function(Q)
F.interpolate(Expression("x[0]"))
print F(0.2, 0.2)
crashes in parallel. e.g. with mpirun -n 2
*** Error: Unable to evaluate function at point.
*** Reason: The point is not inside the domain. Consider setting
"allow_extrapolation" to allow extrapolation. *** Where: This
error was encountered inside Function.cpp.
Clearly "allow_extrapolation" is not needed, and this is actually
confusing to users.
Agreed, allow_extrapolation is very confusing. It should not be
thrown as an option, at least not in parallel.
Please, do not remove it. allow_extrapolation is useful for
circumventing failing floating-point-based evaluation of
Cell::inside(Point& p) for p interior point near facet of the cell.
The
problem is covered here
https://bitbucket.org/fenics-project/dolfin/issue/296.
Floating point robustness should probably be handled inside the
collision routines and not by flags in Function::eval. Nevertheless,
it is very misleading to throw a suggestion to allow_extrapolation
in parallel. I think we should add something like
if (allow_extrapolation &&
MPI::size(_function_space->mesh()->mpi_comm()) == 1)
or simply not allow setting allow_extrapolation to true in parallel.
Chris, I think I’m leaning towards a brand new global_eval rather
than modifying the existing eval. But I have no strong opinion on
this.
The business of 'extrapolation' does need fixing, see also
https://bitbucket.org/fenics-project/dolfin/issue/198.
I would also lean towards separate functions for collective vs local
eval operations. We can mark clearly in the documentation which is
collective.
It would be good if a user can still use:
val = F(x, y)
to evaluate at a point, in python, in parallel. That can be fixed up
behind the scenes, of course. Should such a call return the correct
answer on
all processes, or just on the processes holding the values?
An issue is that this would be a collective operation. This could
cause existing programs to deadlock in parallel.
I can see that eval cannot be always collective... so it's just a
question of which interfaces to it should be, and which should not.
I thought that a user code which asks for the value at a point is most
likely collective?
OK, but I suppose a counterexample might be:
for c in cells(mesh):
print F(c.midpoint())
So what is the right solution? I guess we could start with
F.eval_global(Point)
and see how useful it turns out to be.
Chris
_______________________________________________
fenics mailing list
[email protected]
http://fenicsproject.org/mailman/listinfo/fenics
