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