The generated code depends on the order of construction of the ufl.Coefficients/dolfin.Functions it depends on but not the exact count (id) values. The same pattern applies for Mesh/Domain, since the mesh id cannot be part of the generated code there will be a mapping in the form preprocessing from domain/mesh label/id to a form specific mesh numbering, analoguous to the form specific coefficient numbering.
In other words, today code regeneration is not triggered by this difference: f = Function(V) h = Function(V) assemble(f*h*dx) vs (ordering of f and h is the same): f = Function(V) g = Function(V) h = Function(V) assemble(f*h*dx) but by this (ordering of f and h changed): h = Function(V) f = Function(V) assemble(f*h*dx) the same would apply with mesh construction order: mesh1 = Mesh(...) # mesh1.id() < mesh2.id() mesh2 = Mesh(...) V1 = FunctionSpace(mesh1, ...) V2 = FunctionSpace(mesh2, ...) f1 = Function(V1) f2 = Function(V2) assemble(f1*f2*dx(mesh1)) i.e. a recompilation would be triggered on this: mesh2 = Mesh(...) # mesh1.id() > mesh2.id() mesh1 = Mesh(...) ... same but not this: some_variable = ... # doesn't change mesh1.id() < mesh2.id() mesh1 = Mesh(...) mesh3 = Mesh(...) # doesn't change mesh1.id() < mesh2.id() mesh2 = Mesh(...) ... same A concequence of this is that we'll only use Domain in .ufl files and Mesh in dolfin programs, similar to FiniteElement vs FunctionSpace. Martin On 28 January 2014 14:50, Johan Hake <[email protected]> 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. >> > > 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 >> >> >
_______________________________________________ fenics mailing list [email protected] http://fenicsproject.org/mailman/listinfo/fenics
