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
