Subject: Re: mn and cr complexes (Summary: part 1)

From: Michael Nolan <[email-masked]>
Date: Fri, 9 May 1997 09:47:38 +0100 (BST)

Hi CCL!!

thanks again to all those who replied to my pathetic problems with the
aforementioned complexes.

I am posting the summary in two parts, because I got a lot of answers. The
first is this extremely helpful reply from Prof. Guest.

The answer to most of problems was so simple:
(i) increase the number of cycles allowed!
(ii) changing the LEVEL keyword in GAMESS-UK helped enormously.

I also found that starting with a short M-C bond length (1.75 A) helped
The replies also opened my eyes to how tough TM complexes can be. I knew
that there could be problems because of the d-orbitals, but now I know
better.
It seems also that a correlated method should be used. Our HF results are
giving a different ordering of the HOMO-1, HOMO, LUMO and LUMO+1 orbitals
to that from Hoffmann et al (JACS 1976, 98, 7546 i think) and Byers and
Hall's work (Organometallics 1987).

Anyway, thanks to everyone again.

Michael
Der Kobold hat gesprochen
******************************************************************************
Michael Nolan (nearly BSc.)             Dublin City University (quantum
chem.)
41 Woodview                             Chemistry + German Year 4
Lucan
Co. Dublin
Ireland / Republic of Ireland / ROI / Eire

Email: [email-masked]
******************************************************************************

Date: Wed, 30 Apr 1997 22:32:14 +0100
From: "M.F.Guest" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: mn complexes

Dear Michael,

> I am trying to run ab-initio calculations on Mn(CO)3 and Cr(CO)3, using
> GAMESS-UK.

First, let me say that I am sorry you are having so many problems
trying to get these SCF transition metal complexes sorted out. If you
email me the associated input data sets and key sections of the O/P
files, I will run these for you and help resolve the source of the
problems you are encountering. I've run well over 150 TM complexes
using the code, and am very confident that I can resolve the matters
that are causing grief.

First, a couple of general guidelines.  Convergence problems of the
type you have encountered ("excessive iterations", oscillating energies
etc) can arise for a number of different reasons, and with the
information to hand its difficult to provide a definitive answer to
what is happening, but the following may help:

1. oscillations in the energy can often be resolved by increasing the
value of the "level shifter" used in the calculation over and above the
defaults. Thus, assuming you are on the correct initial configuration
(see below for more on that), then presenting the data sequence

          level 5 20 2
          maxcyc 100

will often help. You need to drive the calculation into the regime
where the DIIS convergence scheme is called into play, from which point
hopefully progress will be a lot better.

2. Bear in mind that running with "RUNTYPE OPXYZ" will require a
stricter convergence of the SCF calculation (10**-7 rather than 10**-5
in the "tester"), and you may just be running out of cycles (the
default 50). Without seeing the O/P it is difficult to be more precise
on this, although if the energy is oscillating that is clearly not the
problem.

3. There is no guarantee that the initial SCF configuration is
"correct", particularly for TM complexes where their may be a multitude
of low lying excited states, and in cases of high symmetry (as in your
examples). In the absence of any better starting point, you should use
the default "guess" option (vectors atoms). If you have successfully
converged a related compound with similar geometry or basis, then you
should use these vectors as a source of input to start the SCF. Thus if
you have the Mn(CO)3 vectors on say the dumpfile mnco3.ed3, then use
these to start the Cr(CO)3 calculation, using the directive

    vectors getq ed4 1 1

where I'm assuming that mnco3.ed3 is assigned to the calculation
using the LFN ED4 (perhaps via the setenv environment setting

    setenv ed4 mnco3.ed3

and that the converged Mn(CO)3 vectors reside in section 1.  This will
definitely help.

4. Note that if you inadvertently "split" the degeneracy of the
starting SCF orbitals then you will not recover (you can check this by
looking at the final set of eigen values). The energy may well crash
below that expected when for example degenerate e orbitals are symmetry
broken, and you must try and avoid that by ensuring the starting mos
exhibit the correct degeneracies.

Looking at the specific points you raised:

> 1) RHF/3-21G (3-21G on all atoms) for Mn(CO)3 this is successful, for
> Cr(CO)3 I get excessive number of iterations and an oscillation of the
> energy.

Use the converged  Mn(CO)3 vectors as input to the Cr(CO)3 calculation
as noted above, using "level 3.0 25 2.0"

> 2) RHF, 6-21G on C and O, 3-21G on Mn.  for Mn(CO)3, this is successful

> 3) RHF with minimal basis ECP on all atoms for Mn(CO)3 and Cr(CO)3.
> This gives a ludicrously low energy (about -70a.u.), oscillations in the
> energy and excessive number of iterations
> I have inputted a z-matrix, cartesian coordinates from X-ray diffraction
> studies (using both OPTXYZ keyword and the cartesian coordinates to
> z-matrix conversion) and the idealised geometry above  and I get the same
> result with them all - excessive number of iterations etc..

Again, a no. of reasons why this could happen, with a splitting
in degeneracy of the input MOs a likely candidate. You have to damp
the oscillations with "level"

> 4) RHF as above, but ECP-double zeta (ECPDZ) on all atoms same result
> 5) RHF, min. basis ECP and ECPDZ on Mn, 3-21G and 6-31G on C and O
> see number 4.
> I assume the fact that Mn(CO)3 is positively charged has nothing to do
> with it (it is a closed shell).
> I know that 3-21G and 6-31G are not good for transition metals, yet I got
> reasonable results using these (MOs and charge distribution).
> Does anyone have any ideas for how I can use ECPs (we are limited to
> about 1.2GB) or anything else to get these calculations to run (we do
> not yet have DFT).  

As I said at the outset, I've run a lot of TM ECP calculations without
experiencing the sort of problems you have encountered.  You could try
just siting the ECP on the TM to start with; are these calculations
using the Hay and Wadt ECP's, or those due to Stevens et al. I've found
the latter a lot better, and would suggest you try these.

> As an aside, I keep getting an error message when
> converting from cartesian coordinates to z-matrix. Has anyone else had
> this?

I seem to remember seeing an example like this posted to the GAMESS-UK
support list. If you have not received any feedback let me be the first
to apologise; Allan Beveridge, who was appointed to deal with this type
of query left his position a month or so ago, and we are a bit thin on
the ground in trying to deal with enquiries, installations etc. Again,
if you send me a data set where this problem manifests itself, I will
try and sort it out.

> sorry for bothering you and thank you in advance

Hopefully we can get your problems resolved asap. Please send me what
you consider to be relevant information (key data sets etc), and we'll
progress matters very rapidly. I trust that when all these problems are
resolved, that you will broadcast the successful outcome to the CCL.

Best regards

Martyn

******************************************************************
* Martyn F. Guest                                                *
* Computing for Science               email:  [email-masked] *
* c/o CCLRC Daresbury Laboratory      FAX  :  +44 (0)1925 603634 *
* Warrington                          voice:  +44 (0)1925 603247 * 
* Cheshire WA4 4AD                                               *
* England, UK                                                    *
******************************************************************