From black \\at// cope.claremont.edu Thu Jun 19 13:50:05 1997 Received: from cope.claremont.edu for black- at -cope.claremont.edu by www.ccl.net (8.8.3/950822.1) id NAA13249; Thu, 19 Jun 1997 13:01:42 -0400 (EDT) Received: by cope.claremont.edu (940816.SGI.8.6.9/940406.SGI.AUTO) id JAA24453; Thu, 19 Jun 1997 09:49:15 -0700 From: "Kersey Black" Message-Id: <9706190949.ZM24451 {*at*} cope.claremont.edu> Date: Thu, 19 Jun 1997 09:49:09 -0700 In-Reply-To: Alan.Shusterman ^%at%^ directory.Reed.EDU (Alan Shusterman) "SPARTAN: Summary: Symmetry Bug" (May 11, 4:56pm) References: <3204440.,at,.isis.Reed.EDU> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: Alan.Shusterman-!at!-directory.Reed.EDU (Alan Shusterman), chemistry ^%at%^ www.ccl.net, sparlist ^%at%^ wavefun.com, sparlist -8 at 8- nissan.wavefun.com, "Wayne Huang" Subject: Re: SPARTAN: Summary: Symmetry Bug Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii On May 11, 4:56pm, Alan Shusterman wrote: > Subject: SPARTAN: Summary: Symmetry Bug > The following note summarizes replies and answers I received to my question > about an apparent symmetry bug in Spartan 4.1. > > Here is my original post: > -------------------------------- > I run into the following bug every few weeks: > > I build a molecule with a certain symmetry (Cs in this case) and optimize its > structure with symmetry ON. Then I try to reoptimize its structure with a > larger basis set while still using symmetry, but Spartan stops with the > following error message: > I have truncated the message and rely on memories for some of the details. It is ironic that this should cross my desk so recently because I confronted a similar symmetry problem this morning, however I just discoved while writing this that it is a feature, and not a bug. I share the problem with the list because others may want to know about this if planing to use the DFT methods. The bottom line is that symmetry when using DFT in 4.1.1 is not supported. Also, the use of constraints is not supported. Thus, I got caught in the following bind. I exploited the Cs symmetry of a transition state (C1 ground states) to effectively constrain it while "geometry optimizing" to a transition state stationary point with that symmetry. This approach worked well at the PM3(tm) level, but when I went to DFT the symmetry was turned off by Spartan and every thing proceeded as if C1. As a consequence the structure optimized towards a ground state structure. This leaves me trying to find a transition state on a relatively flat surface using the Transition State option and C1 symmetry. Wish me luck. I discover in the on-line help that nosymmetry is the default in DFT. I hope that this gets corrected in future versions. The inability to use symmetry this way makes calculations much more costly and more difficult, and makes the DFT options substantially less valuable. Cheers Kersey Black -- <::::::::::::::::::::::> Kersey Black Associate Professor of Chemistry Claremont McKenna, Pitzer, Scripps Colleges 925 N. Mills Ave Claremont, CA 91711-5916 black ^at^ cope.claremont.edu