dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Wed, Mar 04, 2009 at 11:01:15AM -0500, mspieg wrote:
> 
> On Mar 4, 2009, at 6:46 AM, Anders Logg wrote:
> 
> 
>     On Wed, Mar 04, 2009 at 09:26:43AM +0100, Johan Hake wrote:
> 
>         On Wednesday 04 March 2009 08:35:23 Anders Logg wrote:
> 
>             On Wed, Mar 04, 2009 at 08:09:00AM +0100, Martin Sandve Aln s
>             wrote:
> 
>                 On Wed, Mar 4, 2009 at 7:47 AM, Johan Hake <hake@xxxxxxxxx>
>                 wrote:
> 
>                     Hello Marc!
> 
>                     This is a known bug. The two read in meshes are of course
>                     the same but
>                     during assemble, we extract one mesh from the same form. To
>                     be able to
>                     check that the mesh are the same we just compare the mesh
>                     pointers.
>                     Line 79 in dolfin/fem/Form.cpp. This is really not what we
>                     want, as
>                     your case will break this.
> 
>                     We have previously discussed this issue, can't find the
>                     email now. Then
>                     we thought of including some easily compiled mesh signature
>                     that could
>                     be used in the comparison.
> 
> 
>                 If I understand this right, the actual problem isn't the
>                 pointer
>                 comparison, but that the mesh is read twice. That shouldn't be
>                 necessary
>                 to do.
> 
>                 Martin
> 
> 
>             The reason it even works at all (to read in the two functions) is
>             that
>             DOLFIN happens to have precompiled elements for the cases in
>             question.
>             If it had been cubics, it wouldn't have worked.
> 
>             For this reason, we've discussed removing the precompiled elements.
>             One would then (in C++) first need to create the FunctionSpace and
>             then read the degrees of freedom for the Function. The problem with
>             this is that the mesh needs to be read first, so instead of just
> 
>               Function u("function.xml");
> 
>             we get
> 
>               Mesh mesh("mesh.xml");
>               MyFunctionSpace V(mesh);
>               Function u(V);
>               File file("udofs.xml");
>               file >> u;
> 
>             We could add a constructor to Function to simplify this to
> 
>               Mesh mesh("mesh.xml");
>               MyFunctionSpace V(mesh);
>               Function u(V, "udofs.xml");
> 
>             The file udofs.xml would contain all the dofs of u stored as a
>             Vector.
> 
> 
>         I think this looks good. The user then have to know what FunctionSpace
>         the 
>         Function is defined in, but that should be reasonable.
> 
> 
>             In Python, it would be possible to handle storing of general
>             functions
>             to file. The XML file could contain everything needed to
>             dynamically
>             instantiate the function space at run-time (no need for precompiled
>             elements). But then the interfaces would be very different in C++
>             and
>             Python for reading/writing Functions.
> 
> 
>         We still need to hand the mesh, if no other comparision meassure is
>         developed. 
>         So the above example would then look like
> 
>           mesh = Mesh("mesh.xml")
>           u = Function(mesh,"udofs.xml")
> 
>         which is not so much prettier I think.
> 
>         Why not have the same interface for c++ and Python here? Then we keep
>         the 
>         concept of first defining a FunctionSpace which is shared between
>         different 
>         Functions. It will also make the constructor of Function consistant,
>         wrt 
>         always getting a FunctionSpace as the first argument ;)
> 
> 
>     I agree. So does everyone agree on the following interfaces for C++
>     and Python:
> 
>       Mesh mesh("mesh.xml");
>       MyFunctionSpace V(mesh);
>       Function u(V, "udofs.xml");
> 
>       mesh = Mesh("mesh.xml")
>       V = FunctionSpace(mesh, family, degree)
>       u = Function(V, "udofs.xml")
> 
> 
> 
> This sounds good to me...and if I understand the intent, this could reduce the
> xml file sizes considerably by not having to write the mesh out everytime a
> function is written to xml file (e.g. for time-dependent problems).  

Yes.

> the only issue with this approach is that to reconstruct a function from files,
> requires managing and reading in 2 (or potentially three) separate files.  

Yes, it's a drawback. But I think it's outweighed by how much simpler
it will be not needing to have a precompiled library of elements and
looking at signatures. It's also more consistent in that we always
require a FunctionSpace when creating a Function and always require a
Mesh when creating a FunctionSpace.

> As a potential alternative,  would it be possible to embed in a udofs file,  
> the name of the corresponding mesh file (and perhaps the string for
> constructing "MyFunctionSpace" to generate the appropriate function space
> call).  If the mesh file has already been read in, it doesn't need to be read
> in a second time...

The problem with that is that mesh must be stored/cached somewhere and
the XML reader or the Function being read don't have access to it.

> I suppose this is similar to signatures and I can see some of the issues with
> non-uniqueness,  but the current fix still requires the user to carefully
> manage their meshes.  I actually have several problems where I consider the
> interaction of functions on different overlapping meshes, and there is a
> certain convenience to just reading in one file to construct things.  

I don't see a way around it, at least not in the C++ interface.

> But I'm not terribly picky,  getting the larger issue of attaching multiple
> discrete functions is more important to me (and it's easy enough for me to keep
> track of a small handful of files per problem).

Until this is in place, you should be able to do this already
now. Just store the vectors to file and read them back in again.

file << u.vector()

file >> u.vector()

-- 
Anders

Attachment: signature.asc
Description: Digital signature