dolfin team mailing list archive

[Johan Hake <hake@xxxxxxxxx>]

On Friday 31 October 2008 09:38:38 Anders Logg wrote:
> On Fri, Oct 31, 2008 at 07:57:52AM +0000, Garth N. Wells wrote:
> > Martin Sandve Alnæs wrote:
> > > 2008/10/30 Johan Hake <hake@xxxxxxxxx>:
> > >> On Thursday 30 October 2008 19:20:06 Anders Logg wrote:
> > >>> Most things are now in place, finally. At least we can run the
> > >>> Poisson demo again... :-)
> > >>>
> > >>> Anyway, take a look at demo/pde/poisson/main.cpp and see what you
> > >>> think. I think it looks pretty good, but please report if you have
> > >>> any ideas for further improvements of the interface while we're at
> > >>> it.
> > >>
> > >> It looks nice, but I see some magic which I wish you can shed some
> > >> light on.
> > >>
> > >> The introduction of PoissionFunctionSpace is not clear for me. Why do
> > >> we have to instantiate the forms with it?
> > >
> > > Such that the Forms can use the same FunctionSpaces as are used in the
> > > rest of the code, while the user stays in control of their allocation.
> > > In particular, DofMaps needs to be shared between different parts of
> > > the code.
>
> In general the function spaces are named
>
>   PoissonBilinearFormArgumentSpace0
>   PoissonBilinearFormArgumentSpace1
>
>   PoissonBilinearFormCoefficientSpace0
>   PoissonBilinearFormCoefficientSpace1
>   PoissonBilinearFormCoefficientSpace2
>   PoissonBilinearFormCoefficientSpace3
>   ...
>
> Then, if all forms appearing in a form file (both a and L) share the
> same test space (which is natural), then an additional space will be
> generated:
>
>   PoissonTestSpace
>
> Same for the trial space:
>
>   PoissonTrialSpace
>
> If all spaces in the form are the same, then a common space will be
> generated:
>
>   PoissonFunctionSpace
>
> As noted by Martin, this allows a user to control the level of reuse
> of function spaces.

Ok.

> > >> In the form file the two forms L and a are defined. These are then
> > >> reflected in the main.cpp file as before. This is intuitive. But where
> > >> does the PoissonFunctionSpace come from? I as a user has not defined
> > >> it in the form file.
> > >>
> > >> It might help if we introduce the notion of FunctionSpace in FFC/UFL.
> > >> Then some of the magic would disapear I think.
> > >
> > > This could reinforce the problem with circular dependencies I mentioned
> > > earlier. I don't see that anyone has adressed that issue.
> > >
> > >> The talk about a Function always knowing its Space was clear, you can
> > >> always plot it, and so on. But then the introduction of the "magic"
> > >> dedication of FunctionSpace broke that, and also made the actuall
> > >> function of FunctionSpace more blurry.
> > >>
> > >> Intuitively I would prefer:
> > >>
> > >>  ...
> > >>  PoissonFunctionSpace V(mesh);
> > >>
> > >>  Source f(V);
> > >>  Flux g(V);
> >
> > The problem here is that f and g may come from a space other than V. The
> > difficulty for a user is that it's hard (and error prone) to create the
> > FunctionSpaces and associate them with the right Functions.

Won't 

   PoissonBilinearForm a(V,V);
   PoissonLinearForm L(V);

be as error prone with different test and trial spaces too?

> > Garth
> >
> > >>  PoissonBilinearForm a();
> > >>  PoissonLinearForm L();
> > >>
> > >>  L.set_f(f); L.set_g(g);
> > >>  ...
> > >>
> > >> If this is not possible or if it is but we do not want it, please
> > >> inform me.
> > >
> > > We would still need
> > >
> > >   PoissonBilinearForm a(V,V);
> > >   PoissonLinearForm L(V);
> > >
> > > Which looks, I agree, a bit misleading since you cannot
> > > pass any other function spaces to these forms.
>
> Yes, it's misleading. We could possibly modify the code generation to
> something like
>
>   PoissonBilinearForm a(mesh);
>   PoissonLinearForm a(mesh);

and then create the test and trial space with the mesh? Won't it be difficult 
to share the dofmaps with other parts of the code then?

I think I thought it was strange because I have taken the dofmaps (or function 
space if you like) for the trial and test space for granted. With the new 
design this is more explicit and good.

> and let the forms themselves create the right function space. The problem
> then is that it will complicate reuse of function spaces.
>
> The same thing goes for initialization of Functions with or without V.
> Johan asks above about initialization of Functions with V:
>
>   Source f(V);
>   Flux g(V);
>
> This is indeed possible and will lead to a reuse of V also for f and g.
> What happens when one does
>
>   a.f = f;
>
> is that a check is made whether f has a function space and if not a
> FunctionSpace is created and attached to f. So if one has already done
> f(V), that space will be reused.

Good!


Johan