fenics team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Sat, Sep 24, 2005 at 05:49:24PM -0700, Kevin Long wrote:

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

I agree, it's not.

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

Yes, that seems to be one obstacle. In my view, the main issue is to
see if we can overcome any such political obstacles and find a
solution that allows the FEniCS project to benefit from all the good
work you've made on Sundance.

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

There have hardly been any flames on any of the *-dev@xxxxxxxxxx
mailing lists before that I can remember.

> > - 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).

I don't claim GPL is more "open" than LGPL. This is no big deal.
Personally, I could do LGPL if someone gave a good reason for it,
but I prefer GPL.

I'm not sure this is the case with Sandia, but there is sometimes a
misunderstanding that use of GPL libraries would force you to release
your code. That's not the case. If you just use GPL code to run
projects within Sandia, then the GPL does not say anything about your
code. It merely states that if you release and distribute binaries of
your code to the public or sell it to someone (which you probably
don't), you then need to make the code available. As long as you keep
the code within the walls of Sandia, it's no problem.

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

I think registering for a product should be optional, whether you
download something for free or by a new TV. That's just my opinion as
a potential user 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.

Sure.

> To use it as a primary backend, we would have to solve the problems Rob
> mentioned with compiling and dynamic loading on supercomputers.

When you run something on a supercomputer, I imagine most of the
development takes place on a smaller machine where running Python
scripts is not a problem so the forms can be compiled (into C++)
before you even move the code to the supercompuer. Would that work?

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

That's what I suggest we should look at.

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

I was not suggesting we do all the stuff in the list above (giving us
CVS access to Sundance etc). I'm merely saying that these are some
obstacles to the lets-everyone-work-on-Sundance-approach (which is no
critisism against Kevin or Sundance).

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

I'm happy to hear that.

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

I agree, and I don't want to write one.

> 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

As I've said, there has hardly been any flaming on the list before and
there doesn't have to be.

Since we seem to agree that developing a set of interoperable components
is the way to go, we should focus the continuing discussion on this.
The discussion could go something like this: Hey. I would love to be
see this functionality as a FEniCS component. Someone replies: I could
do that. Great. No one needs to be forced into doing anything.

So let me go first: Hey, I need an AST that can do nonlinear forms and
differentiation and I need it as a Python module that could be either
separately maintained on fenics.org or go into FFC.

One more thing, as Matt points out, making something a FEniCS
component does not mean it can't be part of Trilinos, PETSc or
whatever, it can be both.

/Anders