Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!uwm.edu!ogicse!milton!hlab From: uselton@nas.nasa.gov (Samuel P. Uselton) Newsgroups: sci.virtual-worlds Subject: Re: Cray & The Connection Machine: Making a Marriage in Heaven Message-ID: <1991Apr3.061146.5981@milton.u.washington.edu> Date: 2 Apr 91 18:28:21 GMT References: <1991Apr2.054706.24959@milton.u.washington.edu> Sender: hlab@milton.u.washington.edu (Human Int. Technology Lab) Organization: NAS Program, NASA Ames Research Center, Moffett Field, CA Lines: 92 Approved: cyberoid@milton.u.washington.edu [MODERATOR'S NOTE: This is an appropriate coda to the Cray-Connection debate. Thanks! -- Bob J.] From: kilian@poplar.cray.com (Alan Kilian) >What we have here is a difference in application. What I would like to do with >VR is to be able to have a running CFD (Computational Fluid Dynamics) lab and >introduce objects into the fluid flow. For example I'd pull a wing from the >"wing library" and stick it onto an airplane body from the "body library" >and I would immediately see the fluid flow around the wing/body structure. >I could resize the wing by grabbing the tip and pulling. I could change the >angle of attack by grabbing the nose or tail of the body and pulling. >This obviously takes a ton of floatingpoint arithmetic to do. It depends on >the application and the grid sizes, but it's lots anyway. Alan, I don't think you realize how many tons of floating point arithmetic you are specifying. We (NAS Systems Division, NASA Ames) have a high end Cray YMP8 and some very advanced code for doing CFD simulation. To calculate the flow over a wing in isolation takes hours. That doesn't count the prep time deciding how to grid the volume surrounding the wing. Designing grids for complex surfaces (like aircraft bodies) takes man-months to man-years. So I think it will be quite some time before you can >"pull a wing from the >"wing library" and stick it onto an airplane body from the "body library". A stated "Grand Challenge" of the Aerodynamics side of NASA (and of the NAS project in particular) is to get such CFD flow solutions running in interactive speeds by the year 2000. Just being able to change the angle of attack or lower the flaps is EXTREMELY demanding. I don't think you will see aircraft designers >resize the wing by grabbing the tip and pulling because they have a lot more analytical requirements; they don't "eyeball" designs. >So, the moral of the story is that we need gigaflops. Teraflops are required! ANY current machine is going to have to evolve quite a bit to get there. I think that ALL vendors who try to stay near the high end of supercomputing performance are going to need both many processors AND powerful floating point processors. How about MANY, POWERFUL floating point processors? Rumblings I hear say that BOTH Crays are working on systems in which the number of processors go up. And with the recent upgrade to our CM (oh yes, we have one of them too - 32K processors, 1K Weiteks,...) the "new programming model (at least for us in the CFD world) is to think of the machine as 1K Weiteks rather than 32K 1 bit processors. But what does this all have to do with VR? Really? Only that there is a high-end set of "worlds" that people would like to explore, that can absorb as much resource as is available. And people with supercomputers can probably afford VR hardware, software, development,.... For now we are computing our CFD simulations off-line (on Crays, CMs and Intel i860 hypercubes) and developing VR technology to explore the results interactively. > >> Now there is all that I/O to consider - either to the display >> subsystem or to the network. > >> In a VR system each component must perform its >> functions continuously with LITTLE OR NO LATENCY. > >No. this is simply not true. The latency from head motion to display generation >on the HIT labs VPL based VR system is from 1 to 4 seconds. This is a long time >in computer lives. In MY experience, head tracking latency greater than 1/2 second is really distracting, and becomes uncomfortable quickly. The lag has 2 parts: (a) how long does it take to get the new head position info and transform it into useful shape; (b) once you know the new view, how long to redraw the picture. >and this is arguable the best VR system in production. VPL may have the most press, have been doing production longest, and have greatest market penetration and visibility. I would never accept something with 1 to 4 second lag in head tracking. (1) I suspect VPL does better "most of the time". (2) I like our boom mounted head tracking viewer for "real work" although I don't think it gives quite as flashy demos. - higher resolution, no polhemus to get distorted by metal, video signals,... head track in well under 1/60th second including conversion to useful form, I also agree with much of what the other poster (whose message I failed to copy) about special purpose rendering hardware. We drive our VR with an SGI 340/VGX, soon to be upgraded to 380/VGX, because we want to put more visualization primitives into the flow field, and update them. (The project is designed for exploring UNSTEADY flows.)