Firefly and PC GAMESS-related discussion club

Learn how to ask questions correctly

Alex Granovsky
gran@classic.chem.msu.su

if you look into Firefly's output, you'll see:

 -----------------------------------------------
  STATISTICS ON AUTOMATIC COORDINATE GENERATION 
 -----------------------------------------------
  NUMBER OF USER SPECIFIED  BONDS                   0
  NUMBER OF AUTOGENERATED H-BONDS                   0
  NUMBER OF BONDS                                 319
  NUMBER OF ANGLES KEPT                          1474
  NUMBER OF ANGLES DELETED                          1
  NUMBER OF TORSIONS KEPT                        9880
  NUMBER OF TORSIONS DELETED                       98
  NUMBER OF OUT OF PLANE BENDS KEPT              1652
  NUMBER OF OUT OF PLANE BENDS DELETED             23
  NUMBER OF GENERATED PSEUDOBONDS                 154
  NUMBER OF EXTRA COORD.                            0
  NUMBER OF EXTRA COORD. FOR CONSTRAINTS            0
  NUMBER OF CONSTRAINED COORD.                      0

  TOTAL NUMBER OF PRIMITIVES                    13325
 -----------------------------------------------

The number of primitives is really huge (esp. torsions).
The construction of DLCs requires some steps that use
several square arrays with dimension equal to the number
of primitives... so the memory requirements are huge as
well.

Basically, the problem is with Cesiums. Namely, the vdW
radius of Cesium that is internally stored and used to detect
bonds is 2.35 Angstrom. This means that there are lots of automatically
detected Cs-Cs bonds and enormous number of torsions.
The workaround would be to use smaller value as Cs vdW
radius, however there is no way to change the internally
stored value at present.

Regards,
Alex Granovsky




On Wed Apr 7 '10 10:03am, Vyacheslav wrote
------------------------------------------
>Hi,
>I tried to run in direct or conventional mode on 8-40 cores the input with line

>$zmat   dlc=.t. auto=.t. $end

>(of course, in $Contrl I insert nzvar=…).

>In all cases I see in outputs strange demand to give fantastic amount of RAM – for example, in attached output (conventional mode) FF want to have about 800 mwords for its modest needs. Deleting from input option by option (only excess options :) ) I've found out that this requirement is generated with an dlc option.
>Notice, behavior is identical both for 40 cores (5 nodes) and for 8 cores (1 node, 24 Gb RAM). In direct FF demands less memory but if receives it in input then puts forward the new requirement…
>After dlc option removal the input was started in direct with 120 mwords only and now is running (on each node FF use about 3 Gb).
>I have made something incorrectly?

>