On 03/09/2015 15:54, Martin Sandve Alnæs wrote:
On 3 September 2015 at 16:50, Garth N. Wells <[email protected]> wrote:
On 3 September 2015 at 14:42, Chris Richardson <[email protected]>
wrote:
On 03/09/2015 14:10, Martin Sandve Alnæs wrote:
Part of the complexity in this chain steps from the numerous dolfin
signatures. As discussed before, these also need cleanup to clarify
collective/non-collective operations. While at it, we could also
vectorize on x by allowing a number of coordinates wherever there's
an
x argument in the code below.
For a moment I'd like to ignore the ufc/ffc parts and figure out
how
many eval signatures we really need in dolfin? In particular to
resolve the collective/non-collective part. Then we can design the
callback mechanism to match the ideal dolfin design.
Here's one take (dodging the type of 'cell'):
Is it as simple as just having a "collective" and "non_collective"
eval?
Typically, processes will iterate over some set of "local" points,
asking for evaluations ( - OK, they may be "local" on one mesh, but
not another).
When the point is not "on process", the process needs to get it,
somehow.
But all the other processes are unaware - they are thinking about
different points.
It is quite unusual for all processes to want to evaluate the same
point at the same time, for a simple collective operation.
My thought was that we would have to store up a list of points, and
then do a collective operation to resolve all the cross-process
evaluations.
Or maybe I have missed something...
My impression is that Martin is just suggesting the we split evals
into non-collective and collective 'groups', and have as few versions
of eval in each group. With fewer evals, we have few code paths to
think about.
The interface for collective evals is orthogonal to this, and
something we need to look closely at.
Garth
Exactly. The collective variants of eval will always end up calling
non-collective variants of eval but never the other way around.
Also the collective eval variants won't be virtual functions.
The evaluation of a GenericFunction on cells that are known to be
on the local process differs between Function and Expression, but
can be handled with a single signature "virtual void eval(v,x,cell)
const = 0;"
in GenericFunction, implemented by Function and by the users subclass
of Expression. The only thing we need to clean up there in the
ufc::function
is the ufc::cell vs dolfin::cell.
For a collective eval over multiple points, I currently see only two
variants:
a) each process pass a different set of point(s) and wants the
corresponding results
b) each process actually pass the same point(s) and wants all results
In both cases there is first communication of 'who owns which points',
then each process makes calls to the non-collective evals for its own
points,
then the results are communicated back to the right place.
I believe a) is what Chris was talking about as the most common
operation.
OK, makes sense. I suppose I am thinking ahead to an implementation of
'interpolate',
where fitting the collective calls in might be tricky.
Chris
--
Chris Richardson
BP Institute
Madingley Road
Cambridge CB3 0EZ
_______________________________________________
fenics mailing list
[email protected]
http://fenicsproject.org/mailman/listinfo/fenics
