Support

To ask for technical support please contact the SeARCH cluster administrator by sending an e-mail message to “search-admin <at> di.uminho.pt”.

Cluster access

The cluster has two servers that perform the following functions: login of users, compilation of programs, file transfer and job submission.

Thus, these access servers should not be used for computing, which should always be managed through the queue management system (batch).

The access to the SEARCH can only be done through SSH connections (Secure Shell):

$ ssh search.di.uminho.pt

Jobs submission

The jobs submission should use the commands of Torque (based on PBS) and of Maui scheduler. The challenge of finding the configuration well balanced between the requisition machines, the duration of the work, priorities and management system is never completely resolved. Thus, the management policies of the queues will be refined in an effort to maximize the efficiency and the fairness in access to resources.

The queue management system should be used in all computing jobs. In principle there is no need to login to the compute nodes, unless it is necessary to terminate processes that for some reason have been outstanding.

Create a job

By creating jobs is a good practice to put them in separate directories. New directories will be created with mkdir.

For this example we will create a job called “example”.

[xxxx@search xxxx]$ mkdir exemplo

[xxxx@search xxxx]$ cd exemplo

[xxxx@search exemplo]$ _

To create a new job run the vi text editor:

[xxxx@search exemplo]$ vi exemplo.scr

And insert the following:

#!/bin/sh

#PBS -l nodes=1

#PBS -l walltime=05:00

echo “Olá  mundo!”

sleep 60

Then you must record this script (with [Shift]Z+Z or “:w”, for example).

Submit a job

After creating the script you can submit it for execution by the queue management system via the qsub command, using the script name as a parameter.

[Xxxx @ search example] $ qsub exemplo.scr

41209.d1

If the job was properly processed, the identifier of the new job is presented as a command response (41209.d1 the example shown). This identifier can be used for managing the jobs submitted through subsequent commands. To get information about the progress of job, you can use the commands qstat or showq, which present the list of jobs running and waiting.

[xxxx@search exemplo]$ qstat

Job id           Name             User             Time Use S Queue

—————- —————- —————- ——– - —–

36305.d1         Pol14            usr1             30:52:57 R workq

36311.d1         job.sh           fak              156:26:0 R workq

41209.d1         exemplo.scr      xxxx             00:00:00 R workq

From this table we can see that the job 41209 is running (R). When the job is done will no longer appear in this list.

Presentation of results

When the job completes the directory where it was submitted contain two additional files, one containing the error messages (stderr) and another containing the output to the console (stdout).

[Xxxx @ Search instance] $ ls

exemplo.scr exemplo.scr.e41209 exemplo.scr.o41209

When printing the contents of files will appear the following result:

[Xxxx @ search example] $ cat exemplo.scr.o41209

Hello world!

[Xxxx @ search example] $ cat exemplo.scr.e41209

[Xxxx @ search example] $ _

Organization of resources

Current resources are organized in queues of execution in order to facilitate jobs of different duration:

    • Long jobs (over 20 days);
    • Medium jobs (over 20 hours and less than 20 days);
    • Short jobs (over 15 minutes and less than 20 hours);
    • Testing jobs (under 15 minutes).

The existence of these queues is, however, transparent to users who only need to submit their jobs by specifying the resources needed and length of use, illustrating:

[xxxx@search xxxx]$ qsub -l nodes=1:ppn=2 -l walltime=31:12:00 job.sh

Where walltime specifies a duration of 31 hours and 12 minutes to the job “Job.sh”.