Subject: [fenics-dev] FEniCS

From: Anders Logg <[email-masked]>
Date: Sat, 24 Sep 2005 16:12:23 -0500

Let's try again to move this discussion over to [email-masked],
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

As Rob points out, Sundance can do many things that DOLFIN can't:

    - It's fully parallel
    - It has automation for nonlinear problems
    - It has automation for PDE-constrained optimization 
    - It can do more general boundary conditions

None of these features would be very hard to get into DOLFIN (and the
plan is to add a large part of these features within a couple of
weeks/months), but as I've said before, it's no use in reinventing
things already in Sundance if not necessary. (And I'll discuss below
why it might be necessary.)

On the other hand, DOLFIN can do a number of things that Sundance can't:

    - Full use of FFC/FIAT for more efficient evaluation of forms
    - Higher order elements (any degree q on triangles and tets)
    - Arbitrary mixed elements
    - The mono- and multi-adaptive ODE solvers
    - A set of very good built-in solvers/modules for Navier-Stokes
      and updated elasticity

In addition to these differences, Sundance uses Trilinos and DOLFIN
uses PETSc.

2. Developing for Sundance?

Rob suggests that the most efficient path to take would be to develop
for Sundance, rather than for DOLFIN. The logic would be that it would
be easier to add the missing features to Sundance (full use of
FIAT/FFC, higher order elements, mixed elements) than to add the
missing features to DOLFIN (parallel mesh, support for nonlinear
problems).

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?
    
    - Can we get CVS access (rw) to Sundance?

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

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

    - Can we install Trilinos without registering at Sandia?

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

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

    - Can we put the code on fenics.org?

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.

This is how we have built DOLFIN. In itself, DOLFIN is actually pretty
dumb (intentionally). It knows very little about the finite element
method, and it knows nothing about linear algebra. It just delegates
the functionality to other components (PETSc, FFC, FIAT) and wraps it
with a consistent user-interface. The current plan for DOLFIN is to
delegate even more of the functionality, starting with replacing the
DOLFIN mesh library with Sieve.

4. FEniCS

Rob, what is your vision for the FEniCS project, and fenics.org?

Mine is to develop and distribute free software for the Automation of
Computational Mathematical Modeling.

Another purpose of FEniCS is to enable the development of a common
codebase that is free of ties to any particular person, group,
university or national lab.

/Anders

---

From: Matthew Knepley <[email-masked]>
Date: Sat, 24 Sep 2005 17:21:05 -0500

Anders Logg <[email-masked]> writes:

       I apologize for quoting the whole mail, but this is a general comment rather than specific points which will come
later. However, I think this is relevant now.

  I believe, overall, Anders is correct, but I want to be very precise about the origin of my opinion.

  1) Why do people choose a particular software package?

     In our experience with PETSc, people OVERWHELMINGLY choose a package based upon ease of use rather than
     sophistication. While I believe everyone here knows this, it is worth repeating because the consequences
     are so far reaching. What are some components of "ease of use"?

     a) Ease of coding

        This takes hold later, but does not really influence choice as much as we tend to think.

     b) Ease of installation

        This is very important, and is an area in which I think I Trilinos is exceptionally weak. I have heard numerous
        reports of it being hard to install, and personally autoconf really, really, sucks.

     c) Ease of distribution

        This is connected to the former; however it is also impacted by the license, stupid barriers people put up (like
        web forms and questionnaires), and packaging decisions. The decision to keep the Trilinos packages separate in
        terms of interfaces is great (although it is sometimes violated), but for distribution it is an absolute killer.
        People want one thing to download and install, and this is something FENICS shuold consider.

  2) Has Sundance made good decisions which will facilitate ease of use?

     Well, he does distribute a single tarball, but

     a) He depends on Trilinos, which I think is bad for us. 

     b) He has not disentangled important subunits at the INTERFACE level, such as the functional differentiation, even
        though I specifically asked for this more than 1 1/2 years ago.

     c) I think the build and configure (which he inherits from Trilinos) are not up to par

     d) I am still suspicious that Sandia will allow open interaction. Their record is abolutely terrible.

  3) What should FENICS be?

     I agree that it should be a set of interoperable components (which inevitably define interfaces). This does not
     mean they cannot be part of other projects (PETSc, Sundance), but it shuold mean that they are DEVELOPED separately
     but DISTRIBUTED as a whole.

  4) What do I envision?

     I would love to see dozens of front ends that are tailored to different disciplines. I hope to help create one for
     geodynamics out of CIG. Thus, I see a Sundance vs. DOLFIN argument as completely beside the point. I would phrase
     questions like, "Can and should we use the functional AD from Sundance?" or "Shuold we adopt the PDE constrained
     optimization model from Sundance?".

