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 <[EMAIL PROTECTED]>: > >>>>> 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 > > [email protected] > > http://www.fenics.org/mailman/listinfo/dolfin-dev _______________________________________________ DOLFIN-dev mailing list [email protected] http://www.fenics.org/mailman/listinfo/dolfin-dev
