← Back to team overview

dolfin team mailing list archive

Re: Function and DofMap

 



On Mon, 8 Sep 2008, Johan Hoffman wrote:

2008/9/8 Dag Lindbo <dag@xxxxxxxxxx>:
Anders Logg wrote:
There seems to be a problem (among many) with the current design of
the Function classes (see thread "evaluating higher order mesh
function").

In particular, the finite element is missing in DiscreteFunction. My
suggestion would be to just add it and let a DiscreteFunction consist
of the following four items which are always available:

  mesh, x, dof_map, finite_element

Is this enough, and what other issues to we need to fix?


I'm not sure I agree that the dof map and finite element should be owned
by the discrete function. There was a great suggestion from Martin, in a
thread "Abstraction idea" from 06/05/2008, to create a class
FunctionSpace where the mesh, element and dof_map(s) are aggregated.
Citing Martin:
U = FunctionSpace(mesh, dofmapset, form, 0) # or something similar
u = Function(U)
v = Function(U)

This seems a solid approach to me since it would provide a way of
encapsulating the mathematical formulation of the problem, which is more
or less const and likely to be reused by many discrete functions in a
solver.

It seems to me that there is an obvious risk that a lot of redundant
initialization would occur if all discrete functions should own their
own elements and dof maps. There seems to be consensus that the mesh
should be "global" for efficiency reasons, so why not treat the function
space the same way?

Is there a problem with an approach where the funciton _always_ owns the
vector and _never_ owns the function space (and mesh)? A very strict
design would avoid shared/smart pointers, provide a comprehensible user
interface and probably help the parallellization effort.

/Dag

If the Function always owns the vector, there are cases you'll have to
make unneccessary copies of a vector, in particular such scenarios
may occur when trying to combine dolfin with something else.

If the Function never owns the function space, it must always be
constructed explicitly by the user. This may not be a bad thing.
However, if the Function is loaded from a file, nobody owns the
FunctionSpace.

--
Martin

Conceptually, I agree with Dag (and Martin?) that it is natural to have
global function spaces. And if the explicit construction of such spaces
can be made simple, it may not be a bad thing but a natural part in
setting up the mathematical problem. And I do not really like that
functions should be initialized from a form, which defines an equation.

I agree very much with this last sentence.

I think one idea was to not force less mathematically oriented users to
worry about function spaces. I guess there are (at least) 2 types of
functions: (i) functions part of the form, and (ii) functions not part of
the form, but used in pre/postprocessing etc.

Do you really think it is a huge leap for users to know what a function space is? They don't need to know functional analysis.

For (i) it may be natural to construct the function space from the form,
and for (ii) it may be convenient in some cases, but it is not really
obvious that this is the best solution.

Maybe an explicit construction of a function space can come with a
default, such as a nodal basis of piecewise linears?

Note: it must be possible to update the function space if the mesh changes. I guess this would be automatic since the function space references the mesh. Assuming the mesh does not change topology; then I guess there would be some interpolations happening, which could be done by a higher level module or the user.

This thread started from me trying to add a Function to the MeshGeometry class for use in higher order shaped elements. Maybe it would be easier to change that, than the whole Function setup? Unless the Function class needs to change anyway.

- Shawn


Follow ups

References