dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Mon, Mar 23, 2009 at 11:34:47AM +0100, Johan Hake wrote:
> 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.

This issue comes back now and again in many discussions. I don't think
we need to prohibit the use of convenient operations just because we
know they are not optimal. It's enough that it's documented.

One valid argument against allowing full Function input/output from
Python would be that it breaks the compatibility between the C++ and
Python interfaces, but it may not be such a big deal.

-- 
Anders


> > 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
> DOLFIN-dev@xxxxxxxxxx
> http://www.fenics.org/mailman/listinfo/dolfin-dev

Attachment: signature.asc
Description: Digital signature