Possibly. Not sure but I don't like the sound of it. Martin
On 28 January 2014 14:57, Garth N. Wells <[email protected]> wrote: > On 2014-01-28 13:50, Johan Hake wrote: > >> On Tue, Jan 28, 2014 at 10:09 AM, Martin Sandve Alnæs >> <[email protected]> wrote: >> >> There's a design pattern used a few places to integrate ufl and the >>> cpp part of dolfin. The problem it solves is to create ufl objects >>> for dolfin objects originating from the C++ layer. I'd like to >>> discuss that a little bit. I'll try to keep it simple. >>> >>> The pattern is as follows: >>> >>> 1) A ufl finite element object implements __repr__ properly, such >>> that eval(repr(obj)) == obj. >>> >>> 2) This repr string is stored by ffc to be returned by the generated >>> ufc::finite_element::signature() function. >>> >>> 3) When dolfin gets a C++ object from the C++ layer and wants to >>> make a full featured python object of it, it calls >>> eval(element.signature()) to construct a fresh ufl object. >>> >>> Question: How many places in dolfin is this pattern used? Is it only >>> in functionspace.py? >>> >> >> functionpsace.py was the only file that came up when I grepped for >> 'eval(' and 'exec' in the dolfin python interface, so I guess yes. >> >> This seems to work great but puts a design constraint on ufl, namely >>> that finite element objects cannot carry >>> >>> A) additional basic information, such as a label identifying the >>> mesh it is defined on, because that will trigger recompilation for >>> every mesh >>> >>> B) references to dolfin data, such as references to subdomains via a >>> ufl.Domain object. >>> >>> I see a few problems arising from this: >>> >>> I) Both A and B blocks some features from my upcoming ufl domains >>> infrastructure commit. I can accept B and remove some non-critical >>> features. But A is a blocker. >>> >>> II) B may be a blocker for high order elements because we cannot >>> reference high order geometry data via the ufl element. >>> >>> III) A means we cannot make symbolic ufl representations of >>> functions f and g aware of them living on two different meshes. This >>> is a crucial point in my upcoming domains infrastructure and. How do >>> we solve that? If functionspace.py is the only place this happens I >>> think we can get away with something like >>> >>> eval(element.signature()).reconstruct(domain=mesh.ufl_domain()) >>> >>> but that means domain labels will always have to be created >>> automatically from the mesh id. >>> >> >> > The mesh id is not necessarily the same on different processes. Could this > cause a problem? > > Garth > > I think this looks elegant :) >> >> We only need this when we are turning a cpp.FunctionSpace into a >> dolfin.FunctionSpace and then we have the mesh. >> >> The question of whether having Mesh::id as the domain label is >> acceptable of not depends on if the user need to relate to the label. >> Should it be explicitly written in form declarations or just >> implicitly used by the dolfin/ufl layer. If it is the latter I think >> it is acceptable but if it is the latter it is not, as the label/id of >> the Domain/Mesh will change if a Variable is instantiated before the >> mesh. If the latter is the case we probably need to have some sort of >> cached map between Mesh::id and Domain labels. >> >> Johan >> >> Does anyone see another way to get around this? >>> >>> Martin >>> _______________________________________________ >>> fenics mailing list >>> [email protected] >>> http://fenicsproject.org/mailman/listinfo/fenics [1] >>> >> >> >> >> Links: >> ------ >> [1] http://fenicsproject.org/mailman/listinfo/fenics >> >> >> _______________________________________________ >> fenics mailing list >> [email protected] >> http://fenicsproject.org/mailman/listinfo/fenics >> >
_______________________________________________ fenics mailing list [email protected] http://fenicsproject.org/mailman/listinfo/fenics
