| Thread Previous • Date Previous • Date Next • Thread Next |
Anders Logg wrote:
On Wed, Jan 07, 2009 at 04:00:11PM +0000, Garth N. Wells wrote:kent-and@xxxxxxxxx wrote:OK, so you just need to write the vector containing the coefficients to a file, right?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? GarthReading 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. GarthIn 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.The memory issue could be designed for. Signatures can change, and for more complicated equations there is inevitably no pre-compiled element.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.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"); GarthBut then we also have the current discussion about reading/representing higher order meshes. How would that work if we decided to remove input/output for functions and function spaces?
In practice, we're only talking about removing output of the signature of the FiniteElement, so I don't see that this would have any more impact on higher-order meshes than it will on regular functions.
Garth
------------------------------------------------------------------------ _______________________________________________ DOLFIN-dev mailing list DOLFIN-dev@xxxxxxxxxx http://www.fenics.org/mailman/listinfo/dolfin-dev
| Thread Previous • Date Previous • Date Next • Thread Next |
