dolfin team mailing list archive

[Johan Hake <johan.hake@xxxxxxxxx>]

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.

> My point is our development model. The philosophy 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. 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
> 
> > --
> > Marie
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~dolfin
> Post to     : dolfin@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~dolfin
> More help   : https://help.launchpad.net/ListHelp