From chemistry-request@ccl.net Fri Apr 19 12:32:50 1991 Date: Fri, 19 Apr 91 12:01 EST From: "Chuck Ulmer, University of Toledo" Subject: G90 Question To: chemistry@ccl.net Status: R Gaussian 90 now has the ability to do direct SCF calculations. I found that using the direct SCF proceedure is almost three times as fast as indirect SCF on the CRAY for the system and basis set with which I am working. My problem is that I cannot use direct SCF proceedures for MP3 single points and I would like to know if I can speed the MP3 single point calculations by setting the SCF convergence criteria lower (there are SCF=SinglePoint and Conv=N keywords). If this is possible, would this affect resulting energies, would this speed calculations significantly, and how would I do this? Chuck Ulmer Department of Chemistry University of Toledo GRX0663@uoft02.utoledo.edu From chemistry-request@ccl.net Fri Apr 19 13:30:41 1991 Date: Fri, 19 Apr 91 12:45:00 EDT From: bernhold@qtp.ufl.edu To: ULMER%UTCHMA@uoft02.utoledo.edu Subject: Re: G90 Question Status: R You will gain nothing in the perturbation theory calculation by changing the thresholds for the SCF calculation. The coefficients from a converged SCF calculation are used to perform a transformation of the integrals form the atomic orbital basis to the molecular orbital basis, in which the correlated calulation is done. Once the molecular orbitals are determined, the effort required for a non-iterative correlated calculation (like MP2-MP4) is fixed. Changing the SCF tolerances will change only the time required by the SCF. (Even for iterative correlated methods like coupled-cluster theory, or the QCI approximations, the convergence of the SCF has very little effect on the time required -- but it is iterative, so it is not absolutely fixed as in perturbation theory.) Moreover, one must be very careful about lowering SCF convergence tolerances on wavefunctions which are to be used as references in correlated calculations. The correlation correction is relatively fine compared to the magnitude of the SCF energy, but for chemical accuracy, these fine corrections are important. The accuracy of the correlation correction is determined by the accuracy of the SCF orbitals (all other factors remaining fixed), so you want an accurate SCF wavefunction to work from. I'm not familiar with G90, but my experience with earlier versions of Gaussian is that the default thresholds are at the high limit of what I would consider a reasonable level of convergence for a correlated calulation. I'd be very careful about changing tolerances. Hope this helps. -- David Bernholdt bernhold@qtp.ufl.edu Quantum Theory Project bernhold@ufpine.bitnet University of Florida Gainesville, FL 32611 904/392 6365 From chemistry-request@ccl.net Fri Apr 19 14:37:04 1991 Date: Fri, 19 Apr 91 13:01 CST From: "JORGE M. SEMINARIO" Subject: Re: G90 Question To: ULMER%UTCHMA@uoft02.utoledo.edu, chemistry@ccl.net Status: R Regarding the G90 question I just wonder why the SCF=DIRECT works for MP2 and wouldnot work for MP3. Anyhow if the HF run was already done, an indirect calculation would take only two SCF cycles using: # MP3/basis_set GUESS=CHECK GEOM=CHECK Jorge Seminario From chemistry-request@ccl.net Fri Apr 19 15:22:54 1991 Date: Fri, 19 Apr 1991 14:46:28 EDT From: FOX@TURING.PSC.EDU Subject: Re: G90 question To: chemistry@ccl.net Status: R In general, reducing the convergence criteria for post-hartree fock jobs is inadvisable and can cause severe numerical problems. A much better way of accomplishing your aim is to run your MP3 calculation as a two part job, 1) run the SCF=(TIGHT,DIRECT) to obtain the wavefunction 2) run the MP3 with GUESS=READ. This requires naming the checkpoint file, %chk=name, and storing it safely between jobs or running this as a compound job, via --link1--. This also helps in cases where you have a large diffuse basis set which is hard to converge at the SCF level but you want the correlation correction. In a recent case I converged a large basis set SCF calculation in 775 seconds then the conventional SCF required 550 seconds to compute the integrals and two SCF cycles at 90 seconds each before the MP3. The alternate conventional SCF required 1900 seconds before it gave up trying to converge the SCF. Doug Fox Scientific Specialist Pittsburgh Supercomputing Center From chemistry-request@ccl.net Fri Apr 19 17:29:13 1991 Date: Fri, 19 Apr 91 16:43:26 EDT From: bernhold@qtp.ufl.edu To: JSMCM@canal.crc.uno.edu Subject: Re: G90 Question Status: R _Any_ correlated calculation _could_ be done by direct methods, but beyond 2nd order, you have to store the t-amplitudes, which are roughly the same size as the two-electron integrals, so direct methods don't gain you anything (well, maybe 50% of the disk space, but not N**2, as occurs in SCF). From chemistry-request@ccl.net Fri Apr 19 18:21:22 1991 Date: Fri, 19 Apr 91 16:54 CST From: "JORGE M. SEMINARIO" Subject: G90 To: chemistry@ccl.net Status: R I noticed there are two kind of answers on the G90 questions. a) Can I use a direct method for MP3 There is no doubt in G90. No b) Can I use the SCF=DIRECT when doing SinglePoint MP3 ? certainly G90 can not do direct MP3 yet, but Can I use DIRECT in the HF portion of the calculation. I noticed "yes" and "not" for this question In G90 language, Does # MP3/basis_set SCF=DIRECT works ? Recall this works for an non-direct MP2. still if the answer is not it can be done in two steps as already posted. From chemistry-request@ccl.net Fri Apr 19 18:59:32 1991 Date: Fri, 19 Apr 91 18:10:42 EST From: "Mr. Mingzuo Shen" Subject: Help: where is the UNIX-DEC mopac6? To: chemistry@ccl.net Status: R Hello, I am trying to help a coworker here to set up mopac6. I copied the UNIX version on ouchem.chem.oakland.edu sometime ago and successfully compiled it on our DECstation 3100 running Ultrix (DEC's Unix operating system). I also tested all the heats of formation in the manual. That was good, except that I removed everything because of disk space shortage. This coworker would like to have mopac6 running on the same machine. However, the UNIX version on ouchem.chem.oakland.edu is gone. We tried the ultrix_certified.tar.Z. There is no Makefile in the archive. So I made a simple Makefile using the default compiler option (-O). Everything compiled without so much as even one compiler error. But the program says it does not recognize any key words we use (such as MINDO)! So we added a DEBUG keyword. We tried the C6H12 molecule with 1SCF option (keeping the DEBUG). The heat of formation is something like +21379 kcal/mol. Obviously something is wrong. The input file was successfully used with mopac5 on the machines in Cornell (CNSF). In short, questions: (1) Where can I find the older UNIX version? I think Dr. Brent Besler put up the UNIX port on ouchem. (2) Failing that, it is possible that the ultrix_certified.tar.Z works on a DECstation 3100 running under ultrix? The thing to know would be what option (we use mips 1.31) to give to f77. (3) We have IBM RS6000 computers here, is there a port of mopac6 to this machine? Thanks in advance for any help! Sincerely, Mingzuo Shen From chemistry-request@ccl.net Fri Apr 19 20:25:35 1991 Date: Fri, 19 Apr 91 19:59 EST From: "DOUGLAS A. SMITH" Subject: Re: Help: where is the UNIX-DEC mopac6? To: SHEN%CCQC@uga.cc.uga.edu, chemistry@ccl.net Status: R No offense intended to Brent Bessler, Jimmie Stewart, or any one else, but -- 1) The original posting by BB of MOPAC 6.0 was never fully tested or certified (Brent told me this). We downloaded it (as did many others) and found it to be buggy. I don't know who, if anyone, was to blame. 2) I got the source code from Jimmie when I was at the USAFA in January for a visit. It compiled and worked fine (except for one test job which would not read multiple inputs). I also got the source from Richard Counts at QCPE, compiled it, etc. The two versions were almost identical, but if I remember correctly, the ANALYT routine was significantly different. 3) While the DECstation port/compile worked fine, we also ported to our Apollo DN4500's. While we could get it to compile and run fine, there were may problems encountered compared to MOPAC 5.0. Version 6.0 just doesn't like to be on a stack based computer (ask Mike Peterson at UToronto or the folks at Cray). 4) Many, many people are having problems with MOPAC 6.0 giving very different answers than 5.0 did, particularly in the dipole moment values. We have also found that an input deck for C6H6N+, the nitrenium ion derived from azepine, which optimized fine in 5.0, gave three different geometries depending upon which minimization routine in 6.0 was used. This would not be too bad except that only one minima was still a seven membered ring! The others were five membered rings, one with the nitrogen in the ring and a two carbon chain, the second with a five carbon ring and the nitrogen as part of the two atom chain. 5) Henry Kurtz mentioned to me that the DIIS optimization routine was buggy, and the best way to overcome any problems with it was to always specify NODIIS as a keyword (I believe he said that this advice came >from Jimmie Stewart). In a conversation with Dave Dixon of Dupont, he said this sounds like a problem with the implementation of DIIS. I am not competent to comment further, so I will defer questions about this to Dave and Jimmie. The bottom line of all this is that MOPAC 6.0 seems too problematical at this point for every day use. We still use MOPAC 5.0 for our optimizations (such a pity! 6.0 is 3-5 times faster!) and then take the optimized geometries for submission to 6.0 if we want to use features that are available only in 6.0, such as ESP (I know that Brent Bessler and Kenny Mertz made their ESP routines for 5.0 available through anonymous ftp - we tried that but I like it better in 6.0 for some reason that defies rationality). We have also taken the parameters from 6.0 (BLOCKDATA) and shoved them into 5.0, so that we can do more elements with a more reliable optimizer. Again, sorry if I stepped on anyone's toes. If someone (Jimmie or another) fixes MOPAC 6.0, I think many people including myself would be appreciative. Doug Smith Assistant Professor of Chemistry The University of Toledo Toledo, OH 43606-3390 voice 419-537-2116 fax 419-537-4033 email fax0236@uoft02.utoledo.edu