From kaupp@vsibm1.mpi-stuttgart.mpg.de Mon Nov 5 11:00:46 1992 Date: 05 Nov 1992 10:00:46 +0100 From: kaupp@vsibm1.mpi-stuttgart.mpg.de (Martin Kaupp) Subject: ECP calculations To: chemistry@ccl.net Dear Netters, Some recent messages have raised the question of the reliability of energies calculated for transition metals with ECPs. It is true that most of the pseudopotential schemes are somewhat biased towards the atomic ground state, which may not be a good starting point for considering molecular TM systems. One way to get around this problem has been shown by Stoll, Preuss, Dolg et al.: The fit is made in a least-squares manner to a multitude of atomic and ionic states. The procedure and ECPs for the first row TMs are given in: JCP 1987,86,866, the second and third-row TM ECPs in: Theor. Chim. Acta 1990, 77, 123, and lanthanide ECPs in: Theor. Chim. Acta 1989,75,173. I have heard that the Stoll/Preuss group presently prepares actinide ECPs, but the valence space apparently has to be quite large. I use the Stoll/Preuss ECPs (also for main group elements) regularly, and my experience is quite encouraging. Martin Kaupp ********************************************************************** * Dr. Martin Kaupp * * Max-Planck-Institut fuer Festkoerperforschung * * Heisenbergstrasse 1 * * D-7000 Stuttgart 1 * * Germany * * * * Tel.: 0711/6860-497 * * Fax.: 0711/6874371 * * email: kaupp@vsibm1.mpi-stuttgart.mpg.de * * * ********************************************************************** From haedener@iacrs1.unibe.ch Thu Nov 5 12:30:03 1992 From: haedener@iacrs1.unibe.ch (Konrad Haedener) Subject: Re: new perl script for SCHAKAL88 viewer To: CHEMISTRY@ccl.net Date: Thu, 5 Nov 1992 11:30:03 +0100 (NFT) Organization: University of Berne, Switzerland Dongchul Lim writes: [...] > > Just curious. What is "SCHAKAL88" program? > -DCL > > * Dongchul Lim | Phone (203) 432-6288 * > * Dept. of Chemistry, Yale Univ. | Email: lim@rani.chem.yale.edu * > * 225 Prospect Street | (130.132.25.65) * > * New Haven, CT 06511 | * SCHAKAL88 A Fortran Program for the Graphic Representation of Molecular and Crystallographic Models by Dr. Egbert Keller Kristallographisches Institut der Universitaet Hebelstrasse 25 D-7800 Freiburg / FRG Copyright (c) 1988 by Kristallographisches Institut der Albert-Ludwigs-Universitaet Freiburg / FRG The program is being distributed by the author at a resonable charge. Details in: E. Keller, J. Appl. Cryst. 22 (1989) 19-22. Hope this helps, -- Konrad Haedener Phone: +41 31 65 42 25 Institute for Physical Chemistry FAX: +41 31 65 39 94 University of Berne Switzerland haedener@iacrs1.unibe.ch From jrb1@st-andrews.ac.uk Thu Nov 5 13:49:29 1992 From: jrb1@st-andrews.ac.uk (James Bews) Date: Thu, 5 Nov 92 13:49:29 GMT To: chemistry@ccl.net Subject: Molecular Graphics MOLECULAR GRAPHICS Could I please have recommendations for MOLECULAR GRAPHICS programs which can be run under UNIX (on SUN workstations) or VMS or MAC or MSDOS microcomputers (in order of preference). These should be high quality programs suitable for use by XRAY crystallographers etc, as a replacement for CHEMX which we ran on a microVAX. Anything available via anonymous ftp or other public domain versions would be of special interest (because of the usual university cash restraints). Of interest would be: COST (prime consideration) Platform UNIX / VMS / MAC / MSDOS Facilities: Symmetry / Mol. Mech. / etc Thanks for your help: Jim Bews jrb1@st-andrews.ac.uk Chemistry Department The University St Andrews Scotland From jan@si.fi.ameslab.gov Thu Nov 5 04:35:02 1992 From: jan@si.fi.ameslab.gov (Jan Jensen) Subject: Semiempirical vs. Molecular Mechanisms Models To: chemistry@ccl.net Date: Thu, 5 Nov 92 10:35:02 CST Tom Slee raised a very interesting point: semiempirical theory is not necessarily better at conformational analysis than molecular mechanics (MM). The two references are very informative (I admit I know very little about MM), and seem to indicate that MM2 is the program of choice. Have similar studies been done with CHARMM? One problem I have with MM, however, is the strong dependence on parameters - semiempirical methods retain some quantum mechanics to (in principle) model chemistry that parameters have not covered explicitly. Is it perhaps possible that semiempirical methods would be better for systems for which MM has not been specifically parameterized, and for which no (or little) experimental data exist to check against? I want to emphasize that I'm not trying defend any method, I'm simply trying to learn. Jan Jensen P.S. I think I inadvertently send an air-mail to the list. My apologies. From burger@violet.berkeley.edu Thu Nov 5 00:44:44 1992 Date: Thu, 5 Nov 92 08:44:44 -0800 From: burger@violet.berkeley.edu To: chemistry@ccl.net Subject: rotation barrier Recently some one came up with a very interesting question/statement about the barrier of rotation for the rotation around the C-C triple bond of acetylenes. In theory there should be no barrier for this rotation (correct) me if I'm wrong). My question then is: Is there any experimental proof for free rotation around the C-C triple bond? Peter From tripos!kathy@uunet.UU.NET Thu Nov 5 04:34:29 1992 Date: Thu, 5 Nov 92 10:34:29 CST From: tripos!kathy@uunet.UU.NET (Kathy Clark Jupiter1) To: uunet!ccl.net!chemistry@uunet.UU.NET Subject: CRC Press phone number needed Does anyone have a phone number for CRC Press? The Cleveland operator has no information. Thanks in advance Kathy Clark kathy@tripos.com From bernhold@qtp.ufl.edu Thu Nov 5 06:41:56 1992 Date: Thu, 5 Nov 92 11:41:56 EST From: bernhold@qtp.ufl.edu To: roberto@boston.sgi.com, chemistry@ccl.net Subject: Historical MPPs -- LCAP I probably shouldn't dispute with someone who was there, but I distinctly remember several talks by Clementi and Dupuis (as well as posters by others in the group) at a number of Sanibel meetings... On Nov 4 7:01pm, Roberto Gomperts wrote: > Even the loosely coupled model in Enrico's lab (that Graham > describes beneath) had fast "pipe-lined" processors (again something > close to a vector machine). > LCAP was a very interesting architecture. It was never meant to > be a "true" MPP (i.e. 100's or 1000's of processors) and it did > not have shared memory. Not strictly vector, but close (pipelined VLIW), and I think that some of the FPSs had MAX boards which were add-on vector units. I also remember a global memory system being added at some point. All of the nodes had access, but I don't recall if it was simultaneous or serialized. The last incarnation of LCAP I heard about was LCAP-3090, where the FPSs were replaced by IBM 3090s. They did have vector facilities in some of these (they were not all identical). I got the feeling that the LCAP systems were almost continually evolving, with model LCAP-1, -2, and -3090 changed only for completely different node hardware (FPS-164s, -264s, and IBM 3090s). >It is remarkable that most of the original (shared memory) paralallel >computers had/have vector CPUs (Alliant, Convex, Cray). Some new ones do too -- notably the CM-5 -- though piplining (super-scalar) is increasingly popular. -- David Bernholdt bernhold@qtp.ufl.edu Quantum Theory Project bernhold@ufpine.bitnet University of Florida Gainesville, FL 32611 904/392 6365 From roberto@medusa.boston.sgi.com Thu Nov 5 07:26:40 1992 To: bernhold@qtp.ufl.edu Subject: Re: Historical MPPs -- LCAP Date: Thu, 05 Nov 92 12:26:40 EST From: Roberto Gomperts Your message dated: Thu, 05 Nov 92 11:41:56 EST > I probably shouldn't dispute with someone who was there, but I > distinctly remember several talks by Clementi and Dupuis (as well as > posters by others in the group) at a number of Sanibel meetings... > > On Nov 4 7:01pm, Roberto Gomperts wrote: > > > Even the loosely coupled model in Enrico's lab (that Graham > > describes beneath) had fast "pipe-lined" processors (again something > > close to a vector machine). > > > LCAP was a very interesting architecture. It was never meant to > > be a "true" MPP (i.e. 100's or 1000's of processors) and it did > > not have shared memory. > > Not strictly vector, but close (pipelined VLIW), and I think that some > of the FPSs had MAX boards which were add-on vector units. > That is right, as I stated above they had a pipeline architecture, not a "true" vector one. What I was trying to convey is that they were/are specialized and fast processors that went beyond simple scalar execution. In order to take full advantage of these processors you had to do something with your "vanilla scalar (VAX) code". This is also true for the newer generations of superscalar/superpipelined RISC chips as you correctly mentioned at the end of your message. Practically all the RISC chips manufacturers are working in one way or another on faster, specialized architectures, as evidenced by, among others, the newest generation of MIPS chips (R4000). > I also remember a global memory system being added at some point. All > of the nodes had access, but I don't recall if it was simultaneous or > serialized. > > The last incarnation of LCAP I heard about was LCAP-3090, where the > FPSs were replaced by IBM 3090s. They did have vector facilities in > some of these (they were not all identical). > > I got the feeling that the LCAP systems were almost continually > evolving, with model LCAP-1, -2, and -3090 changed only for completely > different node hardware (FPS-164s, -264s, and IBM 3090s). > You are right, LCAP was in constant evolution. I witnessed the end of LCAP-1, the bloom of LCAP-2 and I was directly involved in one of the LCAP-3 experiments (10 FPS164, 10 FPS264, 1 IBM3090, 1 IBM380 and 1 IBM340: Talking about heterogeneous systems! :-) ). I was gone by the time the global memory attempts were made and the FPS machines were faced out. It is interesting to look back at those developments and see how parallelism is evolving today. > >It is remarkable that most of the original (shared memory) paralallel > >computers had/have vector CPUs (Alliant, Convex, Cray). > > Some new ones do too -- notably the CM-5 -- though piplining > (super-scalar) is increasingly popular. > > -- > David Bernholdt bernhold@qtp.ufl.edu > Quantum Theory Project bernhold@ufpine.bitnet > University of Florida > Gainesville, FL 32611 904/392 6365 > > -- Roberto Roberto Gomperts roberto@sgi.com phone: (508) 562 4800 Fax: (508) 562 4755 From roberto@medusa.boston.sgi.com Thu Nov 5 06:54:39 1992 To: chemistry@ccl.net Subject: Re: Musings about parallelism... Date: Thu, 05 Nov 92 11:54:39 EST From: Roberto Gomperts APOLOGY: I sent this message by accident before being done composing it. I apologize for the extra net traffic... Your message dated: Tue, 03 Nov 92 21:29:35 EST > The recent flurry of posts about parallelism prompts my $0.02. If > any of this has been said here before, I'm sorry. (I wasn't a subscriber > when parallelism was a topic last year!) > I guess it is time to have my own $0.02 contribution in this interesting thread. > Parallelism is not *that* new for computational chemistry, though I agree > that it is newer than vectorization. Yes, parallelism came after vectorization although vectorization could easily be viewed as a special case of parallelism. It is just a matter of how you define it. I have often compared difficulties for a broad acceptance of parallelism with the early days of vectorization: initially the conversion of code to effectively take advantage of a particular hardware architecture can be seen as an unsurmountable obstacle. And, of course, you have the naive minds that think that a particular implementation of an algorithm will run well on any kind of machine. This leads always to frustration and the dismissal of interesting and good opportunities. These situations occurred before vector machines were popular and we have seen them as parallel machines evolve. But, in the same way as software developers and other users got use to vector codes (either by conversion of by writing from scratch) we are already seeing more and more parallel codes. This very discussion thread is another indication of the growing acceptance and popularity of parallelism. It is remarkable that most of the original (shared memory) parallel computers had/have vector CPUs (Alliant, Convex, Cray). Even the loosely coupled model in Enrico's lab (that Graham describes beneath) had fast "pipe-lined" processors (again something close to a vector machine). > The first use of parallelism for quantum chemistry that I'm aware of was > in Enrico Clementi's lab at IBM in Kingston NY in the mid 80s (see > IJQC Symp 18, 601 (1984) and JPC 89, 4426 (85)). When I started a postdoc > there in Jan 86, both IBMOL (later KGNMOL) and HONDO ran in parallel on the > LCAP systems. Each LCAP had a serial IBM "master" and 10 FPS array processor > "slaves" that acted in a distributed memory fashion, though later > developments added shared memory. The parallel HONDO 8 referred to in > an earlier post here probably descends from that version, parallelised by > Michel Dupuis. Incidentally this is where Roberto Gomperts (hi!) first > learned about parallelism when developing KGNMOL. Many other comp chem > programs were parallelized for LCAP in this lab too. > LCAP was a very interesting architecture. It was never meant to be a "true" MPP (i.e. 100's or 1000's of processors) and it did not have shared memory. The idea was to have a few reasonable powerful processor. Enrico used to say something like "it was better to have a cart be pulled by 10 strong horses than by 1000 chickens". It turns out that for many Monte Carlo and Ab-Initio programs this model is very appropriate. It is not my intention to get into or start a "religious war" between the MIMD and SIMD sects. Given the right program and the right problem both architectures can show their strengths! > In Jan 88 I joined Hypercube (developers of HyperChem), which had been > founded by Neil Ostlund to write computational chemistry software for > distributed memory MIMD computers. Neil's philosphy was (and still is > I think) that "dusty deck" FORTRAN codes do not parallelize well, and > he sought to start from scratch with distributed memory MIMD parallelism > as one of the design criteria. At that time he already had ab initio > and semi-empirical prototype codes running on the Intel iPSC. I developed > a parallel implementation of the AMBER molecular mechanics potential on > the Intel iPSC/2 (written in C) and later in 1988 ported to a ring of > transputers. These semi-empirical and molecular mechanics codes designed > for distributed memory MIMD live on as parts of HyperChem! Once you've > written for a parallel machine it's easy to run on a serial machine like > the PC - just set the number of nodes to 1! For the SGI version of > HyperChem, parallelism is exploited by simulating the message passing > of distributed memory MIMD on multi-processor Irises. This may be the > only parallel SGI comp chem code *not* parallelized by Roberto! ;-) > I think that, putting aside philosophical opinions, the practical thing to do to bring parallelism "to the masses" is to, in an initial stage, try to convert existing (serial) programs to run in parallel with reasonable efficiency. This approach has several advantages, among others: 1. Usually it is not too hard to do 2. As it has been pointed out users often are confronted with the choice of speed vs throughput. In this context it is imperative that: a. running on 1 processor is as simple as Graham pointed out above: "just set the number of nodes to 1!" b. there is no significant loss in efficiency for the parallel code running on 1 processor with respect to the serial code. I am not implying at all that new parallel algorithms should not be developed and implemented. I am just saying that while that is happening and while there is no consensus on what the "standard" or "converged" parallel architecture of the futures is going to be, it would be a pity not to be able to take advantage of parallelism TODAY. I am sorry if what follows, sounds as advertising, it is only intended as illustration and information. At SGI we are committed to do just that. Make parallelism available TODAY and NOW. And in different flavors and forms, trying to stay away from what I called before "religious wars": use the correct approach for the correct algorithm applied to the correct problem. To truly bring this "to the masses" we work in collaboration with the commercial and academic software vendors. > 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. > It's nice to see the growing interest in and acceptance of parallelism, > but somewhat frustrating that we've had to wait so long! In the meantime > we had to make a serial PC version of our software to pay the rent! ;-) > Why did it take it so long? Well, I guess that this is where the accusing finger goes to hardware vendors and to some system software developers. The development of tools to either convert serial codes to run in parallel or to develop parallel algorithms from scratch has been lagging behind. Again I am not saying that there are no tools out there (SGI certainly has a very neat and useful environment for parallel development) but that it has not kept pace with the developments in hardware, both SIMD and MIMD. It has been my experience in different hardware companies that manufacture parallel computers, that the system software developers in this companies, tend to target the naive user, i.e. the person who will just use this "wonderful and magic" compiler that will take your dusty deck and make it run N times faster on N processors!!! (Obviously marketing hype). While these compilers/preprocessors will do a good job on "well behaved" loops (I am talking here clearly about shared memory machines) they have a long way to go before they can efficiently and correctly tackle "real world" codes. My contention is that the focus of the tool-developers should be the applications software developers. We need tools to for expert or semi-expert users. I think that this is the right way to bring parallelism "to the masses" TODAY. And really, if you look at it, many of the users of the programs are not the ones who developed them, and while they might (should) have a basic understanding of the theoretical foundation of an algorithm or method, they have no interest nor time to get involved in the details of its implementation. Mind you, I am not talking about using a program for scientific research as a black box, but in practice people do not care how a program is vectorized as long as it doesn't throw your "CRAY money" away, or how it runs in parallel as long as it performs well when using more than 1 processor. > Someone (sorry I didn't keep the post) commended CDAN for its recent > articles on parallelism - in the late 80's they declined to have Neil write > an article on parallelism in computational chemistry because they said no > one was interested in parallelism! > > Should you worry about porting or redesigning for distributed memory > MIMD? Only if you: > (a) want a single calculation done faster > or > (b) want to tackle a larger calculation. > For throughput you're better off running n serial jobs on n nodes (provided > the jobs fit!). You can do (a) for at least smaller numbers of nodes by > porting a serial code, but for a large number of nodes or (b) you probably > need to redesign to partition your data and hopefully keep data transfers > minimized, to/from near nodes, and overlapped with calculation. > I would make the question more general and not restrict it to MIMD machines. As (I think it was) Joe Leonard pointed out in one of the first mailings of this thread, there are quite a few programs out there that are running in parallel on shared memory machines (and more are forthcoming!). In my opinion, multiprocessor shared memory machines offer an unique development environment to exploit the appropriate level of parallelism in the right place. Take f.e. the case of Gaussian 92. There a mixed model parallelism was used: a distributed memory model via the use of the "fork()" system call and at the same time the allocation of shared memory regions to avoid all the intricacies of message passing algorithms. Also fine grain parallelism was exploited at the loop level (the "magic" compiler) and via the call to (shared memory) parallel routines for linear algebra operations like matrix multiplies. 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 and current developments would make MIMD implementations of MM and MD codes efficient as for example Doug Smith's message on MacroModel and Tim Mattson's info on the work with Multipole algorithms pointed out. > Exploiting parallelism with networked computers is a good idea that > was first demonstrated in the 80s. Bob Whiteside, now at Hypercube, > gained some acclaim by beating a Cray with a bunch of otherwise-idle > networked Suns while he was at Sandia. As well as accomplishing (a), > networked computers can be used effectively for (b), though most people > seem more excited by the potential for speedup. > Yes, this is for sure a good idea as more than one person have pointed out during the discussion in this thread. Important factors are the wide spread availability of reasonable powerful and not to expensive workstations, their underutilization (usually they are idle overnight), the fact that more and more software is becoming available (tools like C-Linda, Linda, PVM,TCGMSG (==p4?)), and the application programs themselves like the ones mentioned here in the net: COLUMBUS, DISCO, GAMESS (UK & US), HONDO, TURBOMOLE (Germany), MonteCarlos, etc. At SGI we have obviously recognized this trend and its importance. We have been working on extending the parallelism in one box to parallelism across different machines and, at the same time, inside machines. I like to call this concept hierarchical parallelism. My driving principle in this efforts are that it should be easy and transparent to do and that the same time it is reasonable efficient. I have been working together with Rosario Caltabiano (also a former LCAP veteran) in the SGI-Boston (Hudson, MA) office. What we have come up with at this point is a fortran and C callable library that is used to mark begin and end of parallel regions, load distribution and to inform what is the entity that is being computed in parallel (f.e. Fock or Force Matrices in Ab-Initio programs). The idea is to have the original (sequential or parallel-in-a-box) code and just introduce 3 calls per parallel region to enable the run over a cluster of workstations. The same program will be running on each of the machines. In our first pass we implemented the library with NFS (auto) mounted file systems as the communication and synchronization protocol. We found out that there are some reliability issues with this mechanism so currently we are putting the last touches on the library implementation based on PVM. Its is very easy to adapt the library to use other tools like C-Linda, Linda and TCGMSG. It is our intention to make these versions as well. To give an idea of what we can achieve let me quote some results of a single point direct scf calculation of a problem with 211 basis functions (6-31g* basis) that converges in 9 cycles, using a COMMERCIAL ab-initio package: NProc NMach Procs Time (sec) SpeedUp Eff 1 1 1 19779 16 2 8-8 1593 12.41 77% 20 3 8-4-8 1314 15.05 75% NProc: Total NUmber of processors NMach: Total Number of Computers Procs: Processor distribution across the machines Time: Time in seconds WALLCLOCK (Elapsed) SpeedUp: Parallel speed up with respect to 1 processor run Eff: Effectiveness in percentages: (Time-of-1-Proc/Time-of-Nproc)/Nproc This program uses shared memory parallelism inside each node. The time per iteration went from 36-27 min to 2.5-1.8 min. The machines were 2 4d/480 and 1 4d/440 and the same program ran without recompilation or relinking. After an initial (general) setup, the program is started from 1 machine and a file controls how many machines and how many processors per machine are to be used. We have currently implemented a "self-adjusting" load balancing mechanism that uses the timing information of a previous parallel region to distribute the load in the current parallel region. This is useful for using processors with different speeds and/or different external workload (i.e. if somebody else is using the machine(s) and you did not know about it at the beginning of the job). > Cheers, > > Graham > ------------ > Graham Hurst > Hypercube Inc, 7-419 Phillip St, Waterloo, Ont, Canada N2L 3X2 (519)725-4040 > internet: hurst@hyper.com > OK, I hope that this information is useful, there is so much to say and to do in this area. I think that we are at the beginning of an explosive growth in the area parallel computing, and computational chemistry is going to be (and is already) one of the major forces driving this (re)volution. -- Roberto Roberto Gomperts roberto@sgi.com phone: (508) 562 4800 Fax: (508) 562 4755 From djh@ccl.net Thu Nov 5 07:51:01 1992 From: djh@ccl.net (David Heisterberg) Date: Thu, 5 Nov 1992 12:51:01 -0500 To: chemistry@ccl.net Subject: Re: Parallel Clusters JWTESCH@DFWVM04.VNET.IBM.COM writes: >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. Some correction is needed here. As Mr. Tesch has no connection with this project it is not surprising he is ignorant of the situation. First, this particular project was entirely an OSC initiative, so one should not necessarily expect to see any product available from this work. Now, while I have this opportunity, I must say we very much appreciate the valuable comments and ideas Dr. Dupuis has shared with us concerning this work. Second, there has been no contribution from the PVS group in the porting effort. Their responsibility has been to provide fixes and updates of system software in response to our bug reports. The PVS group has entertained plans to produce a more general purpose, higher performance Fortran IO library based on what we developed -- and we would be happy to incorporate this -- but as yet they have not succeeded. Third, the formal arrangements concerning the status of the PVS were not properly stated. And in point of fact, they are a matter between the OSC and our local IBM office only. Fourth, Mr. Sefeca has only the most casual connection with this project, and can't be expected to be knowlegeable about its status. -- David J. Heisterberg (djh@ccl.net) What men value is not rights The Ohio Supercomputer Center but privileges. Columbus, Ohio -- H.L. Mencken From whitbeck@snowlake.wrc.unr.edu Thu Nov 5 05:25:42 1992 Date: Thu, 5 Nov 92 13:25:42 PST From: whitbeck@snowlake.wrc.unr.edu (Mike Whitbeck) To: CHEMISTRY@ccl.net Subject: TeX/LaTeX or ? of MOPAC MANUAL Is there an ftp'able (La)TeX file for the MOPAC 6.0 manual? troff? I have the plain ASCII but if there is a TeX version I would prefer that. Thanks, Mike Whitbeck From GBENT@UCONNVM.UCONN.EDU Thu Nov 5 11:39:56 1992 Date: Thu, 05 Nov 92 16:39:56 EST From: Gary Bent Subject: dft excited states To: chemistry@ccl.net Sorry to take so long to reply after sending my inquiry, but I am a klutz at using electronic mail. Thanks to the many people who answered my question a bout exited states from dft calculations. A summary follows, but first another question. As someone suggested, I have been reading the literature. In a boo k, Density Functional Theory by Dreizler and Gross, on page 32 I find "If n(i) is an arbitrary exact excited state density with energy E(i) then the ground state energy functional provides a lower bound for the exact eigenvalue i.e., Ev[n(i)] < or = E(i). The equality holds if and only if n(i) is an extr emum of Ev[n]." Now as I understand it I am using the ground state energy functional when I calculate an excited state. However when I get the excited state, I have onl y an approximate excited state density. Is it still true, that I have a lower bound for the exact energy, E(i)? If this were true, it would be exciting. Ha rtree-Fock and CI gives upper bounds to the exact energy; dft would give a low er bound. The exact energy would be bracketed. There's something wrong, right ? Now for the summary. Gary, I do not have a reference for you on excited states, but I can tell you some useful stuff about DMol. The A' and A" calculations, each represent the ground state of a particular symmetry. Because symmetry has been imposed, the wavefunctions are guaranteed to be orthogonal, and no wariational collapse to hte ground state is possible. I belive that in these cases, DFT may be appropriately applied to excited states. There are a few other examples of this, but I don't have references. B. Delley reported calculations on Fe-porphyrin using C4v symmetry. He got the correct ground state, whereas CI can not. This was presented at the Elmau conference in about 1988. -george fitzgerald george@gravity.cray.com ps. you could test this by running in C1 symmetry. Be sure to rotate the molecule or it wil continue to have "accidental" symmetry in the MO's. You can specify the orbital occupancy you want with the OCCUP keyward. In this case you should collapse back to the ground state. ======================================================================== 44 Dear Gary, Great, however please study literature more. By now there are hundreds at least examples published, showing that DFT works for excited states. I suggest to start with Tom Ziegler, Chem. Rev. 91 (1991) 651 and go back 15 years using his references. Or you may scan for Salahub or our papers in J. Chem. Phys 87 (1987) 6562 or J. Chem. Phys. 96 (1992) 1280. Paper by Delley on porphirine and by Dunlap on C60 is recommended. Reference to Delley is Physica B172 (1991) 185. There is one problem however with this nice DFT performance. You can not define easily excited states unless you have symmetry in molecule. In your example, try to calculate second excited state in A" symmetry. First state I believe you can get ok, but you likely can not even define the second one. Please read Ziegler on page 663 to see this DFT problem, which to my knowledge is not yet completely solved. Best regards, and good luck with DFT even for excited states. Jan ======================================================================== 52 Dear Gary Bent, The misconception that Density Functional methods cannot be reliably used for excited states is unfortunately widespread. Although there is no general solution to the multiplet problem in density functional theory, many valuable results have been obtained, and the potential for future valuable results is vast. For references, I would cite Ziegler's review- Chem. Rev. 1991, 91, 651-667, my own recent review- Noodleman, Case , Adv. Inorg. Chem. 38, 423-470, Ross and Solomon, JACS 113,3246. Further, most of the peaks in photoelectron spectra are due to excited states of the ion. There must be hundreds of papers on photoelectron spectra using density functional methods-most of them highly successful. Some of these papers/reviews are cited in Ziegler's review. I could give many other examples. My own career over the last 15 to 20 years has largely been concerned with understanding excited states and spectroscopic properties within density functional theory. Further, density functional approaches are quite prominant in EXAFS and EXANS spectroscopies. I think that the misconception arose becuase the Hohenberg Kohn theorem applies only to the ground state. But this is only an abstract existence theorem, and tells one very little about how to construct practical density functionals, and about their capabilities and limitations/problems. These should be examined on a case by case basis. I view density functional theory as an interesting but incomplete theory founded on the basis of quantum mechanics, and on the thoery of reduced density matrices. Density functional theory strongly satisfies Feynman's dictum: "A great deal more truth can become known than can be proven". This is not to say that a more rigorous foundation is not desirable. People like Mel Levy and Axel Becke are working on this. From time to time, I even make a few contributions of my own at the more applied end of the spectrum, as do others like Brett Dunlap. I hope this is helpful. I was not at all surprised at your results, and I would encourage you to try other related problems. Sincerely, Lou Noodleman The Scripps Research Institute Dept. of Molecular Biology La Jolla, Ca 92137 ======================================================================== 82 Dear Gary, If I understand you correctly you are taking the difference of 2 states, each of whtich is the lowest energy state of that symmetry. In that case, the theorems of density functional theory hold. Of course you still have errors due to the local density approximation, but there is no reason to believe that they are any worse for an excited state, which is the lowest state of that symmetry, than for the absolute ground state. In practice, even if you calculate an excited state of the same symmetry, the results are not totally terrible, even though in this case there is no theoretical justification. ----------------------------------------------------------------------------- Professor Salahub also sent a useful message, but I lost it. 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