| 35 | |
| 36 | ==== Lancer IPSLCM5A sur la machine Titane (machine Xeon du CCRT) ==== |
| 37 | |
| 38 | * Etape préalable : assurez-vous que votre login est autorisé à tourner sur la machine titane à l'aide de la commande groups : |
| 39 | {{{ |
| 40 | mercure - /home/cont003/p86caub : groups |
| 41 | }}} |
| 42 | Si ce n'est pas le cas, demandez l'autorisation au CCRT en passant par votre responsable de projet. |
| 43 | |
| 44 | Les étapes à faire sont les mêmes que pour tourner le modèle IPSLCM5A sur mercure, a ceci près : |
| 45 | |
| 46 | * Avant la compilation ET l'exécution, il faut charger les modules nécessaires : |
| 47 | {{{ |
| 48 | module load netcdf/3.6.3 |
| 49 | }}} |
| 50 | |
| 51 | * N'oubliez pas de verifier que votre PATH contient bien le path pour l'outil FCM. Plus d'infos [wiki:ModipslBeginner#FCM là]. |
| 52 | |
| 53 | |
| 54 | * Avant la génération du Job de soumission via la commande ./ins_job, il faut préciser le nombre de CPUs demandés dans le config.card en mettant la variable !JobNumProcTot à 32. Par défaut, cela signifie que la composante atmosphérique tournera sur 30 CPUs alors que la composante océanique et le coupleur utiliseront chacun 1 CPU. |
| 55 | |
| 56 | {{{ |
| 57 | JobNumProcTot=32 |
| 58 | }}} |
| 59 | |
| 60 | * La soumission du job se fait à l'aide de la commande ccc_msub |
| 61 | |
| 62 | {{{ |
| 63 | ccc_msub Job |
| 64 | }}} |
| 65 | |
| 66 | * A noter, que les post-traitements s'effectueront sur la machine cesium. |
| 67 | 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. |
| 68 | (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.) |
| 69 | [[BR]] |
| 70 | Mémo : |
| 71 | {{{ |
| 72 | |
| 73 | mercure : cd ~/.ssh |
| 74 | mercure : ssh-keygen -t rsa |
| 75 | Generating public/private rsa key pair. |
| 76 | Enter file in which to save the key (/home/cont003/xxxxxx/.ssh/id_rsa): |
| 77 | Enter passphrase (empty for no passphrase): (RETURN) |
| 78 | Enter same passphrase again: (RETURN) |
| 79 | Your identification has been saved in ...../.ssh/id_rsa. |
| 80 | Your public key has been saved in ...../.ssh/id_rsa.pub. |
| 81 | The key fingerprint is: |
| 82 | af:.... |
| 83 | mercure : cat id_rsa.pub >>authorized_keys |
| 84 | mercure : ssh cesium |
| 85 | }}} |
| 86 | |
| 87 | * Pour améliorer légerement les performances : |
| 88 | |
| 89 | 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. |
| 90 | [[BR]] |
| 91 | 1 jour simulé par LMDZ sur 30 CPUs : 25s |
| 92 | [[BR]] |
| 93 | 1 jour simulé par NEMO sur 1 CPU : 27s |
| 94 | [[BR]] |
| 95 | ce qui donne 1 mois simulé en 900s (par comparaison on a 1 mois simulé en 600s sur 4 CPUs SX9). |
| 96 | |
| 97 | |
| 98 | 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 : |
| 99 | [[BR]] |
| 100 | 1 jour simulé par LMDZ sur 29 CPUs : 25s |
| 101 | [[BR]] |
| 102 | 1 jour simulé par NEMO sur 2 CPU : 15s |
| 103 | [[BR]] |
| 104 | ce qui va donner 1 mois simulé en 840s. |
| 105 | |
| 106 | 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). |
| 107 | |
| 108 | La configuration idéale est donc : 29 CPUs ATM, 2 CPUs OCE et 1 CPU pour Oasis (lorsque PISCES n'est pas activé). |
| 109 | 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 |
| 110 | Pour activer cette configuration-là, deux étapes sont nécessaires : |
| 111 | |
| 112 | * Compilation : |
| 113 | * Pour des raison de qualité (restartabilité NEMO), enlever les cles cpp suivantes pour la compilation : key_vectopt_loop key_vectopt_memory. Pour faire cela : |
| 114 | {{{ |
| 115 | vi modipsl/config/IPSLCM5A/AA_make |
| 116 | supprimer les cles cpp "key_vectopt_loop key_vectopt_memory" de la varibale P_P à la ligne : |
| 117 | |
| 118 | orca2: ../../modeles/NEMO/WORK |
| 119 | (cd ../../modeles/NEMO/WORK; P_P='key_trabbl_dif key_vectopt_loop key_vectopt_memory ... |
| 120 | |
| 121 | cd modipsl/util ; ./ins_make |
| 122 | }}} |
| 123 | * Compiler NEMO pour qu'il tourne sur 5 process MPI en modifiant directement le code : |
| 124 | {{{ |
| 125 | vi modipsl/modeles/NEMO/WORK/par_oce.F90 (lignes 29-31) |
| 126 | jpni = 1, & !: number of processors following i |
| 127 | jpnj = 5, & !: number of processors following j |
| 128 | jpnij = 5 !: nb of local domain = nb of processors |
| 129 | |
| 130 | cd modipsl/config/IPSLCM5A ; gmake |
| 131 | }}} |
| 132 | |
| 133 | * Execution |
| 134 | * 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 : |
| 135 | * mettre !PeriodNb=1 dans votre Job ; ccc_msub Job |
| 136 | * une fois le 1er run en machine, remettre !PeriodNb=48 |