dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

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, is there a way that we could organize
modules like the adaptivity module and make them easily installable?
I don't think it's a good idea to create things as separate projects
if the intention is to merge it into DOLFIN. It would be something
between dolfin-sandbox and dolfin-main.

--
Anders

Attachment: signature.asc
Description: Digital signature