Ada : classes batch et limitations interactives

*****************************************************************************

Structure des classes sur Ada                                16 decembre 2016

*****************************************************************************

1) Limites en interactif 
   =====================

     - Monoprocessus sequentiel ou multitache (OpenMP/Pthreads) : 
           Memoire pour l'ensemble du travail : < 3.5Go
           Duree   : 30 minutes (temps CPU)
           Nombre de taches max. : 4

     - Multiprocessus (MPI) : 
           Memoire par processus MPI : 3.5Go
           Duree   : 30 minutes (temps Elapsed)
           Nb. de processus max. : 32 (a l'aide de la variable MP_PROCS).


2) Structure des classes en traitement par lots
   ============================================

   Acces aux classes monoprocessus (sequentiel) : 
   --------------------------------------------
   T(h) ^ ELAPSED
        |
   100h +---------------+-----------------|
        |       t4      |      t4L        |
    20h +---------------+-----------------|
        |       t3      |      t3L        |
    10h +---------------+-----------------|
        |       t2      |      t2L        |
     1h +---------------+-----------------| 
        |       t1      |      t1L        |
      0 +---------------+-----------------+--> Memoire
                       3.5Go            20.0Go

L'acces a ces classes se fait par le mot-clef :
                         # @ job_type = serial
La memoire par defaut est de 3.5 Go. Vous pouvez demander jusqu'a 20 Go avec
le mot-clef :            # @ as_limit = 5.0gb


   Acces aux classes OpenMP ou Pthreads (multithread) :
   ----------------------------------------------------

   T(h) ^ ELAPSED
        |
   100h +-------------+--------------+--------------|
        |   mt8t4/L   |   mt16t4/L   |   mt32t4/L   |
    20h +-------------+--------------+--------------|
        |   mt8t3/L   |   mt16t3/L   |   mt32t3/L   |
    10h +-------------+--------------+--------------|
        |   mt8t2/L   |   mt16t2/L   |   mt32t2/L   |
     1h +-------------+--------------+--------------|
        |   mt8t1/L   |   mt16t1/L   |   mt32t1/L   |
      0 +-------------+--------------+--------------+--> Nombre de
                      8             16             32    coeurs

Le nombre de coeurs dans un travail (ici 5) est fixe par les mots-clefs :
                         # @ job_type = serial
                         # @ parallel_threads = 5
La variable OMP_NUM_THREADS est automatiquement positionnee a la valeur de
parallel_threads.

Par defaut, la memoire par coeur est de 3.5 Go. Le maximum que vous pouvez
demander est de 7.0 Go par coeur (classes dites "Large"). Vous pouvez
reduire la demande memoire pour faciliter le passage de vos travaux, ou
l'accroitre (sans depasser 7.0 Go par coeur) avec le mot-clef :
                         # @ as_limit
Attention : as_limit indique une valeur PAR PROCESSUS, or pour un travail
OpenMP/pthreads, il n'y a qu'un seul processus qui genere et comptabilise
la memoire de TOUS les threads. Ainsi, si votre binaire genere 5 threads et
que vous avez besoin de 7.0 Go par thread, vous devez positionner 
as_limit a 5*7,0 Go :    # @ as_limit = 35.0Gb


   Acces aux classes MPI ou hybrides (MPI+threads) :
   ------------------------------------------------

   T(h) ^ ELAPSED
        |
   100h +--------+---------+---------+
        | c8t4/L | c16t4/L | c32t4/L | 
    20h +--------+---------+---------+---------+-- ......... --+---------+
        | c8t3/L | c16t3/L | c32t3/L | c64t3/L |   c.......t3  | c2048t3 |
    10h +--------+---------+---------+---------+-- ......... --+---------|
        | c8t2/L | c16t2/L | c32t2/L | c64t2/L |   c.......t2  | c2048t2 |
     1h +--------+---------+---------+---------+-- ......... --+---------|
        | c8t1/L | c16t1/L | c32t1/L | c64t1/L |   c.......t1  | c2048t1 |
      0 +--------+---------+---------+---------+-- ......... --+---------+-->
                 8        16        32        64,128,256,512,1024      2048
                                                       Nombre de coeurs

Le nombre de processus MPI dans un travail (ici 8) est fixe par les 
mot-clefs :              # @ job_type = parallel
                         # @ total_tasks = 8

Pour un travail hybride, le nombre de taches OpenMP/Pthreads par processus
MPI ne peut exceder 32; il est fixe (ici a 4) grace au mot-clef :
                         # @ parallel_threads = 4
Le nombre de coeurs demandes est alors total_tasks * parallel_threads :
avec les valeurs ci-dessus, il faudrait demander 32 coeurs.

