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
> [email protected]
> http://www.fenics.org/mailman/listinfo/dolfin-dev
_______________________________________________
DOLFIN-dev mailing list
[email protected]
http://www.fenics.org/mailman/listinfo/dolfin-dev
