dolfin team mailing list archive

["Garth N. Wells" <gnw20@xxxxxxxxx>]

On 09/05/10 19:25, Anders Logg wrote:
> On Sun, May 09, 2010 at 07:06:04PM +0100, Garth N. Wells wrote:
> > On 09/05/10 15:04, Marie Rognes wrote:
> > > Garth N. Wells wrote:
> > > > Does this work from the C++ interface too?
> > >
> > >
> > > Nope. It is a pure python prototype.
> >
> > This isn't the design philosophy that we've used in developing
> > DOLFIN. We have developed in C++ (and I think still should) and
> > generated the Python interface automatically, and implemented Python
> > extensions by hand only when necessary. I don't want to see a
> > divergence of the interfaces and advocate that Python 'prototypes'
> > should not be part of DOLFIN.
> >
> > Garth
>
> I think this prototype is too good to be kept as a prototype. We will
> move the things that can be moved to C++, but it might not be possible
> to move all of it since it relies on automatic differentiation and
> auto-generation of the dual problem.

Having Python-only parts when required is fine (like we do now), but why 
not develop the C++ building blocks before committing to dolfin-main? If 
the structure is clear and clean, it doesn't take much effort to write 
the C++ code. By not adding the C++ code now, there is a strong 
likelihood that it will never be added. I would prefer that prototypes 
remain in the sandbox until the C++ code is in place.

The addition of the Python adaptivity code marks a change in development 
approach and should be discussed.

Garth

> Ideally, we will have something similar to the assemble() interface
> which exists in both C++ and Python, but take different arguments.  In
> C++, one will need to supply extra forms (for the dual and the error
> indicators) to AdaptiveVariationalProblem that are generated by FFC on
> the command-line.
>
> --
> Anders