All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ward Fenton <fenton@ccic.gov>
To: ultralinux@vger.kernel.org
Subject: Re: Ultra AXmp
Date: Sun, 26 Jul 1998 00:02:48 +0000	[thread overview]
Message-ID: <marc-linux-ultrasparc-90222358531078@msgid-missing> (raw)
In-Reply-To: <marc-linux-ultrasparc-90222358531013@msgid-missing>

a small comment about the bluebook...

http://www.ccic.gov/pubs/blue99/ should be up in a couple days...

another good reference is on its way in the form of the 
Presidential Advisory Committee for Computing, Information, and
Communications, Information Technology, and the Next Generation
Internet's "Interim report to the President".

I tend to agree with the comments made by Ward Deng.

On Sat, 25 Jul 1998, Ward Deng wrote:

> > 
> > >From what I have seen on the various lists I belong to, I believe that
> > 80-90% of parallelizable problems fall in the coarse-to-medium grain
> > category that is optimally accessible by a beowulf-type architecture.
> > 10-20% (with some overlap -- the distinctions are not sharp) are
> > optimally accessible by garden variety "parallel supercomputers" like
> > the ones discussed above, and 1-2% are accessible only by exotic
> > systems like current generation Crays or homemade/custom/dedicated
> > parallel systems.
> 
> My background is computational mechanics and I have been working in 
> fluid dynamics and solid mechnics for many many years. I can say most of
> the applications in these fields are not "multi-body" type, ie. Beowulf
> type problems. If you guys are interested in the problems/applications,
> look into the "blue book" or its website (http://www.hpcc.gov/pubs/blue98). 
> 
> It has been hard to communicate computer scientists (:-) since most of them
> do not understand what PDE stands for. ;-) To put it in short, the difficulty
> is from the view of level of discretization. Almost any problem that needs to 
> be simulated numerically is impossible to start from particle level (atoms,
> molecules...). Instead we use _continuum_ to discribe it. In mathmatical
> formulae, we "smoothen" the physical domain and treat it "infinite dimension" 
> (remember Newton's calculus...) then we partition the domain into "finite 
> dimension" such as "cells," "grids" and "elements" so we can calculate 
> the mathematical formulae to get the approximate solutions under certain
> _boundary_ and/or _initial_ conditions. You can just imagine Beowulf problem
> consists around 1 million particles of rigid bodies. How many particles 
> are involved in one cubic-foot of soil in the foundation of your house? How do
> you deal with the particles with irregular shapes with only statistical data
> available? How about add plasticity (soil particle will change its shape)
> and viscousity (moisture...)?
> 
> Of course, we dream someday we can use super-supercomputer to solve our
> problems starting from discrete domain but it is not possible in a forseeable
> future. Beowulf-type COTS systems are very exciting but the majority of 
> numerical problems are not in that category. Searching for low-latency,
> high-throughput inter-processor communication should be still listed high
> on our agenda. At least this is my view.
> 
> Just add a little bit noise into this interesting discussion.
> 
> --ward deng
> 
> Ward Deng, Ph.D                   |  Kachina Technologies, Inc.
> Vice President and COO            |  4708 Douglas MacArthur Road NE,
> Tel: 505-888-5934                 |  Albuquerque NM 87110
> Fax: 505-888-5902                 |  info@KachinaTech.COM
> Email: Ward.Deng@KachinaTech.COM  |  URL: http://www.KachinaTech.COM
> 

  parent reply	other threads:[~1998-07-26  0:02 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1998-07-11 18:36 Ultra AXmp Bob Drzyzgula
1998-07-12  1:56 ` David S. Miller
1998-07-12  2:21 ` Matthew Jacob
1998-07-12  2:29 ` David S. Miller
1998-07-12  5:02 ` Matthew Jacob
1998-07-12 12:54 ` Douglas Eadline
1998-07-12 23:59 ` Bob Drzyzgula
1998-07-13  6:27 ` Qiru Zhou
1998-07-13  6:38 ` David S. Miller
1998-07-13 10:40 ` Bob Drzyzgula
1998-07-13 12:09 ` Xavier Beaudouin
1998-07-13 13:59 ` Robert G. Brown
1998-07-13 14:29 ` Robert HYATT
1998-07-13 14:54 ` Matthew Jacob
1998-07-13 14:56 ` Matthew Jacob
1998-07-13 14:59 ` Matti Aarnio
1998-07-13 15:24 ` Robert HYATT
1998-07-13 15:38 ` Robert HYATT
1998-07-13 16:56 ` Robert G. Brown
1998-07-13 17:04 ` Robert G. Brown
1998-07-13 17:13 ` Lawrence D. Lopez
1998-07-13 17:26 ` Mike
1998-07-14  1:44 ` Shannon
1998-07-14  7:00 ` David S. Miller
1998-07-14 18:07 ` Douglas Eadline
1998-07-14 23:23 ` Bob Drzyzgula
1998-07-15  3:31 ` Dave Wreski
1998-07-15  8:07 ` Ward Deng
1998-07-15 11:14 ` Bob Drzyzgula
1998-07-15 11:27 ` David S. Miller
1998-07-15 15:54 ` Robert G. Brown
1998-07-15 17:11 ` Robert G. Brown
1998-07-15 23:22 ` Luis Ponce de Leao
1998-07-21 23:29 ` Ward Deng
1998-07-25 23:34 ` Ward Deng
1998-07-26  0:02 ` Ward Fenton [this message]
1998-07-26  0:45 ` Rich Martin
1998-07-26  3:34 ` Bob Drzyzgula
1998-07-26  4:00 ` Ward Deng
1998-07-26  4:29 ` Ward Deng
1998-07-26 12:29 ` Bob Drzyzgula
1998-07-26 13:57 ` Douglas Eadline

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=marc-linux-ultrasparc-90222358531078@msgid-missing \
    --to=fenton@ccic.gov \
    --cc=ultralinux@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.