From jaeric@mtcamm.monsanto.com Thu Nov 5 11:17:25 1992 From: Jon A. Erickson Subject: LHASA? To: chemistry@ccl.net (OSU Comp. Chem. List) Date: Thu, 5 Nov 92 17:17:25 CST 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@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@ccl.net Subject: Re: Musings about parallelism... My good friend Roberto Gomperts 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@hyper.com