| Thread Previous • Date Previous • Date Next • Thread Next |
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. GarthI 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)
(b) What you describe under point (2) is exactly what Python-only features says to users of the DOLFIN C++ interface.
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.1731030and which I argue has worked pretty well so far. There is no language philosophy.
Garth
-- Marie
| Thread Previous • Date Previous • Date Next • Thread Next |
