kent-and@xxxxxxxxx wrote:
Martin Sandve Alnæs wrote:
On Wed, Jan 7, 2009 at 3:09 PM, Garth N. Wells <gnw20@xxxxxxxxx> wrote:
Anders Logg wrote:
On Wed, Jan 07, 2009 at 02:49:17PM +0100, Johan Hake wrote:
On Wednesday 07 January 2009 14:28:09 Kent Andre wrote:
It seems to me that the problem is that I have created two different
FunctionSpaces that are actually the same and that the test
in Function is a pointer check.
One could of course make a better check based on e.g. a signature.
This should be trivial to do. But I will end up with using
a bit more memory than needed. Is this an acceptable solution ?
A check for the signature is not enough. Eventually we have to check
for the
meshes in the two files being the same too.
Maybe we should add a signature() function for meshes also that
returns some kind of checksum for the mesh?
What's wrong with the approach that I presented? Just read the function
and extract from the function the FunctionSpace and the mesh?
Garth
Reading ten functions from file gives ten meshes in memory.
This is another issue. Kent's code was reading in one function only.
I have a dislike for reading and writing functions, mainly because of
the use of signatures and the presence of pre-compiled finite elements
in DOLFIN (the latter going against the spirit of automated generation).
The most general approach would be to allow the construction of a
Function with a FunctionSpace and a GenericVector. The user has to take
some responsibility in making sure that the DofMap, Mesh, FiniteElement
and GenericVector match. From a quick look at the code, the only extra
thing that would be needed is a Function constructor that accepts a
FunctionSpace and a GenericVector.
Garth
In my case I solve a PDE for computing the coefficients in another PDE.
And it is a lot easier to load the coefficient from file than solving the
PDE.
OK, so you just need to write the vector containing the coefficients to
a file, right?
In my case efficiency is not much of an issue (at least not yet).
The only problem I see with signatures is that one can use more memory than
needed, but in many situations simplicity is more 'important' than memory.
The memory issue could be designed for. Signatures can change, and for
more complicated equations there is inevitably no pre-compiled element.
I think that simplicity points in the direction of reading in vectors,
meshes and dof maps. We could design it such that writing a function to
'u.xml' would write a number of xml files, e.g. u_mesh.xml,
u_dof_map.xml, etc. Then reading u.xml would actaully read in the
separate files. Even clever, I guess that they could all go in one file
and the XML parser would figure it out, e.g.
Function u;
File file("u.xml");
file << u;
Vector x("u.xml");
Mesh mesh("u.xml");
Garth
