>From owner-mailserv@www.ccl.net Fri Apr 4 16:08 EST 1997 Received: from curie.syr.edu for cmartin@curie.syr.edu by www.ccl.net (8.8.3/950822.1) id QAA12928; Fri, 4 Apr 1997 16:08:47 -0500 (EST) Received: by curie.syr.edu (950413.SGI.8.6.12/940406.SGI.AUTO) id PAA17090; Fri, 4 Apr 1997 15:31:37 -0800 Date: Fri, 4 Apr 1997 15:31:37 -0800 Message-Id: <199704042331.PAA17090@curie.syr.edu> From: Charles Martin To: chemistry@www.ccl.net Subject: CCL:electronic correlation Some more comments on non-dynamical and dynamical correlation: An equivalent way to view non-dynamical (or static) and dynamical correlation naturally arises within the framework of very simple pi-electron theory such as the familiar PPP model. The dynamical correlation enters into the pi-electron effective integrals (such as \alpha, \beta, and \gamma) through a good empirical parameterization. The static correlation is then just the pi-pi correlation included by diagonalizing the pi-CI Matrix. From the ab initio point of view, the dynamical correlation enters into the pi-electron effective integrals via time-dependent (i.e. dynamical) many-body perturbation theory. -- ======================================================== || Charles H. Martin || || 2-004 Center for Science and Technology || || W. M. Keck Center for Molecular Electronics || || Department of Chemistry || || Syracuse University || || Syracuse, NY 13244 || -------------------------------------------------------- || cmartin@cat.syr.edu || || cmartin@rainbow.uchicago.edu || || CELL (315) 415-2093 || || OFFICE (315) 443-3754 || || LAB (315) 443-5928 || || FAX (315) 443-4070 || ======================================================== From ROBMARJ@msn.com Fri Apr 11 04:35:28 1997 Received: from upsmot05 for ROBMARJ@msn.com by www.ccl.net (8.8.3/950822.1) id EAA02825; Fri, 11 Apr 1997 04:05:28 -0400 (EDT) Received: from upmajb02.msn.com (upmajb02.msn.com [204.95.110.74]) by upsmot05 (8.6.8.1/Configuration 4) with SMTP id BAA14975 for ; Fri, 11 Apr 1997 01:04:03 -0700 Date: Thu, 10 Apr 97 15:18:42 UT From: "ROBERT NICHOLSON" Message-Id: To: chemistry@www.ccl.net Subject: programs avalible on internet ANY ONE OUT THERE KNOE OF WEBSITES TO OBTAIN FREE COPIES OF PROGRAMS FOR CALCULATING LOG P ELECTRONIC PARAMETERS PKA DIPOLE ETC STERIC PARAMETERS -CONGEST MOLVOL ECT WHAT CNDO PROGRAMS ARE AVAILABLE FREE ON INTERNET E.G. CINMIN REGARDS DR ROBERT NICHOLSON From ps@ocisgi7.unizh.ch Fri Apr 11 06:35:27 1997 Received: from rzusuntk.unizh.ch for ps@ocisgi7.unizh.ch by www.ccl.net (8.8.3/950822.1) id FAA03256; Fri, 11 Apr 1997 05:53:53 -0400 (EDT) Received: from ocisgi7.unizh.ch by rzusuntk.unizh.ch (4.1/SMI-4.1.14) id AA18315; Fri, 11 Apr 97 11:53:43 +0200 Received: by ocisgi7.unizh.ch (950215.SGI.8.6.10/920502.SGI) for CHEMISTRY@www.ccl.net id LAA13395; Fri, 11 Apr 1997 11:53:30 +0200 From: ps@ocisgi7.unizh.ch (Serge Pachkovsky) Message-Id: <199704110953.LAA13395@ocisgi7.unizh.ch> Subject: Analytical CI gradients in semiempirical programs To: CHEMISTRY@www.ccl.net Date: Fri, 11 Apr 1997 11:53:29 +0200 (MDT) X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi everybody, I would like to use this opportunity to thank everybody who'd offered to run my simple test job with Mopac93 once more. Now, I would try to explain the reason for this request, and to pose an additional question. Mopac, since version 6.0, implements analytical gradient for CI energies. The same code is also included in Ampac (starting from the version 2.1, I believe). The implementation is described in Dewar M.J.S., Liotard D.A. (1990) J Mol Struct (Theochem) 206:123, and the theory behind it is quite sound. I wanted to do a few benchmark computations with this implementation. As it was already pointed out on CCL (by Dr. A. Holder, in his message on 13 Jan 1993), " ... some versions of MOPAC and AMPAC 2.1 are broken in certain places when it comes to analytical gradient computation (CI to name just one.) ... ". Indeed, both Mopac6 and Mopac7 Rev. 1 (which I have locally) have problems with the input file given at the end this message. However, it is Mopac93 Rev. 2 which is supposed to be the latest and greatest of all Mopacs out there (;-)), so I wanted to try that as well. Unfortunately, Mopac93 Rev. 2 (thank you, Ernst) still produces incorrect gradient in my test case, even though it is different >from the result produced by Mopac6 and Mopac7 Rev. 1. This brings me to my question: Is there any semiempirical program around which *correctly* implements the method of the paper referenced above? With my best regards, /Serge.P Here is the input. It does a gradient computation for the third excited singlet state of a 3x3 CI on closed-shell RHF. (Technically speaking, Mopac uses a 4x4 CI, but since one of the states is a triplet, it doesn't interact with anything and could have been eliminated by taking a proper linear combination of configutations to begin with). The molecule is benzene in almost, but not quite, D2h symmetry. This should not be a problem, since D2h has no degenerate representations. The cartesian gradients on all atoms should be well below 1 kcal/mol/A. If they are not, then there is a bug in the program you are using. (This can be verified quite easily by re-doing computation with NOANCI, which produces correct answer in all Mopacs I know of). --- cut here --- MNDO 1SCF GRAD C.I.=2 ROOT=3 SINGLET SCFCRT=0.0000001 & PLCRT=0.0000001 T=1000000 MECI 6 -0.00730 1 1.45978 1 -0.00000 1 6 1.19790 1 0.77305 1 -0.00000 1 6 1.19790 1 -0.77304 1 -0.00000 1 6 -0.00730 1 -1.45978 1 -0.00000 1 6 -1.21278 1 -0.77327 1 -0.00000 1 6 -1.21274 1 0.77326 1 -0.00000 1 1 -0.00698 1 2.55278 1 -0.00000 1 1 2.16486 1 1.26278 1 -0.00000 1 1 2.16486 1 -1.26278 1 -0.00000 1 1 -0.00698 1 -2.55278 1 -0.00000 1 1 -2.17950 1 -1.26306 1 -0.00000 1 1 -2.18003 1 1.26315 1 -0.00000 1 --- cut here --- From gaussian.com!moses@lorentzian.com Fri Apr 11 11:35:32 1997 Received: from relay5.UU.NET for gaussian.com!moses@lorentzian.com by www.ccl.net (8.8.3/950822.1) id LAA05390; Fri, 11 Apr 1997 11:15:40 -0400 (EDT) Received: from uucp6.UU.NET by relay5.UU.NET with SMTP (peer crosschecked as: uucp6.UU.NET [192.48.96.37]) id QQckvd12876; Fri, 11 Apr 1997 11:15:45 -0400 (EDT) Message-Id: Received: from m10.UUCP by uucp6.UU.NET with UUCP/RMAIL ; Fri, 11 Apr 1997 11:15:40 -0400 Received: by m10.lorentzian.com; Fri, 11 Apr 1997 11:12:31 -0400 Received: by mousse.gaussian.com; Fri, 11 Apr 1997 09:10:56 -0500 From: gaussian.com!moses@lorentzian.com (David Moses) Subject: Cray T3E version of G94 available To: CHEMISTRY@www.ccl.net Date: Fri, 11 Apr 1997 09:10:55 -0500 (EST) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Gaussian, Inc is pleased to announce the availability of Gaussian 94 for Cray T3E systems. This version has been tested under Unicos/mk Version 1.4.1, Fortran Version 2.0.3, and C Version 5.0.3. With this announcement, we now distribute Gaussian 94 Revision E.2 for Convex, Cray, DEC Alpha, Fujitsu, Hitachi, HP-700, IBM, NEC, SGI, Sun, and Intel 486 & Pentium system. For additional information regarding the Gaussian system of programs, please contact us at the address, telephone numbers (voice or facsimile), electronic mail, or visit our Website. *------------------------*------------------------*-----------------------* | David J. Moses, Ph.D. | Carnegie Office Park | info@gaussian.com | | Vice President, C.O.O. | Building Six | 412-279-6700 (Voice) | | Gaussian, Inc. | Pittsburgh, PA 15106 | 412-279-2118 (FAX) | *------------------------*------------------------*-----------------------* | Be sure to visit our Website at http://www.gaussian.com | *------------------------*------------------------*-----------------------* This notice is sent without warranty of any kind, expressed or implied. Gaussian is a registered trademark of Gaussian, Inc. All other trademarks are the property of their respective holders. Specifications and availability subject to change without notice. From genghis@darkwing.uoregon.edu Fri Apr 11 11:52:32 1997 Received: from darkwing.uoregon.edu for genghis@darkwing.uoregon.edu by www.ccl.net (8.8.3/950822.1) id LAA05296; Fri, 11 Apr 1997 11:06:26 -0400 (EDT) Received: from localhost (genghis@localhost) by darkwing.uoregon.edu (8.8.5/8.8.5) with SMTP id IAA04458 for ; Fri, 11 Apr 1997 08:05:42 -0700 (PDT) Date: Fri, 11 Apr 1997 08:05:41 -0700 (PDT) From: Dale Andrew Braden Reply-To: Dale Andrew Braden To: cclpost Subject: Summary: geometry optimizations Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Dear CCL, Below is the collection of responses to the following question about the choice of coordinates for geometry optimizations. Thanks to all who responded! Dale Braden Department of Chemistry University of Oregon Eugene, OR 97403-1253 genghis@darkwing.uoregon.edu ---------------------------------------------------------------- Question: A brief question: Are there any circumstances in which a geometry optimization in Cartesian coordinates would be *faster* than in redundant internal coordinates? The reason I am asking is because I am trying to optimize the geometry of a hydrogen-bonded dimer in a solvent medium using Gaussian 94, and the change in the two intermolecular Z-matrix coordinates (distance and angle) remains large for many, many iterations. The geometry isn't exactly oscillating between two structures, but it isn't settling down, either, and I thought that perhaps by changing the optimization method from redundant internal coordinates (the default method in G94) to cartesians, the optimization might proceed more smoothly to a converged minimum. I don't want to try this unless it can work, because the calculation is expensive. ----------------------------------------------------------------- From Anthony.Scott@anu.edu.au Fri Apr 11 07:46:52 1997 Date: Tue, 8 Apr 1997 10:12:05 +1000 (EST) From: Anthony P Scott To: Dale Andrew Braden Subject: Re: CCL:G:geometry optimization methods Dale, In my experience one needs to be careful on where you use either cartesian, redundant or internal co-ordinates in geometry optimizations. a case in point. Take azulene. write a z-matrix for it and attempt to optimize in the default redundant co-ordinates. It does not converge. Now use explicitly z-matrix. converges in just a few steps. Not too sure about explicitly using cartesians however. In my work, where I am looking a cyclic type h'bonded systems I always use z-matrix. hope this helps. tony ______________________________________________________________________________ Dr. Anthony P. Scott, Computational Chemistry Group, Office Ph.: 61-6-249-3573 Research School of Chemistry, Dept. Ph.: 61-6-249-3637 Australian National University, Fax: 61-6-249-0750 Canberra, ACT 0200, Email: Anthony.Scott@anu.edu.au AUSTRALIA. ______________________________________________________________________________ ----------------------------------------------------------------- From korkin@qtp.ufl.edu Fri Apr 11 07:46:58 1997 Date: Mon, 7 Apr 1997 22:08:44 -0400 (EDT) From: Anatoli Korkin To: genghis@darkwing.uoregon.edu Subject: Re: CCL:G:geometry optimization methods Dale, You may try to optimize your system using Z-matrix and making separate optimizations for parameters with small and large force constants. Afetr one or two ineractions you may start the final optimization of all of them. Do frequency calculation at a lower level first, and use force constants from it (opt=readfc) in your subsequent optimization at a higher level. Anatoli Korkin --------------------------------------------------------------- From chpajt@bath.ac.uk Fri Apr 11 07:47:02 1997 Date: Tue, 8 Apr 1997 05:58:56 +0100 (BST) From: A J Turner To: Dale Andrew Braden Subject: Re: CCL:G:geometry optimization methods Hi! I am not very familier with g94 - but I do write optimisers my self. The effect you are seeing can often be caused by a poor initial hessian matrix. Rather than look to a different optimiser, how about trying a hessian generated from a lower theory level to start the thing off? cheers Alex ------------------------------------------------------------------- |Alexander J Turner |A.J.Turner@bath.ac.uk | |Post Graduate |http://www.bath.ac.uk/~chpajt/home.html| |School of Chemistry |+144 1225 8262826 ext 5137 | |University of Bath | | |Bath, Avon, U.K. |Field: QM/MM modeling | ------------------------------------------------------------------- ---------------------------------------------------------------------- From schiffer@h1tw0036.hoechst.com Fri Apr 11 07:47:07 1997 Date: Tue, 08 Apr 1997 09:25:23 +0200 From: "Dr. Heinz Schiffer" To: Dale Andrew Braden , Computational Chemistry List Subject: Re: CCL:G:geometry optimization methods Hi Dale, Optimization with Z-matrix coordinates is always the worst that you can do, next come cartesian coordinates, and the best are the natural internal coordinates of Pulay. Cartesian coordinates are o.k. if you have a good initial guess of the Hessian matrix (e.g. computed by a less expensive method). See : Jon Baker, Techniques for Geometry Optimization : A Comparison of Cartesian and Natural Internal Coordinates, J. Comput. Chem. 14(9) (1993) 1085-1100. Ciao, Heinz -- Dr. Heinz Schiffer Phone ++49-69-305-2330 Hoechst CR&T Fax ++49-69-305-81162 Scientific Computing, G864 Email schiffer@h1tw0036.hoechst.com 65926 Frankfurt am Main schiffer@msmwia.hoechst.com --------------------------------------------------------------- From kessi@psizi1.psi.ch Fri Apr 11 07:47:12 1997 Date: Tue, 8 Apr 1997 10:21:35 +0200 From: Alain Kessi To: genghis@darkwing.uoregon.edu Subject: Re: CCL:G:geometry optimization methods > A brief question: Are there any circumstances in which a geometry > optimization in Cartesian coordinates would be *faster* than in redundant > internal coordinates? Most definitely: For very large systems, a Cartesian optimization step will be faster than a redundant internal coordinate step (though the internal coordinate optimization will likely take less steps, but not enough so to compensate for the time each step takes). This is due to the n^3 scaling of internal coordinate steps (where n is the number of Cartesian coordinates), compared to the n^1 scaling of Cartesian steps. Note that in both Cartesian and internal coordinates, the number of steps probably scales something like n^1 (convergence guaranteed in n+1 steps for harmonic potentials). > The reason I am asking is because I am trying to optimize the geometry of > a hydrogen-bonded dimer in a solvent medium using Gaussian 94, and the > change in the two intermolecular Z-matrix coordinates (distance and angle) > remains large for many, many iterations. The geometry isn't exactly > oscillating between two structures, but it isn't settling down, either, > and I thought that perhaps by changing the optimization method from > redundant internal coordinates (the default method in G94) to cartesians, > the optimization might proceed more smoothly to a converged minimum. I > don't want to try this unless it can work, because the calculation is > expensive. Generally speaking, tightly bound structures converge in Cartesians about as fast as in internal coordinates. In all other cases, internals should do better. My guess as to what could go wrong with your system is that the choice of internal coordinates is inadequate. There are many ways to choose internal coordinates, and many probably perform worse (not better) than Cartesian coordinates. Also, performance seems to drop when you add internals to an already complete set. The reason can be sought in the fact that internals are better than Cartesians because the potential energy surface is more harmonic expressed in internals, which means that the Hessian information collected along the way will be more useful. If you take the wrong set of internals, you will not end up with a more harmonic potential. I would look for the problem in the modelling of the solvent. Probably the best way to describe it is with the internal coordinates for each molecule of the solvent, plus as few extra internals as possible to link the molecule to its direct neighbor. This will probably consist in one stretch, one bend and one dihedral for each neighbor pair. Hope this helps in some way ... Alain ------------------------------------------------------------- From kessi@psizi1.psi.ch Fri Apr 11 07:47:18 1997 Date: Tue, 8 Apr 1997 14:50:24 +0200 From: Alain Kessi To: genghis@darkwing.uoregon.edu, chemistry@www.ccl.net, schiffer@h1tw0036.hoechst.com Subject: Re: CCL:G:geometry optimization methods Heinz Schiffer wrote: > Optimization with Z-matrix coordinates is always the worst that you > can do, next come cartesian coordinates, and the best are the natural > internal coordinates of Pulay. Cartesian coordinates are o.k. if you > have a good initial guess of the Hessian matrix (e.g. computed by > a less expensive method). See : Jon Baker, Techniques for Geometry > Optimization : A Comparison of Cartesian and Natural Internal > Coordinates, J. Comput. Chem. 14(9) (1993) 1085-1100. You may also want to have a look at our more recent paper Jon Baker, Alain Kessi and Bernard Delley, The generation and use of delocalized internal coordinates in geometry optimization, J. Chem. Phys. 105(1) (1996) 192-212. which shows some trends for much larger systems. Alain -------------------------------------------------------------- From mckelvey@kodakr.kodak.com Fri Apr 11 07:47:22 1997 Date: Tue, 08 Apr 1997 11:16:02 +0100 From: John McKelvey To: "Dr. Heinz Schiffer" Cc: Dale Andrew Braden , Computational Chemistry List Subject: Re: CCL:G:geometry optimization methods Dr. Heinz Schiffer wrote: > Hi Dale, > > Optimization with Z-matrix coordinates is always the worst that you > can do, next come cartesian coordinates, and the best are the natural > internal coordinates of Pulay. Cartesian coordinates are o.k. if you > have a good initial guess of the Hessian matrix (e.g. computed by > a less expensive method). See : Jon Baker, Techniques for Geometry > Optimization : A Comparison of Cartesian and Natural Internal > Coordinates, J. Comput. Chem. 14(9) (1993) 1085-1100. > > Ciao, > Heinz > I think I do not agree entirely with this. Localised sub units, such as rings whose relative torsion angles are uncertain pose challenging problems. A bad initial guess at the angle will make cartesians a bad choice, and a good Hessian won't help much. Then, either Z-matrices or redundant internals are FAR superior. If the torsion has a low barrier then the Hessian becomes very important. Torsion angles and all their characteristics are rampant in dyes, and we have to worry more about then than any other single geometry factor. Regards, John From jstewart@iti2.net Fri Apr 11 12:35:37 1997 Received: from cougar.iti2.net for jstewart@iti2.net by www.ccl.net (8.8.3/950822.1) id LAA05523; Fri, 11 Apr 1997 11:37:40 -0400 (EDT) Received: from gj1-13.iti2.net (gj1-13.iti2.net [208.141.145.13]) by cougar.iti2.net (8.8.5/8.7.3) with SMTP id JAA04597 for ; Fri, 11 Apr 1997 09:39:28 -0600 Message-Id: <3.0.16.19691231170000.26b75eee@iti2.net> X-Sender: jstewart@iti2.net X-Mailer: Windows Eudora Pro Version 3.0 (16) Date: Fri, 11 Apr 1997 08:37:34 -0600 To: CHEMISTRY@www.ccl.net From: "James J. P. Stewart" Subject: M:Analytical CI gradients in semiempirical programs Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Serge Pachkovsky writes: >As it was already pointed out on CCL (by Dr. A. Holder, >in his message on 13 Jan 1993), " ... some versions of MOPAC and >AMPAC 2.1 are broken in certain places when it comes to analytical >gradient computation (CI to name just one.) ... ". Indeed, both >Mopac6 and Mopac7 Rev. 1 (which I have locally) have problems with >the input file given at the end this message. However, it is >Mopac93 Rev. 2 which is supposed to be the latest and greatest >of all Mopacs out there (;-)), so I wanted to try that as well. > >Unfortunately, Mopac93 Rev. 2 (thank you, Ernst) still produces >incorrect gradient in my test case, even though it is different >from the result produced by Mopac6 and Mopac7 Rev. 1. This brings >me to my question: The calculation suggested by Dr Serge Pachkovsky, has a solution as shown below. This is not, however, a stationary point, further optimization of the geometry yielded a much lower energy. The active space selected (C.I.=2) is obviously incomplete, therefore any results obtained using it are of no value. I found no faults in the analytical C.I. derivatives. These derivatives, developed by D. Liotard and M. J. S. Dewar, are suitable for most systems, although there are some problems with exotic systems, for example, when incomplete active spaces are used in high symmetry systems. In all cases of this type, the fault can be traced back to faulty data sets. Jimmy Stewart SUMMARY OF MNDO CALCULATION MOPAC 93.00 C6 H6 Fri Apr 11 09:14:32 1997 1SCF GRAD C.I.=2 ROOT=3 SINGLET PRECISE & T=1000000 MECI 1SCF WAS SPECIFIED, SO BFGS WAS NOT USED SCF FIELD WAS ACHIEVED HEAT OF FORMATION = 178.329452 KCAL = 746.13043 KJ ELECTRONIC ENERGY = -3211.050618 EV STATE: SINGLET Ag CORE-CORE REPULSION = 2366.323321 EV GRADIENT NORM = 0.088379 DIPOLE = 0.00106 DEBYE SYMMETRY: D2h NO. OF FILLED LEVELS = 15 CONFIGURATION INTERACTION WAS USED IONIZATION POTENTIAL = 8.654564 EV MOLECULAR WEIGHT = 78.113 SCF CALCULATIONS = 1 COMPUTATION TIME = 0.450 SECONDS FINAL GEOMETRY OBTAINED CHARGE 1SCF GRAD C.I.=2 ROOT=3 SINGLET PRECISE & T=1000000 MECI C 0.00000000 0 0.0000000 0 0.0000000 0 0 0 0 -0.0603 C 1.38679795 1 0.0000000 0 0.0000000 0 1 0 0 -0.0609 C 1.54669782 1 119.6644424 1 0.0000000 0 2 1 0 -0.0610 C 1.38669952 1 119.6702375 1 0.0471573 1 3 2 1 -0.0603 C 1.38681944 1 120.6611367 1 -0.0068056 1 4 3 2 -0.0610 C 1.38670070 1 120.6704155 1 0.0008064 1 1 2 3 -0.0609 H 1.09302361 1 119.6655646 1 179.9812673 1 1 2 3 0.0580 H 1.08399604 1 123.5053120 1 179.9933272 1 2 1 3 0.0621 H 1.08401053 1 116.8439442 1 -179.9720243 1 3 2 1 0.0621 H 1.09300380 1 119.6816877 1 179.9776776 1 4 3 2 0.0581 H 1.08399539 1 123.4911948 1 179.9344594 1 5 4 3 0.0621 H 1.08399953 1 123.5005382 1 179.9241279 1 6 1 2 0.0621 From ps@ocisgi7.unizh.ch Fri Apr 11 15:35:33 1997 Received: from rzusuntk.unizh.ch for ps@ocisgi7.unizh.ch by www.ccl.net (8.8.3/950822.1) id OAA07107; Fri, 11 Apr 1997 14:59:22 -0400 (EDT) Received: from ocisgi7.unizh.ch by rzusuntk.unizh.ch (4.1/SMI-4.1.14) id AA24892; Fri, 11 Apr 97 20:59:24 +0200 Received: by ocisgi7.unizh.ch (950215.SGI.8.6.10/920502.SGI) id UAA14938; Fri, 11 Apr 1997 20:59:12 +0200 From: ps@ocisgi7.unizh.ch (Serge Pachkovsky) Message-Id: <199704111859.UAA14938@ocisgi7.unizh.ch> Subject: Re: CCL:M:M:Analytical CI gradients in semiempirical programs To: jstewart@iti2.net (James J. P. Stewart) Date: Fri, 11 Apr 1997 20:59:11 +0200 (MDT) Cc: CHEMISTRY@www.ccl.net In-Reply-To: <3.0.16.19691231170000.26b75eee@iti2.net> from "James J. P. Stewart" at Apr 11, 97 08:37:34 am X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi everybody, First, I would like to nit-pick a bit at the analysis of the CI gradient problem provided by Dr. Stewart. Anybody not interested in this can skip to the end of this message, which is much more dignified. :-) [nit-picks on] > J.J.P. Stewart writes: > The calculation suggested by Dr Serge Pachkovsky, has a solution as > shown below. This is not, however, a stationary point, further > optimization of the geometry yielded a much lower energy. In all my sincere respect to Dr. Stewart, I beg to disagree. The structure given in my original message *is* a stationary point, with a final Cartesian gradient norm of 1.9 kcal/mol/A. It can be refined further, if desired. It is not a *minimum* point, as indicated by two imaginary frequencies in the vibrational analysis. This should, however, have no bearing in the CI computation. > The active space selected (C.I.=2) is obviously incomplete, therefore > any results obtained using it are of no value. Since neither HOMO nor LUMO are degenerate, and have no close-lying MOs (HOMO-1 is 1.1 eV below HOMO in the present case, LUMO+1 is 0.75 eV above LUMO), there is no arbitrariness in the selection of canonical MOs and the active space constructed from these two orbitals is obviously "complete" as far as CI and CI gradient workings are concerned. Two-orbitals active space is quite obviously unsatisfactory ("incomplete"?) in a physical sense, since it does not recover most of the correlation energy. This is not not a legitimate reason for a breakdown of analytical gradients, though ;-) [nit-picks off] With the atavistic urges satisfied, here comes the question to Dr. Stewart which may be of interest to other CCL readers: Since the master copy of Mopac93 apparently works perfectly for my test case: > GRADIENT NORM = 0.088379 while problems seem to exist with the copy of Mopac93 Rev. 2 obtained from QCPE some time in 1996 (I do not have Mopac93 Rev.2 locally, and can't verify it myself, unfortunately): > GRADIENT NORM = 27.74534 , is the Mopac93 Rev. 2 being distributed by QCPE identical to the master copy of Dr. Stewart? If it is not, how does one bring his own copy in synch with the latest and greatest of all Mopacs? With my best regards, /Serge.P From aholder@CCTR.UMKC.EDU Fri Apr 11 17:35:33 1997 Received: from ns1.umkc.edu for aholder@CCTR.UMKC.EDU by www.ccl.net (8.8.3/950822.1) id QAA07752; Fri, 11 Apr 1997 16:48:06 -0400 (EDT) Received: from holder.chem.umkc.edu by ns1.umkc.edu (5.65v3.2/1.1.10.5/01Jan97-0606PM) id AA17625; Fri, 11 Apr 1997 15:47:48 -0500 X-Mailer: InterCon tcpCONNECT4 4.0.2 (Macintosh) Mime-Version: 1.0 Message-Id: <9704111547.AA47052@134.193.11.2> Date: Fri, 11 Apr 1997 15:47:47 -0500 From: "Andy Holder" To: chemistry@www.ccl.net Subject: Pointer to Semichem Press Release Content-Type: Multipart/Mixed;boundary=part_AF740DA300143BDA00000003 --part_AF740DA300143BDA00000003 Content-Type: Text/Plain; charset=US-ASCII Content-Disposition: Inline For a press release from Semichem Inc. (vendors of AMPAC semiempirical software and CODESSA QSAR/QSPR software) set your browser at: http://www.ccl.net/cca/info/software-packages/semichem.note or http://www.semichem.com ******** Note New Address Below! ******** Best regards, Andy Holder =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= DR. ANDREW HOLDER President Semichem, Inc. || Email: andy@semichem.com 7204 Mullen || Phone Number: (913) 268-3271 Shawnee, KS, 66216 || FAX Number: (913) 268-3445 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= --part_AF740DA300143BDA00000003--