These are my general comments, but I invite discussion on any specific points as well.

     Matt

-- 
"Failure has a thousand explanations. Success doesn't need one" -- Sir Alec Guiness

---

From: Robert Kirby <[email-masked]>
Date: Sat, 24 Sep 2005 20:53:21 -0500

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

If the requirement is to solve really big forward and backward problems 
on really big machines, then Sundance is something that hangs together 
and does the whole shebang, thanks in large part to its symbolic 
system.  It is the state of the art in this aspect - nothing else that 
exists today can solve these problems on this scale on these machines. 
(Note that I didn't suggest that we all become FreeFEM developers).  
This is a statement about *current capabilities* and not whether some 
other system such as DOLFIN will do much better eventually.

There are two issues at hand:
1.) The automation of computational mathematical modeling -- there is a 
code that does this.  I was presenting a thesis (not necessarily one I 
would push very hard on) that the best way to proceed is to pool 
resources to make the most complete existing system (in a certain norm) 
better, despite our differences.  Saying "we should all become sundance 
developers" was a way of putting it, for the sake of argument.  Taking 
out existing pieces of Sundance and reusing them would be an alternate 
approach that would be like letting Matt & Barry parallelize our linear 
algebra for us.

2.) research/new ideas.  For me, FEniCS is about new ideas about finite 
element computation rather than a big development push.   It's not just 
about getting code, it's about figuring out the mathematics of the code 
(not the mathematics of the numerical method). This is an 
alternate/contrasting reason to focus on components -- we can try out 
fundamentally new ideas, develop and test them in a controlled context. 
  We can make contributions at the idea level separate from any 
particular software incarnation.  For example, I think that FFC and 
FErari represent fundamentally new and exciting ideas in finite element 
computation.  Were we constrained to work *only* in the context of 
Sundance (or FreeFEM, or FEMLAB), these might be very difficult to try 
out.  Ultimately, if we are going to improve existing codes such as 
Sundance or develop ones that outperform them, it has to come from the 
injection of new ideas.

This is a weaker view of components perhaps than Anders has -- if 
something like FFC or FErari matures to the point where it can truly 
stand alone (I don't think FFC is there yet but it is certainly much 
closer than FErari), great -- lots of people can use it.  On the other 
hand, even if these are just something that sit within the DOLFIN 
framework, we've still learned something about algorithms that we 
didn't know before.  There can also be interoperability at the idea 
level - for example, extending Sundance's run-time system with similar 
kinds of precomputation that are inspired by and properly cite FFC.  
This is not a dogmatic approach to a particular software engineering 
principle -- I am inclined to agree with Kevin that a complete 
modularity will not be fully practical to achieve -- but a recognition 
that things can and should be polished in bite-sized chunks and made 
available at such a level of granularity if possible.

So I speak in a paradox:
1.) I like having a large system that hangs together and am hesitant to 
put a lot of effort into redeveloping stuff that's already there.
2.) I like having little components where I can try out my mad 
scientist ideas.  If these components really stand on their own and are 
useful to other projects as FIAT seems to be, great.  If I learn 
something that can help me make a collaborating code better, great.  If 
I learn something that tells me my ideas or implementations are a bunch 
of crap, I can scrap them.

These reflect a couple of things about my present position:
1.) I have funding to work on FIAT in certain contexts and tackle 
certain kinds of problems with it and not to reinvent bigger systems.
2.) Tenure-track job: It is more important to come up with cool ideas 
and to solve problems than it is to be immersed in code development 
that isn't really cutting edge from the or math/CS standpoint.  I can 
work on FIAT in the context of existing codes, I can work on FErari by 
getting data from FFC, etc.  But unless I have a new mathematical 
theory of log systems that follows from the Masur Separation Theorem, 
writing such a system can be a dangerous time-suck for me, I have been 
advised "you don't get tenure for writing code, you get tenure for 
writing papers".  I used to think that writing a mesh library fell into 
this category, but then Sieve came along -- maybe there's something to 
be said for the axiomitization of log systems :)  This makes me very 
inclined to use as much existing code as possible.
3.) My disposition in research anyway seems to be to come up with 
elegant formulations of "little" problems (e.g. FIAT, FErari) that seem 
very important.  Hopefully these little pieces can make bigger projects 
better.

