CCL: Summ. GAMESS AMD 64 Linking & a strange new situation



 Sent to CCL by: [dedey:+:alumni.bilkent.edu.tr]
 Hi all,
 This is a summary about GAMESS compilation on AMD 64 pc running FC 4.
 !!!PLEASE PAY ATTENTION TO THE FUNNY SITUATION AFTER THE COMMENTS OF THE
 MEMBERS!!!
 My specific problem was ill activation of one of the source files. Although I
 specified the true targets (AMD 64)
 unport.src which has machine dependent codes was not activated.(I still wonder
 why)
 When I activated it manually by replacing all *AMD characters with blanks I
 could link it succesfully.
 So I managed as follows:
 1. manually changed syntax errors of prppop.src (refer to GAMESS mailing list)
 2. followed the instructions of readme.unix file
 3. manually erased all *AMD characters in unport.src and formed the object
 unport.o manually
    normally this part is done by the compall script which calls actvate.x for
 activation accoarding to the specific target
 4. compiled and linked using pgi without any error
 5. configured the rungms & runall scripts, tested all input files.
    all tests were performed succesfully
 I thank to whom participated.
 BELOW ARE COMMENTS FROM THEM
 ************************************************************************
 Brian Salter-Duke <b_duke . octa4.net.au>
 It looks to me as if you need to address machine specific stuff in
 unport.src. Those missing objects early in the lked output may be
 important.
 ************************************************************************
 zhendong zhao zzhao . olemiss.edu
 Hi,
 As I said in the previous email, the updated version has some errors in
 source code. in prppop.src, the > should be .GT.. == should
 be .EQ.. After I correct these errors, I can successfully compile the
 updated version gamess for AMD64 with PGI x64 verion even without
 changing any scripts. This error is mentioned by others in gamess
 email list.
 ************************************************************************
 	 Xiaojian Mao <mxiaojia . mix.wvu.edu>
 what is exactly your linking problem? a lot of undefined symboles? Normally
 you should search all library files
 in your machine to find out which library you should include. In my case, I
 found all those symbols in the
 "libgcc_eh.a" library file. Adding paramter "-lgcc_eh" to
 the link source
 code solved the problem.
 ************************************************************************
 THE FUNNY THING IS:
 I tested the performances of 32 bit and 64 bit GAMESS executables on the 64 bit
 AMD pc.
 In most cases 64 bit executable runs faster but with the CR-CC job employing TZV
 basis 64 bit executable cannot finish the
 job whereas 32 bit exe does succesfully. Inputs are same for both jobs and given
 below.
     $CONTRL RUNTYP=energy  CCTYP=CR-CC $END
     $BASIS GBASIS=tzv $END
     $CONTRL ISPHER=1 $END
     $BASIS NDFUNC=2 NFFUNC=1 NPFUNC=1 POLAR=POPN311 $END
     $CONTRL NOSYM=1  $END
     $system mwords=460 $end
 I here give the related parts from the log files, 64 bit one cannot pass the
 point below but 32 bit finishes succesfully.
 **** BELOW IS WHERE AMD 64 INCOMPLETE JOB GETS STUCK***
  COUPLED CLUSTER CALCULATION
      ---------------------------
  CCTYP                        =CR-CC
  TOTAL NUMBER OF MOS          =   222
  NUMBER OF OCCUPIED MOS       =    21
  NUMBER OF FROZEN CORE MOS    =     6
  NUMBER OF FROZEN VIRTUAL MOS =     0
  MAXIMUM CC ITERATIONS        =    30
  MAXIMUM DIIS ITERATIONS      =     5
  CONVERGENCE CRITERION FOR CC =     7
  AMPLITUDE ACCURACY THRESHOLD = 0.0E+00
      -------------------------------
      PARTIAL INTEGRAL TRANSFORMATION
      -------------------------------
  NUMBER OF CORE MOLECULAR ORBITALS     =    6
  NUMBER OF OCCUPIED MOLECULAR ORBITALS =  222
  TOTAL NUMBER OF MOLECULAR ORBITALS    =  222
  TOTAL NUMBER OF ATOMIC ORBITALS       =  252
  THRESHOLD FOR KEEPING TRANSFORMED 2E- INTEGRALS = 1.000E-09
  AO INTEGRALS WILL BE READ IN FROM DISK...
  EVALUATING THE FROZEN CORE ENERGY...
  ----- FROZEN CORE ENERGY =      -294.1883029370
  # OF WORDS AVAILABLE =  460000000
  # OF WORDS NEEDED    = 1735561322 FOR IN MEMORY TRANSFORMATION
  FOR THE SEGMENTED TRANSFORMATION:
  MINIMUM=   8411282 WORDS FOR 1 MOLECULAR ORBITAL PER PASS
  MAXIMUM=1735561322 WORDS FOR ALL MOLECULAR ORBITALS IN 1 PASS
         (   8033256 EXTRA WORDS WOULD INCLUDE AN EXTRA ORBITAL/PASS)
  SEGMENTED PARTIAL TRANSFORMATION WOULD USE 434173850 WORDS,
  DISTRIBUTING   4 PASSES EACH CONTAINING  54 ORBITALS OVER   1 PROCESSORS.
  CHOOSING SEGMENTED PARTIAL TRANSFORMATION...
  PASS #   1 TOOK      496.02 SECONDS.
  PASS #   2 TOOK      581.45 SECONDS.  **************** stuck in pass # 3 ?????
 *****************
  DDI Process 0: trapped a segmentation fault (SIGSEGV).
  ddikick.x: application process 0 quit unexpectedly.
  ddikick.x: Fatal error detected.
  The error is most likely to be in the application, so check for
  input errors, disk space, memory needs, application bugs, etc.
  ddikick.x will now clean up all processes, and exit...
  ddikick.x: Sending kill signal to DDI processes.
  ddikick.x: Execution terminated due to error(s).
 **** HERE STARTS PARTIAL 32 BIT LOG FILE ****
 **** 32 BIT JOB PASSES THIS PART AND COMPLETES THE CALCULATION SUCCESFULLY ***
 ---------------------------
      COUPLED CLUSTER CALCULATION
      ---------------------------
  CCTYP                        =CR-CC
  TOTAL NUMBER OF MOS          =   222
  NUMBER OF OCCUPIED MOS       =    21
  NUMBER OF FROZEN CORE MOS    =     6
  NUMBER OF FROZEN VIRTUAL MOS =     0
  MAXIMUM CC ITERATIONS        =    30
  MAXIMUM DIIS ITERATIONS      =     5
  CONVERGENCE CRITERION FOR CC =     7
  AMPLITUDE ACCURACY THRESHOLD = 0.0E+00
      -------------------------------
      PARTIAL INTEGRAL TRANSFORMATION
      -------------------------------
  NUMBER OF CORE MOLECULAR ORBITALS     =    6
  NUMBER OF OCCUPIED MOLECULAR ORBITALS =  222
  TOTAL NUMBER OF MOLECULAR ORBITALS    =  222
  TOTAL NUMBER OF ATOMIC ORBITALS       =  252
  THRESHOLD FOR KEEPING TRANSFORMED 2E- INTEGRALS = 1.000E-09
  AO INTEGRALS WILL BE READ IN FROM DISK...
  EVALUATING THE FROZEN CORE ENERGY...
  ----- FROZEN CORE ENERGY =      -294.1883029370
  # OF WORDS AVAILABLE =  460000000
  # OF WORDS NEEDED    = 1735529570 FOR IN MEMORY TRANSFORMATION
  FOR THE SEGMENTED TRANSFORMATION:
  MINIMUM=   8379530 WORDS FOR 1 MOLECULAR ORBITAL PER PASS
  MAXIMUM=1735529570 WORDS FOR ALL MOLECULAR ORBITALS IN 1 PASS
         (   8033256 EXTRA WORDS WOULD INCLUDE AN EXTRA ORBITAL/PASS)
  SEGMENTED PARTIAL TRANSFORMATION WOULD USE 434142098 WORDS,
  DISTRIBUTING   4 PASSES EACH CONTAINING  54 ORBITALS OVER   1 PROCESSORS.
  CHOOSING SEGMENTED PARTIAL TRANSFORMATION...
  PASS #   1 TOOK      576.36 SECONDS.
  PASS #   2 TOOK      723.19 SECONDS.
  PASS #   3 TOOK      787.56 SECONDS. ****************  pass # 3 is done ????
 *****************
  PASS #   4 TOOK      770.50 SECONDS.
  TOTAL NUMBER OF TRANSFORMED 2E- INTEGRALS KEPT = 274367375
  ... END OF INTEGRAL TRANSFORMATION ...
  STEP CPU TIME =  2876.01 TOTAL CPU TIME =     3208.6 (   53.5 MIN)
  TOTAL WALL CLOCK TIME=     4414.7 SECONDS, CPU UTILIZATION IS  72.68%
 ********************************************************************************************
 So I am confused about if recompiling GAMESS with some other parameters will
 solve the problem or not. Is there a way to skip
 such erroneous parts with change in the input. Why not the 64 bit executable
 cannot write the files on the disk where the 32
 bit one does. The flow of the calculation as seen from the output is exactly the
 same for both. The error is a segmentation
 fault but if someone asks about disk space it is not a problem, there is more
 than 200 gb free space. The double precision to
 single thing when moving from 32 to 64 bit architecture is said to be done with
 the compilation scripts of GAMESS. The
 identical
  # OF WORDS AVAILABLE =  460000000
  # OF WORDS NEEDED    = 1735529570 FOR IN MEMORY TRANSFORMATION
 messages imply no such single-double precision problem as the amount of memory
 is the same for both. I also think about swap
 space... In particular I ask;
 Can I find the causes by analyzing some specific source files, if yes which?
 As far as I know there is no way to increase swap space in Linux without
 repartitioning. If I am mistaken how can I do this?
 Any other comments?
 Thanks again...
 --
 Yavuz Dede
 Comp. Chem. Lab.
 +90 312 210 3187
 METU Ankara