fenics team mailing list archive

[Kevin Long <krlong@xxxxxxxxxx>]

On Saturday 24 September 2005 14:12, Anders Logg wrote:
> Let's try again to move this discussion over to fenics-dev@xxxxxxxxxx,
> shall we? Everyone interested can follow the thread at
>
>     http://www.fenics.org/pipermail/fenics-dev/
>
> or sign up to the email list if they want. I have cc:ed everyone on
> our previous discussion in this post, but perhaps they can decide for
> themselves if they want to follow the continuing discussion.
>
>
> So, back to the discussion...
>
> 1. DOLFIN vs. Sundance

I'm not going to even touch any sort of feature-by-feature technical comparison, first of all to not add further fuel to the fire, and second because I suspect that's not the real issue here, is it? The real issue seems to be the conflict between a vision of a completely open development model and the quasi-open model required of DOE researchers.

> For this to happen, I would like to have the following questions
> answered, preferably all with a "yes". Unfortunately though, I
> suspect the answer to most questions is "no".
>
>     - Does Kevin have any interest in working with us?

Yes, though if flames of the sort I've seen recently are a regular sort of thing, I would probably lose interest rather quickly.

>
>     - Can we get CVS access (rw) to Sundance?

See the next answer.

>
>     - Can we make the development model for Sundance completely open?

If by "completely open" you mean (a) release GPL rather than LGPL, and (b) anyone can change the development branch in any way as they see fit, then the answer is no.

Regarding (a): because of the nature of some of our projects Sandia cannot use GPL libraries (we can use GPL compilers, editors, etc, --- including, for instance, FFC --- but not libraries).  

Regarding (b): The development of Sundance so far has been paid for by my research funding for optimization and by Rob's for FIAT. To justify continuation of that funding, I need to solve certain PDE-constrained optimization problems and Rob and I together need to incorporate certain element technology. We will continue to need a stable repository containing a stable version with which we can accomplish those goals.
So I don't envision letting Sundance development turn into a free-for-all.


>     - Can we make frequent releases of Sundance? Without needing to go
>       through a security audit by the US military?

Sundance has been released LGPL. You are therefore free to change it and distribute those changes as allowed under the LGPL. 

About security reviews: anything developed by me (and probably Matt as well) has to go through security review and approval by DOE before being released.
This is so that I don't reveal, intentionally or otherwise, any national security secrets such as whether George Bush's IQ has one octal digit or two. You, however, do not work for DOE and are not privy to national security secrets and so are not subject to those restrictions even if you work with our codes. 

>
>     - Can we install Trilinos without registering at Sandia?

Provided you can get your hands on a copy of it, yes. Trilinos is LGPL and can be distributed accordingly. If you don't want to give Sandia your email address, find someone who has Trilinos, and ask him/her to give it to you. 

That being said, I would encourage you to register anyway. The registration is not used for any nefarious purpose, it is used to compile statistics on usage that are in turn used as part of the justification for funding open-source releases of Trilinos. 

>
>     - Can we get Sundance to use FFC as the backend for evaluating
>       multilinear forms?

Change "the backend" to "one of the backends", and I'd be somewhat interested. To use it as a primary backend, we would have to solve the problems Rob mentioned with compiling and dynamic loading on supercomputers. 

An equivalent idea is using Sundance's symbolic code as a front end to FFC. 

We can do either/both without completely unifying DOLFIN and Sundance.

>     - Can we include Matt and the people at Argonne in the development?

Of course. Sundance developers already include people at U. Chicago, North Carolina State University, Caltech, and UCLA; there's no reason Argonne could not be involved as well.

>     - Can we put the code on fenics.org?

You can do whatever you like with the code, subject to the LGPL license. The  repository I work with, however, will have to be the one at Sandia for the reasons explained above. 

>
>
> 3. My suggestion
>
> Instead of trying to push everything into one package, let's try to
> develop middleware/components that encapsulate important functionality
> in self-contained modules. This way, we can get around all the obvious
> political difficulties of developing a common system.

I agree completely. For many reasons you have different goals for DOLFIN development than I do for Sundance development (for example, PDE-constrained optimization is an optional feature for you, but is the main driver for me), and there's no need to try to cram everything into a single top-level package.  

Again, the Sundance symbolic core is a modular component. You are free to use it, though by virtue of its being bundled, at least for now, in a larger tarball that might be mildly inconvenient. This is the only substantive reason I've heard for not using it (though it being in C++ might be another).

However, I'd recommend that you bear with that inconvenience. Part of working with modular tools is accepting that not all of the external modules will be designed, implemented, or distributed exactly as you'd like. The NOX nonlinear solvers have had (until recently) very unsafe memory management, MPICH builds by default some C++ extensions that don't use namespaces correctly... I could register similar complaints about every single package I use. Indeed, there are features of Sundance itself that I myself don't like, and would change if I had time. The decision of whether or not to use a tool shouldn't be made on whether said tool has undesirable features, but on whether it is easier to live with those features or to redo the work yourself.  The only point I heard Rob trying to make in the recent discussion was that you really want to consider whether it is a good idea to spend several months writing your own symbolic system rather than a couple of days figuring out how to work with an already existing one.  

While I think an insistence on working with a pure component is unrealistic (do you expect, say, MPICH or PETSc to strip out all features you don't use and package them as a bunch of independent tarballs?) you may quite reasonably decide that having the symbolic system written in python is an unalterable requirement. That make some sense given your needs. Even then, I still recommend you free yourself of any belief that writing your own symbolic system will be trivial. Writing a mediocre one is trivial. Writing a good one is not. 

Finally, and I'm only going to say this once:

I am utterly *not interested* in participating in any collaboration in which flame wars occur, ever. I have worked on numerous collaborative teams involving people from universities, labs, and industry, all full of people with strong opinions and large egos, but before this recent exchange I've not seen email discussions degenerate so far into defensiveness and hostility. Please try to be more professional, and more willing to fully grasp the other person's point before responding harshly or before trying to unilaterally cut off the discussion.  

Whether FEniCS succeeds will depend not only on the technical virtuosity of the people involved, but whether it becomes a community that is greater than the sum of its parts. That in turn depends on intangibles like keeping it a pleasant working environment in which people keep their egos under control and their tempers in check.  

kevin