dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Thu, Sep 11, 2008 at 03:59:18PM +0100, Garth N. Wells wrote:
> 
> 
> Anders Logg wrote:
> > On Thu, Sep 11, 2008 at 03:02:36PM +0100, Garth N. Wells wrote:
> >>
> >> Anders Logg wrote:
> >>> On Thu, Sep 11, 2008 at 02:51:41PM +0100, Garth N. Wells wrote:
> >>>> Martin Sandve Alnæs wrote:
> >>>>> I don't agree, isn't the point that several DiscreteFunctions can
> >>>>> share a FunctionSpace?
> >>>>>
> >>>> Yes, but a dof map doesn't define a function space.
> >>>>
> >>>> Garth
> >>> I think the dof map should be in the FunctionSpace, that way several
> >>> functions may share the dof map (which may take time to compute if we
> >>> want to do some reordering).
> >>>
> >>> Two functions in the same function space share the mesh, the element
> >>> and the dof map (these three define the space) but each function has
> >>> its own vector.
> >>>
> >> My point isn't that a DofMap won't shared, it's that it's not part of 
> >> the definition of a function space.
> > 
> > It is part of the function space if we say that a function space is
> > defined by a particular basis:
> > 
> >   V = span{\phi_i}
> > 
> > To define the basis, we need the dof map.
> > 
> 
> The dof map is needed to tie the finite element basis + domain (mesh) to 
> a matrix/vector.

Not only that. It's needed to define the global function space. If we
just have the elements, we don't know the function space. P_k and DG_k
have the same finite element, but different dof maps.

> >> It always possible that two discrete functions which are equivalent can 
> >> share a mesh and finite element (which defines the function space), but 
> >> have different vectors and dof maps.
> > 
> > Is that something we will encounter much? 
> 
> Probably not, but it shows why the dof map doesn't belong in FunctionSpace.
> 
> On reflection, FunctionSpace is pretty simple, so I don't actually see 
> why we need it. If we want to stress that a group of objects belong 
> together in the definition of a discrete function, why not just use a 
> tuple in DiscreteFunction?

We've discussed before that we want to reuse dof maps and share them
between elements. It would be convenient to include the dof map in a
function space and then we only need to worry about one thing that is
shared between functions, namely the function space. This seems very
natural: one function space V and many functions v, u, w in V.

We've also discussed this for UFL, to define functions for a given
function space, rather than for a given finite element:

  V = FunctionSpace("Lagrange", "triangle", 1)
  v = TestFunction(V)
  u = TrialFunction(V)

This would be the offline version used in .ufl files (form files).
For PyDOLFIN, we can add the mesh and have cross-inheritance from UFL
and DOLFIN C++ and do

  V = FunctionSpace(mesh, "Lagrange", "triangle", 1)
  v = TestFunction(V)
  u = TrialFunction(V)
  f = Function(V) # Vector created automatically

-- 
Anders

Attachment: signature.asc
Description: Digital signature