dolfin team mailing list archive

[Johan Hake <johan.hake@xxxxxxxxx>]

On Tuesday May 11 2010 00:09:44 Anders Logg wrote:
> 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).

My first reaction was also negative. However some features is not readilly 
implemented in C++, the whole UFL/FFC part, and of course the new adaptivity 
module, and Viper!. 

I know it sounds crazy but embedding Python in C++ can be done. But I am not 
sure what problem we solve and how good we might be able to solve them and I 
am not sure we gain too much in programability.

Johan
 
> --
> 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