dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Thu, Sep 11, 2008 at 07:35:30PM +0100, Garth N. Wells wrote:
> 
> 
> 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

I guess it can be useful to have it as a class if we want to attach
something else, like boundary conditions. A FunctionSpace could be the
above three things, and then a set of constraints. But I don't know
exactly how this would fit in with the assembly since we apply bcs to
the whole system.

Having a FunctionSpace class might simplify things like eliminating
dofs (and putting them back in again).

-- 
Anders

Attachment: signature.asc
Description: Digital signature