Re: MOPAC 6 bug

[roberto "at@at" medusa.boston.sgi.COM (Roberto Gomperts)]

 > 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 "at@at" sgi.com
 						phone: (508) 562 4800
 						Fax:   (508) 562 4755