← Back to team overview

dolfin team mailing list archive

  1. dolfin team
  2. Mailing list archive
  3. Message #11671

Re: saving and loading function

  Thread Previous • Date Previous • • Thread Next 


Anders Logg wrote:

On Wed, Jan 07, 2009 at 12:04:25PM -0500, Shawn Walker wrote:


On Wed, 7 Jan 2009, Anders Logg wrote:


On Wed, Jan 07, 2009 at 04:42:50PM +0000, Garth N. Wells wrote:


Anders Logg wrote:

On Wed, Jan 07, 2009 at 04:00:11PM +0000, Garth N. Wells wrote:

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

But 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

It will if we want to be able to store a higher-order function space
as a function space with a regular mesh and an additional function
that stores the layout of the coordinates.
Perhaps that is not the best way to do the higher order mesh coordinates. If we want the higher order mesh data to be a general Function (requiring a FunctionSpace), then I do not see how you can get away from needing the FiniteElement signature associated with it, and possibly other things.
Even if you have the vector of data and the DoFmap, that info must still be used to create a Function/FunctionSpace in the code. And in order for that to work the DoFmap must be `compatible' with the particular FiniteElement you will be using. I probably have this wrong, sorry for my confusion.
Another way to do the higher order mesh data would be to keep a little simpler. Have a vector of data, a DoFmap, and an indicator about the degree of polynomial used. This would be less general but not bad. In case of higher-order mesh data, you will ALWAYS use a continuous lagrange finite element. At least I cannot think of a situation where you would use something else. Would this not be desirable? 

If we decide to remove input/output for Functions and FunctionSpaces
(as I've understood is desirable since we then we don't need to rely
on precompiled elements and dofmaps) then how should we read in a
higher-order mesh from file?
The discussion on higher-order meshes got a bit confusing for me a little while back. In summary, exactly what information intended to be in the mesh file for a high-order mesh? 

Garth


Here's one option:

  Mesh mesh("mesh");
  LagrangeFunctionSpace V(mesh);
  File file("mesh_coordinate_vector.xml");
  Vector x;
  file >> x;
  V.set_coordinates(x);

That might work, but it's a bit long. There should be room for
improvement.



------------------------------------------------------------------------

_______________________________________________
DOLFIN-dev mailing list
DOLFIN-dev@xxxxxxxxxx
http://www.fenics.org/mailman/listinfo/dolfin-dev

Follow ups

References

  Thread Previous • Date Previous • • Thread Next