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