Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!mips!cs.uoregon.edu!ogicse!milton!uw-beaver!fluke!ssc-vax!carroll From: carroll@ssc-vax (Jeff Carroll) Newsgroups: comp.arch Subject: Re: massive linpack Message-ID: <4120@ssc-bee.ssc-vax.UUCP> Date: 14 Jun 91 21:53:43 GMT References: <1991Jun8.055711.13457@marlin.jcu.edu.au> <4112@ssc-bee.ssc-vax.UUCP> <1991Jun14.062703.20325@marlin.jcu.edu.au> Sender: news@ssc-vax.UUCP Reply-To: carroll@ssc-vax.UUCP (Jeff Carroll) Organization: Boeing Aerospace & Electronics Lines: 72 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