dolfin team mailing list archive

["Garth N. Wells" <gnw20@xxxxxxxxx>]

Anders Logg wrote:
> 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.

The definitions of P_k and DG_k are what define the space.

> > > > 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.

I agree that it's natural group whatever defines the space, but I'm 
raising the question should a class FunctionSpace or a tuple be used, e.g.

  tuple<Mesh*, FiniteElement*, DofMap*> function_space;

or

  typedef tuple<Mesh*, FiniteElement*, DofMap*> FunctionSpace;
  FunctionSpace function_space;

Garth

> 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
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> DOLFIN-dev mailing list
> DOLFIN-dev@xxxxxxxxxx
> http://www.fenics.org/mailman/listinfo/dolfin-dev