dolfin team mailing list archive

[Johan Hake <hake@xxxxxxxxx>]

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 ;)


Johan