dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Mon, Sep 08, 2008 at 09:04:22AM -0400, Shawn Walker wrote:
> 
> 
> 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.
> >>
> >
> > 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.

It needs to change anyway.

-- 
Anders

Attachment: signature.asc
Description: Digital signature