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...
Chris
class GenericFunction
{
public:
// Known cell on process, non-collective call:
// Note: If we allow multiple x within cell,
// the implementation can be vectorized
virtual void noncollective_eval(v, x, cell) const = 0;
// Unknown cell, collective call:
// Note: there could be a non-collective version with
// unknown cell, which would fail if the point(s) are not local
void collective_eval(v, x) const // not virtual!
{
// Note: If we allow multiple x, we can reduce
// the number of mpi calls significantly in here
cell = find cell x is on
if on this process:
noncollective_eval(v, x, cell)
send v
else:
receive v
// vectorized would be something like his:
find all (x,cell) on this process
non_collective_eval(v,x,cell) for all local points
send and receive all v
}
};
class Function: public GenericFunction
{
public:
virtual void noncollective_eval(v, x, cell) const
{
dofs = restrict to cell
fe = evaluate basis in x on cell
v = sum dofs*fe
}
};
class Expression: public GenericFunction
{
public:
virtual void noncollective_eval(v, x, cell) const = 0;
};
class MyExpression: public Expression
{
public:
virtual void noncollective_eval(v, x, cell)
{
v = user defined code (may involve e.g. cell number lookup)
}
}
I don't really see why we need more than one collective and one
non-collective eval.
Martin
On 3 September 2015 at 11:54, Chris Richardson <[email protected]>
wrote:
This is a mailing list continuation of a bitbucket discussion:
https://bitbucket.org/fenics-project/dolfin/pull-requests/240/interpolation-improvements
[1]
I have been trying to clean up Function::interpolate() a bit.
The following issues have come up:
1. The chain of function calls is long and complex:
e.g. to interpolate in the general case from another Function v:
- this is just an illustrative sketch, with details removed:
Function::interpolate(GenericFunction& v)
FunctionSpace::interpolate(Vector& coeffs, const GenericFunction&
v)
Iterate over cells {
v.restrict(cell_coeffs, element, cell, coords, ufc_cell)
Function::restrict(w, element, cell, coords, ufc_cell)
...
restrict_as_ufc_function(w, element, dolfin_cell, coords,
ufc_cell)
element.evaluate_dofs()
ufc_element->evaluate_dofs()
ufc_function::evaluate(vals, coords, ufc_cell)
GenericFunction::evaluate(vals, coords, ufc_cell)
GenericFunction::eval(vals, x, ufc_cell)
GenericFunction::eval(vals, x)
Function::eval(vals, x)
{
id =
mesh.bb_tree.compute_first_entity_collision(point)
Cell (mesh, id)
Function::eval(val, x, cell, ufc_cell)
restrict(coeffs, element, cell, coords, ufc_cell)
element.evaluate_basis()
values += coeffs * basis
}
2. Many calls use ufc_cell and dolfin_cell with the same data. This
looks bad, and is bad. Can we find a way to transition away from
needing both?
3. In parallel, this model totally breaks down, as it is only at
the very bottom that we realise the point is 'off process' and we
need a collective operation to get it.
_______________________________________________
fenics mailing list
[email protected]
http://fenicsproject.org/mailman/listinfo/fenics [2]
Links:
------
[1]
https://bitbucket.org/fenics-project/dolfin/pull-requests/240/interpolation-improvements
[2] http://fenicsproject.org/mailman/listinfo/fenics
--
Chris Richardson
BP Institute
Madingley Road
Cambridge CB3 0EZ
_______________________________________________
fenics mailing list
[email protected]
http://fenicsproject.org/mailman/listinfo/fenics
