dolfin team mailing list archive

[Martin Sandve Alnæs <martinal@xxxxxxxxx>]

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.

I don't care, I just think it's a waste of your valuable time :-)

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.

Martin