dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Fri, Oct 31, 2008 at 10:05:19AM +0000, 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?

DOLFIN will check that the space is correct and report and error
otherwise.

-- 
Anders


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



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

Attachment: signature.asc
Description: Digital signature