From VSCHELDE@STEEVAST.RUG.AC.BE Tue Nov 3 08:52:18 1992 Date: Tue, 3 Nov 92 11:56 N From: VSCHELDE%STEEVAST.RUG.AC.BE@OHSTVMA.ACS.OHIO-STATE.EDU Subject: solvation energy To: chemistry@ccl.net Dear Netters, I started my research recently and began collecting information on solvation energy in protein folding.Two articles of W.S.Still(1) and A.D.McLachlan(2) are attractive to use in my research. Who has experience with continuum models and wants to help me ? Are there computer programs ready to use or that can fit a MM or MD program? I am also looking for the email addresses of Still and McLachlan. (1) Semianalytical treatment of solvation for MM and MD. J.Am.Chem.Soc.1990,112,6127-6129 (2) Solvation energy in protein folding and binding Nature vol.319 16 jan. 1986 Jean-Luc ********************************************************************** Verschelde Jean-Luc, Lab for mathematical physics State University Ghent Krijgslaan 281 S9 9000 Ghent,Belgium tel:091/644793 Fax:091/644994 Email:VSCHELDE@steevast.rug.ac.be ********************************************************************** From DSMITH@uoft02.utoledo.edu Sat Nov 3 04:28:11 1992 Date: 03 Nov 1992 08:28:11 -0400 (EDT) From: "DR. DOUGLAS A. SMITH, UNIVERSITY OF TOLEDO" Subject: Re: MPP vs. workstations? To: jle@world.std.com In reply to Joe Leonard's comment about clustered workstations, I know that MacroModel 3.5x (yes, MD and MM code) runs on a cluster of HP 7xx workstations. I think that Dan Chodosh has done the work along with Clark Still's group, and I think I saw a preprint of a paper he has submitted or accepted to The Journal of Computational Chemistry. Again, anyone wish to comment further? Doug Smith Assistant Professor of Chemistry The University of Toledo Toledo, OH 43606-3390 voice 419-537-2116 fax 419-537-4033 email dsmith@uoft02.utoledo.edu From DSMITH@uoft02.utoledo.edu Sat Nov 3 04:24:58 1992 Date: 03 Nov 1992 08:24:58 -0400 (EDT) From: "DR. DOUGLAS A. SMITH, UNIVERSITY OF TOLEDO" Subject: Re: ECPs, transition metals, and parallel computing To: CUNDARIT%MEMSTVX1.BITNET@OHSTVMA.ACS.OHIO-STATE.EDU Maybe I am not the one to talk about this - but there is a Grand Challenges project at the OSC which involves researchers from around the state and around the country. IBM has loaned OSC a Power Visualization System (PVS) which seems aptly suited for moderately parallel computing. Dave Heisterberg of OSC, with help from persons at IBM (I don't know names so I can't give credit) have ported HONDO 8 to this platform. I understand that Rod Bartlett's group is supposed to be porting ACES II. Would the Principles care to further elaborate? Oh, by the way, what do the netters thing of parallel MOPAC? My group is working on this. Doug Smith Assistant Professor of Chemistry The University of Toledo Toledo, OH 43606-3390 voice 419-537-2116 fax 419-537-4033 email dsmith@uoft02.utoledo.edu From CUNDARIT@MEMSTVX1.bitnet Tue Nov 3 03:19:00 1992 Date: Tue, 3 Nov 92 08:19 CDT From: CUNDARIT%MEMSTVX1.BITNET@OHSTVMA.ACS.OHIO-STATE.EDU Subject: TMs, parallel computing and ECPs To: chemistry@ccl.net Regarding parallel MOPAC: I thought I saw a blurb in Chemical & Engineering News last year that said that Kim Baldridge at San Diego Supercomputer Center had done some calculations with parallel MOPAC. I think it was on a large, conjugated organic system (coronene?). I think it was on the hypercube out at San Diego. Regarding the PVS: I cannot comment on the OSC proposal since I'm not the PI, but Cornell has a PVS (Power Visualization System) which will be available to academic researchers sometime soon (if I understand their literature correctly). Given the applications that Cornell has highlighted in their Newsletter, it should be quite an exciting "grand challenge" machine (with more than 8Mb/node!). From djh@ccl.net Tue Nov 3 04:17:59 1992 From: djh@ccl.net (David Heisterberg) Date: Tue, 3 Nov 1992 09:17:59 -0500 To: chemistry@ccl.net Subject: MPP vs. workstations? Joe Leonard write: >1) I think most/all of the Comp Chem codes run on shared-memory MIMD I think there have been a number of hypercube implementations, no? We have a parallel version of Hondo running on an IBM Power Visualization System. The PVS does have a global memory, but it's used primarily as a disk and communications buffer. The code runs in each processors' local memory. >2) A significant problem slowing the spread of mpp machines is the relative >lack of tools to assist/facilitate the port. Vector machines have had 8-10 Ain't that the truth? We programmed down to the bare system call, rather than using tools like TCG or Linda, and had no preprocessor available. The housekeeping one has to take care of just in copying common blocks around is bothersome enough. This buys us good performance in some areas, such as gradients, but actually makes the fine tuning much more difficult. Another area, that might be mostly of interest to our group, is parallel IO. The PVS has a HiPPI-connected RAID sub-system. We've been able to sustain 55MB/s global memory to disk bandwidth for "toy" C programs, and 45 MB/s from (multi) processor local memory to disk for real Fortran codes. So for us direct SCF is not a priority. The catch is, the RAID doesn't support a UNIX file system, and in fact doesn't support much of a file- system at all! We had to write our own Fortran IO library and change all READs and WRITEs to CALLs to the library. This was more of a learning experience than an attempt to make a production code, but I think there will remain data-intensive applications and some better paradigms for high performance parallel IO remain to be developed. >micro's basically killing everything in site. It's a great time to be a >software developer, but it's tough living on the hardware side. This is >a real problem, because who will enable us to use the new machines if there's >nobody on the inside with application-apecific expertise? Our thoughts exactly! -- David J. Heisterberg (djh@ccl.net) What men value is not rights The Ohio Supercomputer Center but privileges. Columbus, Ohio -- H.L. Mencken From rs0thp@RohmHaas.Com Wed Nov 4 44:28:28 1992 From: rs0thp@RohmHaas.Com (Dr. Tom Pierce) Subject: Re: MPP vs. workstations? To: chemistry@ccl.net Date: Tue, 3 Nov 1992 10:05:28 +22305823 (EST) RE; Joe Leonard's comments > > 4) Nobody's really addressed the opportunity of clustered workstations > as an alternative to shared-memory MIMD machines. I've seen several groups > working on this problem, and Dr. Luthi at ETH has extended it to clustered > Cray's, if you can call a worldwide net a cluster... At my company, we are building a decent network of workstations . These workstations will be for the most part 486s, and a fraction of RISC Unix systems. To take advantage of all those cpu cycles, I have been implementing Monte Carlo methods for the last few years. Exploring problems with a Monte Carlo approach is a quite simple method to running code in parallel. I just have to partition the problem to different processors, pay abit of attention to error recovery (when someone turns off a computer), and basically behave as a 'good' network citizen.Currently I am only using the Unix workstations, but access to the 486s in not to far off. So Clustered Workstations - They work, They're there, and this amount of recoding for Monte Carlo is not very hard. > 5) Many folks have inquired whether there's a win with parallel codes vs. > running multiple jobs, 1 per processor. It seems that if there is ONE job > that must get done ASAP, mpp is the only way to go, but for production > codes in commercial sites, it's a real tradeoff between run time and > throughput. Nobody wants to accept tradeoffs. And today if you have more than one computer available then such a tradeoff maybe unnecessary. Here, we have come to the conclusion that there are some jobs that 'must' be done as-soon-as-possible. However, most jobs do not need immediate answers. So a viable approach is to have a fast server on the network, then use slower computers for routine planned work. This means that a cluster of workstations is quite effective. -- Sincerely, Thomas Pierce, thpierce@rohmhaas.com or rs0thp@rohvm1 Official Disclaimer:"The opinions expressed are those of the writer and not the Rohm and Haas Company." From vazquez@iqm.unicamp.br Tue Nov 3 15:08:06 1992 From: Pedro A.M. Vazquez Subject: Re: MPP vs. workstations? To: CHEMISTRY@ccl.net Date: Tue, 3 Nov 92 15:08:06 GMT-3:00 >In reply to Joe Leonard's comment about clustered workstations, I know that >MacroModel 3.5x (yes, MD and MM code) runs on a cluster of HP 7xx workstations. >Again, anyone wish to comment >further? > Terry Clark, Ken Kenedy & L. Ridgway Scott from University of Houston parallelized Gromos using their Pfortran translator. The results are reported in the article "Evaluating Parallel Languages for Molecular Dynammics Computations" available in the reports directory of karazm.math.uh.edu I don't know if a production version of Gromos resulted from this work Pedro ============================================================================= Pedro A. M. Vazquez | Depto de Fisico Quimica | Instituto de Quimica Universidade Estadual de Campinas | Fone : 39-7253 | Fax : 39-3805 ============================================================================= chemist: [Cambridge] n. Someone who wastes computer time on number-crunching when you'd far rather the machine were doing something more productive, such as working out anagrams of your name or printing Snoopy calendars or running life patterns. May or may not refer to someone who actually studies chemistry. Jargon File v2.9.6 ============================================================================= From mail Mon Nov 2 10:25:06 1992 From: hyper!slee (Thomas Slee) Subject: Reliability of large-scale semi-empirical calculations. To: chemistry@ccl.net Date: Mon, 2 Nov 1992 10:22:31 -0500 Jan Jensen wrote recently, in the "large-scale semi-empirical calculations" thread: > It sure looks like many molecular mechanics studies of > chemical systems could be checked against (if not entirely replaced by) > semiempirical studies. > I think this oversimplifies the problem. As semi-empirical calculations become able to deal with larger and larger systems the criteria for a useful method change somewhat. Specifically, questions of conformation become increasingly important: and while molecular mechanics force fields have been parametrised to reproduce things such as gauche-anti preferences around particular bonds, semi-empirical methods have been parametrised primarily to reproduce heats of formation of molecules in a given conformation, and primarily smaller molecules. You may want to look at studies such as those by Gundertofte et al (J Comp Chem, vol 12, p 200 (1991)) comparing conformational energies by several molecular mechanics methods and by AM1 and PM3: the semi- empirical methods come out with less than flying colours. Also, for ring systems results have been reported that make it clear that semi-empirical methods still have room for improvement: see Ferguson et al (J Comp Chem vol 13, p 525 (1992)). I think there is a fairly widespread belief that semi-empirical and small-scale ab initio methods are inherently more reliable than molecular mechanics methods for conformational problems that is carried over from their success in other areas, and which is not very well-founded. Any comments? Tom Slee From theresa@si.fi.ameslab.gov Tue Nov 3 06:18:59 1992 From: theresa@si.fi.ameslab.gov (Theresa Windus) Subject: parallel MOPAC To: chemistry@ccl.net () Date: Tue, 3 Nov 92 12:18:59 CST Netters: Kim Baldridge at San Diego Supercomputer Center (kimb@sdsc.edu) has parallelized MOPAC for (I hope this is correct) the Cray and Intel iPSC systems. I don't have specific timing information in front of me, so you should contact her if you have more questions. Theresa Windus Department of Chemistry Iowa State University Ames, IA 50011 e-mail: theresa@si.fi.ameslab.gov From jas@medinah.atc.ucarb.com Tue Nov 3 08:16:40 1992 Date: Tue, 3 Nov 1992 13:16:40 -0500 To: chemistry@ccl.net From: jas@medinah.atc.ucarb.com Subject: Re: MPP vs. workstations? >As I recall the parallel discussion last year... > >1) I think most/all of the Comp Chem codes run on shared-memory MIMD >machines, such as SGI's Power series. DOE Lab codes, however, probably >run on (far?) more interesting platforms... There are efforts underway >with several vendors to get codes ported to their platform(s), which is >the real problem with ALL novel architectures and (small) vendors - if >you don't have the application codes, you just can't crack the market... > >2) A significant problem slowing the spread of mpp machines is the relative >lack of tools to assist/facilitate the port. Vector machines have had 8-10 >years to get things down, and the preprocessors seem applicable to >(super)scalar workstations as well. Parallel machines are new, and look >like they'll require FAR more effort to harness their power - it's almost >easier to design from scratch than port (again, DOE folks can probably >comment at length re: this). > >3) Fortran 77 might be a limiting factor - as the mpp machines seem to >look for various flavors of newer Fortrans (F90, Fortran D, etc). There >was also several discussions re: language selection and programmer/scientist/ >grad student training that were pertinent to this. Object-oriented >techniques, and vendor/multi-vendor tools will play a role here. > >4) Nobody's really addressed the opportunity of clustered workstations >as an alternative to shared-memory MIMD machines. I've seen several groups >working on this problem, and Dr. Luthi at ETH has extended it to clustered >Cray's, if you can call a worldwide net a cluster... > >5) Many folks have inquired whether there's a win with parallel codes vs. >running multiple jobs, 1 per processor. It seems that if there is ONE job >that must get done ASAP, mpp is the only way to go, but for production >codes in commercial sites, it's a real tradeoff between run time and >throughput. > >6) The recent Cray announcement (mpp w/Dec Alpha) is merely another example >that the "attack of the killer micro's" ended several years ago, with the >micro's basically killing everything in site. It's a great time to be a >software developer, but it's tough living on the hardware side. This is >a real problem, because who will enable us to use the new machines if there's >nobody on the inside with application-apecific expertise? > >Joe Leonard >jle@world.std.com > >P.S. There are several parallel QM codes - our SPARTAN package, GAUSSIAN 92 >(both thanx Roberto!), GAMESS-UK (Martin Guest), ... > ------- Has anyone checked into what the folks at IBM's Engineering/Scientific Support Center in Dallas have done regarding RS/6000 clusters and Comp Chem codes? Perhaps Dennis Gerson can respond (Dennis?) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= JACK A. SMITH ...................................................................... Union Carbide Corp. || Phone: (304) 747-5797 Advanced Technical Computing || FAX: (304) 747-5448 P.O. Box 8361 || S. Charleston, WV 25303 || Internet: jas@medinah.atc.ucarb.com -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= From kpc20@cas.org Tue Nov 3 09:33:23 1992 Date: Tue, 3 Nov 92 14:33:23 EST From: kpc20@cas.org (Kevin P. Cross Ext. 3192 Room 2209B) Subject: Re(2): ECPs, transition metals, and parallel computing To: "DR. DOUGLAS A. SMITH, UNIVERSITY OF TOLEDO" Doug, I have talked with Robert J. Harrison at the Theoretical Chemistry Group at Argonne National Laboratory about MOPAC parallization. I think he hit on the heart of the problem. Some of his comments are re-iterated below: "As for MOPAC it should be quite straight forward to get good speed up on a few (8-16?) processor machine/network, but beyond that the matrix diagonalizations and transformations will dominate (as for all semi-empirical codes) and these are non-trivial to parallelize efficiently (big research area in fact in computer science). Dr. Klaus Schoeffel (schoeffel@sc.ZIB-Berlin.DE) was going to parallelize it at one stage but what happened I do not know." How good are parallel matrix diagonalization routines these days? If you are going to start from scratch I would recommend using a (free) package like PVM/Hence available from netlib@ornl.gov I have taken a different approach as I am interested in calculating the properties of many structures rather than optimizing just a few. Consequently, I have developed routines to replicate the entire MOPAC executable with one structure on different machines and to montor/control the distributed job. I have used the routines to calculate properties for 60,000, un-optimized, CONCORD structures on 25 SUN Sparcstation-1s. It took about a week (instead of 6 months on one machine). Sincerely, Kevin P. Cross, Ph.D. ================================================ Kevin P. Cross, Ph.D. Research Chemical Abstracts Service 2540 Olentangy River Road P.O. Box 3012 Columbus, OH 43210 kpc23@cas.org Internet kpc23@cas Bitnet (800)-848-6538 Ext. 3192 ================================================ From berkley@wubs.wustl.edu Tue Nov 3 09:07:08 1992 Date: Tue, 3 Nov 92 15:07:08 -0600 From: berkley@wubs.wustl.edu (Berkley Shands) To: chemistry@ccl.net Subject: MPP vs workstations I've done some extensive work to support "clustered" workstations as a pseudo-MPP machine. The major benefit being you can add and subtract computing power as needed for a problem. The fixed MPP way is preferable in that its only one box, not several, thereby making "fork()" or "pthreads()" an atractive solution. The workstation route has the advantage of costing lots less, uses existing hardware, and can eat spare cycles when they are available. But you then have to support hetero-processor types, detect failures, and the like. One has the up front BIG hardware costs, the other has the people cost to keep it going. It does depend on the frequency of use to justify which is better. I thought it was more fun to see a VAX, a CONVEX, a SUN-4, and ESV, an SGI 4d/380 and an IBM RS/6000 all crunching on the same problem set (and actually getting the right answer!). Which is right for you? Well, everyone has an opinion :-) berkley From jas@medinah.atc.ucarb.com Tue Nov 3 12:00:55 1992 Date: Tue, 3 Nov 1992 17:00:55 -0500 To: chemistry@ccl.net From: jas@medinah.atc.ucarb.com Subject: Re: ...parallel computing > >Oh, by the way, what do the netters thing of parallel MOPAC? My group is >working on this. > >Doug Smith I think exploitation of even the most course-level parallellism in MOPAC (or any other Comp Chem code) would be quite beneficial and easily implemented in a cluster environment, namely: - Line searches - Rigid and optimized grids/reaction paths - Vibrational frequencies - Transition state searches (from both sides at once? and inside out?) - Multiple IRC/DRC trajectories (+/- branches, multiple modes, multiple KE's) - ESP maps This is more aptly called cooperative computing, but these are relatively no-brainer exploitations of a multiple workstation environment to improve throughput on typical production jobs. What would be nice is for programs like MOPAC, which are becoming so ubiquitous on the network, to adopt a server-like architecture, continually polling a well-know port for course-grain tasks (like a single-point SCF). Then a relatively simple task-broker front-end (client), on behalf of a user job request, could broadcast its needs over a network (or even the whole Internet), delegate individual tasks based on responses (and some simple heuristics to help optimize overall throughput), and then collect the pieces back into a coherent job. With an AFS-like filesystem available, where large files don't need to be transfered, this becomes even more effective. Then one can concentrate on the fine-grain tasks (within a single-point SCF, say) at the MPP level. There's at least one example of such a loosely-coupled 2-tiered approach in the QMD/QMC world using multicasts over the Internet (I'll post the reference when I locate it). -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= JACK A. SMITH ...................................................................... Union Carbide Corp. || Phone: (304) 747-5797 Advanced Technical Computing || FAX: (304) 747-5448 P.O. Box 8361 || S. Charleston, WV 25303 || Internet: jas@medinah.atc.ucarb.com -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= From AHOLDER@VAX1.UMKC.EDU Sat Nov 3 10:47:01 1992 Date: 03 Nov 1992 16:47:01 -0600 (CST) From: Andy Holder Subject: Conformational energies by Semiempirical methods. To: CHEMISTRY@ccl.net Tom Slee made some comments about semiempirical/ab initio methods and conformational energies. I basically agree with him that these methods are not the all-in-all cure for this problem. MM is essentially derived to reproduce these results and it does a pretty creditable job at it. The quantum methods are parameter- ized to reproduce a vast majority of properties depending on the electron distribution, a quantity that can't really be used dir- ectly, but that must be pointed at from other properties of the system. If you want to know about where the electrons are, you need quantum mechanics. This leads to the whole world of non-classical chemistry and transition states, etc... In closing I'll say here what I say to students that I teach here UMKC (this is not intended as pat- ronizing, so don't blast me, OK?): "Science is a model. It helps us understand in simplifed terms a physical universe that is simply too complex for the human mind. All models by nature are simpfications that fail at some point. Scientific models fail at many and various points. Science is not the TRUTH. If you want ultimate TRUTH go to religion. We scientists don't deal in that stuff." This statement is especially true of us computational chemists. It never hurts to be reminded of this occasionally. Some models are better than others at particular things. (Tom Slee's comment that began this horrible rampage.) I'm glad that MM does a better job that QM at something it was specifically derived to reproduce. That means its a good model for that property. QM is better for other things. "Old professors never die, they just write interminable messages to captive audiences....." Andy Holder =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= DR. ANDREW HOLDER Assistant Professor of Computational/Organic Chemistry Department of Chemistry || BITNET Addr: AHOLDER@UMKCVAX1 University of Missouri - Kansas City || Internet Addr: aholder@vax1.umkc.edu Spencer Chemistry, Room 315 || Phone Number: (816) 235-2293 Kansas City, Missouri 64110 || FAX Number: (816) 235-1717 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= From JWTESCH@DFWVM04.VNET.IBM.COM Tue Nov 3 11:32:15 1992 Date: Tue, 3 Nov 92 17:32:15 CST From: JWTESCH@DFWVM04.VNET.IBM.COM To: chemistry@ccl.net Subject: Parallel Clusters The port of HONDO 8 at Ohio was largely done with the help of Michel Dupuis, working with a person in the PVS group and Dave Heisterberg of OSI. The PVS is not on loan but is currently on a lease until NSF funding comes in.Anyone with questions about chem codes on PVS should contact Rich Sefecka at Watson Research RSEFECK@yktvmh.vnet.ibm.com or phone 914-784-5089. A number of other ab initio codes have also been parallelized on clusters.Joe Golab, Jeff Nichols and others working at the Univ. of Utah parallelizedDISCO and compared PVM, LINDA, and EXPRESS (3 popular parallel programming environments) using a cluster of RS 6000's. Mike Schmidt has a parallel version of GAMESS at Iowa State. State. Michel DuPuis has parallelized portions of HONDO on a cluster. An article in Future Generation Computer Systems 8 (1992) 27-29, North-Hollanddiscusses parallelization of an LCAO-MO method using 8 RS 6000 320's with a 7x speedup. Author Stefzan Brode of BASM AG, Rhein, Germany. Our IBM porting group is actively working on several molecular mechanics/dynamics codes on parallel workstations, and have achieved relatively goodsuccess with systems connected with SOCC or FDDI. (approx 3x from 4 for a start). I think that by next year at this time we will see several commercially available cluster parallel computational chemistry codes on a number of different workstations. John Tesch From mckelvey@Kodak.COM Tue Nov 3 17:21:48 1992 Date: Tue, 3 Nov 92 22:21:48 -0500 From: mckelvey@Kodak.COM To: osc@Kodak.COM Subject: IBM/RS6000 compilers Ouch! We are chagrinned to observe that the relative performance as measured bycpu speed on our MOPAC6 benchmark has been for the worse as time has moved along. My benchmark molecule (4 pyridines in a chain) went from 4' 38'' to 5' 19'' with the latest IBM compiler (rec'd 3 weeks ago). I used -O3 and -ew. Using only -O gave 5' 21 sec. Anyone have a suggestion ? Dennis Gerson ? John McKelvey Res Labs E. Kodak