On Wed, Jan 7, 2009 at 3:26 PM, Garth N. Wells <gnw20@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
Ok.
Since the user has to keep track of the surrounding context anyway,
I'd like to simply do this for restarting simulations etc:
file << u.vector()
file >> u.vector()
Writing vectors seems to work fine with .xml files.
It would also be nice to be able to dump the vector contents to a raw
binary file, which should be faster and reduce the disc space needed.
