fenics team mailing list archive

[Matthew Knepley <knepley@xxxxxxxxxxx>]

Anders Logg <logg@xxxxxxxxx> 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

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

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