Différences entre versions de « GOTM - General Ocean Turbulence Model »
m |
|||
| Ligne 6 : | Ligne 6 : | ||
Le code <tt>gotm_ismer</tt> est en fait une copie du code <tt>gotm-4.0.0</tt> qui a subit quelques modifications somme toute assez superficielles associées aux modèles biogéochimiques. Dans un futur pas très lointain, l'objectif est de migrer vers [[FABM]] (Framework for Aquatic Biogeochemical Models), un code traitant les modèles biogéochimiques de manière modulaire et donc beaucoup plus flexible, couplés à gotm-4.1. | Le code <tt>gotm_ismer</tt> est en fait une copie du code <tt>gotm-4.0.0</tt> qui a subit quelques modifications somme toute assez superficielles associées aux modèles biogéochimiques. Dans un futur pas très lointain, l'objectif est de migrer vers [[FABM]] (Framework for Aquatic Biogeochemical Models), un code traitant les modèles biogéochimiques de manière modulaire et donc beaucoup plus flexible, couplés à gotm-4.1. | ||
| − | Pour obtenir le code gotm_ismer, vous devez d'abord avoir obtenu un accès à [[demeter]]. Ensuite, vous devez créer un répertoire de travail dans lequel le code sera téléchargé. Ce répertoire sera la | + | Pour obtenir le code gotm_ismer, vous devez d'abord avoir obtenu un accès à [[demeter]]. Ensuite, vous devez créer un répertoire de travail dans lequel le code sera téléchargé. Ce répertoire sera la racine du code. Le nom <tt>gotm_ismer</tt> est fortement suggéré afin de faciliter la portabilité du code. |
mkdir gotm_ismer | mkdir gotm_ismer | ||
cd gotm_ismer | cd gotm_ismer | ||
| Ligne 24 : | Ligne 24 : | ||
=== Compiler le code === | === Compiler le code === | ||
| − | La compilation du code consiste à lire, interpréter, lier et condenser les routines fortran dans un fichier exécutable ou programme dont on se servira pour exécuter le modèle. Le code source se trouve dans le répertoire <tt>src/</tt> qui contient les routines fortran (.F90) qui sont classées dans des sous-répertoires représentant certaines sections du code. | + | La compilation du code consiste à lire, interpréter, lier et condenser les routines fortran dans un fichier exécutable ou programme dont on se servira pour exécuter le modèle. Le code source se trouve dans le répertoire <tt>src/</tt> qui contient les routines fortran (<tt>.F90</tt>) qui sont classées dans des sous-répertoires représentant certaines sections du code. |
gotm/ ! Contient le programme principal. | gotm/ ! Contient le programme principal. | ||
observations/ ! ... | observations/ ! ... | ||
| Ligne 42 : | Ligne 42 : | ||
NETCDFINC = /opt/local/netcdf-3.6.1/include | NETCDFINC = /opt/local/netcdf-3.6.1/include | ||
NETCDFLIBDIR = /opt/local/lib | NETCDFLIBDIR = /opt/local/lib | ||
| − | * Déterminer quelles portions du code vous voulez compiler. Dans l'exemple suivant, le code correspondant aux modules <tt>sediment</tt> et <tt>seagrass</tt> (qu'on retrouve dans le répertoire <tt>src/extras/</tt>) ne sera pas compilé alors que le module | + | * Déterminer quelles portions du code vous voulez compiler. Dans l'exemple suivant, le code correspondant aux modules <tt>sediment</tt> et <tt>seagrass</tt> (qu'on retrouve dans le répertoire <tt>src/extras/</tt>) ne sera pas compilé alors que le module <tt>bio</tt> et le module <tt>netcdf</tt>, qui permet de sauvegarder les sorties du modèle en format NetCDF, le sera: |
# What do we include in this compilation | # What do we include in this compilation | ||
NetCDF=true | NetCDF=true | ||
| Ligne 49 : | Ligne 49 : | ||
BIO=true | BIO=true | ||
| − | Une fois le fichier | + | Une fois le fichier <tt>Rules.make</tt> correctement modifié, vous pouvez compiler le code en faisant: |
make realclean | make realclean | ||
make | make | ||
| − | À la fin de la compilation, l'exécutable | + | À la fin de la compilation, l'exécutable <tt>gotm_prod_IFORT</tt> est créé. Le terme <tt>prod</tt> indique que la compilation a été faite en mode production, option que l'on détermine dans le fichier <tt>Rules.make</tt> (l'autre option disponible est <tt>debug</tt>), et le terme <tt>IFORT</tt> indique qu'elle a été réalisée avec le compilateur <tt>ifort</tt> utilisant le fichier de configuration <tt>compilers/compiler.IFORT</tt>. En cas de problème, consultez la page [[dépannage]]. |
=== Configurer une expérience === | === Configurer une expérience === | ||
| − | Si vous arrivez à compiler le code avec succès, c'est que vous êtes maintenant prêts à construire votre propre expérience. Vous pouvez pour cela vous inspirer des cas test (voir prochaine section), ou bien suivre les indications de cette section. Mettre en place une expérience nécessite d'abord de créer un répertoire de travail à partir duquel vous exécuterai le modèle. La pratique commune est de mettre toutes vos expérience (vous risquez d'en faire plus d'une) dans un répertoire | + | Si vous arrivez à compiler le code avec succès, c'est que vous êtes maintenant prêts à construire votre propre expérience. Vous pouvez pour cela vous inspirer des cas test (voir prochaine section), ou bien suivre les indications de cette section. Mettre en place une expérience nécessite d'abord de créer un répertoire de travail à partir duquel vous exécuterai le modèle. La pratique commune est de mettre toutes vos expérience (vous risquez d'en faire plus d'une) dans un répertoire <tt>exp/</tt> que vous pouvez créer dans un endroit où vous avez suffisamment d'espace disque. Sur [[brandypot]], il est commun d'utiliser la partition <tt>/sas/usagers</tt> pour y mettre ce répertoire, comme par exemple <tt>/sas/usagers/dumoda01/gotm/exp</tt>. Afin de simplifier l'exécution du code, il est conseillé de faire un lien symbolique de <tt>exp/</tt> dans <tt>/home/dumoda01/gotm_ismer</tt> en faisant la commande: |
cd gotm_ismer | cd gotm_ismer | ||
ln -s /sas/usagers/dumoda01/gotm/exp . | ln -s /sas/usagers/dumoda01/gotm/exp . | ||
| − | De cette manière, le répertoire sera accessible aisément à partir du répertoire racine, mais les données parfois volumineuses seront stockées dans un endroit où il y a suffisamment d'espace. Dans | + | De cette manière, le répertoire sera accessible aisément à partir du répertoire racine, mais les données parfois volumineuses seront stockées dans un endroit où il y a suffisamment d'espace. Dans <tt>exp/</tt>, créez un répertoire portant le nom de votre expérience (ex. <tt>potter_cove_1/</tt>). À ce stade-ci, vous avez besoin de trois ingrédients principaux pour réaliser votre expérience: 1) l'exécutable (<tt>gotm_prod_IFORT</tt>, que vous avez déjà), 2) des fichiers de paramètres <tt>namelist</tt> (<tt>*.nml</tt>) et 3) des fichiers intrants (<tt>*.dat</tt>). |
| − | La façon la plus sûre d'obtenir le premier est de créer une lien symbolique de l'exécutable se trouvant dans | + | La façon la plus sûre d'obtenir le premier est de créer une lien symbolique de l'exécutable se trouvant dans <tt>src/</tt> dans le répertoire de l'expérience: |
cd potter_cove_1 | cd potter_cove_1 | ||
ln -s /home/dumoda01/gotm_ismer/src/gotm_prod_IFORT . | ln -s /home/dumoda01/gotm_ismer/src/gotm_prod_IFORT . | ||
De cette façon, toute modification au code sera prise en compte automatiquement. | De cette façon, toute modification au code sera prise en compte automatiquement. | ||
| − | Les fichiers namelist correspondant à la dernière version du code sont situés dans le répertoire | + | Les fichiers namelist correspondant à la dernière version du code sont situés dans le répertoire <tt>gotm_ismer/nml/</tt>. Chaque fichier contient plusieurs namelists associées aux routines du code dont certains paramètres peuvent être affectés. Les namelists permettent de modifier des variables ou des paramètres sans avoir à recompiler le code. Chacun des paramètres sont documentés dans les fichiers. Certains fichiers sont obligatoires alors que d'autres dépendent des modules que l'on désire utiliser. En voici la liste complète: |
# Mandatory namelist files | # Mandatory namelist files | ||
gotmrun.nml | gotmrun.nml | ||
| Ligne 75 : | Ligne 75 : | ||
obs.nml | obs.nml | ||
kpp.nml | kpp.nml | ||
| + | |||
# Module-dependent namelist files | # Module-dependent namelist files | ||
bio.nml | bio.nml | ||
| Ligne 81 : | Ligne 82 : | ||
bio_iow.nml | bio_iow.nml | ||
| − | C'est à travers les namelist que l'on gère les intrants au modèle. Par exemple, on peut demander au modèle de lire les variables météorologiques ou des profils de température et de salinité à partir de fichiers. Dans un tel cas, il faut donc fournir ces fichiers et ce dans un format texte spécifique. C'est le troisième et dernier ingrédient à mettre dans la soupe. Pour de l'aide sur la façon de formater ces fichiers, consultez le fichier | + | C'est à travers les namelist que l'on gère les intrants au modèle. Par exemple, on peut demander au modèle de lire les variables météorologiques ou des profils de température et de salinité à partir de fichiers. Dans un tel cas, il faut donc fournir ces fichiers et ce dans un format texte spécifique. C'est le troisième et dernier ingrédient à mettre dans la soupe. Pour de l'aide sur la façon de formater ces fichiers, consultez le fichier <tt>GOTM_HOWTO_observations.txt</tt> situé dans le répertoire racine. Les sections suivantes décrivent différentes façon de générer ces fichiers selon l'origine des données. |
=== meteo.dat === | === meteo.dat === | ||
| − | + | Tel qu'indiqué dans <tt>GOTM_HOWTO_observations.txt</tt>, le fichier <tt>meteo.dat</tt> doit être formaté de la manière suivante: | |
| − | Tel qu'indiqué dans | ||
1957-09-01 00:00:00 2.46 6.80 1011.1 12.13 10.20 0.61 | 1957-09-01 00:00:00 2.46 6.80 1011.1 12.13 10.20 0.61 | ||
1957-09-01 06:00:00 0.46 6.32 1011.2 13.85 11.04 0.63 | 1957-09-01 06:00:00 0.46 6.32 1011.2 13.85 11.04 0.63 | ||
| Ligne 97 : | Ligne 97 : | ||
1957-09-03 06:00:00 1.17 3.47 1010.4 14.78 13.42 0.69 | 1957-09-03 06:00:00 1.17 3.47 1010.4 14.78 13.42 0.69 | ||
... | ... | ||
| − | |||
=== Cas test === | === Cas test === | ||
| Ligne 103 : | Ligne 102 : | ||
=== Visualisation des résultats === | === Visualisation des résultats === | ||
| − | Pour visualiser les sorties du modèle, le logiciel [http://ferret.pmel.noaa.gov/ Ferret] constitue une option extrêmement intéressante. Ce programme permet de produire des figures très simplement en tenant compte des méta-données contenues dans les fichiers NetCDF. Pour se familiariser avec le logiciel et obtenir de l'aide, consultez le site [http://ferret.pmel.noaa.gov/]. Dans cette section sont présentés des exemples de scripts permettant de visualiser des quantités importantes pour l'interprétation d'une simulation couplée. Les scripts ferret ( | + | Pour visualiser les sorties du modèle, le logiciel [http://ferret.pmel.noaa.gov/ Ferret] constitue une option extrêmement intéressante. Ce programme permet de produire des figures très simplement en tenant compte des méta-données contenues dans les fichiers NetCDF. Pour se familiariser avec le logiciel et obtenir de l'aide, consultez le site [http://ferret.pmel.noaa.gov/]. Dans cette section sont présentés des exemples de scripts permettant de visualiser des quantités importantes pour l'interprétation d'une simulation couplée. Les scripts ferret (<tt>*.jnl</tt>) sont en fait une liste de commandes Ferret qu'on peut exécuter avec la commande suivante: |
ferret -gif -script scriptname.jnl | ferret -gif -script scriptname.jnl | ||
| − | L'option | + | L'option <tt>-gif</tt> dit à ferret de ne pas afficher les figures à l'écran pendant l'exécution du script. Les figures seront plutôt produites et sauvegardées par la commande |
frame/file=figure.gif | frame/file=figure.gif | ||
qui apparaît dans le script. Voici donc quelques exemples appliqués à une simulation couplée représentant le golfe d'Amundsen avec le modèle biologique de type Fasham et al. (1990). | qui apparaît dans le script. Voici donc quelques exemples appliqués à une simulation couplée représentant le golfe d'Amundsen avec le modèle biologique de type Fasham et al. (1990). | ||
Version du 11 mars 2013 à 20:52
Introduction
GOTM (General Ocean Turbulence Model) est un modèle libre qui simule les processus physique d'une colonne d'eau lacustre ou océanique en solutionnant les équations du transport moyen et turbulent sur la verticale. Il a été développé à l'origine par Hans Burchard, Karsten Bolding, Manuel Ruiz-Villareal et Pierre-Philippe Mathieu et hébergé à l'Institute of Oceanography in Hambourg d'où l'on peut obtenir le code source (www.gotm.net). Depuis 2008, Dany Dumont et plusieurs étudiants et collaborateurs ont utilisé ce code riche et versatile dans plusieurs projets. Pour faciliter la collaboration interne et pour tirer parti des modifications apportées, une branche du code gotm-4.0.0 a été déposée dans un dépôt svn sur les serveurs du LASSO (ISMER) sous le nom de gotm_ismer. Ce dépôt a été créé afin de partager et de documenter à l'interne les avancées faites par chacun. Lorsque le code évolue significativement, les modifications sont proposées à l'équipe de développeurs qui les incorporent dans la version officielle, profitant ainsi à toute la communauté GOTM.
Guide d'utilisation
Obtenir le code gotm_ismer
Le code gotm_ismer est en fait une copie du code gotm-4.0.0 qui a subit quelques modifications somme toute assez superficielles associées aux modèles biogéochimiques. Dans un futur pas très lointain, l'objectif est de migrer vers FABM (Framework for Aquatic Biogeochemical Models), un code traitant les modèles biogéochimiques de manière modulaire et donc beaucoup plus flexible, couplés à gotm-4.1.
Pour obtenir le code gotm_ismer, vous devez d'abord avoir obtenu un accès à demeter. Ensuite, vous devez créer un répertoire de travail dans lequel le code sera téléchargé. Ce répertoire sera la racine du code. Le nom gotm_ismer est fortement suggéré afin de faciliter la portabilité du code.
mkdir gotm_ismer cd gotm_ismer
Accédez à ce répertoire et exécutez la commande suivante:
svn co http://demeter.uqar.ca/svn/gotm_ismer/trunk .
Si le téléchargement a été effectué avec succès, vous devriez retrouver les répertoires suivants:
compilers/ ! Contient les informations permettant de compiler le modèle sur votre ordinateur doc/ ! Documentation originale LaTeX include/ ! Définitions de pré-compilation nml/ ! Modèles de namelists (fichiers de contrôle ou de paramétrage des simulations) scripts/ ! Fonctions et scripts pertinents src/ ! Code source templates/ ! Modèles de routines test_cases/ ! Cas test
Compiler le code
La compilation du code consiste à lire, interpréter, lier et condenser les routines fortran dans un fichier exécutable ou programme dont on se servira pour exécuter le modèle. Le code source se trouve dans le répertoire src/ qui contient les routines fortran (.F90) qui sont classées dans des sous-répertoires représentant certaines sections du code.
gotm/ ! Contient le programme principal. observations/ ! ... meanflow/ ! ... airsea/ ! ... turbulence/ ! ... util/ ! ... extras/ ! ...
Rules.make
Le répertoire src/ contient également le fichier Makefile, qui fixe les règles de compilation qui ne doivent pas être modifiées (à moins que vous ne décidiez de faire certaines modifications avancées au code), et le fichier Rules.make.template qui contient les règles de compilation et les variables d'environnement propres à l'utilisateur et qui elles doivent être modifiées par l'utilisateur. Pour effectuer cette étape, faite une copie du fichier modèle Rules.make.template en le nommant Rules.make.
cp Rules.make.template Rules.make
Modifiez ensuite les variables d'environnement en fonction de votre profil et de votre plate-forme. L'exemple suivant s'applique au serveur brandypot:
- Spécifier le compilateur à utiliser. Cette variable servira à pointer vers un fichier compiler.$FORTRAN_COMPILER qui doit exister et se trouver dans le répertoire compilers/:
FORTRAN_COMPILER=IFORT
- Indiquer l'emplacement des librairies NetCDF:
NETCDFINC = /opt/local/netcdf-3.6.1/include NETCDFLIBDIR = /opt/local/lib
- Déterminer quelles portions du code vous voulez compiler. Dans l'exemple suivant, le code correspondant aux modules sediment et seagrass (qu'on retrouve dans le répertoire src/extras/) ne sera pas compilé alors que le module bio et le module netcdf, qui permet de sauvegarder les sorties du modèle en format NetCDF, le sera:
# What do we include in this compilation NetCDF=true SEDIMENT=false SEAGRASS=false BIO=true
Une fois le fichier Rules.make correctement modifié, vous pouvez compiler le code en faisant:
make realclean make
À la fin de la compilation, l'exécutable gotm_prod_IFORT est créé. Le terme prod indique que la compilation a été faite en mode production, option que l'on détermine dans le fichier Rules.make (l'autre option disponible est debug), et le terme IFORT indique qu'elle a été réalisée avec le compilateur ifort utilisant le fichier de configuration compilers/compiler.IFORT. En cas de problème, consultez la page dépannage.
Configurer une expérience
Si vous arrivez à compiler le code avec succès, c'est que vous êtes maintenant prêts à construire votre propre expérience. Vous pouvez pour cela vous inspirer des cas test (voir prochaine section), ou bien suivre les indications de cette section. Mettre en place une expérience nécessite d'abord de créer un répertoire de travail à partir duquel vous exécuterai le modèle. La pratique commune est de mettre toutes vos expérience (vous risquez d'en faire plus d'une) dans un répertoire exp/ que vous pouvez créer dans un endroit où vous avez suffisamment d'espace disque. Sur brandypot, il est commun d'utiliser la partition /sas/usagers pour y mettre ce répertoire, comme par exemple /sas/usagers/dumoda01/gotm/exp. Afin de simplifier l'exécution du code, il est conseillé de faire un lien symbolique de exp/ dans /home/dumoda01/gotm_ismer en faisant la commande:
cd gotm_ismer ln -s /sas/usagers/dumoda01/gotm/exp .
De cette manière, le répertoire sera accessible aisément à partir du répertoire racine, mais les données parfois volumineuses seront stockées dans un endroit où il y a suffisamment d'espace. Dans exp/, créez un répertoire portant le nom de votre expérience (ex. potter_cove_1/). À ce stade-ci, vous avez besoin de trois ingrédients principaux pour réaliser votre expérience: 1) l'exécutable (gotm_prod_IFORT, que vous avez déjà), 2) des fichiers de paramètres namelist (*.nml) et 3) des fichiers intrants (*.dat).
La façon la plus sûre d'obtenir le premier est de créer une lien symbolique de l'exécutable se trouvant dans src/ dans le répertoire de l'expérience:
cd potter_cove_1 ln -s /home/dumoda01/gotm_ismer/src/gotm_prod_IFORT .
De cette façon, toute modification au code sera prise en compte automatiquement. Les fichiers namelist correspondant à la dernière version du code sont situés dans le répertoire gotm_ismer/nml/. Chaque fichier contient plusieurs namelists associées aux routines du code dont certains paramètres peuvent être affectés. Les namelists permettent de modifier des variables ou des paramètres sans avoir à recompiler le code. Chacun des paramètres sont documentés dans les fichiers. Certains fichiers sont obligatoires alors que d'autres dépendent des modules que l'on désire utiliser. En voici la liste complète:
# Mandatory namelist files gotmrun.nml gotmmean.nml gotmturb.nml airsea.nml obs.nml kpp.nml # Module-dependent namelist files bio.nml bio_fasham.nml bio_npzd.nml bio_iow.nml
C'est à travers les namelist que l'on gère les intrants au modèle. Par exemple, on peut demander au modèle de lire les variables météorologiques ou des profils de température et de salinité à partir de fichiers. Dans un tel cas, il faut donc fournir ces fichiers et ce dans un format texte spécifique. C'est le troisième et dernier ingrédient à mettre dans la soupe. Pour de l'aide sur la façon de formater ces fichiers, consultez le fichier GOTM_HOWTO_observations.txt situé dans le répertoire racine. Les sections suivantes décrivent différentes façon de générer ces fichiers selon l'origine des données.
meteo.dat
Tel qu'indiqué dans GOTM_HOWTO_observations.txt, le fichier meteo.dat doit être formaté de la manière suivante:
1957-09-01 00:00:00 2.46 6.80 1011.1 12.13 10.20 0.61 1957-09-01 06:00:00 0.46 6.32 1011.2 13.85 11.04 0.63 1957-09-01 12:00:00 -0.16 6.20 1010.8 15.38 10.72 0.88 1957-09-01 18:00:00 -0.56 4.41 1010.2 13.56 10.50 0.83 1957-09-02 00:00:00 1.83 3.43 1009.8 13.31 10.65 0.40 1957-09-02 06:00:00 3.70 6.76 1009.1 13.08 10.86 1.00 1957-09-02 12:00:00 5.24 7.13 1009.5 14.33 12.49 0.98 1957-09-02 18:00:00 5.67 8.07 1009.7 15.06 12.09 0.71 1957-09-03 00:00:00 5.15 6.46 1010.4 14.68 12.88 0.83 1957-09-03 06:00:00 1.17 3.47 1010.4 14.78 13.42 0.69 ...
Cas test
À venir...
Visualisation des résultats
Pour visualiser les sorties du modèle, le logiciel Ferret constitue une option extrêmement intéressante. Ce programme permet de produire des figures très simplement en tenant compte des méta-données contenues dans les fichiers NetCDF. Pour se familiariser avec le logiciel et obtenir de l'aide, consultez le site [1]. Dans cette section sont présentés des exemples de scripts permettant de visualiser des quantités importantes pour l'interprétation d'une simulation couplée. Les scripts ferret (*.jnl) sont en fait une liste de commandes Ferret qu'on peut exécuter avec la commande suivante:
ferret -gif -script scriptname.jnl
L'option -gif dit à ferret de ne pas afficher les figures à l'écran pendant l'exécution du script. Les figures seront plutôt produites et sauvegardées par la commande
frame/file=figure.gif
qui apparaît dans le script. Voici donc quelques exemples appliqués à une simulation couplée représentant le golfe d'Amundsen avec le modèle biologique de type Fasham et al. (1990).