Subject: Re: CCL:gamess compilation

From: "Pablo Vitoria" <qibvigap=at=lg.ehu.es>
Date: Fri, 14 Nov 2003 17:46:27 +0100

Hi,

I compiled Gamess (version 3July2003R2) with ifc 7.1 and did not observe that behaviour. Which optimization flags did you use? In my dual Xeon I either '-tpp7 -O2 -xW' or '-tpp7 -O3' worked fine, but '-tpp7 -O3 -xW' although much faster gave wrong results with some of the exam files.

Besides, if you want to get rid of the 'FLUSH--FAILED:: Bad address' messages, you should change line 428 of the file unport.src from '*F2C  CALL FLUSH(LUNIT)' to 'C---*F2C  CALL FLUSH(LUNIT)'.

Best regards

Pablo
--------------------------------------------------------
Pablo Vitoria Garcia
Dpto. Química Inorgánica, Facultad de Ciencias
Universidad del País Vasco (UPV/EHU)
Aptdo. 644
48080 Bilbao (Bizkaia)

Tfno. 94 6015992
Fax. 94 4648500
  ----- Original Message ----- 
  From: Zhenhua Li 
  To: CCL 
  Sent: Friday, November 14, 2003 1:43 PM
  Subject: CCL:gamess compilation

  Dear Listers,
  I am compiling the gamess(US) under Redhat 8.0 with intel fortran compiler 7.1. I successfully compiled it. It runs well for HF calculations. But when I tried to run CI jobs, such as the exam09 and exam33 provided by gamess source. The job failed with error message:
   STEP CPU TIME =     0.12 TOTAL CPU TIME =        0.2 (    0.0 MIN)
   TOTAL WALL CLOCK TIME=        0.6 SECONDS, CPU UTILIZATION IS  42.86%
  FLUSH--FAILED:: Bad address
  FLUSH--FAILED:: Bad address
        170758  WORDS OF DYNAMIC MEMORY USED
  FLUSH--FAILED:: Bad address
  FLUSH--FAILED:: Bad address
   EXECUTION OF GAMESS TERMINATED NORMALLY Fri Nov 14 20:36:58 2003
  FLUSH--FAILED:: Bad address
  FLUSH--FAILED:: Bad address
                                                                                                                                                              
  DATA SERVER STATS: TOTAL DISTRIBUTED MEMORY USED (MEMDDI)=       0 MWORDS.
  FIRST DATA SERVER'S MAXIMUM MEMORY=             0 WORDS, CPU=     0.0 SECONDS.
                                                                                                                                                              
  ddikick: all processes have ended gracefully.

  Seems the problem is with the dynamic memory allocation. 

  Have anyone met such problems before? 

  Zhenhua Li
  Chem. Dept. of Fudan University
  Shanghai, China