Reply - Large Gaussian RWF Files

 > I have a question concerning the case of large RWF-files in Gaussian
 92/DFT. > Doing analytical FREQ calculations the RWF-file grows to
 remarkable size and > sometimes becomes larger than the available diskspace
 (or the limit of the
 > file-system specified by the operating system). >
 > Im am working on a AIX-system and I am thinking about the possibility to
 > split the RWF-file in two files and to put them on two different
 > file-systems. So my question is, if this splitting of the RWF-file is >
 possible (and HOW) ?
 >
 > But I would also be happy to get other comments on the possibility to >
 decrease the amount of necessary diskspace during analytical FREQ
 > calculations.
 >
 > Thanx in advance
 >
 > Ch. Ehrendorfer
 Common "workstation" UNIX operating systems (IBM AIX, SGI Irix 5.2 and
 6.0,
 and HP UX but not DEC OSF/1 - nor Cray UNICOS or Convex) limit file system
 size to about 8-14 GB and a single file to about 2 GB.  To minimize Gaussin
 92/DFT scratch file sizes, try a combination of the keywords:
      Direct MP2=Stingy Opt=CalcHFFC Freq=NoRaman
 This forces direct MP2 and direct SCF which minimizes scratch file size.  A
 system of about 165 basis functions may be accommodated within 2 GB.  Using
 "Freq" without the "NoRaman" modifier reduces the maximum
 problem size to
 about 150 basis functions.
      NOTE:  Do not use "Direct" redundantly, i.e., as a keyword AND as
 a
      modifier for another keyword since it can "confuse" the job setup
      routine.  For example:
      DON'T USE THE COMBINATION:   Direct Opt=(Direct, CalcHFFC)
 Modifying the code in order to parse the scratch file(s) is a significant
 undertaking and may be unneccessary.  Relief may be forthcoming in the near
 future from the eagerly awaited next major update to Gaussian/DFT and
 manufacturers are bound to introduce changes to their OS in 95-96.  In
 other words, the modified code will be obsolete just about the time you
 modify and test it.  If you really need it now, you may consider purchasing
 or borrowing time on an alternative system, e.g., DEC OSF/1, which doesn't
 have this limitation.
 Karl F. Moschner              Karl.F.Moschner -AatT- urlus.sprint.com
 Unilever Research U. S.