fenics team mailing list archive

[Johan Jansson <johanjan@xxxxxxxxxxxxxxxx>]

Hi!

This mail from Theo seems to have been caught by some Mailman bounce
filter, I'm forwarding it to the list manually.

  Johan

----- Forwarded message from mailman-bounces@xxxxxxxxxx -----

...

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.

Theo

-----Original Message-----
From: fenics-dev-bounces@xxxxxxxxxx [mailto:fenics-dev-bounces@xxxxxxxxxx]
On Behalf Of Robert C. Kirby
Sent: Monday, September 26, 2005 3:35 PM
To: Discussion of FEniCS development
Subject: [fenics-dev] components, a counter-example?

I'd like to raise the question as to what degree we can truly  
modularize all of our code into discrete pieces.  I am going to use  
the multiadaptive ODE solver for the sake of discussion because:

1.) It's a really neat piece of work, one of the most interesting  
ideas in ODE I've seen, that other people should be aware of and use.
2.) It is currently neither parallel nor available as a standalone  
package.
3.) I like to pick on Anders :)

Suppose that we want to parallelize and distribute it to maximize its  
effect on the world and become "the standard".  (As an aside, there  
are parallel time-stepping packages like Sundials that are seen as  
"standards" in certain senses.  A parallel multi-adaptive solver that  
can also do DAE could be a worthy competitor)  Obviously to do this,  
we will need some way of communicating components of vectors across  
processors.  As usual, there are two main options here:

1.) we can roll our own using standard C arrays and low-level MPI  
calls :(   I believe that Sundials has recreated things that look  
like PETSc internally to avoid doing very low-level stuff at every turn.
2.) we can use some well-developed, maintained package that does this  
for us, like PETSc.

Moreover, depending on how we implement algorithms inside the solver,  
we might use some linear and nonlinear solution technology, further  
increasing the reliance on PETSc inside.

So, it seems that if we want to leverage somebody else's parallelism,  
we have to buy into a particular package.  Sure, somebody could  
always strip out PETSc and use Trilinos vectors, but that involves  
grubbies and is tough to automate without further grubbies.

Now, suppose that I want to take the new standard in parallel ODE/DAE  
and have Sundance use it.  This seems rather clunky, as I'm forced to  
compile and link *two* linear algebra packages into my code --  
Trilinos for Sundance and PETSc for the time-stepper.  Even if I  
never see PETSc thanks to a well-designed interface, it can  
contribute significantly to the size of the executable and forces me  
to keep up installations of two big codes.

This seems clunky.  Even though it's less modular, it would simplify  
my life as an end-user if the multiadaptive solver were presented in  
an integrated fashion as part of Trilinos.  (Conjecture: Part of  
setting a standard in scientific computing is making end-users who  
don't necessarily share your software engineering philosophy or other  
kinds of philosophy happy.)

 From Anders' standpoint, this is obviously suboptimal -- he would  
have to develop in Trilinos, release his code in Trilinos, etc and  
*not* as a stand-alone component.  Further, if he wants all the PETSc  
universe to have his time-stepping technology, then he must develop  
two different versions of the code...

Software should be modularized as much as makes sense -- I don't  
think it can be absolutized.  We should discuss this both in general  
as well in the particular case of helping Anders' very nice method  
become the standard for time-stepping.

This is also an illustration of how we can't just come up with a good  
idea and declare victory.  Just having a stand-alone module doesn't  
make it a standard.  You have to get people to use it and swear by  
it.  (David Keyes' enthusiasm has contributed heavily to PETSc's  
success.)  One approach to making this happen is to suffer some  
inconvenience (loss of identity?) and implement the ODE solver in a  
specific widely-used system like PETSc where people are more likely  
to use it with a minimal of install/configure/maintain effort on  
their part.  Besides breadth of distribution, it allows more fair  
comparisons with current "standard" methods in terms of accuracy,  
cost, etc and can help justify using the method to people who don't  
care anything about Galerkin methods, just getting the solution.   
This can help make the technical case and hopefully not tell us  
things we don't want to hear.
Are there other approaches that will maximize Anders' impact on  
scientific computing and generally guide the FEniCS project in  
software engineering?


Rob Kirby

"Mathematical software should be mathematical."




_______________________________________________
fenics-dev mailing list
fenics-dev@xxxxxxxxxx
http://www.fenics.org/cgi-bin/mailman/listinfo/fenics-dev






----- End forwarded message -----