Módosítások

=== Job submission ===

Back then, the SGE scheduler was designed to be able to operate different types of architectures. That’s why you can’t post binary files directly, only scripts, like the

/bin/hostname

</code>

can be posted with the following command:

qsub hostname.sh

</code>

The scripts can be used for separating the different binaries:

qsub -q serial.q range.sh

</code>

The command qsub can be issued with a number of different switches, which are gathered in the following table:

|The shell in which the scripts run.

|-

| -j y

|Joining the error and the output in one file.

|-

| -r y

|After a restart, should the job restart too (from the beginning).

|Resource reservation. This will cause that bigger parallel jobs will get higher priority.

|}

qsub command arguments can be added to the ~/.sge_request file. If this file exists then it will be added to the qsub arument list.

qmod -us 903

</code>

The previous one suspends the running of number 903 (SIGSTOP), while the latter one allows (SIGCONT).

If there is a need to change the features (resource requirements) of a job put into the waiting list, it can be done with the command: ''qalter''

<code>

qalter -l h_cpu=0:12:0 903

</code>

The previous command alternates the hard-CPU requirements of the job number 903 (h_cpu) and changes it to 12 minutes. The switches of the qalter command are mainly overlap the ones of the qsub command.

In a special case, we have to execute the same task, but on different data. These tasks are the array jobs. With SGE we can upload several jobs to the waiting. For example in the pi task shown in previous chapter, it can be posted multiple times, with different parameters, with the following script:''array.sh''

<code>

The SGE_TASK_ID is an internal integer used by the SGE, which created values for each running job. The interval can be set up when posting the block:

<code>

qsub -t 1-7 array.sh

</code>

meaning that the array.sh program will run in seven issues, and the SGE_TASK_ID will have the value of 1, 2, ..., 7 in every running issue. The qstat -f shows how the block tasks are split:

<code>

parallel.q@cn30 BIP 0/0/24 0 linux-x64

test.q@cn32 BIP 0/7/24 7.15 linux-x64

907 1.00000 PI_ARRAY_T stefan r 06/04/2011 10:34:14 1 1

<code>

HOSTNAME ARCH NCPU LOAD MEMTOT MEMUSE SWAPTO SWAPUS

global - - - - - - -

cn01 linux-x64 24 24.43 62.9G 3.0G 0.0 0.0

serial.q BI 0/42/48