Firefly and PC GAMESS-related discussion club


 
Learn how to ask questions correctly  
 
 
We are NATO-free zone
 



Re^2: memory allocation for CASSCF

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


Dear Dr. Granovsky,
I have yet another problem with the same job. I have followed your suggestions and reran the calculation, however when it gets to the calculation of CI it seem to freeze. Here are the last lines in the output file that I get:

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?


[ Previous ] [ Next ] [ Index ]           Wed May 24 '17 2:33pm
[ Reply ] [ Edit ] [ Delete ]           This message read 143 times