dolfin team mailing list archive

["Martin Sandve Alnæs" <martinal@xxxxxxxxx>]

2008/11/29 Anders Logg <logg@xxxxxxxxx>:
> On Sat, Nov 29, 2008 at 04:19:46PM +0100, Martin Sandve Alnæs wrote:
>> 2008/11/29 Anders Logg <logg@xxxxxxxxx>:
>> > On Sat, Nov 29, 2008 at 03:09:53PM +0100, Martin Sandve Alnæs wrote:
>> >> How do you intend to handle (sub)functions in a mixed space?
>> >> Currently I don't see how the function space stuff generalizes
>> >> to even simple mixed spaces.
>> >>
>> >> Take this simple example in a pure form language (FFC or UFL):
>> >>     element1 = VectorElement("CG", "triangle", 2)
>> >>     element2 = FiniteElement("CG", "triangle", 1)
>> >>     mixed_element = element1 + element2
>> >>     f, g = Functions(mixed_element)
>> >>
>> >> Now in PyDOLFIN, would a function space be defined by (reusing the elements):
>> >>     space1 = FunctionSpace(mesh, element1)
>> >>     space2 = FunctionSpace(mesh, element2)
>> >>     mixed_space1 = space1 + space2
>> >>
>> >> or:
>> >>     mixed_space2 = FunctionSpace(mesh, mixed_element)
>> >>
>> >> and would the functions in this space be
>> >>     f, g = Functions(mixed_space)
>> >> or
>> >>     fg = Function(mixed_space)
>> >>     f, g = fg.sub(0), fg.sub(1)
>> >> ?
>> >> Neither of these two definitions of (f, g) works out.
>> >
>> > It should be just as in your first example, but replace Element with
>> > FunctionSpace:
>> >
>> >  V1 = VectorFunctionSpace(mesh, "CG", 2)
>> >  V2 = FunctionSpace(mesh, "CG", 1)
>> >  mixed_space = V1 + V2
>> >  f, g = Functions(mixed_space)
>> >
>> >> The syntax
>> >>     f, g = Functions(mixed_space)
>> >> doesn't work, since ufl.Functions does not return ufl.Function objects,
>> >> but ufl.Indexed objects that refer to subexpressions of ufl.Function objects.
>> >>
>> >> The syntax
>> >>     fg = Function(mixed_space)
>> >>     f, g = fg.sub(0), fg.sub(1)
>> >> would require that sub returns something that is a subclass of what
>> >> ufl.Functions returns (ufl.Indexed) and at the same time is a dolfin.Function.
>> >
>> > It should be enough to just define the following function:
>> >
>> > def Functions(V):
>> >    v = Function(V)
>> >    return tuple(v[i] for i in range(V.num_subspaces()))
>>
>> In pure UFL, given
>>     v = ufl.Function(mixed_element)
>> then
>>    v[i]
>> is not subfunction i, but value component i of v.
>>
>> You can't override v[i] in dolfin.Function, then indexing of vector
>> functions won't work.
>
> Is it really necessary to have Functions()? It should be enough with
> TestFunctions() and TrialFunctions().

Won't the problem be the same with those?

> For extraction of subfunctions from computed solutions, we need to use
> what is already implemented in the C++. It is not necessary that what
> comes back is a subclass of ufl.Functions. It will simply be a new
> function (with copies of the values) just as in C++.
>
> This means that there will be a difference between the following two
> statements:
>
>  w = Function(mixed_space)
>
>  # Extract two independent Functions with their own vectors
>  (u, p) = w.split()

These can't be used in a form, and you don't want to separate
functions in the form definition from assembly coefficient functions,
so what do you mean?

>  # Extract UFL expressions, both sharing the same global vector
>  u = w[0:2]
>  p = w[2]

This can still be achieved using "u, p = ufl.Functions(mixed_space)",
or we can have a splitting function "u, p = split(w)".

> The first versions of u, p can be plotted and saved to file, but not
> the second versions (for the same reason that we can't save grad(u)
> directly to file).

Also the first versions can't be used in a form, or you'll have to solve
the exact same problem I began with in this thread.

-- 
Martin