Enviant càlculs a Química Física (l'arxiu script.pbs)

1. Introducció

El nostre actual sistema de cues Torque/Maui requereix d'uns fitxers script.pbs que contenen la informació que requereix el sistema de cues per fer córrer els càlculs. Actualment, com sabeu, hi ha uns scripts que va crear el Marc i que jo continuo modificant del tipus .pl que serveixen per enviar els càlculs a les cues estalviant-se modificar el pbs. En realitat, tots aquests scripts .pl són enllaços d'un original script.pl que és un programet en Perl que, bàsicament, crea scripts.pbs per a diferents programes i els envia.

Ara bé, hi ha programes poc utilitzats o que s'han d'emprar d'una manera "especial" i per aquests no hi ha script.pl creat. Per fer-ho fàcil, a continuació enumero els diferents scripts.pl que tenim al servidor:

Sé que s'usen més programes que aquests i que alguns són de codi propi. Per aquesta raó a continuació intentaré explicar breument com s'ha de construir un arxiu.pbs típic, com funciona i quins aspectes s'han de tenir en compte per enviar un càlcul.

2. L'arxiu script.pbs

A continuació un arxiu pbs d'exemple per enviar el càlcul input.inp amb el programa soft.

---------------------------------------
#PBS -q queue
#PBS -N input.inp
#PBS -M user@klingon.uab.cat
#PBS -l nodes=1:qdynamics7:ppn=8:soft
#PBS -k oe
#PBS -r n

cd $PBS_O_WORKDIR
. /QFcomm/modules.profile
module load SOFT

export SCRATCH=/tmp/input.inp.$USER/
mkdir $SCRATCH
cd $SCRATCH
soft -np 8 $PBS_O_WORKDIR/input.inp $PBS_O_WORKDIR/input.out
---------------------------------------

Aquí tenim un cas general, primer hi ha el bloc de línies del PBS que controlen les variables del càlcul. Després hi ha els arguments típics dels mòduls que s'han de cridar per fer funcionar un programa determinat i, finalment, al tercer bloc trobem l'execució del càlcul. Analitzem punt per punt aquest arxiu i començarem per les primeres línies on s'especifiquen determinades opcions per al gestor de cues.

2.1 Línies PBS

a) #PBS -q queue. No té cap misteri, simplement s'hi ha d'especificar la cua on volem enviar el càlcul.

b) #PBS -N input.inp. Determina el nom del job que veurem fent qstat. No cal que sigui igual al nom de l'input, però nosaltres donem el mateix nom a l'input i al job quan generem l'script.pbs a partir del .pl.

c) #PBS -M user@klingon.uab.cat. Determina a on s'ha d'enviar un mail. Amb una línia extra que no afegim #PBS -m podem especificar que volem rebre un mail quan comenci el job (b), quan acabi (e) o quan s'aborta (a). Com que no especifiquem aquesta línia el defecte és que només rebrem un mail quan el job ha estat abortat pel sistema de cues (sovint l'administador se l'ha de carregar per un motiu X).

d) #PBS -l nodes=1:queue:ppn=8:opteron:soft. Aquesta és, potser, la línia més important. Amb PBS -l determinem els requeriments del job. Comencem per nodes i ppn. Evidentment, nodes és el número de nodes i ppn el número de processadors per node. O sigui, que, en principi, no té perquè ser el mateix fer un nodes=2 que un nodes=1:ppn=2. Si només especifiquem nodes=2 ens pot agafar dos processadors del mateix node o un processador d'un node i l'altre d'un altre, ara bé amb nodes=1:ppn=2, segur que només agafarà un node i pendrà dos processadors d'aquest node. Aixó és molt important perquè alguns programes simplement no paral·litzen entre diferents nodes (com Gaussian) peró sí entre diferents processadors d'un mateix node. Altres programes, com charmm, amb una especifació de nodes=16 agafarien 8 processadors d'un node i 8 d'un altre, però depenent dels nodes que hi hagi lliures podrien agafar-se altres combinacions (un node amb 8 i dos amb 4, 4 amb 4, etc.). D'aquesta tasca se n'ocupa l'scheluder Maui però això ja és una altra història.

