Firefly and PC GAMESS-related discussion club


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



Re: memory allocation for CASSCF

Alex Granovsky
gran@classic.chem.msu.su


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 ]           Fri Apr 21 '17 2:48pm
[ Reply ] [ Edit ] [ Delete ]           This message read 156 times