[molpro-user] strange behavior using PROC in OPTG

[Benj FitzPatrick]

Hello,
First off, I'm using 2008.1 patchlevel 5, compiled with ifort 10.1, and running
on amd64.

I trying to get the geometry, harmonic frequencies, and anharmonic frequencies
of the C2H3 radical.  In the past I used a series of HF calcs, starting with a
small basis set and working up in size, for molecules that had convergence
problems (this was David Glowacki's excellent solution).  C2H3 seems to be such
a molecule (methyl exhibited none of these problems), so I thought I'd try that
approach when finding the geometries and harmonic frequencies (then I'd use the
wavefunction file from this to start the surf/vscf/vci calc).

I have included the input file below.  The problem is that when the first
hessian appears to be calculated properly (looking at molpro.log it is doing all
of the HF calcs and then a UCCSD(T) calc), but the geometry optimization steps
don't get a better geometry after about the 3rd step (the rms of the gradient
remains about 0.03).  Once the hessian is calculated a second time the geometry
converges in 6 steps.  Additionally, if one of these jobs restarts from a
calculation that already has the hessian two things happen.  One, the hessian is
recalculated (and the output file implies it is the one being used), and, two,
the calculation converges to the geometry in 7-8 steps (ie it doesn't appear to
get stuck at any point).  Two final notes, in all cases where I use PROC and
HESSPROC the optimization step is always listed as 1, and the frequency
calculation says that my molecule is not in standard orientation (this message
does not come up when I leave out the procedures).  My question is, am I
specifying something improperly in my input file when using these procedures?
Thanks,
Benj FitzPatrick
University of Chicago

For those of you who are wondering why I would go to all of this trouble, the
answer is that if I don't the SURF part of the subsequent job gets lots of
negative values in the 1D potentials (and probably elsewhere, I killed most of
these jobs after I found that out) or it crashes b/c UCCSD(T) can't converge. 
The former leads to nonsensical values for the anharmonic frequencies (some are
******, some are 1 cm-1, and the rest tend to be off by hundreds or thousands of
wavenumbers).



 ***,uccsdt opt of c2h3 from c2h3-eq_opt-uccsdt-avdz-tight-b.log***
memory,300,M
file,2,c2h3-eq_opt-uccsdt-avdz-f3c6.wfu;
!the below don't appear to change anything in going from the
!defaults up to d-16
gthresh,oneint=1.d-16,twoint=1.d-16,zero=1.d-16;

cc2  =       1.20000;
hc3  =       1.05000;
hcc3 =       109.471;
hc4  =       1.1000;
hcc4 =       108.471;
dih4 =       20.000;
hc5  =       1.02000;
hcc5 =       109.0;
dih5 =       165.000;
  geometry={
 mass;
 ang;
 nosym;
 c;
 c,   1, cc2;
 h,   2, hc3,        1, hcc3;
 h,   1, hc4,        2, hcc4,         3, dih4;
 h,   1, hc5,        2, hcc5,         3, dih5;
 }

basis=6-31g*;
{hf;
wf,15,1,1}
basis=6-311g**;
{hf;
wf,15,1,1}
basis=aug-cc-pvdz;
{hf;
wf,15,1,1}
{uccsd(t);
wf,15,1,1}

{optg,root=1,step=1.d-6,gradient=1.d-6,proc=UCCSDT;
numhess,hstep=4,procedure=UCCSDT;}

!the below also works, but with the same behavior
!optg,root=1,step=1.d-6,gradient=1.d-6,proc=UCCSDT,numhess=4,procedure=UCCSDT;

{frequencies,proc=UCCSDT;
save,5300.2}