A més, podem especificar nodes= al número de nodes o bé al node en concret on volem enviar el càlcul, això pot resultar cabdal per fer que el nostre càlcul vagi a una màquina determinada perquè té unes caracterísques especials (més disc o memòria per exemple). Per fer-ho, hauríem d'escriure nodes=borg44.uab.es per exemple.

Finalment, queue, opteron i soft són requeriments que es demanen als nodes on han de còrrer els càlculs, és a dir, nodes que tinguin com a opció formar part de la cua queuei, ser opterons i tenir l'opció soft perquè tenen aquest programa. Les propietats d'un node es poden saber fent pbsnodes -a nom_del_node. Per exemple:

$pbsnodes -a borg73.uab.es
borg73.uab.es
state = free
np = 8
properties = opteron,IB,qdynamics7,em64t
ntype = cluster
status = opsys=linux,uname=Linux borg73.uab.es 2.6.26.6-49.fc8 #1 SMP Fri Oct 17 15:33:32 EDT 2008 x86_64,sessions=? 0,nsessions=? 0,nusers=0,idletime=1671510,totmem=47188296kb,availmem=40088248kb,physmem=16472024kb,ncpus=8, loadave=0.00,netload=106906831555,state=free,jobs=,varattr=,rectime=1290617733

En aquest cas, les propietats que posaríem són les de la línia properties: #PBS -l nodes=1:queue:ppn=8:opteron:IB:qdynamics7:em64t. Fixeu-vos que la separació entre les propietats són els dos punts i no la coma.

e) #PBS -k oe. Defineix si els fitxers anomenats standard error i standard otuput han de ser retinguts al host d'execució del qsub. És a dir, al servidor on ens trobem. oe significa que els dos seran retinguts i que es crearan al $HOME de l'usuari. Aprofito per comentar que un cop el càlcul ha acabat bé no estaria malament anar eliminant aquests arxius perquè no us omplin el $HOME d'arxius petits o buits.

f) #PBS -r n. Determina que el job no pot ser rerunable. No cal que toqueu aquesta opció.

Trobareu més informació sobre totes aquestes opcions fent: man qsub.

2.2 Línies de càrrega de variables (mòduls)

Un cop acabades les línies on donem informació al sistema de cues, hem de passar a escriure el que s'executarà al node remot. Faig una separació entre la càrrega de variables i l'execució del programa per facilitar-me l'explicació però no és una separació real.

Si ens fixem en l'exemple, hi ha primer un apartat on anem cap a un directori anoemenat $PBS_O_WORKDIR. Es tracta d'una variable del sistema de cues on $PBS_O_WORKDIR fa referència al directori exacte des d'on enviem el job, a on som, des d'on fem qsub. No té més importància que aquesta. Altres variables del sistema de cues Torque/Maui poden consultar-se fent man qsub.

Les dues línies següent són bàsiques per entendre com funciona l'assignació de programes al nostre clúster. Primer, executem un modules_profile que el que farà simplement serà activar-nos la possibilitat d'usar els mòduls. Recordeu que els mòduls serveixen, molt bàsicament, per declarar variables de programes i afegir al PATH les comandes dels diferents programes sense haver d'estar tocant el bashrc.

Posteriorment carreguem el mòdul que ens interessa. Aquí hem de tenir clar quin programa volem i amb quines característiques. Per exemple, és molt important que el programa estigui en 64 bits si enviem a una cua de 64 bits o bé que sigui la versió adecuada. Recordeu que només cal escriure module av a spock o scott per veure la llista de mòduls que tenim amb les diferents versions del programes disponibles.

També heu de tenir present si el programa requereix un mòdul extra per al càlcul en paral·lel, és a dir, un mòdul d'interfície en paral·lel com MPICH2, MVAPICH2, OPENMPI o bé si per satisfer determinats requeriments de llibrerires ens calens els mòduls dels compiladors (PGI o IFC). En determinats casos, el mòdul del programa ja carrega els mòduls extra que es requereixen o, per altra banda, el que succeeix normalment és que usant l'script.pl ja se'ns crea un arxiu script.pbs on es carreguen tots els mòduls que calgui. En qualsevol cas, si teniu dubtes sobre un programa i els mòduls que cal carregar, no dubteu en consultar-ho. Al web també trobareu molta informació respecte els diferents programes que hi ha a la Unitat.

