🚀 go-pugleaf

In article <1991Jun14.062703.20325@marlin.jcu.edu.au> csrdh@marlin.jcu.edu.au (Rowan Hughes) writes:
>This is now only slightly related to architecture, but I'll give my 2c
>worth.

Yup.

Probably belongs in sci.math.num-analysis, but I'm afraid to post there :^)

On the other hand, the IEEE floating point argument probably belongs there
too, but the guy from IBM would find that audience even less hospitable
than this one.

>If Jeff has to solve large (N>5000) dense problems, then he has a real
>problem. In my area (fluid dynamics) the bulk of matrices, originating from
>the Navier-Stokes eqns, are large (n=100,000 is common) and very sparse,
>typically  25 non-zero elements per row. Unfortunately they often have
>zero's on the diagonal (psi-zeta form of NS). These types of problems are
>best solved by methods specifically designed for sparse banded matrices.
>Direct methods (LU, Householder etc) will work quite well, but they
>will never have the capabilities of routines like BICO. 

You're right; we had a real problem. We had two FPS 264s running 168
hours a week, and we needed a special dispensation from upper management
to take the machines down for periodic maintenance. Then we bought a couple
of hypercubes, and suddenly we had more computer time than we knew what to
do with... for a few weeks.

My field is electromagnetics (not static magnetics), and I'll admit that
computational EM has not yet reached the level of sophistication of CFD,
but we haven't figured out a good way to use FEM on Maxwell's equations
yet, due to the hyperbolicity of the PDEs. There are some people who
use finite differences on the type of problems we're solving, but we've
found that the boundary integral methods we use give much more satisfactory
answers. A couple of years ago I worked with some guys who were trying to solve
Maxwell's equations by modifying one of their aero codes, but the answers
were just plain wrong.

I have nothing against using sparse algorithms (or iterative methods) on 
sparse problems. I'm just pointing out that there is a certain segment of
the aerospace industry that is interested in solving large dense problems,
sometimes in environments in which you can't devote $O(10^7) of machinery
to solving them.

>I'd be so bold
>as to suggest that Jeff's type of problem is more the exception, than
>the rule. 

Probably. EM engineers are just learning how to use large computers, for
the most part; but they'll be using them more and more as time goes by.
There's a small group known as the Applied Computational Electromagnetics
Society (ACES) which I keep intending to join, which is largely composed
of people who do this sort of thing (as well as the people who use iterative
methods to solve finite difference formulations). It's about two years off
the ground now.

But I'm sure that EM people aren't the only ones in the world using boundary
integral methods that result in dense formulations...

>The largest problems capable of actually being solved will
>always be sparse.

This is probably true too in general, but the answer to this question in
any specific case is somewhat architecture dependent (have we been booted
out of comp.arch yet?); direct matrix methods parallelize *very* well.



-- 
Jeff Carroll		carroll@ssc-vax.boeing.com

"...and of their daughters it is written, 'Cursed be he who lies with 
any manner of animal.'" - Talmud