On Sun, May 09, 2010 at 07:50:14PM +0100, Garth N. Wells wrote:
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?
Simply because we just finished the Python version and thought it
would be useful to others.
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.
It's not unlikely. There is quite a strong commitment to moving parts
of it to C++.
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.
I'm not sure the sandbox is a good place (at least not in its current
form). It's a mixture of stuff that works and stuff that doesn't work,
things that are broken, test snippets etc.
If we decide to enforce a strong policy that we should not add
experimental code to DOLFIN,
