xterm Xt error: Can't open display: 
xterm:  DISPLAY is not set

     

1. the program you are trying to run requires you to be a member of a software group. Check in the software pages whether the program has access prerequisites.
2. you created your batch script file on a Windows box then copied it across to the VU or XE. Windows introduces some extraneous invisible characters at the end of the lines in the file. To remove these from a batch script called, say, runjob.sh and convert it from DOS to Unix format you do

         dos2unix runjob.sh
         

    #!/bin/sh
    #PBS -Pa99 
    #PBS -lwalltime=20:00:00,vmem=300MB
    #PBS -ljobfs=1GB
    #PBS -wd

1. If you submit a script as an argument to qsub, check that there is a newline character at the end of the last executable line. The easiest way to do this is to simply cat the script - if the last line of the output has your shell prompt attached, edit the file to put a blank line at the end.

2. Often when using a workstation, people run their job in the background, say ./runjob &, which works fine interactively. However, when translated to a queue batch script the result is often

       #!/bin/sh
       #PBS -q normal
       #PBS -l walltime=00:10:00,vmem=400MB
   
       ./runjob &
   

   This script will exit almost immediately as it is trying to run runjob in the background. Since the script exits immediately, the queue system assumes that the job is finished and kills off all user processes. Consquently, your code which runs fine interactively gets killed almost immedately out on the queue.

   There are two solutions. Try the batch job script

       #!/bin/sh
       #PBS -q normal
       #PBS -l walltime=00:10:00,vmem=400MB
   
       ./runjob
   

   NOTE: the missing &

   BUT, if your runjob is itself a complicated script which starts up all sorts of program in the background try

       #!/bin/sh
       #PBS -q normal
       #PBS -l walltime=00:10:00,vmem=400MB
   
       ./runjob
   
       wait
   

   which will tell the shell (/bin/sh) to wait until all background jobs are finished before exiting. This will prevent your background jobs from being killed and allow your program to complete.

Usually the reason your job is not running is shown by qstat -s jobid.

More information on how the scheduler works is available here.

Say a large parallel jobs requires N cpus to be available to start running. Most sites would hold cpus idle as running jobs complete until N CPUs become available. This can leave a lot of cpus idle for quite a while.

On NF systems smaller queued jobs are able to "jump" the queued N CPU parallel job and start early keeping as many cpus as possible busy all the time. The scheduler uses a sophisticated algorithm such that when around N CPUs worth of jobs have jumped ahead and started, some subset of those (and possibly other) running jobs are selected to be suspended to allow the queued parallel job to start. The scheduler tries to limit job suspension to maintain fairness to all jobs and to projects.

In order to optimize CPU utilization on the system, queued jobs are started as soon as possible. This results in small jobs (which can "fill" small "holes" in the available cpus more easily) generally spending much less time in queued state. The trade-off is that they potentially spend some time in suspended state. The NF estimates that job preemption (suspension/resumption) is giving around 25-30% better system utilization than more traditionally scheduled systems. That means everyone's grants are effectively 25-30% larger - we hope you will accept occasional longer suspensions for this win.

Important: suspend time is roughly proportional to the job's requested walltime. It is in your best interest to make your walltime (and other resource) requests as accurate as possible.

There is more explanation in the scheduling policy document.

Obviously what you specify with -lncpus should be reflected in the Gaussian %nproc line.

For memory requests, the %mem line in your Gaussian input file specifies the work area that Gaussian uses. Gaussian also needs memory for the program, other data and shells etc. To safely allow for this other memory, the %mem value should be about 500-600MB less than the PBS -lvmem value (possibly more in some cases). You can tune this difference with experience by comparing the actual vmem used by your job (see the job stdout file after the job completes) and the %mem request.

You can also specify a maxdisk option to Gaussian - this should reflect your -ljobfs request.

     jobid1=`qsub job1`
     qsub -Wdepend=after:$jobid1 job2

There are various ways to avoid this race condition. One sure way is to hold job1 until job2 is submitted:

     jobid1=`qsub -h job1`
     qsub -Wdepend=after:$jobid1 job2
     qrls $jobid1

     jobid1=`qsub -a now+120 job1`
     qsub -Wdepend=after:$jobid1 job2

The same problem can arise with other forms of job dependencies

Note that if you are using the Intel fortran compiler you will also need:
setenv decfort_dump_flag y (in tcsh)
export decfort_dump_flag=y (in bash)