dolfin team mailing list archive

[Johan Hake <hake@xxxxxxxxx>]

On Monday 23 March 2009 10:37:44 Martin Sandve Alnæs wrote:
> On Mon, Mar 23, 2009 at 10:25 AM, Johan Hake <hake@xxxxxxxxx> 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 <hake@xxxxxxxxx> 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