ATTENTION : Les travaux qui demandent plus de 32 coeurs 
(total_tasks * parallel_threads > 32) tournent sur des noeuds qui leur sont
DEDIES. Dans ce cas, le nombre de coeurs reserves ET FACTURES est un
multiple de 32 : si vous demandez 65 coeurs, 96 coeurs vous seront factures.

Par defaut, la memoire par coeur est de 3.5 Go. C'est le maximum accessible
pour un travail de plus de 64 coeurs; pour 64 coeurs ou moins, le maximum est
de 7.0 Go par coeur (classes dites "Large"). Vous pouvez reduire la demande
memoire pour faciliter le passage de vos travaux, ou l'accroitre (sans
depasser 3.5 ou 7.0 Go par coeur) avec le mot-clef :
                         # @ as_limit
Attention : as_limit indique une valeur PAR PROCESSUS MPI. Ainsi, pour les
travaux MPI "purs", la memoire par processus MPI est egale a la memoire par
coeur. Par exemple, pour demander 3.0 Go par processus MPI, specifiez
                         # @ as_limit = 3.0Gb
Mais pour les travaux hybrides (MPI+threads), la memoire par tache MPI est
egale a la memoire par thread multipliee par le nombre de threads demandes.
Par exemple, si votre binaire genere 5 threads par processus MPI et que vous
avez besoin de 7.0 Go par thread, vous devez positionner as_limit a :
                         # @ as_limit = 35.0Gb

Il n'y a que 28 noeuds sur lesquels peuvent passer les travaux "Larges"
(plus de 3.5 Go de memoire par coeur) contre 304 noeuds pour les travaux
usuels : il est donc logique d'avoir plus d'attente dans les classes "Large".


3) Remarques generales
   ===================

Toutes les limites en temps des classes sont exprimees en temps Elapsed
(ou temps d'horloge); le mot-clef est :
                         # @ wall_clock_limit = hh:mm:ss
Le temps qui vous est facture est le temps Elapsed consomme multiplie par
le nombre de coeurs reserves. Ce temps Elapsed est susceptible de varier
suivant la charge des noeuds (entrees/sorties, echanges de messages); par
consequent, prevoyez une marge de securite au niveau du temps demande.

Les executions paralleles EN INTERACTIF sont en competition avec les travaux
paralleles : quand les ressources demandees ne sont pas disponibles, la 
demande est rejetee avec un message d'erreur.

La compilation de certains codes peut depasser la limite en temps de
l'interactif. Une classe - compil - est dediee a ces compilations, avec un
temps Elapsed maximum de 20h. Le mot-clef est :
                         # @ class = compil

Pour deboguer vos codes, vous pouvez reduire le temps d'attente de vos jobs
en utilisant le mot-clef :
                         # @ class = debug
Attention, vous ne pouvez alors pas demander plus de 900s de temps Elapsed
et plus de 64 coeurs.

Pour utiliser les noeuds de pre/post-traitement, le mot-clef est :
                         # @ requirements = (Feature == "prepost")
Le temps Elapsed maximal est de 20h. Vous ne pouvez pas reserver plus de 32
coeurs (1 noeud de calcul maximum). Vous pouvez demander jusqu'a 100 Go de
memoire pour une execution sequentielle ou 30 Go par coeur reserve en
parallele (mpi, openmp ou hybride).
Attention, l'utilisation des noeuds de pre/post-traitement doit etre
exclusivement reservee a des taches de pre/post-traitement, c'est a dire :
- soit des travaux effectuant beaucoup d'entrees/sorties (recombinaison de
  fichiers, ...),
- soit des travaux necessitant beaucoup de memoire (generation/partitionnement
  de maillage, ...).

Uniquement pour transferer de donnees entre la frontale de pre/post-traitement
et une machine exterieure a l'IDRIS, utilisez les mots-clefs suivants :
                         # @ job_type = serial
                         # @ class = archive 
                         # @ requirements = (Feature == "prepost-front")
Le temps Elapsed maximal est de 20h.

Les travaux compris entre 20h et 100h (classes t4) ne sont pas rembourses
en cas de probleme sur les noeuds de calcul : nous ne pouvons garantir la 
stabilite du materiel sur une duree de pres de 5 jours. Des travaux aussi
longs devraient prevoir l'implementation de points de reprise.


4) Travaux bonus
   =============

Il est possible d'executer des travaux dits "bonus" en ajoutant le mot-clef
suivant (avant #@queue) :
                         # @ account_no = bonus

Les travaux bonus ne sont pas imputes dans l'allocation des heures DARI du
projet. Mais ils ne s'executeront que lorsque la charge de la machine est
faible via des classes specifiques pour les travaux paralleles.
Les travaux bonus sont limites a 512 coeurs maximum et a 20h de temps
elapsed maximum. Pour de plus amples informations concernant ces travaux
bonus, voir notre site web.


To see the English version, type : news classes
*****************************************************************************