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. > >> 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. > > 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 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. > >>> Any help with getting the remaining demos and the Python interface > >>> working again appreciated. > >> I could probably help with getting the python interface up and going, at > >> least > >> with the metaclass stuff discussed earlier. ok! -- Anders
signature.asc
Description: Digital signature
_______________________________________________ DOLFIN-dev mailing list [email protected] http://www.fenics.org/mailman/listinfo/dolfin-dev
