.. _dvp.chainvalid: **CHAINE DE VALIDATION** ######################## Cette chaine de validation est constituée de 2 scripts: * $HOMEMARS/../../TOOLS/CHAINVALID/mktest_all * $HOMEMARS/../TOOLS/CHAINVALID/verif_testcase_all .. warning:: Pour utiliser la chaine, il faut ajouter dans ses PATH (dans .cshrc ou manuellement dans fenêtre) différents chemins et ainsi accéder à tous les scripts:: setenv PATH $HOMEMARS/../TOOLS/CHAINVALID:$HOMEMARS/../TOOLS/CHAINVALID/SIG:${PATH} 1. Création de son propre HOMEMARS :: svn checkout $HTTPSVNROOT/trunk mon_trunk setenv HOMEMARS mon_trunk/Mars_Agrif2 .. note:: Il peut être nécessaire de créer le lien suivant sous $HOMEMARS/../TOOLS/MARSENV/:: ln -s mkconfdir_caparmor mkconfdir 2. Introduction des modifications à apporter au code MARS Introduire toutes les modifications. Attention, pour introduire des modifications dans le code, le développeur doit s'assurer que: * les modifications respectent le format des routines, * les entêtes des routines, auteur et dates de modifications sont précisées, * les modifications sont généralisées (à tous les Makefile par exemple, ou tous les schémas proches) * la parallélisation est correcte en OMP, MPI et hydride * ... Tout ceci pour s'assurer une continuité dans le code. **Aucune modification ne peut être introduite si la chaine de validation n'a pas donné de bons résultats**: a. tous les jobs ont tourné b. les résultats sont identiques à la version précédente, ou les modifications sont validées, config après config, cas test par cas test. **N'introduire qu'un type de modification à la fois**, mais chercher à ce que le commit soit complet du premier coup. Lors du commit, le message devra être le plus explicite possible car essentiel pour lister les modifications et revenir en arrière si besoin est. **Spécifier quand les résultats changent avec un WARNING explicite dans texte du commit.** Pour les nouveautés, le développeur prendra soin de compléter la documentation sous $HOMEMARS/../DOC/SPHINX/SRC/. Pour la créer, utiliser les alias suivants:: depuis datarmor alias docmars 'module load anaconda-py2.7/4.3.13 ; cd /home7/datahome/marsdev/MARS/CODE/trunk/DOC/SPHINX ; make clean ; make html ; make epub ; \rm -rf /home/wwwinter/www/htdocs/docmars/html ; mv build/html/ /home/wwwinter/www/htdocs/docmars/. ; cp ./build/latex/MARS3D.pdf /home/wwwinter/www/htdocs/docmars/html/. ; cp ./build/epub/MARS3D.epub /home/wwwinter/www/htdocs/docmars/html/.; mkdir /home/wwwinter/www/htdocs/docmars/html/CHAINOP ; cp -R /home7/datahome/marsdev/CHAINOP/DOC/build/html/* /home/wwwinter/www/htdocs/docmars/html/CHAINOP/. ; chgrp -R physed /home/wwwinter/www/htdocs/docmars/*; chmod -R g+w /home/wwwinter/www/htdocs/docmars/*' 3. Lancement de la chaine Un fichier décrit la procédure de lancement de la chaine de validation :: /home7/datahome/marsdev/PROCEDURE_CHAIN_VALID Un autre fichier décrit l'avancement des derniers COMMIT et lancement de la chaîne de validation :: /home7/datahome/marsdev/README_COMMIT 4. Vérification des runs :: verif_testcase_all rXXXX roldrev [oldrdir] > & fichier_bilan - oldrdir est généralement /home7/datawork/marsdev/MARS/RUN_MARS - roldrev est le dernier numéro disponible sous : /home7/datawork/marsdev/MARS/RUN_MARS/CONF (car **l'introduction de nouveautés dans le code MARS se fait dans la dernière version disponible**) Un exemple de fichier bilan (bon) est disponible sous /home7/datahome/marsdev/MARS/VERIF/out_r1881_r1878 Ce fichier se lit ainsi (février 2015): - avoir "fin normale" partout sauf pour le cas EVAP - OK quand les variables des fichiers NetCDF (écrits avec l_out_nc4par=.True.) sont vérifiées une à une par un script python - ne pas avoir de différences excepté: * quelques lignes pour le cas INNER (OMP et MPIOMP) 5. Pour effacer tous les cas test et configurations réalistes créés par la chaine de validation: :: clean_testcase_all rXXXX .. warning:: Cette commande va effacer tous les CONF-rXXXX*