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 <[email protected]> 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
signature.asc
Description: Digital signature
_______________________________________________ DOLFIN-dev mailing list [email protected] http://www.fenics.org/mailman/listinfo/dolfin-dev
