dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

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?

-- 
Anders

Attachment: signature.asc
Description: Digital signature