2.2 Línies d'execució del programa

Només resten les línies d'execució del programa, que al nostre exemple inicial són:

---------------------------------------
export SCRATCH=/tmp/input.inp.$USER/
mkdir $SCRATCH
cd $SCRATCH
soft -np 8 $PBS_O_WORKDIR/input.inp $PBS_O_WORKDIR/input.out
---------------------------------------

On soft seria l'executable i la resta un conjunt de definció de variables per a l'SCRATCH.

La majoria de programes es creen amb els scripts .pl i allà s'especifica quin és l'executable, com funciona el número de nodes i demés. Ara bé, per a programes poc habituals, especials o que heu fet vosaltres mateixos (és a dir, aquells sense script .pl per enviar els jobs) heu de conèixer el seu funcionament pas per pas per tal d'escollir l'executable i les opcions que calen. Aquesta informació es pot trobar als manuals (consulteu els manuals de harry o bé a la xarxa), tot i que, a més, informació resumida i important se sol trobar en els README dels codis fonts del programa. Si el programa l'heu fet vosaltres, evidentment, sabeu com funciona.

IMPORTANT. Fixeu-vos que en aquest exemple, creem un directori SCRATCH que no està compartit per xarxa, hi és físicament al disc del node, anem allà i executem el programa des de l'SCRATCH. Això funciona per exemple per aconseguir que programes com Gaussian facin l'escriptura intesiva al disc propi del node. Altres, per exemple, Gamess, requereixen copiar l'input a l'SCRATCH i executar-ho en aquest directori. Sigui com sigui, és molt important tenir en compte aquest factor, la velocitat i l'estabilitat de la nostra xarxa es veu afectada quan hi ha un càlcul intensiu que ho escriu tot (fitxers d'integrals, informació temporal, etc.) al /users/ quan el que seria convenient és que només si hi escrigui l'output al /users/ (sempre que aquest ouput no sigui on el càlcul vomita tota la informació d'integrals, etc., que no sol ser el cas). Això és d'especial importància per a les màquines del Servei d'Informàtica perquè amb la connexió en VPN es resenteixen molt més si han d'escriure per xarxa i pot haver-hi problemes d'estabilitat de la xarxa del Clúster.

D'aquesta forma, per exemple, una altra opció interessant per aquestes línies seria:

---------------------------------------
export SCRATCH=/tmp/input.inp.$USER/
mkdir $SCRATCH
cp -f $PBS_O_WORKDIR/* $SCRATCH
cd $SCRATCH
soft -np 8 input.inp $PBS_O_WORKDIR/input.out
---------------------------------------

S'hauria de crear un directori per càlcul per fer-ho més ordenat. Per altra banda, en cas que el programa no ens permiti redigir l'output del càlcul, s'hauria de copiar finalment l'ouput al $PBS_O_WORKDIR (és a dir, s'hauria de fer:
cp -f $PBS_O_WORKDIR/* $SCRATCH
cd $SCRATCH
soft -np 8 input.inp
cp -f $SCRATCH/* $PBS_O_WORKDIR/
)
Tot i que no és gaire aconsellable perquè llavors només podrem controlar el càlcul des del node i no des del servidor. A més, sempre hi ha l'opció d'entrar al node on hi ha el càlcul, anar al directori $SCRATCH i recuperar la informació que calgui.

La recomanació és que en cas de dubte consulteu sempre a l'administrador amb els vostres programes, que us mireu bé la diferent documentació relacionada amb els programes i, finalment, que mireu també si hi ha informació aquí. Així podreu fer que els càlculs siguin més eficients i que tot funcioni millor per a tots.

Unitat de Química Física
Departament de Química
Edifici Cn.
Universitat Autònoma de Barcelona
08193 Cerdanyola
Tel. Departament: +34 93-581.1997
Fax Departament: +34 93-581.2477
Última actualització: 28/07/2015