On Mar 4, 2009, at 6:46 AM, Anders Logg wrote:
On Wed, Mar 04, 2009 at 09:26:43AM +0100, Johan Hake wrote:
On Wednesday 04 March 2009 08:35:23 Anders Logg wrote:
On Wed, Mar 04, 2009 at 08:09:00AM +0100, Martin Sandve Alnæs wrote:
On Wed, Mar 4, 2009 at 7:47 AM, Johan Hake <[email protected]> wrote:
Hello Marc!
This is a known bug. The two read in meshes are of course the
same but
during assemble, we extract one mesh from the same form. To be
able to
check that the mesh are the same we just compare the mesh
pointers.
Line 79 in dolfin/fem/Form.cpp. This is really not what we
want, as
your case will break this.
We have previously discussed this issue, can't find the email
now. Then
we thought of including some easily compiled mesh signature
that could
be used in the comparison.
If I understand this right, the actual problem isn't the pointer
comparison, but that the mesh is read twice. That shouldn't be
necessary
to do.
Martin
The reason it even works at all (to read in the two functions) is
that
DOLFIN happens to have precompiled elements for the cases in
question.
If it had been cubics, it wouldn't have worked.
For this reason, we've discussed removing the precompiled elements.
One would then (in C++) first need to create the FunctionSpace and
then read the degrees of freedom for the Function. The problem with
this is that the mesh needs to be read first, so instead of just
Function u("function.xml");
we get
Mesh mesh("mesh.xml");
MyFunctionSpace V(mesh);
Function u(V);
File file("udofs.xml");
file >> u;
We could add a constructor to Function to simplify this to
Mesh mesh("mesh.xml");
MyFunctionSpace V(mesh);
Function u(V, "udofs.xml");
The file udofs.xml would contain all the dofs of u stored as a
Vector.
I think this looks good. The user then have to know what
FunctionSpace the
Function is defined in, but that should be reasonable.
In Python, it would be possible to handle storing of general
functions
to file. The XML file could contain everything needed to dynamically
instantiate the function space at run-time (no need for precompiled
elements). But then the interfaces would be very different in C++
and
Python for reading/writing Functions.
We still need to hand the mesh, if no other comparision meassure
is developed.
So the above example would then look like
mesh = Mesh("mesh.xml")
u = Function(mesh,"udofs.xml")
which is not so much prettier I think.
Why not have the same interface for c++ and Python here? Then we
keep the
concept of first defining a FunctionSpace which is shared between
different
Functions. It will also make the constructor of Function
consistant, wrt
always getting a FunctionSpace as the first argument ;)
I agree. So does everyone agree on the following interfaces for C++
and Python:
Mesh mesh("mesh.xml");
MyFunctionSpace V(mesh);
Function u(V, "udofs.xml");
mesh = Mesh("mesh.xml")
V = FunctionSpace(mesh, family, degree)
u = Function(V, "udofs.xml")
This sounds good to me...and if I understand the intent, this could
reduce the xml file sizes considerably by not having to write the
mesh out everytime a function is written to xml file (e.g. for time-
dependent problems).
the only issue with this approach is that to reconstruct a function
from files, requires managing and reading in 2 (or potentially three)
separate files.
As a potential alternative, would it be possible to embed in a udofs
file, the name of the corresponding mesh file (and perhaps the
string for constructing "MyFunctionSpace" to generate the appropriate
function space call). If the mesh file has already been read in, it
doesn't need to be read in a second time...
I suppose this is similar to signatures and I can see some of the
issues with non-uniqueness, but the current fix still requires the
user to carefully manage their meshes. I actually have several
problems where I consider the interaction of functions on different
overlapping meshes, and there is a certain convenience to just
reading in one file to construct things.
But I'm not terribly picky, getting the larger issue of attaching
multiple discrete functions is more important to me (and it's easy
enough for me to keep track of a small handful of files per problem).
thanks for addressing this
cheers
marc
?
--
Anders
_______________________________________________
DOLFIN-dev mailing list
[email protected]
http://www.fenics.org/mailman/listinfo/dolfin-dev
----------------------------------------------------
Marc Spiegelman
Lamont-Doherty Earth Observatory
Dept. of Applied Physics/Applied Math
Columbia University
http://www.ldeo.columbia.edu/~mspieg
tel: 845 704 2323 (SkypeIn)
----------------------------------------------------
_______________________________________________
DOLFIN-dev mailing list
[email protected]
http://www.fenics.org/mailman/listinfo/dolfin-dev
