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
