dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Fri, Oct 31, 2008 at 10:25:58AM +0000, Garth N. Wells wrote:
> 
> 
> Johan Hake wrote:
> > 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);
> > 
> 
> The above will work.
> 
> Is there a nifty name we could use for when the test and trial spaces 
> are the same? Could we still use PoissonFunctionSpace in this case, even 
> if the there a coefficient functions from other spaces? This way only 
> FunctionSpace would need to be declared.
> 
> Garth

One option would be to use FunctionSpace only for common test and
trial spaces and don't look at the coefficient spaces. These are
assigned automatically anyway (unless the user really wants to specify
them).

-- 
Anders


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

Attachment: signature.asc
Description: Digital signature