dolfin team mailing list archive

[kent-and@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

Agree. If we are to employ negative indices on bc this could be a way to
do it.

Is the name FunctionSpace the best? I mean also a finite element is a
function space.

But I think the structure is handy.

Kent