dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Sat, Nov 29, 2008 at 06:46:58PM +0100, Martin Sandve Alnæs wrote:
> 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?

Why? It works fine with the current FFC implementation. Test and trial
functions don't really care about anything else than the element so
they will in principle just be "pure form compiler objects".

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

Why can't they be used in a form? It works fine today. One should be
able to use any Function in a form.

> >  # 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)".

There are two different versions: one that works on the global vector
level (creating new functions) and one that works on the form compiler
level (using ufl.split to create new UFL expressions).

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

Both u and p will be a Function so one should be able to plug them
into any form just like other coefficients.

-- 
Anders

Attachment: signature.asc
Description: Digital signature