dépendance univoque entre deux groupes de travaux dans SLURM

Question

Le serveur vient de passer de CONDOR à SLURM. J'apprends donc à essayer de traduire mon script de soumission en SLURM.

Ma question est la suivante, j'ai deux tableaux de travail. Le second dépend du premier. Pour le moment, je quelque chose comme

events1=$(sbatch --job-name=events --array=1-3 --output=z-events-%a.stdout myfirst.sh) 
jobid_events1=`echo ${events1} | sed -n -e 's/^.*job //p' ` 
echo "The job ID of the events is "${jobid_events1} 

postevents1=$(sbatch --job-name=postevents --dependency=afterany:${jobid_events1} --array=1-3 mysecond.sh) 
jobid_postevents1=`echo ${postevents-cftables1} | sed -n -e 's/^.*job //p' ` 
echo "The job ID post-event calculations is "${jobid_postevents1} 

Voici le second tableau d'emploi postevents1 ne commencera après chaque élément du premier ensemble d'emplois événements1 a terminé. Cependant, ce que je veux, c'est que le i -ième élément de la deuxième matrice de travail dépend uniquement du i -ième élément du premier tableau de travail (En pratique, les deux tableaux ont toujours la même taille). Je sais que cela peut être fait en utilisant DAG dans le cas de CONDOR.

Je me rends compte que je peux casser manuellement le deuxième tableau de travail et faire la correspondance individuellement. Cependant, étant donné que je devrai rompre le deuxième tableau de travail, cela devient de plus en plus gênant pour moi si un troisième travail dépend de tous les éléments du second tableau de travail.

Modifier: Selon damienfrancois réponse de, le mot-clé aftercorr est ce que je cherchais. J'ai une question de suivi. Même si, à première vue, «réussir avec succès» est tout à fait logique. Cependant, si l'une des tâches (dans le premier tableau de travail) ne se termine pas correctement, il faut supprimer manuellement la tâche correspondante dans le second tableau? Si c'est le cas, ce qui le rend potentiellement compliqué est que tout autre travail qui dépend de l'achèvement partiel des tâches du second tableau de travail sera bloqué là si une tâche du premier groupe de travail échoue (ce qui est assez courant dans ma pratique). Dans ce cas, comment peut-on implémenter l'option "afterany"?

Merci beaucoup d'avance!

Answer 1

Depuis la version 16.05, Slurm a une option de --dependency=aftercorr:job_id[:jobid...]

Une tâche de ce tableau de travail peut commencer l'exécution après la tâche ID correspondant dans le travail spécifié a terminé avec succès (couru à fin avec une sortie code de zéro).

Il fait ce dont vous avez besoin.

Il a cependant l'inconvénient que vous décrivez; les travaux dans le second tableau continueront à attendre indéfiniment si le travail correspondant dans le premier tableau tombe en panne. Vous avez plusieurs moyens d'action, dont aucun est parfait:

1. si les accidents de travail peuvent être détectés à partir du script de soumission, et les accidents sont aléatoires, vous pouvez simplement requeue le travail avec scontrol require $SLURM_JOB_ID pour qu'il fonctionne à nouveau .Sinon, vous pouvez ajouter, à la fin des travaux dans la deuxième matrice, un code Bash qui vérifierait si un travail du premier tableau est toujours dans la file d'attente et, dans le cas contraire, annuler tout ce qui reste emplois dans le second tableau; quelque chose comme ceci (non testé) [[ $(squeue --noheader --name events | wc -l) == 0 ]] && scancel $SLURM_JOB_ID

2. Enfin, une dernière option consiste à utiliser un système de flux de travail à part entière. Voir this pour une courte introduction et des pointeurs.