GU: Summary:HESSIAN restart

[Brion Jean <jean.brion@univ-reims.fr>]

                        Dear Netters,

Some days ago I posted the message below:

I meet some troubles when using the Intrinsic vibrational
frequencies calculation in GAMESS, by the "DECOMP"
option in $FORCE.

The intrinsic frequencies calculated in a "restart"
JOB2,  reading cartesian hessian 
(SCFTYPE=HESSIAN + RDHESS=.TRUE. +  DECOMP=.TRUE.)  are sometimes
different from those calculated in the previous single JOB1
(SCFTYPE=OPTIMIZE + HSSEND=.TRUE. + NVIB=2 + DECOMP=.TRUE. ). 

I had suspected (among other things) a geometry orientation problem 
and then tried  to replace (in JOB2) "COORD=ZMAT" by "COORD=CART"
and create a $ZMAT group. BUT it appears that (unfortunately for me) 
GAMESS still make a reorientation for  "COORD=CART" option, while
without sepicifing "COORD" option (default: COORD=UNIQUE) it works very
well.
That was the reason why my try failed . The complete and right solution
was given by Jan Jensen . 

  Thank you to Drs Jan Jensen and Martin Ystenes for their help.

                         F. Bohr

---------------------------------------------------------------
Return-Path: <jan@si.fi.ameslab.gov>
Subject: Re: GAMESS: HESSIAN restart calculation
To: jean.brion@cleo.univ-reims.fr (Brion Jean)
Date: Mon, 6 May 1996 15:24:50 -0500 (CDT)
X-Mailer: ELM [version 2.4 PL25]
Content-Length: 1270
Status: RO

Dear Dr Bohr:

        The problem is as follows:  When a Z-matrix is used in the input,
the resulting Cartesian coordinates are transformed to their principle axes.
This is not done for the subsequent geometries in an optimization run.
Therefore, if you transfer the optimized coordinates with a Z-matrix it
can happen that the new principal axes are very different from the ones
in the optimization run.  As a result you get very different Cartesian
coordinates for JOB1 and JOB2.  The hessian in JOB2 was computed for JOB1
Cartesian coordinates and so you get funny results for the internal
coodinate decomposition (the cartesian frequancies are calculated simply
by diagonalizing the read in hessian and do not change).  The fix is
to transfer the optimized Cartesian coordinates and using a $ZMAT group.

Hope this helps.  Best regards.
                                Jan Jensen


-------------------------------------------------------------



Return-Path: <owner-gamess-users@glueserv1.umd.edu>
Mime-Version: 1.0
Date: Sun, 5 May 1996 21:17:01 +0100
To: gamess-users@glue.umd.edu
Subject: Re: GU: Troubles with restart vibrational calc.
Sender: owner-gamess-users@glueserv1.umd.edu
Precedence: bulk
Reply-To: gamess-users@glue.umd.edu
Status: RO

Dear Bohr,

I do not know whether this is the same problem, but we have also seen some
very strange problems with GAMESS in the parallell version. For us it has
happened that the $VEC group is read incorrectly, if and only if,
we use "PRTIFC=.T." in the force group.

So to me it appears that there is a bug related to the $force group that
under certain circumstances seem to cause overwriting of certain
matrices.

Martin Ystenes



**************************************************
*     Dr F. Bohr                                 *
*     Laboratoire de Chimie Physique             *
*     Universite de Reims, Faculte des Sciences  *
*     Moulin de la Housse                        *
*     B.P. 1039                                  *
*     51687 Reims Cedex 2                        *
*     FRANCE                                     *
*     Tel: (33) 26-05-32-33                      *
*     Fax: (33) 26-05-31-47                      *
*     E-mail: jean.brion@univ-reims.fr           *
**************************************************