So, this expounds upon my previous emails and hopefully explains how I 
am approaching research.

Rob

---

From: Kevin Long <[email-masked]>
Date: Sat, 24 Sep 2005 17:49:24 -0700

> So, back to the discussion...

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.

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

>       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

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. 

> 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

---

From: Anders Logg <[email-masked]>
Date: Sun, 25 Sep 2005 09:06:47 -0500

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.

> 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 [email-masked]
mailing lists before that I can remember.

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

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

> We can do either/both without completely unifying DOLFIN and

That's what I suggest we should look at.

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

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

> 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

---

From: Robert C. Kirby <[email-masked]>
Date: Sun, 25 Sep 2005 20:22:22 -0500

Let me clarify a couple of things about what I said:

> 2.) research/new ideas.  For me, FEniCS is about new ideas about 
> finite element computation rather than a big development push.   It's 
> not just about getting code, it's about figuring out the mathematics 
> of the code (not the mathematics of the numerical method).

Of course we need code -- maybe "get the ideas right first, then do a 
push to implement them," would be better.  This relates to another 
paradox which I present:

"now & then"

"Now":
There are people relying on certain codes to produce results today.  
Implications: 1.) reuse everything you can because time you spend 
redeveloping is time you don't spend getting results. 2.) teaming up on 
a code that gets results gets more results sooner.  3.) One must 
present a clear and compelling reason for redevelopment of existing 
pieces (even if they have certain quirks and undesirable features).

The danger is in being short-sided and stifling innovation.

"Then":
What will be the "next big thing"?  How are we going to (perhaps both 
and) improve Sundance/DOLFIN/etc and design a (code OR collection of 
codes) that will be vastly superior in terms of user interface, 
extensibility, algorithmic elegance and efficiency, etc.
Implications: 1.) results today don't matter as long as we'll get the 
next big thing eventually.  2.) Reuse of existing code is deemphasized. 
3.) You get to do just what you want and form everything just the way 
you would have it.

The danger is in thinking "I can do it better" repeating quality work 
other people have done from slightly different perspectives.  You also 
will have to convince people that what you have done really *is* better 
although other things that were quicker to the punch have become 
ingrained standards that people are hesitant to stray from because they 
work.

> theory of log systems that follows from the Masur Separation Theorem,

Log systems are very important and useful, but we have ones existing.  
I have no ideas on how to make them any better and therefore will not 
write one.  I would say similar things about build systems, although I 
know some of us have very strong opinions (and implementations) about 
how they can be better.  I encourage such research.

> elegant formulations of "little" problems (e.g. FIAT, FErari) that 
> seem very important.  Hopefully these little pieces can make bigger 
> projects better.

I see this as a way to have a foot in both "now" and "then".  Research 
is a long process.  I can't do everything -- it's good to have results 
that are making present impacts.  It's good to have ideas that might 
pan out in the future.

Rob

---

From: "Johan Hoffman" <[email-masked]>
Date: Mon, 26 Sep 2005 11:34:10 +0200 (MEST)

I agree that there will always this "now & then" paradox to live with.
There will also be various constraints on all people involved, naturally
resulting in different focus for the different participants in FEniCS, and
therefore I think it is very important to keep the format of FEniCS open.
Users of DE solvers will benefit from the (hopefully) inventive components
avaliable, and the developers of new components will also benefit from
having a "reasonably complete" system with a common interface to use as
front- and backends of there components.

It seems reasonable that the various FEniCS components avaliable for
download at the homepage (today: DOLFIN,FFC,FIAT,Ko,Puffin) are compatible
in terms of interfaces, which is the case today. Apart from that, together
with compatible licenses of some form, I think further restrictions should
be kept to a minimum.

I do not think that we today should worry too much about "selling" FEniCS,
or the different components of FEniCS.

/Johan

> _______________________________________________
> fenics-dev mailing list
> [email-masked]
> http://www.fenics.org/cgi-bin/mailman/listinfo/fenics-dev
>

