Date: Fri, 3 Apr 1992 07:58:56 +0000 (GMT) From: Leif Laaksonen Subject: Re: The wind is changing To: Joe M Leonard Cc: chemistry@ccl.net Hi Joe and the rest of the world, I have been thinking about the same things as you asked about. I have been a scientist/programmer for some years and one of the worst problems is old code. Or rather the problem of reusing old code or parts of it. Most of the old code has not any graphics either. So much about the past. The future, I believe, will be object oriented. I don't think we can afford anymore programs built just for one application, without the possibility to reuse yeasily parts of it in other problems. The basic idea is of course classes. We should start making classes for SCF, CI, MCSCF, MP ... if you are a quantum chemist and MC and MD classes for the other. I will not say that c++ is the name of the language which is using classes but the main thing is that it uses classes. The programming will be done with application builders which generate the interface to the program. All programs will of course have a graphical interface for the pre- and postprocessing. I will not mention the name of any programming languages to prevent any bashing and I'm not saying the all the tools are already there but eventually they will. On the hardware side the workstations and the parallel machines will slowly push the supercomputers against the wall. Before we used crays because they where the only machines to be fast enough and they had memory enough. Now we can get as much memory on almost any machine and I suspect that there are not too many scientific problems that are that time sensitive that one can not wait even for a month for a calculation on a workstation. However, I believe that there will always be problems that have to be run on a supercomputer but there will be less in the future. One should of course not neglect the graphics in general and molecular graphics in particular. Regards, -leif laaksonen --------------------------------------------------------- laaksone@convex.csc.fi Centre for Scientific Computing P.O. Box 40 SF-02101 Espoo FINLAND Phone: 358 0 4572378 Telefax: 358 0 4572302 Voice Mail: 358 486257407 "In every job to be done there is an element of fun" Mary Poppins --------------------------------------------------------- From marc@david.SACLAY.cea.fr Fri Apr 3 01:56:21 1992 Date: 03 Apr 92 08:58:32+0100 From: SBPM Marc GINGOLD To: chemistry@ccl.net, jkl@ccl.net Subject: Re: Comp.Chem.Fees I appreciated very much the joke. The style was good and subtle. To next year! Date: Fri, 3 Apr 92 08:50:54 EST From: "G. Ravishanker" Subject: Re:The wind is changing To: chemistry@ccl.net I agree with most of what was said in the note by Leif Laaksonen. However there are a couple of place where I would like to add some comments. >> On the hardware side the workstations and the parallel machines will slowly >> push the supercomputers against the wall. Before we used crays because >> they where the only machines to be fast enough and they had memory enough. For the most part this is true. What we are discovering is that the data storage capacity provided by the supercomputer centers cannot be matched locally for some time to come. Given the current price of disks for workstations it is hard to imagine coming up with a multi-giga byte storage device and proper backup facilities locally. We of course run everything here and store everything "there", in the supercomputer center (oh,oh!!!!) >> However, I believe that there will always be problems that have to be >> run on a supercomputer but there will be less in the future. I think it depends on where the supercomputer industry will go. If they catch up one way or the other and offer machines that are consistently 10-20 times faster than the workstations and provide several times the memory of a workstation, it could still be attractive. However, it certainly does not look like they are in any hurry to change things around. Ravi From chemistry-request@ccl.net Fri Apr 3 16:14:46 1992 Date: Fri, 3 Apr 92 14:18:47 EST From: memura@stardent.chem.UTOLEDO.EDU (Mike Mura) Subject: 3d PostScript=pex? To: chemistry@ccl.net I heard from a Comp. Sci. friend of mine that an extension to postscript to include 3D structures exists. I believe that it is called pex ( PostScript extension). Beyond this I know very little about it. Perhaps It will become a standard following the success of Postscript. Michael Date: Fri, 3 Apr 92 15:11:24 CST From: doherty@msc.EDU (David C. Doherty) Subject: Re: 3d PostScript=pex? To: memura@stardent.chem.UTOLEDO.EDU (Mike Mura) Cc: chemistry@ccl.net >I heard from a Comp. Sci. friend of mine that an extension to postscript >to include 3D structures exists. I believe that it is called >pex ( PostScript extension). Beyond this I know very little about it. >Perhaps It will become a standard following the success of Postscript. I believe that PEX is actually a 3D extension to X windows (Phigs Extension to X). Allows one to do Phigs over an X wire. -- David C. Doherty Minnesota Supercomputer Center doherty@msc.edu From chemistry-request@ccl.net Fri Apr 3 18:07:49 1992 Date: Fri, 3 Apr 1992 16:49 EDT From: WILLSD@STAT.APPSTATE.EDU Subject: g90 opt bug To: CHEMISTRY@ccl.net I have discovered what is to me a rather mysterious bug in what should be a very simple geometry optimization in g90. The problem occurs with tetrahedral anions such as MgBr4-2 or GaCl4-1, for which the only simple basis in g90 is the sto-3g basis. When these are optimized in Td geometry, the initial rhf calculation is fine, and the program correctly recognizes the Td geometry. However, the first step in the optimization (of the bond distance only) causes g90 to crash with an error message indicating that the symmetry has changed to C3v. Since no angles are changed, and the bond lengths are represented by the same variable, it does not seem possible to get a C3v geometry at any step in the optimization. Has anyone seen problems like this? If so what did you do to solve them? thanks, Steve Williams Chemistry ASU Boone, NC 28608 willsd@conrad.appstate.edu From chemistry-request@ccl.net Fri Apr 3 20:50:19 1992 Date: Fri, 3 Apr 1992 19:46:15 -0500 From: Kerwin D Dobbs Subject: Re: g90 opt bug To: CHEMISTRY@ccl.net, WILLSD@STAT.APPSTATE.EDU Steve Williams and other G90 users, I ran into this problem a long time ago with tetrahedral systems. You described it well...after the first gradient, the opimization gives up because of a supposed change in symmetry. I never bothered the "help" line for G90 users (help@gaussian.com) because I figured my quick solution to the problem was the one that they would probabley give me. The solution is to just disable symmetry altogether with the keyword "nosymm" on the route card. Your molecule will remain in the symmetry dictated by the z-matrix while G90 crunches through the numbers without taking advantage of this symmetry. Maybe Mike Frisch has a word or two on this subject. If it is a true bug, I wonder if it has been fixed in the brand-spanking new release of Gaussian 92? I just got my brochure today in the mail, and let me tell you, this new release has so many new capabilities to explore that I may have to start working 16 hour days to satisfy my interests, 8^). (No, I already work on the weekends!) Kerwin Dobbs From chemistry-request@ccl.net Fri Apr 3 21:56:10 1992 Date: Fri, 03 Apr 92 20:02:31 EST From: SC18000 Subject: RE:ESP.f for MOPAC To: chemistry@ccl.net Can anybody out there send me the esp.f routines for MOPAC6.0. Please send it via e-mail to sc18@NEMOMUS I'm Ken Fountain Sincerely, K.R.Fountain/Prof. of Chemistry From chemistry-request@ccl.net Sat Apr 4 03:14:51 1992 Date: Sat, 4 Apr 92 01:16:54 -0500 From: fredvc@esvax.dnet.dupont.COM Subject: CODE & MACHINES To: chem@chem I read with some interest the comments of Joe Leonard and Leif Laaksonen (sp?) on the alleged merits of learning to write for some of the new machine architectures. I am not convinced that workstations and mpp machines are the as much the wave of the future as they are touted to be. For example, the best of the mpps (CM-n) are turning out to be as expensive as a medium sized CRAY. Also, cache architecture (workstns) has turned out to be a real bottleneck on some of the things we have encountered. A recent article in CACM points out that the lack of software for parallel architectures is a REAL bottleneck. What people want is performance. It has yet to be proven that performance can be gotten out of an mpp machine without a LOT of work. Given the current flux in the marketplace, one could spend a great deal of effort learning to program a machine that will no longer exist in 2-3 years!! Finally, I did an analysis of performance characteristics of minisupers and mpps against supercomputers a few years ago. I concluded that, with the availability of machines like the Y-MP C-90, neither minisupers nor mpps were likely to be competitive on a performance basis. Economic constraints may force consideration of such machines, however. The paper was published in the Int'l Journal of Supercomputer Applications in 1989 (I think). I have seen nothing since to indicate that my analysis was faulty. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ FREDERIC A. VAN-CATLEDGE Scientific Computing Division || Office: (302) 695-1187 Central Research & Development Dept. || FAX: (302) 695-9658 The Du Pont company || P. O. Box 80320 || Internet: fredvc@esvax.dnet.dupont.com Wiilmington DE 19880-0320 || ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++