Ma Foire aux Questions
-
Comment créér une nouvelle testing?
Pour créér une nouvelle testing:
On suppose que la dernière testing est basée sur la rNNNN de la trunk et que l'on veut inclure dans une nouvelle testing toutes les modifications survenues sur la trunk jusqu'à la version rTTTT.
Procédure à suivre:
- Récupérer la testing:
svn checkout http://svn.lmd.jussieu.fr/LMDZ/LMDZ5/branches/testing LMDZ
- Se mettre où il faut:
cd LMDZ
- Faire le merge:
svn merge -rNNNN:TTTT http://svn.lmd.jussieu.fr/LMDZ/LMDZ5/trunk
On récupère ainsi dans la version de travail toutes les modifications apportées à la trunk depuis la dernière testing. Attention, il faut bien mettre NNNN dans la commande merge et non NNNN+1 (comme on pourrait le croire)
- Après avoir réglé d'éventuels conflits suites au merge, ne pas oublier de faire un commit en précisant dans le commentaire (pour mémoire) les numéros de révisions qu'on a mergé (on peut éventuellement recopier dans le commentaire la commande faite au point 3. ci-dessus):
svn commit -m "Merged trunk changes rNNNN:TTTT into testing branch"
le répertoire de travail pointant bien toujours sur la branche testing
-
Comment rajouter les informations sur la licence à un nouveau fichier?
Réponse de Lionel:
1) Tu mets le texte de l'en-tête dans un fichier : $ cat > Header_license.txt Name of program: LMDZ Creation date: 1984 Version: LMDZ5 License: CeCILL version 2 Holder: Laboratoire de m\'et\'eorologie dynamique, CNRS, UMR 8539 See the license file in the root directory 2) Tu vas dans le répertoire concerné : cd RRTM 3) Tu lances la commande récursive : svn propset -R copyright -F Header_license.txt .
Et on oublie pas de faire la commission après ...
-
Comment rajouter une propriété à un fichier sous svn
Pour rajouter la propriété "Id" par exemple au fichier libf/dyn3dpar/guide_p_mod.F90, faire:
svn propset svn:keywords "Id" libf/dyn3dpar/guide_p_mod.F90
-
Comment changer un commentaire de svn?
Méthode "bourrin":
- se mettre sur la machine servant de serveur svn
- faire
svnadmin setlog /home/svnroot/LMDZ -r NNN fichier_commentaires
- synchroniser le trac avec le nouveau log svn:
bash$ trac-admin home_trac_du_projet Trac [home_trac_du_projet]> repository resync * Trac [home_trac_du_projet]> exit
-
Comment relancer un couplé "modipsl" pour le débugguer?
- Comment lancer un couplé sur une certaine période de temps et le relancer à partir des restarts ainsi créés (i.e. le modèle se plante au 14ème jour d'une simulation, on voudrait lancer 10 jours à outputs normaux puis 4 jours avec tous les outputs activés pour essayer de comprendre ce qui se passe)
ATTENTION, cette procédure n'est plus nécessaire quand xios est activé: on peut extraire un point qui plante en modifiant simplement les *xml contrôlant xios et en relançant son job. Voir la FAQ utilisateurs
- Commencer par se créer un environnement de départ propre en modifiant le job de soummission: on rajoute un exit avant le lancement effectif de l'exécutable. On récupère ainsi sous le RUN_DIR, un répertoire contenant les fichiers et les exécutables nécessaires au lancement.
e.g.: echo echo "#######################################" echo "# DIR BEFORE RUN EXECUTION #" echo "#######################################" echo ls -lrt echo "========================================================================" if [ ${DRYRUN} -le 1 ] ; then REAL_DATE_INIT=$( date ) echo > ${Exe_Output} echo "#######################################" >> ${Exe_Output} echo "EXECUTION of : ${EXECUTION}" echo "EXECUTION of : ${EXECUTION}" >> ${Exe_Output} echo >> ${Exe_Output} pwd exit
- Sauvegarder ce répertoire pour ne pas avoir à répéter la manip précédente X fois:
cd $SCRATCHDIR/RUN_DIR cd ... mv CPL6V5.10x00A.88591/ Dir_Init/
- Recopier le répertoire "initial" dans un répertoire de travail
cp -R Dir_Init/ Run_00
- Faire les modifications de pas de temps qui s'imposent dans le répertoire de travail:
nday dans run.def (pour lmdz)
nn_itend, nn_stock, nn_write dans namelist_cfg (pour opa9)
e.g. pour faire un run de 10 jours avec 15 pas de temps OPA9 par jour: - nday = 10 - nn_itend = nn_it000 + 10 * ORCA_NPDT_JOUR - 1 = 51690 - nn_stock = nn_itend - nn_write = 10 * ORCA_NPDT_JOUR = 150
- Lancer un job qui se positionne dans le répertoire Run_00 et lance juste l'exécution. Attention, bien partir du Job qui correspond au modèle qu'on veut débugger (faire attention à l'entête et à la ligne d'exécution, il faut enlever le hostfile et rankfile) :
e.g. #!/bin/ksh ###################### ## CURIE TGCC/CEA ## ###################### #MSUB -r CPL6NPV5.01 # Job Name #MSUB -o Script_Output_CPL6NPV5.01.relance # standard output #MSUB -e Script_Output_CPL6NPV5.01.relance # error output #MSUB -eo #MSUB -n 380 # Number of cores #MSUB -T 86400 # Wall clock limit (seconds) #MSUB -q standard # thin nodes #MSUB -A gencmip6 # Below specific options that can be activated ##MSUB -q ivybridge # Option for Airain #MSUB -N 24 # Number of nodes (16 cores per node) #MSUB -x # exclusive node #MSUB -E '--cpu_bind=none' BATCH_NUM_PROC_TOT=$BRIDGE_MSUB_NPROC set +x set -vx cd $SCRATCHDIR/RUN_DIR/.../Run_00 time mpirun ... ./script_lmdz.x.ksh : ... ./script_opa.xx.ksh : -np 1 ./script_xios.x.ksh >> out_execution 2>&1
- Si tout s'est bien passé, on sauvegarde le répertoire dans lequel la simulation a 'bien' tourné et on prépare un nouveau répertoire dans lequel on va faire tourner le modèle à partir des restarts juste créés et avec les outputs "à fond".
mv Run_00/ Run_00_10j cp -R Dir_Init/ Run_00
on recopie les restarts des différents modèles dans le répertoire de travail:
cd Run_00 for i in 0 1 ...... do cp ../Run_00_10j/XXXXX_restart_00$i.nc restartopa_00$i.nc cp ../Run_00_10j/XXXXX_restart_ice_00$i.nc restart_ice_in_00$i.nc cp ../Run_00_10j/XXXXX_restart_trc_00$i.nc restart_trc_in_00$i.nc done cp ../Run_00_10j/sechiba_rest_out.nc sechiba_rest_in.nc cp ../Run_00_10j/stomate_rest_out.nc stomate_rest_in.nc cp ../Run_00_10j/restart.nc start.nc cp ../Run_00_10j/restartphy.nc startphy.nc
on modifie les pas de temps dans run.def, namelist.cfg (ici pour refaire 5 jours)
- nday=5 - nn_it000 = nn_itend (du pas 4 ci-dessus) + 1 - nn_itend = nn_it000 + 5 * ORCA_NPDT_JOUR - 1 - nn_date0 = la bonne date - nn_stock = nn_itend - nn_write = 5 * ORCA_NPDT_JOUR = 75
on modifie le output.def pour sortir uniquement un fichier "ins" à tous les pas de temps, si on utilise xios, modifier les xml appropriés
# Noms des fichiers phys_out_filenames= histmth histday histhf histhf3h histhf3hm histstn # Sortir ou non les fichiers phys_out_filekeys= n n y n n n # Niveaux de sorties phys_out_filelevels= 5 2 10 5 5 5 ### Frequences des sorties phys_out_filetimesteps = 1.mth, 1.day, 1TS, 0.125day, 0.125day, 1800.s
on n'oublie de faire la synchro des fichiers pour avoir les sorties jusqu'au moment du plantage
dans physiq.def: ok_sync=y
- On relance le job de l'étape 5
- Commencer par se créer un environnement de départ propre en modifiant le job de soummission: on rajoute un exit avant le lancement effectif de l'exécutable. On récupère ainsi sous le RUN_DIR, un répertoire contenant les fichiers et les exécutables nécessaires au lancement.
-
Comment dépasser un hgardfou?
Dans le modèle couplé, il est possible de perturber légèrement les états de démarrage pour essayer de dépasser un hgardfou. On utilise l'utilitaire AddNoise qu'on peut trouver sur curie ici:
~p86mart/Util/AddNoise
et qu'on lance comme ceci:
~p86mart/Util/AddNoise <restart couple océan> O_SSTSST 0.01
Le début du fichier AddNoise.f90:
PROGRAM AddNoise !------------------------------------------------------------ ! ! NAME: AddNoise ! ! PURPOSE: ! ! CATEGORY: to run ensemble members ! ! CALLING SEQUENCE: ! ! ./AddNoise FileIn VarName Amplitude ! ! INPUTS: ! FileIn : name of the input file ! VarName : name of the variable on which to apply the noise ! Amplitude : the amplitude of the randoim values ! (between -amplitude/2 and amplitude/2) ! ! ASSOCIATED MODULES: ! ! SIDE EFFECTS: ! ! RESTRICTIONS: ! ! EXAMPLE: ! ! > ./AddNoise OUTPUT/CM5V1NTW_20491231_sstoc_out.nc O_SSTSST 0.1 ! ! To COMPILE on Curie : ! ! ifort -o AddNoise -I${NETCDF_INCDIR} AddNoise.f90 -lnetcdff ${NETCDF_LDFLAGS} ! ! MODIFICATION HISTORY: ! * S. Labetoulle - Nov. 2009 : created from chgsst.f90 ! * O. Marti - June 2016 : adapted to IPSLCM6 (still works with IPSLCM5) ! !------------------------------------------------------------
-
Comment lancer un profiling?
Sur curie:
- compiler et linker le code avec l'option -pg: l'option doit apparaître dans les lignes %BASE_FFLAGS et %BASE_LD du arch.fcm
- renseigner la variable d'environnement
export GMON_OUT_PREFIX=gmon.out
à l'exécution - faire tourner l'exécutable comme d'habitude
On retrouve, après exécution, des fichiers gmon.out.* (1 par process) dans le répertoire d'exécution. On peut faire un graphe de l'arbre d'appel avec les pourcentages de temps passés dans les routines les plus gourmandes avec la commande:
gprof lmdz.x gmon.out.* | ~/gprof2dot.py | dot -T png -o output.png
dot étant une commande du module graphviz et gprof2dot.py, une routine python à récupérer sur le net