← Back to team overview

dolfin team mailing list archive

Re: Redesign almost finished

 

On Friday 31 October 2008 11:05:19 Garth N. Wells wrote:
> Johan Hake wrote:
> > 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?
>
> No, because there are never more that two, we can use the meaningful
> names "Test" and "Trial" and they are always the first arguments to the
> Form constructor.
>
> A possible solution along these lines was discussed last week which
> involved giving PoissonBilinearFormCoefficientSpace1, etc, names which
> involved the name used in the FFC input.

Ok.

If we have the same trial and test space, but different functionspaces. Then I 
suppose one only would like to create one space for the former. How would 
this be done?

  PoissonTestSpace TestV(mesh);
  PoissonBilinearForm(TestV,TestV);
  
or do we have to instantiate both?

  PoissonTestSpace  TestV(mesh);
  PoissonTrialSpace TrialV(mesh);
  PoissonBilinearForm(TestV,TrialV);
 
Johan

> Garth
>
> >>> 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
> > _______________________________________________
> > DOLFIN-dev mailing list
> > DOLFIN-dev@xxxxxxxxxx
> > http://www.fenics.org/mailman/listinfo/dolfin-dev




Follow ups

References