From: jac@ds8.scri.fsu.edu (Jim Carr)
Newsgroups: sci.physics.fusion
Subject: Re: Fusion, simulations and the net
Date: 11 Sep 92 19:44:04 GMT
Reply-To: jac@ds8.scri.fsu.edu (Jim Carr)
Organization: SCRI, Florida State University

In article <11SEP199213080370@lims02.lerc.nasa.gov> edwlt12@lims02.lerc.nasa.gov (MIKE JAMISON) writes:
>This doesn't *exactly* fit the subject of fusion, but, neither have a lot 
>of other posts to s.p.f :)
>
>I've been curious as to the average number of computers connected to the 
>net, and their individual/combined processing power.  At NASA Lewis, we 
>have a scientific VAX cluster, along with the required supercomputers (Cray 
>YM-P, Cyber something or other).  Obviously, their time is well occupied :)

Here at SCRI we have a compute cluster consisting of about 900 Mips of 
various models of the IBM RS-6000 machines.  Certain groups of them 
are connected by a token ring that, I think, now uses fiber and their 
(separate) ethernet strand is filtered from the rest of our machines. 
I think something close to 2 Gflops has been achieved on a 1000x1000 
LINPACK with the PVM system.  These cluster machines are "headless"; we, 
like everyone else, also have some number of workstations in a heterogeneous 
cluster with a distributed queueing system to do work in the background at 
some non-intrusive nice level. 

>At home, however, I've got a 486 that just sits most of the time.  The 
>figures I've heard on the 486 (33 MHz) give it a FLOP rating of about 1 
>MFLOP or so.  Get a million of these thing together on a net (well over 1 
>million 486's have been sold, so this isn't entirely unreasonable) and 
>you've got you Teraflop computer, with enough memory to run a simulation of 
>just about any fusion configuration you want, in the background (we can all 
>send e-mail in the foreground, and barely slow the background tasks down).
>
>I believe a finite-element approach to such a simulation would run fairly 
>well, keeping interprocessor communications down (a machine running at 1+
>MFLOP isn't going to be doing much good if it has spend half its time 
>getting information at 9600 baud [or lower]).

The problem in such applications (especially with finite element methods 
where every cell talks to every other cell at every time step) is precisely 
the interprocessor communication.  Many people here are exploring such 
issues, particularly for very large systems where the aggregate size of 
such a system of computers far exceeds the memory available in most 
supercomputers.  However, 9600 baud does not cut it.  That is the 
reason for a *dedicated* > Megabit network in our machine cluster. 

I do not know if the fusion community is working on this approach, but 
there are some problems where it is extremely cost effective.  There 
are others, of course, where conventional big iron is best. 

>The other consideration is that PCs aren't the only machines connected to 
>the net.

That is an understatement.  There are gigaflop machines on the net. 

>For all I know, some clever people may have written a virus that does 
>something *good* already.  Maybe some simulations are *already* running in 
>the background on the entire net, and most of us don't know it...

These things have been done.  A large factoring problem was done in this 
way on machines across the country with the results accumulated via 
mail (this was an "embarrasingly parallel" problem where no intermediate 
results needed to be shared) and the final calculation done on our CM-2. 
One must, of course, have an account on this machine unless you wish to 
violate the law.

--
J. A. Carr                                    |  "The New Frontier of which I  
jac@gw.scri.fsu.edu                           |  speak is not a set of promises
Florida State University  B-186               |  -- it is a set of challenges."
Supercomputer Computations Research Institute |   John F. Kennedy (15 July 60)