Utiliser Modipsl sur titane

​Retour au sommaire du mode d'emploi

Environnement minimum

• Vous devez charger explicitement la bonne bibliothèque NetCDF. Pour cela il faut faire la commande :

  module load netcdf/3.6.3
  

Vous pouvez également la rajouter dans votre environnement.

• Vérifiez que votre PATH contient bien le path pour l'outil FCM. Plus d'infos ​là.

Commandes de gestion de job

• ccc_msub -> soumet un job
• ccc_mdel ID -> tue un job de n° ID
• ccc_mstat -u login -> permet de voir tous les jobs soumis par login
• mpp -> permet de voir tous les jobs soumis sur la machine

Avant de lancer un Job

Modifier la limite de temps CPU

Dans le Job n'oubliez pas de modifier la limite de temps CPU demandée

#MSUB -T 1800             # Limite temps (en secondes)

Note 1: Pour connaître les temps autorisés sur les différentes queues de la machine vous pouvez utiliser la commande class.
Note 2: La machine titane n'a pas de tmpdir, la simulation tourne donc sur le scratchdir dans le répertoire RUN_DIR (doit être modifié prochainement)

Choisir son groupe de soumission

Par défaut les entêtes de Job créés par modipsl sont positionnées pour utiliser les heures genci du groupe gen2211.
La première chose que vous devez faire c'est de vous demander sur quel compte vous avez des heures de calcul (genci ou dsm ?). Pour cela vous devez vous reporter à la demande d'heures de calcul faite en début d'année.

• Si vous appartenez au groupe gen2211 et que vous avez des heures sur ce projet vous n'avez rien à changer.
• Si vos heures sont sur un autre projet genci vous devez modifier le numéro de projet dans le fichier libIGCM/AA_job ainsi que dans libIGCM/AA_rebuild_fromWorkdir.
• Si vos heures sont sur les projets dsm (p24, p86, etc...) vous devez enlever les lignes #MSUB -p gen2211 des fichiers libIGCM/AA_job et libIGCM/AA_rebuild_fromWordir. Et dans ce

dernier remplacer la queue mono par monoext

Note 1: si vous aviez déjà lancé la commande ./ins_job vous devez également modifier les jobs créés (libIGCM/rebuild_fromWorkdir.job et config/.../EXP.../Job...)
Note 2: pour connaître les groupes auxquels vous appartenez vous pouvez utiliser la commande groups

Comment choisir le nombre de processus demandés ?

La méthode de parallélisation de LMDZ impose la règle suivante : il faut au moins 3 bandes de latitude par processus Si vous avez choisi un trop grand nombre de processus la simulation s'arrête avec le message suivant :

Arret : le nombre de bande de lattitude par process est trop faible (<2).
  ---> diminuez le nombre de CPU ou augmentez la taille en lattitude

Pour modifier le nombre de processus il faut changer la valeur de la variable JobNumProcTot dans config.card avant de lancer la commande ins_job.

Running

Les simulations sont lancées sur le scratchdir $SCRATCHDIR/RUN_DIR/.... ou $SCRATCHDIR/$CONFIG/... (suivant les versions de libIGCM). Il faut donc faire très attention aux quotas si l'on lance plusieurs simulations simultanées.

Les post-traitements

Les rebuild se font sur la queue mono de titane, et les autres post-traitements sur la machine cesium. Rappel : Pour que cela marche il faut avoir créé des clés avec une passphrase vide pour ssh et s'être connecté sur cesium au moins une fois. (Attention, si vous vous servez pour vos connexions de clés ssh déjà générées avec des passphrases non vides de ne pas les écraser.)
Mémo :

mercure : cd ~/.ssh
mercure : ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/cont003/xxxxxx/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase): (RETURN)
Enter same passphrase again: (RETURN)
Your identification has been saved in ...../.ssh/id_rsa.
Your public key has been saved in ...../.ssh/id_rsa.pub.
The key fingerprint is:
af:....
mercure : cat id_rsa.pub >>authorized_keys
mercure : ssh cesium

