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? 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. Does anyone see another way to get around this? Martin
_______________________________________________ fenics mailing list [email protected] http://fenicsproject.org/mailman/listinfo/fenics
