LHASA?
Hi folks,
Does anyone have any information on a synthesis program
called LHASA? I have heard it runs on a pc.
Thanx in advance for any info.
--
#################################################################
# Jon Erickson e-mail: jaeric "at@at" mtcamm.monsanto.com #
# Monsanto Company, U3E phone: (314) 694-1511 #
# 800 N. Lindbergh Blvd. #
# St. Louis MO, 63167 #
# #
# "What a waste it is to lose one's mind." --Dan Quayle #
#################################################################
From mail Thu Nov 5 22:04:17 1992
Date: Thu, 5 Nov 1992 19:21:14 -0500
From: hyper!hurst (Graham Hurst)
To: chemistry "at@at" ccl.net
Subject: Re: Musings about parallelism...
My good friend Roberto Gomperts <roberto "at@at" boston.sgi.com> added a
lot
to my parallelism musings about the benefits of porting existing comp
chem codes to shared-memory parallel machines. I agree that this is
a viable route to achieving speedup through parallelism, but it is
effectively limited to a small number of nodes (as are shared-memory
computers) and cannot realize the potential benefit of distributed
memory parallelism (including networked computers) of being able to
tackle larger problems with mode nodes (assuming a fixed memory/node).
The latter can be realized with parallelized memory usage.
My musings were specifically about distributed memory MIMD parallelism
(i.e. independent processors not sharing memory with other processors).
simply because that is where most of my parallel experience lies.
I tried to be explicit about that throughout my email, but several
points also apply to shared-memory or SIMD parallelism.
I agree with Roberto that there are different benefit/effort tradeoffs
for different algorithms with different parallel architectures. For
little or moderate effort many existing comp chem codes can (and have)
been ported to shared-memory parallelism with speedups of roughly 4-8
on 8 nodes say. Similar results can be obtained with simple ports
(often simulating shared memory!) on distributed memory machines.
I agree with Roberto that many will be happy with this kind of speedup,
though for throughput n serial jobs on n nodes is still better. (Roberto
may remember me saying I'd rather have 8 hours on 1 node than 1 hour
on 8 nodes when we were IBM! The trouble is I can't wait 8 hours
anymore...)
The point I'd hoped to make was that to get more speedup, or to exploit
parallelism in memory usage, redesign becomes neccessary. Redesign
doesn't have to mean start from scratch, but I don't call it porting
because usually it requires higher level changes (to data organization,
flow, etc.) than those required to switch serial platforms. If these
benefits aren't worth the effort, don't bother!
Roberto wrote:
> [My] message dated: Tue, 03 Nov 92 21:29:35 EST
>> BTW HyperChem's implementation of the MOPAC methods *is* parallel for
>> distributed memory MIMD computers, but we haven't yet convinced
Autodesk
>> to market such a version. :-(
>>
> I should add that SGI's implementation of Mopac (obtainable via
> QCPE) is also parallel. I must confess that it is not one of the
> best examples of an efficient parallel implementation departing
> from an existing parallel code. But I think that any researcher
> would be more than happy if he/she can obtain a result more than
> 2 times faster when using 3 processors than when using 1.
Yes, but I was explicit here about *distributed memory* parallel.
I only added this because people had been discussing parallelizing MOPAC
for iPSC/860s, and the semi-emipirical part of HyperChem was first
implemented for the iPSC.
*I* wouldn't be happy if I only got a speedup of 2 on 3 nodes (and I think
I'm still a researcher...)! ;-)
Bob Harrison (Hi Bob!) was quoted as pointing out that diagonalization was
the tough part of parallelizing semi-empirical codes. This topic has been
around for a while with discussion of a parallel Jacobi algorithm dating
back to '71 (see Math. Comput. 25, 579 (1971)) and parallel QR from '77
(see IEEE Trans. Comput. C-26, 147 (1977)). The problem is a lot easier
if a Jacobi diagonalizer is used, and the penalty for that choice is
offset in geometry optimization, MD, numerical derivatives, or other calcs
with multiple similar diagonalizations because the last solution can be
used a guess for the next diagonalization. The diagonalizer used in
HyperChem is fully parallel, using the one sided parallel Jacobi algorithm
of Pat Eberlein (sorry I can't locate the reference)! Jim McIver's
parallel semi-empirical code (for iPSC/2) also uses this and it may also
be the one in the Kim Baldridge's MOPAC for iPSC/860.
...
> In other cases, given the underlying algorithms of the currently
> available commercial MM and MD programs like Charmm, Discover,
> Sybil, etc. the best parallel implementation is a shared memory
> one (sorry Graham!!). That is not to say that future
> developments would make MIMD implemetations of MM and MD codes
> efficient.
You don't have to wait for the future - I did it in '88! And it's
certainly a currently available commercial program - is there anyone
out there who hasn't heard of HyperChem? Sorry Roberto but there
is nothing about the *underlying algorithms* which makes shared memory
the best parallel implementation. I'm sure there is a lot about
*those programs* which makes you think so though :-). Klaus Schulten,
Herman Berendsen, and Bernie Brooks have parallel MM/MD codes for
distributed memory machines as well (and I'm sure others).
Boy, you'd think Roberto and I were paid by the word at IBM judging
by the length of these posts...
Cheers,
Graham
------------
Graham Hurst
Hypercube Inc, 7-419 Phillip St, Waterloo, Ont, Canada N2L 3X2 (519)725-4040
internet: hurst "at@at" hyper.com