Firefly and PC GAMESS-related discussion club

 
Learn how to ask questions correctly  
 
 

 

Alexandra Tsybizova
alexandra.tsybizova@org.chem.ethz.ch

AMES LABORATORY DETERMINANTAL FULL CI
    PROGRAM WRITTEN BY JOE IVANIC AND KLAUS RUEDENBERG
         PROGRAM REWRITTEN BY ALEX A. GRANOVSKY
    --------------------------------------------------

THE NUMBER OF DETERMINANTS HAVING SPACE SYMMETRY A  
IN POINT GROUP C1   WITH SZ=  0.0 IS         245025
WHICH INCLUDES          70785 CSFS WITH S=  0.0
WHICH INCLUDES         113256 CSFS WITH S=  1.0
WHICH INCLUDES          51480 CSFS WITH S=  2.0
WHICH INCLUDES           9009 CSFS WITH S=  3.0
WHICH INCLUDES            495 CSFS WITH S=  4.0

and then it just sits there and it looks as it does nothing. I get no error message though. After following this calculation for about a month I tried to rerun it and the problem seems to be reproducible. The program quickly gets to this point again and again stops doing anything it seems.

Should I have waited longer?

Best regards,
Alexandra



On Fri Apr 21 '17 2:48pm, Alex Granovsky wrote
----------------------------------------------
>Dear Alexandra,

>below please find some additional comments on your questions.
>
>
>>Also, as my system is big, I have in-total 2950 orbitals, which, if I understood correctly from the manual, I should all put as a $VEC group into my input file. As a result, my input files are enormously big (~280 Mb) and often make such programs as WinSCF or Notepad++ crash when I try to open them. This is very unpleasant to work with, so I was thinking whether there might be is a way around this problem. Can I cut the number of orbitals in the $VEC group, and if so - how do I know which lines of the .dat file correspond to which orbital?

>Actually, for MCSCF you only need to provide MCSCF's core and active
>orbitals. There is no need to provide all MOs including virtual orbitals.

>For compatibility reasons, orbitals are written to the punch (.dat)
>file in the GAMESS (US) format. This means that the first two integers
>of each $vec line are orbital number modulo 100 and the relative line
>number (i.e. line number relative to the first line containing MO
>components of the current orbital). There are two digits available
>for orbital number modulo 100 and three digits for relative line
>number, without any space or other separator between them.
>Each line also contains five components of MO so that if the overall
>number of AOs is larger than 100*5 = 500, then orbital number data
>and line number data will be printed without any delimiter between
>them. Be careful and hopefully this would not confuse you. Also, take
>care to specify the proper number of MOs to read in $GUESS group
>using its NORB keyword.

>In addition I'd recommend you to specify the following option in your
>input files:

>

 $contrl wide=.t. $end

>This option increases the number of decimal places used to print MOs
>data so orbitals will be saved with better precision. While this
>increases the size of $vec group and input files, this also provides
>much better initial guess orbitals for large systems, especially if
>basis set contains quasi-linear dependences.
>
>
>As to editing of large input files under Windows OS, I'd strongly
>recommend you to install FAR manager (it is distributed free of charge)
>and use its internal file editor.

>As to your MCSCF job, how large is the active space?
>For such a large job you definitely need to use the following options
>for integral transformation stage:

>

 $trans altpar=1 mptran=2 dirtrf=.t. mode=12 $end                   

>Hope this helps.

>Kind regards,
>Alex Granovsky
>
>
>
>
>
>On Tue Apr 11 '17 3:11pm, Alexandra Tsybizova wrote
>---------------------------------------------------
>>Dear Firefly team, dear Dr. Granovsky,
>>I have faced problems with memory allocations during my CASSCF calculations.

>>Prior to doing a proper CASSCF run I did a test run with EXETYP=CHECK in the $CONTRL which terminated normally and did not reveal any memory problems. However, when i try to do an actual  CASSCF run I get an error "FSF: fatal error no. 0x00020027 ..." which points out that I have not allocated enough memory to the task. This error appears in the part of the output file which is responsible to the 2-electron integrals.
>
>
>>I am already using 479 MW of memory, which is on the edge of Firefly memory limit of 480 MW. Naturally, when I try to allocate the amount memory above 480 mwords  the job crashes with an error  "Fatal error in mem init, error code = 14"

>>I tried to use
>>./firefly8 -prealloc:500 in order to make Firefly to preallocate 500 MW, but this did not work.
>>Is there a solution to that problem?

>>Also, as my system is big, I have in-total 2950 orbitals, which, if I understood correctly from the manual, I should all put as a $VEC group into my input file. As a result, my input files are enormously big (~280 Mb) and often make such programs as WinSCF or Notepad++ crash when I try to open them. This is very unpleasant to work with, so I was thinking whether there might be is a way around this problem. Can I cut the number of orbitals in the $VEC group, and if so - how do I know which lines of the .dat file correspond to which orbital?