fenics team mailing list archive

[Matthew Knepley <knepley@xxxxxxxxxxx>]

Johan Jansson <johanjan@xxxxxxxxxxxxxxxx> writes:
> From: tomtzigt <tomtzigt@xxxxxxxxxxxxxxxx>
> To: "'Robert C. Kirby'" <kirby@xxxxxxxxxxxx>, fenics-dev-bounces@xxxxxxxxxx
> Subject: RE: [fenics-dev] components, a counter-example?
> Date: Mon, 26 Sep 2005 16:08:33 -0400
>
> I think this discussion would be helped by a classification of the software
> system Fenics wants to be: Does it want to be
>
> - a flexible software development environment for new algorithms, or
> - a high performance production code to solve big problems
>
> MATLAB is a great development environment for tinkering with new algorithms
> but it isn't useful to try to solve a large problem. Similarly, if you want
> to focus Fenics on helping to explore new algorithms, you may want to forgo
> efficiency and add general abstractions for distributed memory computations
> that would map onto PETSc, and/or Trilinos, data structures. The 20-30%
> performance hit created by the additional abstraction is well worth the
> decoupling, AND you have solved an end users problem again; not linking in
> two environments that do the same thing differently.
>
> The beauty of not being a high-performance code is that you can spend some
> of your software architecture effort on abstractions and how components
> should fit together. If history provides any guidance, systems with good
> abstractions last longer because they provides the vehicle for divide and
> conquer, and more people will be able to contribute to the system. Simply
> relying on the yearly 30% performance improvements of hardware provides some
> protection from being inefficient. Clearly, the inefficiency can't be too
> large, but the standard template library as an example proves that you can
> actually gain efficiency with the right abstractions.

    Actually this is the first thing that I vehemetly disagree with. After many
years developing parallel scientific software, I believe developing anything but
a toy in Matlab or Mathematica is a waste of time. Migration time often outweighs
total development time in a mix of open languages. It is perfectly possible to
develop the right abstractions in parallel and efficiently. This is shown by
early adoption of FIAT and FFC in these systems. We do this in Petsc ALL the time.
I believe the above discussion presents a false dichotomy.

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