dolfin team mailing list archive
-
dolfin team
-
Mailing list archive
-
Message #11577
Re: saving and loading function
On Wed, Jan 07, 2009 at 03:07:03PM +0000, Garth N. Wells wrote:
>
>
> Martin Sandve Alnæs wrote:
> > 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()
Agree. It would be good if we could remove the precompiled elements.
> > 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.
> >
>
> Binary output would be useful.
Yes.
For time-dependent problems, there is the class dolfin/ode/ODESolution.h
which is not really specific to ODE solutions. We can rename it to
TimeSeries and use it for storing a time series of vectors/functions.
The class does some clever caching, keeping some data in memory
(configurable), some on disk (in binary) and when new data is needed
from disk it reads in blocks.
--
Anders
Attachment:
signature.asc
Description: Digital signature
References
-
saving and loading function
From: Kent Andre, 2009-01-07
-
Re: saving and loading function
From: Johan Hake, 2009-01-07
-
Re: saving and loading function
From: Kent Andre, 2009-01-07
-
Re: saving and loading function
From: Johan Hake, 2009-01-07
-
Re: saving and loading function
From: Anders Logg, 2009-01-07
-
Re: saving and loading function
From: Garth N. Wells, 2009-01-07
-
Re: saving and loading function
From: Martin Sandve Alnæs, 2009-01-07
-
Re: saving and loading function
From: Garth N. Wells, 2009-01-07
-
Re: saving and loading function
From: Martin Sandve Alnæs, 2009-01-07
-
Re: saving and loading function
From: Garth N. Wells, 2009-01-07