Adapp : exécution d'un travail séquentiel en batch

Les travaux sont gérés sur l'ensemble des noeuds par le logiciel LoadLeveler. Ils sont répartis dans des classes principalement en fonction du temps Elapsed, du nombre de coeurs et de la mémoire demandés. Vous pouvez consulter ici la structure des classes sur Ada et Adapp.

Pour soumettre un travail séquentiel en batch depuis Adapp, il faut :

  • Créer un script de soumission :

    pg_seq.ll
    # @ job_type = serial
    # Specifique Adapp
    # @ requirements = (Feature == "prepost")
    # Temps CPU max. d'un processus hhh:mm:ss (1h30mn ici)
    # @ wall_clock_limit=1:30:00
    # Nom du travail LoadLeveler
    # @ job_name = Mono
    # Fichiers de sortie du travail
    # @ output   = $(job_name).$(jobid)
    # @ error    = $(job_name).$(jobid)
    # @ queue
     
    # Pour avoir l'echo des commandes
    set -x
     
    # On se place dans le repertoire temporaire TMPDIR
    cd $TMPDIR
     
    # La variable LOADL_STEP_INITDIR est automatiquement positionnee par
    # LoadLeveler au repertoire dans lequel on tape la commande llsubmit
    cp $LOADL_STEP_INITDIR/a.out .
     
    # Execution du programme
    ./a.out
  • Soumettre ce script via la commande llsubmit :

    $ llsubmit pg_seq.ll

Remarques

  • Ne pas oublier le mot-clef # @ requirements = (Feature == “prepost”) sinon votre calcul se fera sur les nœuds de calcul standards.
  • Dans cet exemple, on suppose que l'exécutable a.out se situe dans le répertoire de soumission, c'est-à-dire le répertoire dans lequel on entre la commande llsubmit (la variable LOADL_STEP_INITDIR est automatiquement valorisée par LoadLeveler).
  • Le fichier de sortie du calcul Mono.numero_job se trouve également dans le répertoire de soumission. Il est créé dès le début de l'exécution du travail; l'éditer ou le modifier pendant le déroulement du travail peut perturber celui-ci.
  • Mémoire : La valeur par défaut est de 3,5 Go. La valeur maximale que vous pouvez demander est de 100 Go via le mot-clef as_limit. Par exemple, pour demander 20 Go : # @ as_limit = 20.0gb.
  • La limite de temps Elapsed associée au mot-clef wall_clock_limit est relative à l'ensemble du job. Elle est de 20h maximum pour les classes spécifiques à Adapp.
  • Il est aussi possible de limiter le temps CPU de chaque commande exécutée dans le job avec le mot-clef cpu_limit. L'utilisation combinée des deux mot-clefs wall_clock_limit et cpu_limit permet d'assurer l'exécution des dernières instructions d'un travail (celles suivant l'exécution de votre binaire) :

    job.ll
    # @ job_type = serial
    # @ requirements = (Feature == "prepost")
    # @ wall_clock_limit=1:00:00
    # @ cpu_limit=45:00
    # @ job_name = myjob
    # @ output = $(job_name).$(jobid)
    # @ error  = $(job_name).$(jobid)
    # @ queue
     
    set -x
     
    # Copy to the TMPDIR the files you need for your computation:
    cp -p ... $TMPDIR
    cd $TMPDIR
     
    # Run:
    ./my_prog
     
    # Save to the WORKDIR  the result files you are interested in:
    ls -alrt
    mkdir $WORKDIR/results.$(jobid)
    cp ... $WORKDIR/results.$(jobid)

    C'est l'exécution de votre binaire qui consomme l'essentiel des temps Elapsed et CPU du travail. C'est donc votre binaire qui va se heurter à la limite de temps CPU fixée par le mot-clef cpu_limit. Cependant, vous ne connaissez pas à l'avance la durée de cette phase de calcul. De plus, le répertoire TMPDIR étant automatiquement effacé à la fin du travail, vous devez sauvegarder vos fichiers avant cet effacement. Pour être sûr qu'il restera assez de temps pour effectuer les sauvegardes, choisissez une valeur cpu_limit pour le programme suffisamment inférieure à la valeur wall_clock_limit du travail. Un exécutable pouvant voir ses écritures sur disque très ralenties par la charge globale de la machine, le temps Elapsed de l'executable my_prog dans le travail va fluctuer mais pas son temps CPU. Il est donc prudent de prendre une marge confortable entre le wall_clock_limit et le cpu_limit. Il n'est cependant pas possible de vous donner une règle de bon sens car le ratio temps CPU/temps Elapsed varie pour chaque exécutable : il vous faudra procéder par essais successifs.