COFFRE ET MITGCM
COFFRE avec le modèle MITgcm
Un outil de développement donnant accès à un ensemble de modèles à partir d'un même gabarit.
COFFRE se présente sous la forme d'un dépôt git qui permet d'utiliser des codes centralisés (e.g., modèles NEMO, CICE, MITgcm,...).
Tous les codes centralisés viennent se greffer à la copie de travail sous forme de sous-modules git. L'utilisation des sous-modules offre les fonctionnalités suivantes :
- Le code des sous-modules ne peut pas être modifiés par l'utilisateur
- Seules les modifications apportées à notre clone du coffre sont conservées
- La version utilisée des sous-modules se résume à une révision spécifique sans branche associée (mode HEAD détaché de GIT)
- Les révisions des sous-modules utilisés lors d'un git commit du COFFRE sont mémorisées. On peut ainsi extraire une révision quelconque du COFFRE et récupérer les révisions exactes des sous-modules qui lui sont associées.
Cette page du WIKI documente l'utilisation de COFFRE avec la modèle MITgcm. Soit, la branche MITgcm et toutes les branches qui sont ou seront créées à partir de celle-ci.
NOTE: Une documentation plus complète est disponible sur le site du WIKI POLR [ https://srwebpolr01.uqar.ca/polr/index.php/COFFRE_ET_MITgcm ]. Entres autres, la page du WIKI contient la documentation des outils avancés de gestion des sous-modules git tels *git-rcheckout* et *git-rstatus* qui éliminent, en partie, l'utilisation de la commande *git submodule ...*.
Première utilisation du projet coffre
Pour une première utilisation de l'environnement `coffre`, il faut procéder de la façon suivante:
- Sur le site gitlasso [ https://gitlasso.uqar.ca/sennevil/coffre ], faire un `FORK` du projet afin de s'en faire un projet personnel.
Lorsque l'on dispose de sa propre copie du `coffre` il suffit alors de faire un git clone de son projet coffre personnel et d'extraire la branche sur laquelle on veut travailler.
Exemple d'utilisation
À partir d'ici, on suppose qu'un fork de `coffre` a déjà été effectué et sauvegardé dans notre espace de nommage personnel.
NOTE : Le code source du modèle `MITgcm` est extrait à partir du service GITHUB. L'utilisateur doit avoir un compte sur github.com et avoir créé une clef RSA lui permettant de s'y connecter.
Lorsqu'on crée une nouvelle configuration, On travaille toujours avec la plus récente version du modèle `MITgcm` . La configuration nécessaire se trouve sur la branche MITgcm.
$>git clone git@gitlasso.uqar.ca:caveenj/coffre.git $>cd coffre $>git branch -a * master remotes/origin/HEAD -> origin/master remotes/origin/master remotes/origin/nemo-cice4 remotes/origin/MITgcm $>module load git-submodule-tools $>git-rcheckout MITgcm Basculement sur la branche 'MITgcm' Votre branche est à jour avec 'origin/MITgcm'.
On vérifie l'état de nos sous-module:
$> git submodule status 18fff58a996c61bd132dae9b4a23a67f93ee23a9 MITgcm (checkpoint67q)
ou encore (avec git-submodule-tools) :
git-rstatus SUBMODULE WISU <> HEAD state MITgcm (checkpoint67q)
Le résultat de la commande nous indique que nous utilisons la révision 18fff58 de MITgcm.
Structure de coffre avec le modèle MITgcm
Dans l'arborescence ci-dessous, seuls les composantes précédées des symboles ** font partie de notre projet **coffre**. Toutes les autres composantes proviennent de sous-modules git.
**coffre ├── MITgcm (sous-module provenant de github) │ **├── gabarit ** ├── build-mitgcm-gcc492.sh ** ├── build-mitgcm-ifort.sh ** ├── code ** │ ├── CPP_OPTIONS.h ** │ ├── DIAGNOSTICS_SIZE.h ** │ ├── packages.conf ** │ ├── PTRACERS_SIZE.h ** │ └── SIZE.h ** └── run ** ├── gendata.m ** └── rdmds.m **├── EXP01 (un dossier personnel de l'utilisateur) **│ ├──build **│ ├── code **│ └── run **├── README.md **├── init_exp.sh **├── .gitignore **└── .gitmodules
Créer un nouveau projet utilisant la dernière version de MITgcm
Dans cet exemple nous allons créer une nouvelle configuration ayant pour nom EXP01 (comme dans l'arborescence ci-dessus). Cette configuration utilisera la version la plus récente de MITgcm disponible sur github.com.
$> load module git-submodule-tools $>cd coffre $>pwd /home/caveenj/projets/coffre $>git branch -a * master remotes/origin/HEAD -> origin/master remotes/origin/MITgcm remotes/origin/gsl2km remotes/origin/master remotes/origin/nemo-cice4 $> git-rcheckout MITgcm Switched to branch 'MITgcm' Your branch is up to date with 'origin/MITgcm'.
On s'assure que le sous-module MITgcm est bien présent:
$> git-rtatus SUBMODULE WISU <> HEAD state MITgcm (checkpoint67q)
Nous allons créer une nouvelle configuration utilisant la plus récente version de MITgcm :
$> ./init_exp.sh EXP01 Creation de EXP01 Basculement sur la nouvelle branche 'EXP01' On va greffer le sous-module MITgcm a la derniere version Warning: untrusted X11 forwarding setup failed: xauth key data not generated Warning: No xauth data; using fake authentication data for X11 forwarding. Sur la branche EXP01 Fichiers non suivis: EXP01/ aucune modification ajoutée à la validation mais des fichiers non suivis sont présents OK
Fonctionnement de init_exp.sh
Le script init_exp.sh sert à créer une nouvelle branche git sur laquelle une structure de répertoires sera installée. Cette structure servira à configurer et lancer le modèle MITgcm pour une nouvelle simulation.
Liste des opérations effectuées par init_exp_sh
- S'assurer que la branche (nom_expérience, ici EXP01) n'existe pas déjà dans le dépôt git, tant localement que sur le référentiel distant (e.g., gitlasso) ;
- S'assurer que le répertoire (nom_expérience) n'existe pas déjà ;
- Créer la nouvelle branche git ;
- Basculer sur la nouvelle branche (git checkout) ;
- Créer le répertoire nom_expérience;
- Copier le contenu du répertoire gabarit vers le répertoire nom_expérience;
- Faire un appel à git submodule update --remote pour récupérer la version la plus récente du modèle MITgcm;
- Faire un git commit .gitmodules, si nécessaire, pour enregistrer la nouvelle version de MITgcm.
init_exp_sh ne fait pas de git add,commit du nouveau répertoire nom_expérience. Ceci doit être fait par l'utilisateur.
$> git status Sur la branche EXP01 Fichiers non suivis: (utilisez "git add <fichier>..." pour inclure dans ce qui sera validé) EXP01/ aucune modification ajoutée à la validation mais des fichiers non suivis sont présents (utilisez "git add" pour les suivre)
L'ajout des fichiers avec git add tient compte du contenu du fichier .gitignore. Ce fichier peut être ajusté au besoin. Le fichier fourni avec coffre se présente comme suit :
$> cat .gitignore # #Gitignore pour le modele MITgcm **/build mitgcmuv *.bak *~ *.nc *.mat *.data *.meta *.bin *.log STDERR.* STDOUT.*
Pour sauvegarder notre nouvelle configuration et toutes les expériences s'y rattachant, on retourne dans notre projet coffre
$>cd coffre $> git add EXP01 $> git status Sur la branche EXP01 Modifications qui seront validées : (utilisez "git reset HEAD <fichier>..." pour désindexer) nouveau fichier : EXP01/build-mitgcm-gcc492.sh nouveau fichier : EXP01/build-mitgcm-ifort.sh nouveau fichier : EXP01/code/CPP_OPTIONS.h nouveau fichier : EXP01/code/DIAGNOSTICS_SIZE.h nouveau fichier : EXP01/code/PTRACERS_SIZE.h nouveau fichier : EXP01/code/SIZE.h nouveau fichier : EXP01/code/packages.conf nouveau fichier : EXP01/run/gendata.m nouveau fichier : EXP01/run/rdmds.m $> git commit -m'Ajout fichiers config pour EXP1' [EXP01 4be4ffe] Ajout fichiers config pour EXP1 9 files changed, 1250 insertions(+) create mode 100755 EXP01/build-mitgcm-gcc492.sh create mode 100755 EXP01/build-mitgcm-ifort.sh create mode 100644 EXP01/code/CPP_OPTIONS.h create mode 100644 EXP01/code/DIAGNOSTICS_SIZE.h create mode 100644 EXP01/code/PTRACERS_SIZE.h create mode 100644 EXP01/code/SIZE.h create mode 100644 EXP01/code/packages.conf create mode 100644 EXP01/run/gendata.m create mode 100644 EXP01/run/rdmds.m
Et nous pouvons continuer ainsi à modifier le code ou les fichiers de configuration de notre expérience et faire des git commit git push selon nos besoins.
git push origin EXP01 Énumération des objets: 28, fait. Décompte des objets: 100% (28/28), fait. Delta compression using up to 40 threads. Compression des objets: 100% (23/23), fait. Écriture des objets: 100% (27/27), 15.05 KiB | 15.05 MiB/s, fait. Total 27 (delta 5), reused 21 (delta 3) To gitlasso.uqar.ca:caveenj/coffre.git * [new branch] EXP01 -> EXP01
Lorsque nous voudrons ultérieurement réutiliser cette configuration et cette même version de MITGCM à partir du serveur gitlasso, on procédera de la façon suivante:
$>git clone git@gitlasso.uqar.ca:caveenj/coffre.git Clonage dans 'coffre'... remote: Counting objects: 746, done. remote: Compressing objects: 100% (448/448), done. remote: Total 746 (delta 297), reused 737 (delta 294) Réception d'objets: 100% (746/746), 4.81 MiB | 36.79 MiB/s, fait. Résolution des deltas: 100% (297/297), fait. $> cd coffre $>git branch -a * master remotes/origin/EXP02 remotes/origin/HEAD -> origin/master remotes/origin/MITgcm remotes/origin/gsl2km remotes/origin/master remotes/origin/nemo-cice4 $> git-rcheckout EXP01 Branch 'EXP01' set up to track remote branch 'EXP01' from 'origin'. Switched to a new branch 'EXP01' Submodule 'MITgcm' (git@github.com:MITgcm/MITgcm.git) registered for path 'MITgcm' Cloning into '/share/archives/caveenj/projets/coffre/MITgcm'... Submodule path 'MITgcm': checked out '18fff58a996c61bd132dae9b4a23a67f93ee23a9' $> git-rstatus SUBMODULE WISU <> HEAD state MITgcm (checkpoint67q)
Créer une ou plusieurs expériences à partir d'une même configuration et d'une même version de MITgcm
Si on désire créer d'autres simulations à partir d'une même configuration, par exemple EXP01, il suffit de basculer sur la branche désirée et créer une nuvelle branche.
$> git status Sur la branche EXP01 Votre branche est à jour avec 'origin/EXP01'. rien à valider, la copie de travail est propre $> git checkout -b EXP01+2deg Basculement sur la nouvelle branche 'EXP01+2deg' $> git status Sur la branche EXP01+2deg rien à valider, la copie de travail est propre $> git-rstatus SUBMODULE WISU <> HEAD state MITgcm (checkpoint67q)
Personnalisation du COFFRE avec MITgcm
Lorsque un utilisateur utilise sa propre copie du coffre, il peut facilement modifier le contenu de la branche MITgcm pour y adapter le contenu du répertoire gabarit (et même init_exp.sh) pour l'adapter à ses besoins.
La seule raison d'être de coffre est de permettre de récupérer ultérieurement, voire dans dix ans, n'importe-quelle configuration de l'utilisateur et de refaire les simulations avec la même version de MITgcm qui avait été utilisée à l'époque.