-- 
Johan Hoffman, PhD
Assistant Professor
School of Computer Science and Communication
Royal Institute of Technology KTH
SE-100 44 Stockholm
Sweden

Email: [email-masked]
URL: www.nada.kth.se/~jhoffman

---

From: "Robert C. Kirby" <[email-masked]>
Date: Mon, 26 Sep 2005 09:55:46 -0500

> or the different components of FEniCS.

Let me offer a counterpoint to this.  We must be careful about what  
we mean by "standard" if we want to "set a new standard in  
Computational Mathematical Modeling." (quoted from www.fenics.org)
Perhaps this will generate discussion on certain sociological ideas  
that we haven't considered yet.  Matt has commented on related  
questions with "why do people pick a software package."  The thesis  
for debate, which I invite any/all to confirm/refute in a civilized  
manner, is:

"In order to set a new standard in computational mathematical  
modeling, the FEniCS project must be actively involved in the broader  
scientific computing community, getting this community to adopt both  
particular components and assembled systems as they emerge."

1.) There are standards like the XHTML standard, ANSI C, BLAS etc.   
These are useful if they have large buy-in from a community.  If we  
want to set the "standard" in this sense, then we need to sell the  
idea and fix a interfaces (and reference implementations) in  
conjunction with lots of people.  Everybody except Micro$oft seems to  
think such standards are very useful.

2.) There are standards like "this is the standard to beat".  If you  
want to play this game, you have to jump at least this high.  If I  
had some good idea about how to write a parallel solver library, I  
would have a big problem facing me.  There are already really good  
ones like PETSc and Trilinos.  To be taken seriously, I would first  
have to show a dramatic improvement over the existing "standards" and  
be as complete as they are.  Being taken seriously is a prerequisite  
to setting a new standard in this sense.  Setting those packages  
aside and writing one that is not as good is a bad career move.  But  
perhaps somebody will take the plunge, and come up with something  
better.  It takes huevos, but rejecting current paradigms is  
sometimes necessary to make qualitative advances in science.

3.) My final point is the time factor -- a "standard" is something  
that everybody uses because everybody has been using it and has time,  
energy, code-base, and know-how invested in it (FORTRAN is an example  
of something that is a standard in multiple senses).  Inertia  
prevents scientists from scrapping existing scientific/engineering  
code in favor of better ones -- the present code runs and gets  
results.  Today, we are seeing people willing to take a leap with PDE  
codes and jump into these new-fangled automated things.  However, if  
we wait some n years to start selling FEniCS components or an  
integrated FEniCS system, then we have to overcome the inertia of  
people having already invested in other systems (e.g. FreeFEM, Deal)  
and being hesitant to change.  The sell becomes not "you should use  
an automated system" but "you should scrap your current automated  
system in favor of mine".  I claim the latter will be a harder sell  
-- the technical merit of a system matters more when people are  
confronted with two new products (I don't have a car, I think I'll  
buy one -- what's the best one out there that I can afford?) and told  
to choose one than it does when they have a working product are asked  
to scrap it for the latest/greatest (I have a Ford, do I really need  
to upgrade to a Volvo?  Sure, it may be great, but I can get where  
I'm going just fine without spending any more money or time looking  
for a new car)

The thing I'm trying to avoid here is irrelevance to the broader  
world of scientific computing.  Even if we have the best system in  
the world but we can't sell it to plasma physicists or geologists or  
whoever, we have not set a new standard in computational mathematical  
modeling.  If our would-be clients are already committed to other  
projects, we have not set a new standard in computational  
mathematical modeling.  If we develop a system that is not as good as  
others, we have not set a new standard in computational mathematical  
modeling.

Rob Kirby

"Mathematical software should be mathematical."

---

From: Matthew Knepley <[email-masked]>
Date: Mon, 26 Sep 2005 11:11:17 -0500

"Robert C. Kirby" <[email-masked]> writes:
> 3.) My final point is the time factor -- a "standard" is something  that everybody uses because everybody has been using
> it and has time,  energy, code-base, and know-how invested in it (FORTRAN is an example  of something that is a standard
> in multiple senses).  Inertia  prevents scientists from scrapping existing scientific/engineering  code in favor of
> better ones -- the present code runs and gets  results.  Today, we are seeing people willing to take a leap with PDE
> codes and jump into these new-fangled automated things.  However, if  we wait some n years to start selling FEniCS
> components or an  integrated FEniCS system, then we have to overcome the inertia of  people having already invested in
> other systems (e.g. FreeFEM, Deal)  and being hesitant to change.  The sell becomes not "you should use  an automated
> system" but "you should scrap your current automated  system in favor of mine".  I claim the latter will be a harder
> sell  -- the technical merit of a system matters more when people are  confronted with two new products (I don't have a
> car, I think I'll  buy one -- what's the best one out there that I can afford?) and told  to choose one than it does
> when they have a working product are asked  to scrap it for the latest/greatest (I have a Ford, do I really need  to
> upgrade to a Volvo?  Sure, it may be great, but I can get where  I'm going just fine without spending any more money or
> time looking  for a new car)
>
> The thing I'm trying to avoid here is irrelevance to the broader  world of scientific computing.  Even if we have the
> best system in  the world but we can't sell it to plasma physicists or geologists or  whoever, we have not set a new
> standard in computational mathematical  modeling.  If our would-be clients are already committed to other  projects, we
> have not set a new standard in computational  mathematical modeling.  If we develop a system that is not as good as
> others, we have not set a new standard in computational mathematical  modeling.

  Neat discussion, and in my opinion long overdue in scientific computing which tends to focus on
