dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

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

?

-- 
Anders

Attachment: signature.asc
Description: Digital signature