dolfin team mailing list archive

[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

> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> DOLFIN-dev mailing list
> DOLFIN-dev@xxxxxxxxxx
> http://www.fenics.org/mailman/listinfo/dolfin-dev

Attachment: signature.asc
Description: OpenPGP digital signature