dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Mon, May 10, 2010 at 08:53:12AM -0700, Johan Hake wrote:
> On Monday May 10 2010 08:35:11 Garth N. Wells wrote:
> > On 10/05/10 16:20, Johan Hake wrote:
> > > On Sunday May 9 2010 13:26:04 Garth N. Wells wrote:
> > >> On 09/05/10 21:08, Marie Rognes wrote:
> > >>> Garth N. Wells wrote:
> > >>>> On 09/05/10 20:11, Anders Logg wrote:
> > >>>>> 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,
> > >>>>
> > >>>> The question is not on experimental code - it's preserving the
> > >>>> language-neutral nature of DOLFIN and whether we want to continue this
> > >>>> approach. I would like DOLFIN to remain language-neutral.
> > >>>>
> > >>>>> 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.
> > >>>>
> > >>>> A DOLFIN-app? Once ready, it could be merged into dolfin-main. I would
> > >>>> like to have the adaptivity code in dolfin-main now (with C++ code),
> > >>>> but I'm too much of a cynic to be sold on assurances that C++ code
> > >>>> will be added ;). What's the driver if the code already meets the need
> > >>>> of the developer?
> > >>>
> > >>> I don't think I'll embark on the philosophical issues. However,
> > >>>
> > >>> (1) I take personal responsibility for adding this on the c++ side to
> > >>> the extent this is possible (at least as long as it stays in
> > >>> dolfin-main ;) )h
> > >>
> > >> Great! I look forward to it . . . soon ;).
> > >>
> > >>> (2) I'm envisioning having a hard time at explaning (potential) users
> > >>> that "we can do this really cool thing, that nobody else can do, but we
> > >>> do not want to make it easily accessible because of our language
> > >>> philosophy".
> > >>
> > >> Two points on the argumentation under (2):
> > >>    (a) Code can always be made available. I've made Python-only code
> > >>
> > >> publicly available in support of papers, etc (e.g.,
> > >> http://www.dspace.cam.ac.uk/handle/1810/221687)
> > >
> > > This is true, but the availability of the features decrease dramatically,
> > > which I think is a very important argument.
> > >
> > >>    (b) What you describe under point (2) is exactly what Python-only
> > >>
> > >> features says to users of the DOLFIN C++ interface.
> > >
> > > Live with it! ;)
> > >
> > > For a long time alot of features were only available for C++ users. For
> > > example everything regardning paralell assemble in DOLFIN. Also when I
> > > found something that were not available for Python, or suboptimal, I had
> > > to implement it my self.
> >
> > We do our best to be indifferent, which means use C++ when possible and
> > allow SWIG to generate the Python wrappers, and then add hand-made
> > Python features when necessary.
>
> I know. I just do not think the reacent addition differ too much from this
> philosophy if you just exchange the language names, and change the latter part
> with:
>
>   and port as much of the Python code that is possible to C++, so the feature
> will be exposed to C++.
>
> In this case, I guess, not all parts are possible to port to DOLFIN as it
> relies heavily on UFL. That said, I have already seen suggestions, in this
> thread, for how to do this.
>
> > If SWIG could generate good C++ from
> > Python, then I would be very happy with Python-only development.
>
> That would be nice!

I'm not sure that would be so nice... :-)

We would then get a slightly awkward interface (C++) to a highly
inefficient code (Python).

--
Anders


> > >> My point is our development model. The philoso.phy relates to the
> > >> design/development process which we described in
> > >>
> > >>     http://doi.acm.org/10.1145/1731022.1731030
> > >>
> > >> and which I argue has worked pretty well so far. There is no language
> > >> philosophy.
> > >
> > > Which still, I would say, is mostly true. I would obviously like the
> > > above mentioned feature to be implemented in C++ too. But having more
> > > eyes and most important users of a features, creates dynamics to the
> > > development process, we would not have if it was not committed to main.
> > >
> > > It might also not be the author of a particular feature that implements
> > > it for the other language.
> >
> > That's fine, but who? Unfortunately we don't employ any programmers to
> > do this for us.
>
> I think the main point here is that we all agree that we should strive to keep
> it language indifferent. And then _we_ as a community need to make it happen.
> I also think we are pretty good at it already.
>
> Johan
>
>
> > Garth
> >
> > > Sometimes (read almost everytime) the main author has a
> > > prefered language. Implementing the feature in the other language might
> > > be frustrating and it is likely the results get suboptimal.
> > >
> > > Johan
> > >
> > >> Garth
> > >>
> > >>
> > >> _______________________________________________
> > >> Mailing list: https://launchpad.net/~dolfin
> > >> Post to     : dolfin@xxxxxxxxxxxxxxxxxxx
> > >> Unsubscribe : https://launchpad.net/~dolfin
> > >> More help   : https://help.launchpad.net/ListHelp
>
> _______________________________________________
> Mailing list: https://launchpad.net/~dolfin
> Post to     : dolfin@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~dolfin
> More help   : https://help.launchpad.net/ListHelp

Attachment: signature.asc
Description: Digital signature