Subject: summary: problem with g94 casscf77 under linux

From: BRION Jean <[email-masked]>
Date: Fri, 10 Jul 98 12:25:55 WETDST

Hello, 

 I posted few days ago one question about 
 a problem occuring with a g94 casscf(7,7)
 job under linux.

********************************************
*		   Hello,
*
*We have installed the Gaussian 94 package on a Linux machine
*and we meet now one problem when trying a CASSCF(7,7) (generating
*784 configurations)...
*The problem is in link 510, 
*when the program begins "Generating Lanczos Guess".
*At this moment, we establish that the running 
*does not create any output more...
*(even with a long calculation time about 3000 minutes !). 
*
*-We have a PII 400 machine, with 256Mo of memory and a 9Go hard disk.
*
*-Gaussian version is D.4
*
*-Linux version is S.u.S.E 1998 5.2 Kernel 2.0.33
*
*-the memory used for this calculation was 8MW
*
*-The previous CASSCF(5,5) has worked very well in 5 minutes for 75
*generated CONFIGURATIONS.
*
*-When adding the FULLDIAG keyword in 
*the CASSCF options list, the calculation
*works !  (but takes a long time)
*
*- on a HP755 machine:
*
*The same CASSCF(5,5) calculations takes about 10 minutes 
*
*The same CASSCF(7,7) works very well, and takes about 12 minutes
*
*
*We have tried another thing to try to solve
*our problem: i.e add the -malign-double in the
*compilator options.
*
*=> Although other jobs (than the casscf(7,7) one)
*run faster, our problem on the CASSCF(7,7)
*remains the same (that means this job never stops
*without output and without  error).
*
********************************************

 I thank all the people who have answered.
 I thank particularly  Darko Babic for giving us the
 solution. Under linux, the problem comes from the EPS variable 
 (epsilon) which is evaluated in a "bad way" by the EPSETA subroutine
 in utilam.F in Gaussian 94 source (see the mail below).

********************************************
*
*From: Darko Babic <[email-masked]>
*Subject: Re: CCL:G:problem with g94 casscf77 under linux
*In-Reply-To: <[email-masked]>
*Mime-Version: 1.0
*Content-Type: text/plain; charset="us-ascii"
*Status: RO
*
*
*
*
*
*
*        Dear Prof. Henon,
*
*        The problem you have with link 510 is related to the unusual result
*of the variable EPS (epsilon) under Linux.  This variable tells to Gaussian
*what is the working precision in numerical computations.  It is the minimum
*positive floating number such that 1 + EPS = 1.  EPS is computed in the sub-
*routine EPSETA in utilam.F by successively halving EPS and adding the result 
*to ONE until EPS becomes so small that its addition to ONE does not affect
*ONE.  This value is used for numerical control of in Gaussian.
*
*        It turns out that, under Linux, the value of EPS is calculated unrea-
*listically SMALL and the requirements for convergence are therefore too to-
*ugh.  L510 gets into infinite loop at certain place (I don't remember now
*where, but if you wish I'll find it).
*
*        The value of EPS calculated in EPSETA is 1.084...E-19 under Linux.  
*On some other machines (Hewlett-Packard, SP2, ...) I got few orders of magni-
*tude HIGHER value (by separately running the EPSETA subroutine from utilam.F).
*There are built-in values of EPSILON and ETA in gcc-library (under Linux)
*(DBL_EPSILON and DBL_MIN) as: 2.2204460492503131E-016 and 2.2250738585072014
*E-308, respectively, which are close to the values obtained on other machines.
*So I concluded that the calculated value of EPS is unrealistically small and
*I simply commented out the computation of EPS and ETA in SUBROUTINE EPSETA
*(in utilam.F), inserted declaration of the above EPS and ETA values instead,
*and recompiled Gaussian.
*
*        In this way, the new values of EPS and ETA affect ALL the computation
*of Gaussian.  If you want be more selective, you can only replace calls to
*EPSETA in l510.F (there are two, I think) by declarations of EPS and ETA as
*above.
*
*        Here is the modified SUBROUTINE EPSETA from utilam.F:

      SUBROUTINE EPSETA(EPS,ETA)
      Implicit Real*8(A-H,O-Z)
C
C     COMPUTE AND RETURN ETA, THE SMALLEST REPRESENTABLE NUMBER,
C     AND EPS IS THE SMALLEST NUMBER FOR WHICH 1+EPS.NE.1.
C
      Save ZERO, ONE, TWO
      DATA ZERO/0.0D0/, ONE/1.0D0/, TWO/2.0D0/

      ETA=2.2250738585072014D-308
      EPS=2.2204460492503131D-16

C      ETA = ONE
C   10 IF((ETA/TWO).EQ.ZERO) GOTO 20
C          ETA = ETA / TWO
C          GOTO 10
C   20 EPS = ONE
C   30 IF((ONE+(EPS/TWO)).EQ.ONE) GOTO 40
C          EPS = EPS / TWO
C          GOTO 30
   40 RETURN
      END

        Congratulations for the yesterday win!

*        Darko Babic
*Institute "Rudjer Boskovic"
*HR-10001 Zagreb, P.O.B. 1016
          Croatia
*                                                        
*                                                       
*                                                        
********************************************                                                        

 Incidentally, I establish with pleasure that the result of
 the game "Croatie-France" in the world cup 
 didn't affect the sympathy between 
 chemical researchers ... !

********************************************
*From: "Joseph W. Bausch" <[email-masked]>
*Subject: Re: CCL:G:problem with g94 casscf77 under linux
*Status: RO
*
*>Has someone already met this difficulty ? Is this
*>a gaussian environement problem or a machine configuration problem ?
*
*I believe to get the most out of your compiling options, you should use the
*following in your f2c.make file in place of the OPTFLAG = -02 line:
*
*OPTFLAG = -O3 -funroll-loops -fomit-frame-pointer -malign-double -m486
*-malign-loops=2 -malign-jumps=2 -malign-functions=2
*
*Also, when running G94 jobs on a linux intel box, it appears you want to
*give the job as little memory as it needs!  I know this sounds strange, but
*giving the job more memory than it needs results in a slowdown.  I am sure
*you'll get a response from M. Nicklaus that will explain this better than I
*can.
*
Joe
---------
*
********************************************

     Sincerely.
     
               E. Henon