Compiler le modèle IPSLCM5A

• il faut supprimer les 2 clés : "key_vectopt_loop key_vectopt_memory" dans config/IPSLCM5A/AA_make
• il faut explicitement demander l'utilisation de 5 processeurs pour NEMO. Sinon le message est :

  xmlf90 ../../../lib/libioipsl.a -L/applications/netcdf-3.6.3/lib -lnetcdff -lnetcdf
  /applications/intel/cprof/11.1.056/lib/intel64/libimf.so: warning: warning: feupdateenv is not implemented and will always fail
  ../../../lib/libopa.a(opa.o): In function `opa_mp_opa_model_':
  opa.F90:(.text+0x2a5): relocation truncated to fit: R_X86_64_PC32 against symbol `dom_oce_mp_narea_' defined in COMMON section in ../../../lib/libopa.a(dom_oce.o)
  opa.F90:(.text+0x8bb): relocation truncated to fit: R_X86_64_PC32 against symbol `in_out_manager_mp_nprint_' defined in COMMON section in ../../../lib/libopa.a(in_out_manager.o)
  ...
  opa.F90:(.text+0xa4d): additional relocation overflows omitted from the output
  gmake[2]: *** [../../../bin/opa] Error 1
  

La correction à faire est la suivante :

dans modipsl/modeles/NEMO/WORK/par_oce.F90 (lignes 29-31)
      jpni   = 1,                   &  !: number of processors following i
      jpnj   = 5,                   &  !: number of processors following j
      jpnij  = 5                       !: nb of local domain = nb of
processors

Faire une simulation avec le modèle IPSLCM5A

• Si vous travaillez sur 32 processus (JobNumProcTot=32) cela signifie que la composante atmosphérique tournera sur 30 CPUs alors que la composante océanique et le coupleur utiliseront chacun 1 CPU.

• Pour améliorer légerement les performances :

La configuration par défaut du modèle couplé à la résolution 96x95x39 est quasiment équilibrée, cad que le modèle d'atmosphère sur 30 CPUs est très légerement plus rapide que le modèle d'ocean sur 1 CPU.
1 jour simulé par LMDZ sur 30 CPUs : 25s
1 jour simulé par NEMO sur 1 CPU : 27s
ce qui donne 1 mois simulé en 900s (par comparaison on a 1 mois simulé en 600s sur 4 CPUs SX9).

On voit donc que c'est le modèle d'océan qui va "guider" le temps de restitution du modèle couplé complet. En utilisant 2 process MPI pour l'océan on obtient :
1 jour simulé par LMDZ sur 29 CPUs : 25s
1 jour simulé par NEMO sur 2 CPU : 15s
ce qui va donner 1 mois simulé en 840s.

On voit donc que désormais, c'est le modèle d'atmosphère qui va "guider" le temps de restitution du modèle couplé complet. Mais à cette résolution là, il n'est pas possible d'utiliser plus de process pour LMDZ en parallélisation MPI seule (limite à 3 bandes de latitudes par process MPI).

La configuration idéale est donc : 29 CPUs ATM, 2 CPUs OCE et 1 CPU pour Oasis (lorsque PISCES n'est pas activé). Si PISCES est activé (c'est le cas avec IPSLCM5A CMIP5) la configuration ideale est : 26 CPUs ATM, 5 CPUs OCE et 1 CPU pour Oasis Pour activer cette configuration-là, deux étapes sont nécessaires :

• Execution Cas particulier : si vous souhaitez faire utiliser à votre NEMO parallèle un restart généré par un NEMO mono-processeur, alors il faut forcer une resoumission (ccc_msub) apres le 1er run de la simulation. Pour cela :
  • mettre PeriodNb=1 dans votre Job ; ccc_msub Job
  • une fois le 1er run en machine, remettre PeriodNb=48