easy metrics (flops, peak) with no clear connection to reality, as well as funding sources. I
want to mention that we should not think that all components are always used the same way, or
even that we can think of all the ways consumers will use them. That is what innovation is about.

  For instance, FIAT can be used standalone to generate quadrature tables for an element, which are
then compiled in. Even here it is a vast improvement over stuff worked out by hand or copied from
tables. However, it an also be used at runtime to define static structures, or as part of a code
generation system. But FFC goes farther, and uses FIAT to exactly integrate an arbitrary form. This
probably does not exhaust the uses, but shows that one component may be used lots of different ways.
The metrics I like for FEniCS components (squishy as they may be) are conceptual fertility and ease of
use.

  Lastly, standards are great. But in my opinion, all standards are just a community admitting that
someone has done a good job. That is why standards efforts which do not embody advances made by
actual simulation (ESI, CCA) never work. The best way to integrate FEniCS into the community is to
work with application groups directly.

     Matt

---

From: Anders Logg <[email-masked]>
Date: Mon, 26 Sep 2005 11:45:18 -0500

On Mon, Sep 26, 2005 at 11:11:17AM -0500, Matthew Knepley wrote:
> > that everybody uses because everybody has been using it and has
> > time, energy, code-base, and know-how invested in it (FORTRAN is
> > an example of something that is a standard in multiple senses).
> > Inertia prevents scientists from scrapping existing
> > scientific/engineering code in favor of better ones -- the present
> > code runs and gets results.  Today, we are seeing people willing
> > to take a leap with PDE codes and jump into these new-fangled
> > automated things.  However, if we wait some n years to start
> > selling FEniCS components or an integrated FEniCS system, then we
> > have to overcome the inertia of people having already invested in
> > other systems (e.g. FreeFEM, Deal) and being hesitant to change.
> > The sell becomes not "you should use an automated system" but "you
> > should scrap your current automated system in favor of mine".  I
> > claim the latter will be a harder sell -- the technical merit of a
> > system matters more when people are confronted with two new
> > products (I don't have a car, I think I'll buy one -- what's the
> > best one out there that I can afford?) and told to choose one than
> > it does when they have a working product are asked to scrap it for
> > the latest/greatest (I have a Ford, do I really need to upgrade to
> > a Volvo?  Sure, it may be great, but I can get where I'm going
> > just fine without spending any more money or time looking for a
> > new car)
> >
> > the world but we can't sell it to plasma physicists or geologists
> > or whoever, we have not set a new standard in computational
> > mathematical modeling.  If our would-be clients are already
> > committed to other projects, we have not set a new standard in
> > computational mathematical modeling.  If we develop a system that
> > is not as good as others, we have not set a new standard in
> > computational mathematical modeling.
> 
>   Neat discussion, and in my opinion long overdue in scientific
> computing which tends to focus on easy metrics (flops, peak) with no
> clear connection to reality, as well as funding sources. I want to
> mention that we should not think that all components are always used
> the same way, or even that we can think of all the ways consumers
> will use them. That is what innovation is about.
> 
>   For instance, FIAT can be used standalone to generate quadrature
> tables for an element, which are then compiled in. Even here it is a
> vast improvement over stuff worked out by hand or copied from
> tables. However, it an also be used at runtime to define static
> structures, or as part of a code generation system. But FFC goes
> farther, and uses FIAT to exactly integrate an arbitrary form. This
> probably does not exhaust the uses, but shows that one component may
> be used lots of different ways.  The metrics I like for FEniCS
> components (squishy as they may be) are conceptual fertility and
> ease of use.
> 
>   Lastly, standards are great. But in my opinion, all standards are
> just a community admitting that someone has done a good job. That is
> why standards efforts which do not embody advances made by actual
> simulation (ESI, CCA) never work. The best way to integrate FEniCS
> into the community is to work with application groups directly.
> 
>      Matt

