From chemistry-request#* at *#ccl.net Fri Jun 19 11:28:30 1992
Date: Fri, 19 Jun 92 09:48:45 -0400
From: roberto&$at$&medusa.boston.sgi.COM (Roberto Gomperts)
Subject: Re:  MOPAC 6 bug
To: system ^%at%^ alchemy.chem.utoronto.CA, chemistry ^%at%^ ccl.net
Status: R


> This bug was already reported in QCPE Bulletin Vol. 12, No. 1, page 5,
> and for those who didn't see it, the solution is (envelope please...)

I had not seen this solution. It seems very similar to what George Fitzgerald
was suggesting. I implemented a slightly different solution on SGI's version of
Mopac.
Since MULLIK.f is the offending routine I decided to tackle the problem there.
I use a scratch area (that I have been using as a REAL scratch area for some
multiprocessing sections of the code). So, in MULLIK.f I declare:

        common /sgi_scrch/ scr_sgi(3*morb2)

(some where after the inclusion of SIZES)
and then, almost at the end of the routine, starting at the call to DENSIT
I use "scr_sgi" instead of C:

      CALL DENSIT(VECS,NORBS,NORBS,NCLOSE,NOPEN,FRACT,scr_sgi,2)
      LINEAR=(NORBS*(NORBS+1))/2
      DO 100 I=1,LINEAR
  100 scr_sgi(I)=scr_sgi(I)*STORE(I)
      SUMM=0.D0
      DO 130 I=1,NORBS
         SUM=0
         DO 110 J=1,I
  110    SUM=SUM+scr_sgi(IFACT(I)+J)
         DO 120 J=I+1,NORBS
  120    SUM=SUM+scr_sgi(IFACT(J)+I)
         SUMM=SUMM+SUM
  130 scr_sgi(IFACT(I+1))=SUM
      CALL VECPRT(scr_sgi,NORBS)
      RETURN
      END


Advantages of this approach:
- No extra transfer of data (back and forth) to temporary arrays
- If by any chance MULLIK is going to be called from other places of the
  program, no precautions have to be taken to protect C in /VECTOR/

Disadvantage:
- Need extra space (In SGI's version if use this space anyway...)

I will be passing these suggestions to Richard Counts at QCPE..



						Roberto Gomperts
						roberto -x- at -x- sgi.com
						phone: (508) 562 4800
						Fax:   (508) 562 4755