On Monday 23 March 2009 10:37:44 Martin Sandve Alnæs wrote: > On Mon, Mar 23, 2009 at 10:25 AM, Johan Hake <[email protected]> wrote: > > On Monday 23 March 2009 09:51:00 Martin Sandve Alnæs wrote: > >> On Sun, Mar 22, 2009 at 9:49 PM, Johan Hake <[email protected]> wrote: > >> > Hello! > >> > > >> > Now that we have removed the read/write Function from/to file in the > >> > c++ interface we have to change the python interface too. I haven't > >> > done this yet. > >> > > >> > But before I do this I wonder if we _should_ add some logic in the > >> > python interface that allow the functionality we previously had, i.e., > >> > writing and reading Function to and from a file directly? > >> > > >> > We could perhaps extend the <</>> operator in the c++ wrapper so an > >> > xml file with the vector, mesh and the FiniteElement signature will be > >> > saved in. Then in python we can jit compile the FE, when reading the > >> > file. We should probably have one constructor taking only the xml file > >> > but also one taking an optional mesh argument, preventing the problems > >> > with duplications of meshes. > >> > > >> > Would this be desirable? I know Ola have made some thoughts about > >> > this. > >> > >> Only for toy programs. We still need to share the function spaces > >> between functions. > > > > While I do see your point, I cannot see why this should prevent us from > > having this functionality. The main argument of removing this > > functionality from the beginning was not the non-sharing of > > FunctionSpaces but the difficulties of using a precompiled library of > > finite_elements and dofmaps. > > > > A duplication of finite elements and dofmaps is of course a drawback. > > Programmers who want full sharing can do this by using the vector to/from > > file interface. > > > > I will probably not use this feature, but others might. > > Which is exactly why it shouldn't be implemented. > Since this is the simplest version to use, unexperienced > users will use it and not see the cost.
While I might disagree with this point of view, as the unexperienced user probably do not care in the first place, I might agree with the more general agrument that a Function always need a FunctionSpace to be initialized, which enforces your point of view. > I don't care, I just think it's a waste of your valuable time :-) Thank's for your concern ;) > Speaking of Function, will it be easy to pass keyword arguments > to ufl.Function.__init__? There are some features in the UFL > roadmap requiring this. For now we do not do this as FFC.Function only needs the FiniteElement. However it should be possible to add this either as a dict parameter: ufl_kwargs or as hardcoded optional kwargs. The former is probably preferable. Johan _______________________________________________ DOLFIN-dev mailing list [email protected] http://www.fenics.org/mailman/listinfo/dolfin-dev
