Subject: Summary: Symmetry Bug

From: [email-masked] (Alan Shusterman)
Date: 11 May 97 16:56:57 PDT

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:

SPARTAN AB INITIO PROGRAM

Molecule (C1) and archive (CS) have differenty symmetry. Calculation
terminating.

Can anyone tell me at what point the molecule adopted C1 symmetry? (The input
file and the molecule on the scree both still have CS symmetry).  Does anyone
have any advice on how to proceed? (I really want to do the larger basis set
with symmetry, so I need to convince Spartan that the molecule does have CS
symmetry.)

Note: transferring the coordinates in the archive (CS) to the input file
doesn't help (Spartan already did this automatically when I set up the
calculation for the larger basis set). Spartan still thinks the molecule is C1
and the archive is CS.
-----------------------
Most of the replies that I received fell into one of two categories:
1. use some other software (sound advice in this case; see below)
2. double-check the coordinates in the input file to make sure they really have
the expected symmetry. This turns out not to be important in this case (see
below).

My own comment on suggestion #2 is that the molecule I began with really did
have CS symmetry, so this symmetry was maintained during the initial (small
basis set) optimization, and the final geometry stored in the archive file had
this symmetry. When I setup a reoptimization with a larger basis set, Spartan
automatically copies the symmetric "archive" geometry over the "input"
geometry, i.e., it makes a new input file, but the input geometry, though
changed, still has CS symmetry.  The real problem is that Spartan was failing
to recognize an obviously symmetric structure. There is no need to double-check
the coordinates (I think).

The "solution" to my problem appears to be this: SPARTAN 4.1 DOES NOT USE
SYMMETRY IN CALCULATIONS INVOLVING DIFFUSE BASIS FUNCTIONS.  I don't know if
this is documented anywhere, but it is the source of my trouble - my initial
optimization (Cs symmetry) did not use diffuse functions, but the
reoptimization did call for diffuse functions.

Here is a test that I ran to verify the problem: I built bent HOF. This
molecule MUST have CS symmetry because it is a nonlinear triatomic. I saved
several identical input files and used each one to start a geometry
optimization using a different basis set. The optimizations using standard
basis sets (STO-3G, 3-21G(*), 6-31G*, 6-31G**, 6-311G**) all recognized and
used the molecule's CS symmetry. The optimizations using diffuse basis sets
(3-21+G(*), 6-31+G**, 6-31++G**) all disabled symmetry first and carried out
the optimization for a C1 molecule. The same behavior was observed whether the
calculations were done in memory or DIRECT.

Until this is fixed, Spartan users should realize that optimizations for
symmetric molecules using diffuse basis sets cannot be carried out with the
apparent symmetry. Also, they cannot be "restarted" using wavefunctions or
Hessians derived from nondiffuse (i.e., high symmetry) archives. If user knows
in advance that calculations with diffuse functions will be needed, then s/he
should either disable symmetry at the outset, or not use the "restart" option
when using the diffuse basis sets.

My thanks to all who contributed.

Alan Shusterman
Department of Chemistry
Reed College
Portland, OR