doc/fr/advanced.rst

   1 ..
   2    Copyright (C) 2008-2017 EDF R&D
   3
   4    This file is part of SALOME ADAO module.
   5
   6    This library is free software; you can redistribute it and/or
   7    modify it under the terms of the GNU Lesser General Public
   8    License as published by the Free Software Foundation; either
   9    version 2.1 of the License, or (at your option) any later version.
  10
  11    This library is distributed in the hope that it will be useful,
  12    but WITHOUT ANY WARRANTY; without even the implied warranty of
  13    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
  14    Lesser General Public License for more details.
  15
  16    You should have received a copy of the GNU Lesser General Public
  17    License along with this library; if not, write to the Free Software
  18    Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307 USA
  19
  20    See http://www.salome-platform.org/ or email : webmaster.salome@opencascade.com
  21
  22    Author: Jean-Philippe Argaud, jean-philippe.argaud@edf.fr, EDF R&D
  23
  24 .. _section_advanced:
  25
  26 ================================================================================
  27 **[DocU]** Usages avancés du module ADAO
  28 ================================================================================
  29
  30 Cette section présente des méthodes avancées d'usage du module ADAO, comment
  31 obtenir plus d'information lors d'un calcul, ou comment l'utiliser sans
  32 l'interface graphique (GUI). Cela nécessite de savoir comment trouver les
  33 fichiers ou les commandes incluses dans l'installation complète de SALOME. Tous
  34 les noms à remplacer par l'utilisateur sont indiqués par la syntaxe ``<...>``.
  35
  36 Convertir et exécuter un fichier de commandes ADAO (JDC) par l'intermédiaire d'un script Shell
  37 ----------------------------------------------------------------------------------------------
  38
  39 Il est possible de convertir et exécuter une fichier de commandes ADAO (JDC, ou
  40 paire de fichiers ".comm/.py", qui se trouvent dans le répertoire ``<Répertoire
  41 du fichier JDC ADAO>``) automatiquement en utilisant un script de commandes
  42 Shell "type" contenant toutes les étapes requises. Si la commande principale de
  43 lancement de SALOME, nommée ``salome``, n'est pas couramment accessible dans un
  44 terminal courant, l'utilisateur doit savoir où se trouvent les principaux
  45 fichiers de lancement de SALOME, et en particulier ce fichier ``salome``. Le
  46 répertoire dans lequel ce fichier réside est symboliquement nommé ``<Répertoire
  47 principal d'installation de SALOME>`` et doit être remplacé par le bon dans le
  48 modèle "type" de fichier Shell.
  49
  50 Lorsqu'un fichier de commande ADAO est construit par l'interface d'édition
  51 graphique d'ADAO et est enregistré, s'il est nommé par exemple
  52 "EtudeAdao1.comm", alors un fichier compagnon nommé "EtudeAdao1.py" est
  53 automatiquement créé dans la même répertoire. Il est nommé ``<Fichier Python
  54 ADAO>`` dans le modèle "type", et il est converti vers YACS comme un ``<Schéma
  55 xml YACS ADAO>`` sous la forme d'un fichier en ".xml" nommé "EtudeAdao1.xml".
  56 Ensuite, ce dernier peut être exécuté en mode console en utilisant l'ordre
  57 standard du mode console de YACS (voir la documentation YACS pour de plus amples
  58 informations).
  59
  60 Dans tous les exemples de fichiers de commandes Shell de lancement, on choisit
  61 de démarrer et arrêter le serveur d'application SALOME dans le même script. Ce
  62 n'est pas indispensable, mais c'est utile pour éviter des sessions SALOME en
  63 attente.
  64
  65 L'exemple le plus simple consiste uniquement à lancer l'exécution d'un schéma
  66 YACS donné, qui a préalablement été généré par l'utilisateur en interface
  67 graphique. Dans ce cas, en ayant pris soin de remplacer les textes contenus
  68 entre les symboles ``<...>``, il suffit d'enregistrer le script de commandes
  69 Shell suivant::
  70
  71     #!/bin/bash
  72     USERDIR="<Répertoire du fichier JDC ADAO>"
  73     SALOMEDIR="<Répertoire principal d'installation de SALOME>"
  74     $SALOMEDIR/salome start -k -t
  75     $SALOMEDIR/salome shell -- "driver $USERDIR/<Schéma xml YACS ADAO>"
  76     $SALOMEDIR/salome shell killSalome.py
  77
  78 Il faut ensuite le rendre exécutable pour l'exécuter.
  79
  80 Un exemple une peu plus complet consiste à lancer l'exécution d'un schéma YACS
  81 indiqué par l'utilisateur, en ayant préalablement vérifié sa disponibilité. Pour
  82 cela, en remplaçant le texte ``<Répertoire principal d'installation de
  83 SALOME>``, il suffit d'enregistrer le script de commandes Shell suivant::
  84
  85     #!/bin/bash
  86     if (test $# != 1)
  87     then
  88       echo -e "\nUsage: $0 <Schéma xml YACS ADAO>\n"
  89       exit
  90     else
  91       USERFILE="$1"
  92     fi
  93     if (test ! -e $USERFILE)
  94     then
  95       echo -e "\nErreur : le fichier XML nommé $USERFILE n'existe pas.\n"
  96       exit
  97     else
  98       SALOMEDIR="<Répertoire principal d'installation de SALOME>"
  99       $SALOMEDIR/salome start -k -t
 100       $SALOMEDIR/salome shell -- "driver $USERFILE"
 101       $SALOMEDIR/salome shell killSalome.py
 102     fi
 103
 104 Un autre exemple de script consiste à ajouter la conversion du fichier de
 105 commandes ADAO (JDC, ou paire de fichiers ".comm/.py") en un schéma YACS associé
 106 (fichier ".xml"). A la fin du script, on choisit aussi de supprimer le fichier
 107 de ``<Schéma xml YACS ADAO>`` car c'est un fichier généré. Pour cela, en ayant
 108 bien pris soin de remplacer le texte ``<Répertoire principal d'installation de
 109 SALOME>``, il suffit d'enregistrer le script de commandes Shell suivant::
 110
 111     #!/bin/bash
 112     if (test $# != 1)
 113     then
 114       echo -e "\nUsage: $0 <Cas .comm/.py ADAO>\n"
 115       exit
 116     else
 117       D=`dirname $1`
 118       F=`basename -s .comm $1`
 119       F=`basename -s .py $F`
 120       USERFILE="$D/$F"
 121     fi
 122     if (test ! -e $USERFILE.py)
 123     then
 124       echo -e "\nErreur : le fichier PY nommé $USERFILE.py n'existe pas.\n"
 125       exit
 126     else
 127       SALOMEDIR="<Répertoire principal d'installation de SALOME>"
 128       $SALOMEDIR/salome start -k -t
 129       $SALOMEDIR/salome shell -- "python $SALOMEDIR/bin/salome/AdaoYacsSchemaCreator.py $USERFILE.py $USERFILE.xml"
 130       $SALOMEDIR/salome shell -- "driver $USERFILE.xml"
 131       $SALOMEDIR/salome shell killSalome.py
 132       rm -f $USERFILE.xml
 133     fi
 134
 135 Dans tous les cas, les sorties standard et d'erreur se font dans le terminal de
 136 lancement.
 137
 138 Exécuter un schéma de calcul ADAO dans YACS en utilisant le mode "texte" (TUI YACS)
 139 -----------------------------------------------------------------------------------
 140
 141 Cette section décrit comment exécuter en mode TUI (Text User Interface) YACS un
 142 schéma de calcul YACS, obtenu dans l'interface graphique par la fonction
 143 "*Exporter vers YACS*" d'ADAO. Cela utilise le mode texte standard de YACS, qui
 144 est rapidement rappelé ici (voir la documentation YACS pour de plus amples
 145 informations) à travers un exemple simple. Comme décrit dans la documentation,
 146 un schéma XML peut être chargé en python. On donne ici une séquence complète de
 147 commandes pour tester la validité du schéma avant de l'exécuter, ajoutant des
 148 lignes supplémentaires initiales pour charger de manière explicite le catalogue
 149 de types pour éviter d'obscures difficultés::
 150
 151     #-*-coding:iso-8859-1-*-
 152     import pilot
 153     import SALOMERuntime
 154     import loader
 155     SALOMERuntime.RuntimeSALOME_setRuntime()
 156
 157     r = pilot.getRuntime()
 158     xmlLoader = loader.YACSLoader()
 159     xmlLoader.registerProcCataLoader()
 160     try:
 161      catalogAd = r.loadCatalog("proc", "<Schéma xml YACS ADAO>")
 162     except:
 163       pass
 164     r.addCatalog(catalogAd)
 165
 166     try:
 167         p = xmlLoader.load("<Schéma xml YACS ADAO>")
 168     except IOError,ex:
 169         print "IO exception:",ex
 170
 171     logger = p.getLogger("parser")
 172     if not logger.isEmpty():
 173         print "The imported file has errors :"
 174         print logger.getStr()
 175
 176     if not p.isValid():
 177         print "Le schéma n'est pas valide et ne peut pas être exécuté"
 178         print p.getErrorReport()
 179
 180     info=pilot.LinkInfo(pilot.LinkInfo.ALL_DONT_STOP)
 181     p.checkConsistency(info)
 182     if info.areWarningsOrErrors():
 183         print "Le schéma n'est pas cohérent et ne peut pas être exécuté"
 184         print info.getGlobalRepr()
 185
 186     e = pilot.ExecutorSwig()
 187     e.RunW(p)
 188     if p.getEffectiveState() != pilot.DONE:
 189         print p.getErrorReport()
 190
 191 Cette démarche permet par exemple d'éditer le schéma YACS XML en mode texte TUI,
 192 ou de rassembler les résultats pour un usage ultérieur.
 193
 194 .. _section_advanced_R:
 195
 196 Exécuter un calcul ADAO en environnement R en utilisant l'interface TUI ADAO
 197 ----------------------------------------------------------------------------
 198
 199 .. index:: single: R
 200 .. index:: single: rPython
 201
 202 Pour étendre les possibilités d'analyse et de traitement, il est possible
 203 d'utiliser les calculs ADAO dans l'environnement **R** (voir [R]_ pour plus de
 204 détails). Ce dernier est disponible dans SALOME en lançant l'interpréteur R dans
 205 le shell "``salome shell``". Il faut de plus disposer, en R, du package
 206 "*rPython*", qui peut si nécessaire être installé par l'utilisateur à l'aide de
 207 la commande R suivante::
 208
 209     #-*-coding:iso-8859-1-*-
 210     #
 211     # IMPORTANT : à exécuter dans l'interpréteur R
 212     # --------------------------------------------
 213     install.packages("rPython")
 214
 215 On se reportera à la documentation [GilBellosta15]_ pour de plus amples
 216 renseignements sur ce package.
 217
 218 Les calculs ADAO définis en interface textuelle (API/TUI, voir la
 219 :ref:`section_tui`) peuvent alors être interprétés depuis l'environnement R, en
 220 utilisant des données et des informations depuis R. La démarche est illustrée
 221 sur :ref:`subsection_tui_example`, proposé dans la description de l'interface
 222 API/TUI. Dans l'interpréteur R, on peut exécuter les commandes suivantes,
 223 directement issues de l'exemple simple::
 224
 225     #-*-coding:iso-8859-1-*-
 226     #
 227     # IMPORTANT : à exécuter dans l'interpréteur R
 228     # --------------------------------------------
 229     library(rPython)
 230     python.exec("
 231         from numpy import array
 232         import adaoBuilder
 233         case = adaoBuilder.New()
 234         case.set( 'AlgorithmParameters', Algorithm='3DVAR' )
 235         case.set( 'Background',          Vector=[0, 1, 2] )
 236         case.set( 'BackgroundError',     ScalarSparseMatrix=1.0 )
 237         case.set( 'Observation',         Vector=array([0.5, 1.5, 2.5]) )
 238         case.set( 'ObservationError',    DiagonalSparseMatrix='1 1 1' )
 239         case.set( 'ObservationOperator', Matrix='1 0 0;0 2 0;0 0 3' )
 240         case.set( 'Observer',            Variable='Analysis', Template='ValuePrinter' )
 241         case.execute()
 242     ")
 243
 244 dont le résultat est::
 245
 246     Analysis [ 0.25000264  0.79999797  0.94999939]
 247
 248 Dans la rédaction des calculs ADAO exécutés depuis R, il convient d'être très
 249 attentif au bon usage des guillemets simples et doubles, qui ne doivent pas
 250 collisionner entre les deux langages.
 251
 252 Les données peuvent venir l'environnement R et doivent être rangées dans des
 253 variables correctement assignées, pour être utilisées ensuite en Python pour
 254 ADAO. On se reportera à la documentation [GilBellosta15]_ pour la mise en
 255 oeuvre. On peut transformer l'exemple ci-dessus pour utiliser des données
 256 provenant de R pour alimenter les trois variables d'ébauche, d'observation et
 257 d'opérateur d'observation. On récupère à la fin l'état optimal dans une variable
 258 R aussi. Les autres lignes sont identiques. L'exemple devient ainsi::
 259
 260     #-*-coding:iso-8859-1-*-
 261     #
 262     # IMPORTANT : à exécuter dans l'interpréteur R
 263     # --------------------------------------------
 264     #
 265     # Variables R
 266     # -----------
 267     xb <- 0:2
 268     yo <- c(0.5, 1.5, 2.5)
 269     h <- '1 0 0;0 2 0;0 0 3'
 270     #
 271     # Code Python
 272     # -----------
 273     library(rPython)
 274     python.assign( "xb",  xb )
 275     python.assign( "yo",  yo )
 276     python.assign( "h",  h )
 277     python.exec("
 278         from numpy import array
 279         import adaoBuilder
 280         case = adaoBuilder.New()
 281         case.set( 'AlgorithmParameters', Algorithm='3DVAR' )
 282         case.set( 'Background',          Vector=xb )
 283         case.set( 'BackgroundError',     ScalarSparseMatrix=1.0 )
 284         case.set( 'Observation',         Vector=array(yo) )
 285         case.set( 'ObservationError',    DiagonalSparseMatrix='1 1 1' )
 286         case.set( 'ObservationOperator', Matrix=str(h) )
 287         case.set( 'Observer',            Variable='Analysis', Template='ValuePrinter' )
 288         case.execute()
 289         xa = list(case.get('Analysis')[-1])
 290     ")
 291     #
 292     # Variables R
 293     # -----------
 294     xa <- python.get("xa")
 295
 296 On remarquera les conversions explicite de type ``str`` et ``list`` pour
 297 s'assurer que les données sont bien transmises en type standards connus du
 298 package "*rPython*". De plus, ce sont les données qui peuvent être transférées
 299 entre les deux langages, et pas des fonctions ou méthodes. Il convient donc
 300 d'élaborer en Python de manière générique les fonctions d'exécution requises par
 301 ADAO, et de leur transmettre ensuite de manière correcte les données disponibles
 302 en R.
 303
 304 Les cas plus complets, proposés dans les :ref:`subsection_tui_advanced`, peuvent
 305 être exécutés de la même manière, et ils donnent le même résultat que dans
 306 l'interface API/TUI en Python standard.
 307
 308 .. _section_advanced_observer:
 309
 310 Obtenir des informations sur des variables spéciales au cours d'un calcul ADAO en YACS
 311 --------------------------------------------------------------------------------------
 312
 313 .. index:: single: Observer
 314 .. index:: single: Observer Template
 315
 316 Certaines variables spéciales internes à l'optimisation, utilisées au cours des
 317 calculs, peuvent être surveillées durant un calcul ADAO. Ces variables peuvent
 318 être affichées, tracées, enregistrées, etc. C'est réalisable en utilisant des
 319 "*observer*", qui sont des scripts, chacun associé à une variable.
 320
 321 Des modèles ("templates") sont disponibles lors de l'édition le cas ADAO dans
 322 l'éditeur graphique. Ces scripts simples peuvent être adaptés par l'utilisateur,
 323 soit dans l'étape d'édition intégrée, ou dans l'étape d'édition avant
 324 l'exécution, pour améliorer l'adaptation du calcul ADAO dans le superviseur
 325 d'exécution de SALOME.
 326
 327 Pour mettre en oeuvre ces "*observer*" de manière efficace, on se reportera aux
 328 :ref:`ref_observers_requirements`.
 329
 330 Obtenir plus d'information lors du déroulement d'un calcul
 331 ----------------------------------------------------------
 332
 333 .. index:: single: Logging
 334
 335 Lors du déroulement d'un calcul, des données et messages utiles sont
 336 disponibles. Il y a deux manières d'obtenir ces informations.
 337
 338 La première, et la manière préférentielle, est d'utiliser la variable interne
 339 "*Debug*" disponible dans chaque cas ADAO. Elle est atteignable dans l'interface
 340 graphique d'édition du module. La mettre à "*1*" permet d'envoyer des messages
 341 dans la fenêtre de sortie de l'exécution dans YACS ("*YACS Container Log*").
 342
 343 La seconde consiste à utiliser le module Python natif "*logging*" (voir la
 344 documentation Python http://docs.python.org/library/logging.html pour de plus
 345 amples informations sur ce module). Dans l'ensemble du schéma YACS,
 346 principalement à travers les entrées sous forme de scripts, l'utilisateur peut
 347 fixer le niveau de logging en accord avec les besoins d'informations détaillées.
 348 Les différents niveaux de logging sont : "*DEBUG*", "*INFO*", "*WARNING*",
 349 "*ERROR*", "*CRITICAL*". Toutes les informations associées à un niveau sont
 350 affichées à tous les niveaux au-dessus de celui-ci (inclut). La méthode la plus
 351 facile consiste à changer le niveau de surveillance en utilisant les lignes
 352 Python suivantes::
 353
 354     import logging
 355     logging.getLogger().setLevel(logging.DEBUG)
 356
 357 Le niveau par défaut standard de surveillance par logging est "*WARNING*", le
 358 niveau par défaut dans le module ADAO est "*INFO*".
 359
 360 Il est aussi recommandé d'inclure de la surveillance par logging ou des
 361 mécanismes de débogage dans le code de simulation, et de les utiliser en
 362 conjonction avec les deux méthodes précédentes. Néanmoins, il convient d'être
 363 prudent dans le stockage de "grosses" variables car cela coûte du temps,
 364 quel que soit le niveau de surveillance choisi (c'est-à-dire même si ces
 365 variables ne sont pas affichées).
 366
 367 .. _subsection_ref_parallel_df:
 368
 369 Accélérer les calculs de dérivées numériques en utilisant un mode parallèle
 370 ---------------------------------------------------------------------------
 371
 372 .. index:: single: EnableMultiProcessing
 373 .. index:: single: NumberOfProcesses
 374
 375 Lors de la définition d'un opérateur, comme décrit dans le chapitre des
 376 :ref:`section_ref_operator_requirements`, l'utilisateur peut choisir la forme
 377 fonctionnelle "*ScriptWithOneFunction*". Cette forme conduit explicitement à
 378 approximer les opérateurs tangent et adjoint par un calcul par différences
 379 finies. Il requiert de nombreux appels à l'opérateur direct (fonction définie
 380 par l'utilisateur), au moins autant de fois que la dimension du vecteur d'état.
 381 Ce sont ces appels qui peuvent être potentiellement exécutés en parallèle.
 382
 383 Sous certaines conditions, il est alors possible d'accélérer les calculs de
 384 dérivées numériques en utilisant un mode parallèle pour l'approximation par
 385 différences finies. Lors de la définition d'un cas ADAO, c'est effectué en
 386 ajoutant le mot-clé optionnel "*EnableMultiProcessing*", mis à "1", de la
 387 commande "*SCRIPTWITHONEFUNCTION*" dans la définition de l'opérateur. Le mode
 388 parallèle utilise uniquement des ressources locales (à la fois multi-coeurs ou
 389 multi-processeurs) de l'ordinateur sur lequel SALOME est en train de tourner,
 390 demandant autant de ressources que disponible. Si nécessaire, on peut réduire
 391 les ressources disponibles en limitant le nombre possible de processus
 392 parallèles grâce au mot-clé optionnel "*NumberOfProcesses*", que l'on met au
 393 maximum souhaité (ou à "0" pour le contrôle automatique, qui est la valeur par
 394 défaut). Par défaut, ce mode parallèle est désactivé
 395 ("*EnableMultiProcessing=0*").
 396
 397 Les principales conditions pour réaliser ces calculs parallèles viennent de la
 398 fonction définie par l'utilisateur, qui représente l'opérateur direct. Cette
 399 fonction doit au moins être "thread safe" pour être exécutée dans un
 400 environnement Python parallèle (notions au-delà du cadre de ce paragraphe). Il
 401 n'est pas évident de donner des règles générales, donc il est recommandé, à
 402 l'utilisateur qui active ce parallélisme interne, de vérifier soigneusement sa
 403 fonction et les résultats obtenus.
 404
 405 D'un point de vue utilisateur, certaines conditions, qui doivent être réunies
 406 pour mettre en place des calculs parallèles pour les approximations des
 407 opérateurs tangent et adjoint, sont les suivantes :
 408
 409 #. La dimension du vecteur d'état est supérieure à 2 ou 3.
 410 #. Le calcul unitaire de la fonction utilisateur directe "dure un certain temps", c'est-à-dire plus que quelques minutes.
 411 #. La fonction utilisateur directe n'utilise pas déjà du parallélisme (ou l'exécution parallèle est désactivée dans le calcul de l'utilisateur).
 412 #. La fonction utilisateur directe n'effectue pas d'accès en lecture/écriture à des ressources communes, principalement des données stockées, des fichiers de sortie ou des espaces mémoire.
 413 #. Les "*observer*" ajoutés par l'utilisateur n'effectuent pas d'accès en lecture/écriture à des ressources communes, comme des fichiers ou des espaces mémoire.
 414
 415 Si ces conditions sont satisfaites, l'utilisateur peut choisir d'activer le
 416 parallélisme interne pour le calcul des dérivées numériques. Malgré la
 417 simplicité d'activation, obtenue en définissant une variable seulement,
 418 l'utilisateur est fortement invité à vérifier les résultats de ses calculs. Il
 419 faut au moins les effectuer une fois avec le parallélisme activé, et une autre
 420 fois avec le parallélisme désactivé, pour comparer les résultats. Si cette mise
 421 en oeuvre échoue à un moment ou à un autre, il faut savoir que ce schéma de
 422 parallélisme fonctionne pour des codes complexes, comme *Code_Aster* dans
 423 *SalomeMeca* [SalomeMeca]_ par exemple. Donc, si cela ne marche pas dans votre
 424 cas, vérifiez bien votre fonction d'opérateur avant et pendant l'activation du
 425 parallélisme...
 426
 427 .. warning::
 428
 429   en cas de doute, il est recommandé de NE PAS ACTIVER ce parallélisme.
 430
 431 On rappelle aussi qu'il faut choisir dans YACS un container par défaut de type
 432 "*multi*" pour le lancement du schéma, pour permettre une exécution
 433 véritablement parallèle.
 434
 435 Passer d'une version d'ADAO à une nouvelle
 436 ------------------------------------------
 437
 438 .. index:: single: Version
 439
 440 Le module ADAO et ses fichiers de cas ".comm" sont identifiés par des versions,
 441 avec des caractéristiques "Major", "Minor" et "Revision". Une version
 442 particulière est numérotée "Major.Minor.Revision", avec un lien fort avec la
 443 numérotation de la plateforme SALOME.
 444
 445 Chaque version "Major.Minor.Revision" du module ADAO peut lire les fichiers de
 446 cas ADAO de la précédente version mineure "Major.Minor-1.*". En général, elle
 447 peut aussi lire les fichiers de cas de toutes les versions mineures "Major.*.*"
 448 d'une branche majeure, mais ce n'est pas obligatoirement vrai pour toutes les
 449 commandes ou tous les mots-clés. En général aussi, un fichier de cas ADAO d'une
 450 version ne peut pas être lu par une précédente version mineure ou majeure du
 451 module ADAO.
 452
 453 Passer de la version 8.x à la 8.y avec x < y
 454 ++++++++++++++++++++++++++++++++++++++++++++
 455
 456 Il n'y a pas d'incompatibilité connue pour les fichiers de cas ADAO. La
 457 procédure de montée en version consiste à lire l'ancien fichier de cas ADAO
 458 avec le nouveau module SALOME/ADAO, et à l'enregistrer avec un nouveau nom.
 459
 460 Pour faciliter les futures évolutions, il est fortement recommandé de veiller à
 461 ce que vos fichiers scripts utilisateurs utilisent une syntaxe compatibible avec
 462 Python 2 et avec Python 3. En particulier, on recommande d'utiliser la syntaxe
 463 fonctionnelle pour les "*print*" et non pas la syntaxe "*commande*", comme par
 464 exemple::
 465
 466     # Python 2 & 3
 467     x, unit = 1., "cm"
 468     print( "x = %s %s"%(str(x),str(unit)) )
 469
 470 ou::
 471
 472     # Python 2 & 3
 473     x, unit = 1., "cm"
 474     print( "x = {0} {1}".format(str(x),str(unit)) )
 475
 476 plutôt que::
 477
 478     # Python 2 uniquement
 479     x, unit = 1., "cm"
 480     print "x =", x, unit
 481
 482 Passer de la version 7.8 à la 8.1
 483 +++++++++++++++++++++++++++++++++
 484
 485 Il n'y a pas d'incompatibilité connue pour les fichiers de cas ADAO. La
 486 procédure de montée en version consiste à lire l'ancien fichier de cas ADAO
 487 avec le nouveau module SALOME/ADAO, et à l'enregistrer avec un nouveau nom.
 488
 489 Passer de la version 7.x à la 7.y avec x < y
 490 ++++++++++++++++++++++++++++++++++++++++++++
 491
 492 Il n'y a pas d'incompatibilité connue pour les fichiers de cas ADAO. La
 493 procédure de montée en version consiste à lire l'ancien fichier de cas ADAO
 494 avec le nouveau module SALOME/ADAO, et à l'enregistrer avec un nouveau nom.
 495
 496 Passer de la version 6.6 à la 7.2
 497 +++++++++++++++++++++++++++++++++
 498
 499 Il n'y a pas d'incompatibilité connue pour les fichiers de cas ADAO. La
 500 procédure de montée en version consiste à lire l'ancien fichier de cas ADAO avec
 501 le nouveau module SALOME/ADAO, et à l'enregistrer avec un nouveau nom.
 502
 503 Il y a une incompatibilité introduite dans les fichiers de script de
 504 post-processing ou d'observers. L'ancienne syntaxe pour interroger un objet
 505 résultat, comme celui d'analyse "*Analysis*" (fourni dans un script à travers le
 506 mot-clé "*UserPostAnalysis*"), était par exemple::
 507
 508     Analysis = ADD.get("Analysis").valueserie(-1)
 509     Analysis = ADD.get("Analysis").valueserie()
 510
 511 La nouvelle syntaxe est entièrement compatible avec celle (classique) pour les
 512 objets de type liste ou tuple::
 513
 514     Analysis = ADD.get("Analysis")[-1]
 515     Analysis = ADD.get("Analysis")[:]
 516
 517 Les scripts de post-processing doivent être modifiés.
 518
 519 Passer de la version 6.x à la 6.y avec x < y
 520 ++++++++++++++++++++++++++++++++++++++++++++
 521
 522 Il n'y a pas d'incompatibilité connue pour les fichiers de cas ADAO. La
 523 procédure de montée en version consiste à lire l'ancien fichier de cas ADAO avec
 524 le nouveau module SALOME/ADAO, et à l'enregistrer avec un nouveau nom.
 525
 526 Il y a une incompatibilité introduite dans les fichiers de script d'opérateur,
 527 lors de la dénomination des opérateurs élémentaires utilisés pour l'opérateur
 528 d'observation par script. Les nouveaux noms requis sont "*DirectOperator*",
 529 "*TangentOperator*" et "*AdjointOperator*", comme décrit dans la quatrième
 530 partie du chapitre :ref:`section_reference`. Les fichiers de script d'opérateur
 531 doivent être modifiés.