My point on this is that it is easier to create new standards with
small, flexible components with limited scope. (Which does not mean we
can't bundle things and distribute as a whole.) FIAT is one good
example of this.

Maybe (probably) we won't be able create one big system that everyone
uses, but some of the components we develop in the process may well
become standard and it's difficult to say at first which components
will gain acceptance.

/Anders

---

From: "Robert C. Kirby" <[email-masked]>
Date: Mon, 26 Sep 2005 13:07:14 -0500

> arbitrary form. This

Another benefit of components.

> The metrics I like for FEniCS components (squishy as they may be)  
> are conceptual fertility and ease of use.
>
The first of these is a nice way of rephrasing my comment that we  
have to be about ideas.

> just a community admitting that

I agree with this.  This may mean finding ways of butting our pieces  
into their codes (e.g. putting FIAT into Sundance of CIG as a way to  
sell weird elements/more than linears to the apps people using it)  
rather than/on top of doing our own thing just the way we would want it.

However, we are seeing certain fields (e.g. geosciences) are ripe for  
significant reinvestment into codes.  My comments are intended to  
suggest that we need to actively find ways of selling what we can to  
these communities.

Rob Kirby

---

From: "Robert C. Kirby" <[email-masked]>
Date: Mon, 26 Sep 2005 13:10:37 -0500

> become standard and it's difficult to say at first which components

But by whatever definition of "standard" we use, we need to have  
those small flexible components and/or a system be adopted by a  
signficant user base outside of our immediate circles.  These means  
actively seeking out users and peddling our wares to high-impact  
application groups.  Setting a standard is an active, outward  
reaching activity.  I'm saying we can't just be passive and hope  
people come to us and see the light.

Rob Kirby

---

From: Anders Logg <[email-masked]>
Date: Mon, 26 Sep 2005 13:34:55 -0500

> people come to us and see the light.

I agree. One example of this is FEniCS'05 coming up in a couple of
weeks, but we could/should do more.

Another comment I would like to make is that the level of outward
reaching activity needs to match the maturity of the code that we're
pushing. If we take FFC/DOLFIN as an example, it has only recently
stabilized to the point where it can be used by others than the small
group of developers. We're currently working hard on putting together
manuals for both FFC and DOLFIN and they should be ready for the
meeting.

/Anders

---

From: "tomtzigt" <[email-masked]>
Date: Mon, 26 Sep 2005 14:37:06 -0400

Rob et. al.

  Coming from the commercial world, this last paragraph hits home: you have
to solve people's problems for them to come your way. Even when you solve
their problems, you still need to 'grease the skids' to win them over. The
best way that I think open source software can do this is by having
well-defined and complete, working examples for key problems. It needs to be
interesting, but small enough so that a prospective 'client' can see what is
going on. This stuff needs to be perfect: I have a 10 minute rule for open
source software: anything that doesn't start working within 10 minutes, I
will ignore. 

  What I have found is that if the key examples have sufficient appeal,
others will jump in and smooth the rough edges, if there are any. In CMM,
the application stack is sufficiently complex that you need a handful of
very different software engineering disciplines to build out the whole
stack. I am talking here about CAD, 3D graphics, statistics, large scale
software development, and QA, and it is unlikely that a fully integrated
application can materialize without bringing in folks that have
fundamentally different views of the world. Divide and conquer is the key
here, but what components contain, and how components need to be composed is
a very difficult sw engineering problem, that will have as many answers as
there are sw architects.

  Another sobering statistics is that for every line of code in the main
branch there are three lines of code needed in the infrastructure (build
system, regression system, QA, release engineering, etc.). The bigger your
system gets the more inertia the support system exerts on the core. Given
these statistics, and limited resources, you are effectively forced to
concentrate on doing few problems well. But you can expand your world of
influence by 'solving' integration problems with other efforts. This has a
secondary benefit and that is that trying to solve the integration problem
you get a close up view of another 'interpretation' of the same problem:
both in terms of software engineering as well as in mathematics. This
experience is very valuable and is gained in much less time then if you had
to do the whole package yourself. As the saying goes: A fool learns from his
own mistakes, but a genius learns from mistakes other people make.

Theo

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Robert C. Kirby
Sent: Monday, September 26, 2005 2:11 PM
To: Anders Logg
Cc: Kevin Long; [email-masked]; Discussion of FEniCS development
Subject: Re: [fenics-dev] Re: FEniCS

Rob Kirby

---

From: Matthew Knepley <[email-masked]>
Date: Mon, 26 Sep 2005 20:43:29 -0500

> own mistakes, but a genius learns from mistakes other people make.

  While this might convince a lot of people that configure, build, and packaging
are inherently complex, I believe that no real hard thinking has been put into
these components. Instead, we see slavish reproduction of what shuold have been
throw away ideas and prototypes. Witness the longevity and dominance of make.
Hopefully we have the courage to reinvent these broken systems in the same way
that we plan to reinvent numerics. To reiterate, I do not believe that WE need
to concentrate on a few problems, unless by that you mean first order nonlinear
PDEs. We should allow anyone to easy construct and solve these. Its important
to motivate ourselves with problems, but not to make them the focus of the system.

     Matt

---

From: Anders Logg <[email-masked]>
Date: Mon, 26 Sep 2005 21:49:57 -0500

> to motivate ourselves with problems, but not to make them the focus of the system.

I agree, and we should probably give BuildSystem a shot at some point.

Matt, are you pushing it actively (web page, manual etc)?

/Anders

---

From: Matthew Knepley <[email-masked]>
Date: Mon, 26 Sep 2005 22:00:37 -0500

> Matt, are you pushing it actively (web page, manual etc)?
                                     ^^^ I'm too mathy

  I do have a partial manual, but of course it would benefit from others work. I
just got back from SciPy '05 and there was a lot of interest. Particularly from
the matplotlib guy John Hunter, who incidentally is at U of C medical. I definitely
will bring this tpoic up at FEniCS '05, and maybe I should give a talk on it.
Barry said he was trying to come, and I am going to talk to Paul Hovland as well.

      Matt

---

From: "tomtzigt" <[email-masked]>
Date: Tue, 27 Sep 2005 09:09:59 -0400

Matt:

  I think I understand where you are coming from but I just want to make
sure: are you saying that the support systems that surround a typical code
are frequently anemic and are rehashed where it should have been redone?

  I am very interested in hearing your thoughts on how you have solved the
build and configuration problem: we spent millions of dollars a year on this
problem, and if there is a solution, I would like to know!

Theo

P.S. the reason why make is still so ubiquitous is that when you start with
an OS port, particularly in the old UNIX days, you tend to bootstrap the
whole development with make. You have your hands full with getting the
kernel going that you really didn't have time or interest in first rewriting
your build environment. Now all the developers are proficient with make, and
the rest is then simple familiarity. This is still happening today when
folks are creating new sw development environments for embedded devices. 

-----Original Message-----
From: Matthew Knepley [mailto:[email-masked]] 
Sent: Monday, September 26, 2005 9:43 PM
To: tomtzigt
Cc: 'Robert C. Kirby'; 'Anders Logg'; 'Kevin Long'; [email-masked];
'Discussion of FEniCS development'
Subject: Re: [fenics-dev] Re: FEniCS

> own mistakes, but a genius learns from mistakes other people make.

  While this might convince a lot of people that configure, build, and
packaging
are inherently complex, I believe that no real hard thinking has been put
into
these components. Instead, we see slavish reproduction of what shuold have
been
throw away ideas and prototypes. Witness the longevity and dominance of
make.
Hopefully we have the courage to reinvent these broken systems in the same
way
that we plan to reinvent numerics. To reiterate, I do not believe that WE
need
to concentrate on a few problems, unless by that you mean first order
nonlinear
PDEs. We should allow anyone to easy construct and solve these. Its
important
to motivate ourselves with problems, but not to make them the focus of the
system.

     Matt
-- 
"Failure has a thousand explanations. Success doesn't need one" -- Sir Alec
Guiness

---

From: Anders Logg <[email-masked]>
Date: Tue, 27 Sep 2005 08:33:59 -0500

> Barry said he was trying to come, and I am going to talk to Paul Hovland as well.

It would be great if Barry and Paul could come. I'd like to hear about
BuildSystem and also Sieve if possible.

/Anders

---

From: Matthew Knepley <[email-masked]>
Date: Tue, 27 Sep 2005 12:17:00 -0500

> problem, and if there is a solution, I would like to know!

  Solved is something I reserve for math problems (even there it is dicey),
but engineering solution "do better". We definitely kick autoconf's butt,
and nothing comparable exists in Windows since they have such ironfisted
control. I will talk about this at FEniCS '05.

         Matt

> folks are creating new sw development environments for embedded devices. 

   I would lump this mindless make fad in with the overall lack of creativity
or ambition in the OS arena (e.g. Rob Pike's article on the death of OS
research). However, this is also another contributing factor. I believe the
abstractions are EXTREMELY weak. Make introduces the DAG and a single predicate,
then stops. Packaging systems are worse. I don't believe OS even begins before
Hoare's theory of cooperating processes. Our configure has made a little progress
I think, but the build stuff is still crap, albeit better crap than make. I
would love it if we made progress here.

         Matt

---

From: Kevin Long <[email-masked]>
Date: Tue, 27 Sep 2005 11:18:38 -0700

> control. I will talk about this at FEniCS '05.

Matt,

I wholeheartedly agree with your contention that the abysmal state of systems 
codes can be improved by the same sort of careful CS design we're trying to 
do in our FE codes. 

For example, a few years back, Paul Boggs and I did this with GUI design: we 
wrote a code that read an XML description of the task the GUI was to 
accomplish and produced the Java components to carry it out. Our foray into 
GUI-land was spurred by a desire within Sandia to have GUI interfaces for 
optimization. Since we had no intellectual interest in writing such a GUI, we 
decided to slay the beast once and for all by writing a single code to write 
GUIs for us. Unfortunately, once we did the proof-of-concept code we were 
never able to find a suitable programmer to hand it off to for transition to 
production: the good Java coders at Sandia didn't think at the level of 
abstraction required to understand our approach. Paul and I of course wanted 
to get back to mathematical software, so we dropped it and the code now lies 
on a disk somewhere unused. I still think it was a nice piece of CS work, 
though.

This same basic idea -- solve a general problem once, abstractly -- can be 
applied throughout systems programming as you have done with your configure 
system. As bad as they are, even the horrible autoconf/automake system and 
the less-horrible-but-still-bad make system were first attempts at 
generalizing certain systems tasks rather than writing a bunch of one-off 
scripts.

- kevin

---

From: Matthew Knepley <[email-masked]>
Date: Tue, 27 Sep 2005 13:47:10 -0500

> on a disk somewhere unused. I still think it was a nice piece of CS work, 

  Very cool. I know that Paul DuBois had a similar effort at Livermore, but
of course it made Python GUIs from XML.

> generalizing certain systems tasks rather than writing a bunch of one-off 

  True, even Perl was beautiful once. I respect the original autoconf, I just
think it betrayed its mission. Reading the original help, the idea was to TEST
everything, rather than read a sort of database of settings as Larry Wall's
competitor at the time did. However, all too often, autoconf goes back to the
database approach when the going gets tough. I'd like a roundtable at the
FEniCS get together about abstractions for build since I still do not have
great ones there.

      Matt

---

From: Anders Logg <[email-masked]>
Date: Tue, 27 Sep 2005 17:38:38 -0500

> FEniCS get together about abstractions for build since I still do not have

That would be great. Any other thoughts/suggestions on how to organize
the meeting are welcome. There are two days October 19-20 and I'm
thinking there will be about 12 talks. Other than that, the schedule
is up for discussion. Also, many of us will be at TTI for the entire
week (Claes, Johan, Hans Petter, Garth) so there will be plenty of
time for discussion outside of the program.

/Anders