MCSR

You must make sure you specify enough memory when you submit the job to PBS. If in doubt, try
specifying a lot more memory than you think you need. You must also specify enough memory in your
input file. Memory specified in the input file will take precedence over memory specified to PBS.

How can I make the read-write file span multiple physical files?

If I try something like this:
%RWF=/dsk1/f1,-1,/dsk2/f2,-1,/dsk3/f3,-1
then the program just writes to the first file until it runs out of space on that disk.
If I give explicit sizes like this:
%RWF=/dsk1/f1,20,/dsk2/f2,20, ...
then I get an error message:
No file to extend for IUnit=1 --Out of disk space
Error termination in NtrErr
There is lots of disk space available on all of these disks, far more than 20 MW.

The value -1 says that a file segment may be enlarged without limit. It is intended for use on the
final file segment only. Contrary to what is implied in the manual, -1 is not an option which means
use all available space and then go on to the next file. The information required for this is not readily
available from most operating systems.

The value 0 says to retain the current size of an existing file segment. Thus, it should not be used for file
segments which do not already exist. All other values are interpreted as words, not as megawords. Thus,
your second example specified each file segment as 20 words in length, and that fills up quickly. You need
to add the MW suffix to the value of 20 in your second example in order for things to work properly.

Is there any way to get the molecular orbitals in the same orientation as was used in the Gaussian input file, rather than in Gaussians standard orientation? (I want to be able to compare the MOs in a series of related molecules, but the program doesn't give the orbitals in a consistent orientation.)

You can use the NoSymm keyword to obtain this desired effect. NoSymm tells Gaussian to ignore any
symmetry in the molecule, treating it as if it had no symmetry, and leaving the molecule in the input orientation.
Using NoSymm will have significant performance consequences for Hartree-Fock and DFT calculations,
and negligible to modest performance consequences for other calculation types.

How can I optimize the geometry of thiophne at the MP2 level?
(The job I ran exited without converging after 63 cycles, taking an enormous amount of time on each point.
Whats wrong? Would I be better off using Cartesian coordinates?)
Route section from the job:
#P RMP2/3-21G** SCF=DIRECT FOPT MP2=STINGY

The problem is with your route. You have specified MP2 twice. This results in an MP4 optimization, not one
at the MP2 level. As a result, you are using the FP optimizer, which only uses energies and not gradients.

I would suggest that you use this route instead:
#P MP2/6-31G** SCF=Direct FOpt=CalcHFFC

for the following reasons:
MP2=Stingyonly affects MP2 frequency calculations, so you can leave that off.
(It is ignored in this case, so it wont actually hurt you either).
FOpt is a good idea; it does not change the optimization algorithm, but adds a check to see that your
coordinates are really independent and span the space in which you are optimizing.
However, an even better optimization method would be to compute the HF frequencies at the first point
by using FOpt=CalcHFFC. The force constants are quite transferable between basis sets and methods.
You should consider moving to 6-31G* or 631G** to really get the correlation as opposed to basis set
incompleteness. In order to get systematic improvement with electron correlation, you must use an
adequate basis set. The 3-21G** basis set suffers from considerable basis set incompleteness, and 631G*
is the smallest basis set you should consider using.
The issue of Cartesian vs. internal coordinates is the subject of considerable debate. In general, if you have
a good Z-matrix, an optimization with internals will be at least as fast as one using Cartesian coordinates.

I was running a large MP2 calculation when the job died having filled my 1 GB scratch disk. I had used
MAXDISK=80000000 and MP2=DIRECT in the route section. Why did Gaussian ignore MAXDISK?

There are two common misunderstandings about MAXDISK: its units and what it can control. The units are
REAL*8 words; divide the number of bytes you want by 8 to get the proper value to specify to MAXDISK.
Since 80 million REAL*8 words is only 640 MB, you are correct that the scratch disk usage should not exceed
the available disk space. The real problem is that the scratch space used for the AO integrals is not included in
MAXDISK. In your case, you need to specify SCF=Direct to minimize disk usage.
Certain calculation types also require fixed minimum amounts of scratch space and thus cannot honor MAXDISK
when it is smaller. These include QCISD(T) and MP4SDTQ energies and QCISD gradients. MP2 frequency
calculations also try to obey MAXDISK, but will consume more space if that is the only way for execution to continue.

What do these messages (prefaced by >>>> below) from Gaussian mean?

ONE-ELECTRON INTEGRALS COMPUTED USING PRISM. THE SMALLEST EIGENVALUE OF THE
OVERLAP MATRIX IS 1.527D-01 PROJECTED HUCKEL GUESS. REQUESTED CONVERGENCE ON RMS
DENSITY MATRIX=1.00D-08 WITHIN 64 CYCLES. REQUESTED CONVERGENCE ON MAX DENSITY
MATRIX=1.00D-06. INTEGRAL ACCURACY REDUCED TO 1.0D-05 UNTIL FINAL ITERATIONS.
>>>> PROBLEM DETECTED WITH INEXPENSIVE INTEGRALS. >>>> SWITCHING TO FULL ACCURACY
AND REPEATING LAST CYCLE.

Gaussian 98 attempts to perform the initial iterations of a HartreeFock or Density Functional calculation using
aggressive cutoffs in order to speed up the calculation, then switching to more accurate results as convergence is
approached. This message indicates that the cutoffs were found to be too aggressive and the program switched
over to full accuracy early. There is no problem with the final converged results.

what should I do if I get this error "/usr/local/apps/g98/linda-exe/l302.exel: error while loading shared libraries: util.so: cannot open shared object file: No such file or directory"?
To run a g98 job on mimosa, you need to have a file called .cshrc in your home/login directory, containing the following:
setenv g98root /usr/local/apps
source /usr/local/apps/g98/bsd/g98.login