dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

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.

-- 
Anders

Attachment: signature.asc
Description: Digital signature