2 Copyright (C) 2008-2021 EDF R&D
4 This file is part of SALOME ADAO module.
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.
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.
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
20 See http://www.salome-platform.org/ or email : webmaster.salome@opencascade.com
22 Author: Jean-Philippe Argaud, jean-philippe.argaud@edf.fr, EDF R&D
26 ================================================================================
27 **[DocU]** Usages avancés du module ADAO
28 ================================================================================
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 ``<...>``.
36 Convertir et exécuter un fichier de commandes ADAO (JDC) par l'intermédiaire d'un script Shell
37 ----------------------------------------------------------------------------------------------
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 standard, 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.
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
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
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
73 USERDIR="<Répertoire du fichier JDC ADAO>"
74 SALOMEDIR="<Répertoire principal d'installation de SALOME>"
75 $SALOMEDIR/salome start -k -t
76 $SALOMEDIR/salome shell -- "driver $USERDIR/<Schéma xml YACS ADAO>"
77 $SALOMEDIR/salome shell killSalome.py
79 Il faut ensuite le rendre exécutable pour l'exécuter.
81 Un exemple un peu plus complet consiste à lancer l'exécution d'un schéma YACS
82 indiqué par l'utilisateur, en ayant préalablement vérifié sa disponibilité. Pour
83 cela, en remplaçant le texte ``<Répertoire principal d'installation de
84 SALOME>``, il suffit d'enregistrer le script de commandes Shell suivant :
90 echo -e "\nUsage: $0 <Schéma xml YACS ADAO>\n"
95 if (test ! -e $USERFILE)
97 echo -e "\nErreur : le fichier XML nommé $USERFILE n'existe pas.\n"
100 SALOMEDIR="<Répertoire principal d'installation de SALOME>"
101 $SALOMEDIR/salome start -k -t
102 $SALOMEDIR/salome shell -- "driver $USERFILE"
103 $SALOMEDIR/salome shell killSalome.py
106 Un autre exemple de script consiste à ajouter la conversion du fichier de
107 commandes ADAO (JDC, ou paire de fichiers ".comm/.py") en un schéma YACS associé
108 (fichier ".xml"). A la fin du script, on choisit aussi de supprimer le fichier
109 de ``<Schéma xml YACS ADAO>`` car c'est un fichier généré. Pour cela, en ayant
110 bien pris soin de remplacer le texte ``<Répertoire principal d'installation de
111 SALOME>``, il suffit d'enregistrer le script de commandes Shell suivant :
117 echo -e "\nUsage: $0 <Cas .comm/.py ADAO>\n"
121 F=`basename -s .comm $1`
122 F=`basename -s .py $F`
125 if (test ! -e $USERFILE.py)
127 echo -e "\nErreur : le fichier PY nommé $USERFILE.py n'existe pas.\n"
130 SALOMEDIR="<Répertoire principal d'installation de SALOME>"
131 $SALOMEDIR/salome start -k -t
132 $SALOMEDIR/salome shell -- "python $SALOMEDIR/bin/AdaoYacsSchemaCreator.py $USERFILE.py $USERFILE.xml"
133 $SALOMEDIR/salome shell -- "driver $USERFILE.xml"
134 $SALOMEDIR/salome shell killSalome.py
138 Dans tous les cas, les sorties standard et d'erreur se font dans le terminal de
141 Exécuter un schéma de calcul ADAO dans YACS en utilisant le mode "texte" (TUI YACS)
142 -----------------------------------------------------------------------------------
144 Cette section décrit comment exécuter en mode TUI (Text User Interface) YACS un
145 schéma de calcul YACS, obtenu dans l'interface graphique par la fonction
146 "*Exporter vers YACS*" d'ADAO. Cela utilise le mode texte standard de YACS, qui
147 est rapidement rappelé ici (voir la documentation YACS pour de plus amples
148 informations) à travers un exemple simple. Comme décrit dans la documentation,
149 un schéma XML peut être chargé en python. On donne ici une séquence complète de
150 commandes pour tester la validité du schéma avant de l'exécuter, ajoutant des
151 lignes supplémentaires initiales pour charger de manière explicite le catalogue
152 de types pour éviter d'obscures difficultés :
155 #-*- coding: utf-8 -*-
159 SALOMERuntime.RuntimeSALOME_setRuntime()
161 r = pilot.getRuntime()
162 xmlLoader = loader.YACSLoader()
163 xmlLoader.registerProcCataLoader()
165 catalogAd = r.loadCatalog("proc", "<Schéma xml YACS ADAO>")
166 r.addCatalog(catalogAd)
171 p = xmlLoader.load("<Schéma xml YACS ADAO>")
173 print("IO exception:",ex)
175 logger = p.getLogger("parser")
176 if not logger.isEmpty():
177 print("The imported file has errors :")
178 print(logger.getStr())
181 print("Le schéma n'est pas valide et ne peut pas être exécuté")
182 print(p.getErrorReport())
184 info=pilot.LinkInfo(pilot.LinkInfo.ALL_DONT_STOP)
185 p.checkConsistency(info)
186 if info.areWarningsOrErrors():
187 print("Le schéma n'est pas cohérent et ne peut pas être exécuté")
188 print(info.getGlobalRepr())
190 e = pilot.ExecutorSwig()
192 if p.getEffectiveState() != pilot.DONE:
193 print(p.getErrorReport())
195 Cette démarche permet par exemple d'éditer le schéma YACS XML en mode texte TUI,
196 ou de rassembler les résultats pour un usage ultérieur.
198 .. _section_advanced_R:
200 Exécuter un calcul ADAO en environnement R en utilisant l'interface TUI ADAO
201 ----------------------------------------------------------------------------
204 .. index:: single: rPython
206 Pour étendre les possibilités d'analyse et de traitement, il est possible
207 d'utiliser les calculs ADAO dans l'environnement **R** (voir [R]_ pour plus de
208 détails). Ce dernier est disponible dans SALOME en lançant l'interpréteur R dans
209 le shell "``salome shell``". Il faut de plus disposer, en R, du package
210 "*rPython*", qui peut si nécessaire être installé par l'utilisateur à l'aide de
211 la commande R suivante :
214 #-*- coding: utf-8 -*-
216 # IMPORTANT : à exécuter dans l'interpréteur R
217 # --------------------------------------------
218 install.packages("rPython")
220 On se reportera à la documentation [GilBellosta15]_ pour de plus amples
221 renseignements sur ce package.
223 Les calculs ADAO définis en interface textuelle (API/TUI, voir la
224 :ref:`section_tui`) peuvent alors être interprétés depuis l'environnement R, en
225 utilisant des données et des informations depuis R. La démarche est illustrée
226 sur :ref:`subsection_tui_example`, proposé dans la description de l'interface
227 API/TUI. Dans l'interpréteur R, on peut exécuter les commandes suivantes,
228 directement issues de l'exemple simple :
231 #-*- coding: utf-8 -*-
233 # IMPORTANT : à exécuter dans l'interpréteur R
234 # --------------------------------------------
237 from numpy import array
238 from adao import adaoBuilder
239 case = adaoBuilder.New()
240 case.set( 'AlgorithmParameters', Algorithm='3DVAR' )
241 case.set( 'Background', Vector=[0, 1, 2] )
242 case.set( 'BackgroundError', ScalarSparseMatrix=1.0 )
243 case.set( 'Observation', Vector=array([0.5, 1.5, 2.5]) )
244 case.set( 'ObservationError', DiagonalSparseMatrix='1 1 1' )
245 case.set( 'ObservationOperator', Matrix='1 0 0;0 2 0;0 0 3' )
246 case.set( 'Observer', Variable='Analysis', Template='ValuePrinter' )
250 dont le résultat est :
253 Analysis [ 0.25000264 0.79999797 0.94999939]
255 Dans la rédaction des calculs ADAO exécutés depuis R, il convient d'être très
256 attentif au bon usage des guillemets simples et doubles, qui ne doivent pas
257 collisionner entre les deux langages.
259 Les données peuvent venir l'environnement R et doivent être rangées dans des
260 variables correctement assignées, pour être utilisées ensuite en Python pour
261 ADAO. On se reportera à la documentation [GilBellosta15]_ pour la mise en
262 oeuvre. On peut transformer l'exemple ci-dessus pour utiliser des données
263 provenant de R pour alimenter les trois variables d'ébauche, d'observation et
264 d'opérateur d'observation. On récupère à la fin l'état optimal dans une variable
265 R aussi. Les autres lignes sont identiques. L'exemple devient ainsi :
268 #-*- coding: utf-8 -*-
270 # IMPORTANT : à exécuter dans l'interpréteur R
271 # --------------------------------------------
276 yo <- c(0.5, 1.5, 2.5)
277 h <- '1 0 0;0 2 0;0 0 3'
282 python.assign( "xb", xb )
283 python.assign( "yo", yo )
284 python.assign( "h", h )
286 from numpy import array
287 from adao import adaoBuilder
288 case = adaoBuilder.New()
289 case.set( 'AlgorithmParameters', Algorithm='3DVAR' )
290 case.set( 'Background', Vector=xb )
291 case.set( 'BackgroundError', ScalarSparseMatrix=1.0 )
292 case.set( 'Observation', Vector=array(yo) )
293 case.set( 'ObservationError', DiagonalSparseMatrix='1 1 1' )
294 case.set( 'ObservationOperator', Matrix=str(h) )
295 case.set( 'Observer', Variable='Analysis', Template='ValuePrinter' )
297 xa = list(case.get('Analysis')[-1])
302 xa <- python.get("xa")
304 On remarquera les conversions explicite de type ``str`` et ``list`` pour
305 s'assurer que les données sont bien transmises en type standards connus du
306 package "*rPython*". De plus, ce sont les données qui peuvent être transférées
307 entre les deux langages, et pas des fonctions ou méthodes. Il convient donc
308 d'élaborer en Python de manière générique les fonctions d'exécution requises par
309 ADAO, et de leur transmettre ensuite de manière correcte les données disponibles
312 Les cas plus complets, proposés dans les :ref:`subsection_tui_advanced`, peuvent
313 être exécutés de la même manière, et ils donnent le même résultat que dans
314 l'interface API/TUI en Python standard.
316 .. _section_advanced_eficas_gui:
318 Utiliser l'interface graphique EFICAS d'ADAO comme une commande TUI d'ADAO
319 --------------------------------------------------------------------------
321 Pour faciliter l'édition rapide avec EFICAS d'ADAO d'un fichier de commandes
322 ADAO (JDC, ou paire de fichiers ".comm/.py", qui se trouvent ensemble dans un
323 répertoire d'étude de l'utilisateur), on peut lancer l'interface graphique
324 directement depuis l'interpréteur Python. Pour cela, dans un interpréteur
325 Python obtenu depuis le "SALOME shell", on utilise les commandes suivantes :
328 from adao import adaoBuilder
331 Si nécessaire, des messages explicites permettent d'identifier les variables
332 d'environnement requises qui seraient absentes. Cette commande ne doit
333 néanmoins pas être lancée dans la console Python de SALOME (car dans ce cas il
334 suffit d'activer le module puisque l'on est déjà dans l'interface
335 graphique...), mais elle peut l'être dans une session "SALOME shell" obtenue
336 depuis le menu "Outils/Extensions" de SALOME. Pour mémoire, le moyen le plus
337 simple d'obtenir un interpréteur Python inclu dans une session "SALOME shell"
338 est de lancer la commande suivante dans un terminal :
341 $SALOMEDIR/salome shell -- python
343 avec ``SALOMEDIR`` le ``<Répertoire principal d'installation de SALOME>``.
345 .. _section_advanced_execution_mode:
347 Changer le mode par défaut d'exécution de noeuds dans YACS
348 ----------------------------------------------------------
350 .. index:: single: YACS
352 Diverses raisons peuvent conduire à vouloir modifier le mode par défaut
353 d'exécution de noeuds dans YACS (voir [#]_ pour le bon usage de ces
354 possibilités). Cela peut être pour des raisons de performances, ou par exemple
355 pour des raisons de conflits de ressources.
357 On peut vouloir utiliser ce changement de mode d'exécution pour étendre l'usage
358 des ressources de calcul locales ou pour déporter les calculs d'un noeud qui le
359 nécessite. C'est en particulier le cas d'un noeud qui devrait utiliser une
360 ressource de simulation disponible sur un cluster par exemple.
362 Par ailleurs, les divers calculs qui sont menés (opérateurs fournis par
363 l'utilisateur, fonctions de restitution des résultats, etc.) peuvent aussi
364 présenter des conflits s'ils sont exécutés dans un processus unique, et en
365 particulier dans le processus principal de SALOME. C'est le fonctionnement par
366 défaut de YACS pour des raisons de performances et de simplicité. Il est
367 néanmoins recommandé de changer ce fonctionnement lorsque l'on rencontre des
368 instabilités d'exécution ou des messages d'erreur au niveau de l'interface
371 Dans tous les cas, dans le schéma YACS en édition, il suffit de changer le mode
372 d'exécution du ou des noeuds qui le nécessitent. Il faut les exécuter dans un
373 nouveau conteneur créé pour l'occasion (il ne suffit pas d'utiliser le
374 conteneur par défaut, il faut explicitement en créer un nouveau) et dont les
375 caractéristiques sont adaptées à l'usage visé. La démarche est donc la suivante
378 #. Créer un nouveau conteneur YACS, par utilisation du menu contextuel des "*Containers*" dans la vue arborescente du schéma YACS (usuellement à gauche),
379 #. Adapter les caractéristiques du conteneur, en sélectionnant par exemple une propriété de "*type*" valant "*multi*" pour une exécution véritablement parallèle, ou en choisissant une ressource distante de calcul définie par la propriété de "*Resource*", ou en utilisant les paramètres avancés,
380 #. Sélectionner graphiquement dans la vue centrale le noeud dont on veut changer le mode d'exécution,
381 #. Dans le panneau à droite des entrées du noeud, déplier les choix d'exécution (nommés "*Execution Mode"*), cocher la case "*Container*" à la place du défaut "*YACS*", et choisir le conteneur nouvellement créé (il porte usuellement le nom "*container0*"),
382 #. Enregistrer le schéma YACS modifié.
384 On peut répéter cette démarche pour chaque noeud qui le nécessite, en
385 réutilisant le même nouveau conteneur pour tous les noeuds, ou en créant un
386 nouveau conteneur pour chaque noeud.
390 ce changement de mode d'exécution est extrêmement puissant et souple. Il est
391 donc recommandé à l'utilisateur à la fois de l'utiliser, et en même temps
392 d'être attentif à l'interaction des différents choix qu'il effectue, pour
393 éviter par exemple une dégradation involontaire des performances, ou des
394 conflits informatiques compliqués à diagnostiquer.
396 .. _section_advanced_observer:
398 Obtenir des informations sur des variables spéciales au cours d'un calcul ADAO
399 ------------------------------------------------------------------------------
401 .. index:: single: Observer
402 .. index:: single: Observer Template
404 Certaines variables spéciales internes à l'optimisation, utilisées au cours des
405 calculs, peuvent être surveillées durant un calcul ADAO. Ces variables peuvent
406 être affichées, tracées, enregistrées, etc. C'est réalisable en utilisant des
407 "*observer*", qui sont des commandes rassemblées sous forme de scripts, chacun
408 associé à une variable.
410 Des modèles ("templates") sont disponibles lors de l'édition le cas ADAO dans
411 l'éditeur graphique. Ces scripts simples peuvent être adaptés par l'utilisateur,
412 soit dans l'étape d'édition intégrée, ou dans l'étape d'édition avant
413 l'exécution, pour améliorer l'adaptation du calcul ADAO dans le superviseur
414 d'exécution de SALOME.
416 Pour mettre en oeuvre ces "*observer*" de manière efficace, on se reportera aux
417 :ref:`section_ref_observers_requirements`.
419 .. _section_advanced_logging:
421 Obtenir plus d'information lors du déroulement d'un calcul
422 ----------------------------------------------------------
424 .. index:: single: Logging
426 Lors du déroulement d'un calcul, des données et messages utiles sont
427 disponibles. Il y a deux manières d'obtenir ces informations.
429 La première, et la manière préférentielle, est d'utiliser la variable interne
430 "*Debug*" disponible dans chaque cas ADAO. Elle est atteignable dans l'interface
431 graphique d'édition du module. La mettre à "*1*" permet d'envoyer des messages
432 dans la fenêtre de sortie de l'exécution dans YACS ("*YACS Container Log*").
434 La seconde consiste à utiliser le module Python natif "*logging*" (voir la
435 documentation Python http://docs.python.org/library/logging.html pour de plus
436 amples informations sur ce module). Dans l'ensemble du schéma YACS,
437 principalement à travers les entrées sous forme de scripts, l'utilisateur peut
438 fixer le niveau de logging en accord avec les besoins d'informations détaillées.
439 Les différents niveaux de logging sont : "*DEBUG*", "*INFO*", "*WARNING*",
440 "*ERROR*", "*CRITICAL*". Toutes les informations associées à un niveau sont
441 affichées à tous les niveaux au-dessus de celui-ci (inclut). La méthode la plus
442 facile consiste à changer le niveau de surveillance en utilisant les lignes
447 logging.getLogger().setLevel(logging.DEBUG)
449 Le niveau par défaut standard de surveillance par logging est "*WARNING*", le
450 niveau par défaut dans le module ADAO est "*INFO*".
452 Il est aussi recommandé d'inclure de la surveillance par logging ou des
453 mécanismes de débogage dans le code de simulation, et de les utiliser en
454 conjonction avec les deux méthodes précédentes. Néanmoins, il convient d'être
455 prudent dans le stockage de "grosses" variables car cela coûte du temps,
456 quel que soit le niveau de surveillance choisi (c'est-à-dire même si ces
457 variables ne sont pas affichées).
459 .. _subsection_ref_parallel_df:
461 Accélérer les calculs de dérivées numériques en utilisant un mode parallèle
462 ---------------------------------------------------------------------------
464 .. index:: single: EnableMultiProcessing
465 .. index:: single: NumberOfProcesses
467 Lors de la définition d'un opérateur, comme décrit dans le chapitre des
468 :ref:`section_ref_operator_requirements`, l'utilisateur peut choisir la forme
469 fonctionnelle "*ScriptWithOneFunction*". Cette forme conduit explicitement à
470 approximer les opérateurs tangent et adjoint (s'ils sont nécessaires) par un
471 calcul par différences finies. Cela requiert de nombreux appels à l'opérateur
472 direct (qui est la fonction définie par l'utilisateur), au moins autant de fois
473 que la dimension du vecteur d'état. Ce sont ces appels qui peuvent être
474 potentiellement exécutés en parallèle.
476 Sous certaines conditions (décrites juste après), il est possible d'accélérer
477 les calculs de dérivées numériques en utilisant un mode parallèle pour
478 l'approximation par différences finies. Lors de la définition d'un cas ADAO,
479 c'est effectué en ajoutant le mot-clé optionnel "*EnableMultiProcessing*", mis
480 à "*1*" ou à "*True*". Ce mot-clé est inclus à la commande
481 "*SCRIPTWITHONEFUNCTION*" dans la définition de l'opérateur par interface
482 graphique, ou aux "*Parameters*" accompagnant la commande "*OneFunction*" par
483 interface textuelle. Par défaut, ce mode parallèle est désactivé
484 ("*EnableMultiProcessing=0*"). Le mode parallèle utilise uniquement des
485 ressources locales (à la fois multi-coeurs ou multi-processeurs) de
486 l'ordinateur sur lequel l'exécution est en train de se dérouler, demandant par
487 défaut autant de ressources que disponible. Si nécessaire, on peut réduire les
488 ressources disponibles en limitant le nombre possible de processus parallèles
489 grâce au mot-clé optionnel "*NumberOfProcesses*", que l'on met au nombre
490 maximal souhaité (ou à "*0*" pour le contrôle automatique, qui est la valeur
493 Les principales conditions pour réaliser ces calculs parallèles viennent de la
494 fonction définie par l'utilisateur, qui représente l'opérateur direct. Cette
495 fonction doit au moins être "thread safe" pour être exécutée dans un
496 environnement Python parallèle (notions au-delà du cadre de ce paragraphe). Il
497 n'est pas évident de donner des règles générales, donc il est recommandé, à
498 l'utilisateur qui active ce parallélisme interne, de vérifier soigneusement sa
499 fonction et les résultats obtenus.
501 D'un point de vue utilisateur, certaines conditions, qui doivent être réunies
502 pour mettre en place des calculs parallèles pour les approximations des
503 opérateurs tangent et adjoint, sont les suivantes :
505 #. La dimension du vecteur d'état est supérieure à 2 ou 3.
506 #. Le calcul unitaire de la fonction utilisateur directe "dure un certain temps", c'est-à-dire plus que quelques minutes.
507 #. 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).
508 #. 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.
509 #. 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.
511 Si ces conditions sont satisfaites, l'utilisateur peut choisir d'activer le
512 parallélisme interne pour le calcul des dérivées numériques. Malgré la
513 simplicité d'activation, obtenue en définissant une variable seulement,
514 l'utilisateur est fortement invité à vérifier les résultats de ses calculs. Il
515 faut au moins les effectuer une fois avec le parallélisme activé, et une autre
516 fois avec le parallélisme désactivé, pour comparer les résultats. Si cette mise
517 en oeuvre échoue à un moment ou à un autre, il faut savoir que ce schéma de
518 parallélisme fonctionne pour des codes complexes, comme *Code_Aster* dans
519 *SalomeMeca* [SalomeMeca]_ par exemple. Donc, si cela ne marche pas dans votre
520 cas, vérifiez bien votre fonction d'opérateur avant et pendant l'activation du
525 en cas de doute, il est recommandé de NE PAS ACTIVER ce parallélisme.
527 On rappelle aussi qu'il faut choisir dans YACS un container par défaut de type
528 "*multi*" pour le lancement du schéma, pour permettre une exécution
529 véritablement parallèle.
531 .. _subsection_new_adao_version:
533 Passer d'une version d'ADAO à une nouvelle
534 ------------------------------------------
536 .. index:: single: Version
538 Le module ADAO et ses fichiers de cas ".comm" sont identifiés par des versions,
539 avec des caractéristiques "Major", "Minor" et "Revision". Une version
540 particulière est numérotée "Major.Minor.Revision", avec un lien fort avec la
541 numérotation de la plateforme SALOME.
543 Chaque version "Major.Minor.Revision" du module ADAO peut lire les fichiers de
544 cas ADAO de la précédente version mineure "Major.Minor-1.*". En général, elle
545 peut aussi lire les fichiers de cas de toutes les versions mineures "Major.*.*"
546 d'une branche majeure, mais ce n'est pas obligatoirement vrai pour toutes les
547 commandes ou tous les mots-clés. En général aussi, un fichier de cas ADAO d'une
548 version ne peut pas être lu par une précédente version mineure ou majeure du
551 Passer de la version 9.x à la 9.y avec y > x
552 ++++++++++++++++++++++++++++++++++++++++++++
554 Il n'y a pas d'incompatibilité connue pour les fichiers de cas ADAO. La
555 procédure de montée en version consiste à lire l'ancien fichier de cas ADAO
556 avec le nouveau module SALOME/ADAO, et à l'enregistrer avec un nouveau nom.
558 Passer de la version 8.5 à la 9.2
559 +++++++++++++++++++++++++++++++++
561 Il n'y a pas d'incompatibilité connue pour les fichiers de cas ADAO. La
562 procédure de montée en version consiste à lire l'ancien fichier de cas ADAO
563 avec le nouveau module SALOME/ADAO, et à l'enregistrer avec un nouveau nom.
565 Par contre, il peut se présenter des incompatibilités provenant de fichiers
566 scripts utilisateurs qui n'auraient pas une syntaxe compatible avec Python 3.
567 L'erreur la plus immédiate est l'usage de l'impression "*print*" avec la
568 syntaxe "*commande*" au lieu de la syntaxe fonctionnelle "*print(...)*". Dans
569 ce cas, il est suggéré de corriger la syntaxe des fichiers utilisateurs dans
570 l'environnement 8 avant de passer en environnement 9.
572 Passer de la version 8.x à la 8.y avec y > x
573 ++++++++++++++++++++++++++++++++++++++++++++
575 Il n'y a pas d'incompatibilité connue pour les fichiers de cas ADAO. La
576 procédure de montée en version consiste à lire l'ancien fichier de cas ADAO
577 avec le nouveau module SALOME/ADAO, et à l'enregistrer avec un nouveau nom.
579 Pour faciliter les futures évolutions, il est fortement recommandé de veiller à
580 ce que vos fichiers scripts utilisateurs utilisent une syntaxe compatible avec
581 Python 2 et avec Python 3. En particulier, on recommande d'utiliser la syntaxe
582 fonctionnelle pour les "*print*" et non pas la syntaxe "*commande*", comme par
588 print( "x = %s %s"%(str(x),str(unit)) )
595 print( "x = {0} {1}".format(str(x),str(unit)) )
600 # Python 2 uniquement
604 Passer de la version 7.8 à la 8.1
605 +++++++++++++++++++++++++++++++++
607 Il n'y a pas d'incompatibilité connue pour les fichiers de cas ADAO. La
608 procédure de montée en version consiste à lire l'ancien fichier de cas ADAO
609 avec le nouveau module SALOME/ADAO, et à l'enregistrer avec un nouveau nom.
611 Passer de la version 7.x à la 7.y avec y > x
612 ++++++++++++++++++++++++++++++++++++++++++++
614 Il n'y a pas d'incompatibilité connue pour les fichiers de cas ADAO. La
615 procédure de montée en version consiste à lire l'ancien fichier de cas ADAO
616 avec le nouveau module SALOME/ADAO, et à l'enregistrer avec un nouveau nom.
618 Passer de la version 6.6 à la 7.2
619 +++++++++++++++++++++++++++++++++
621 Il n'y a pas d'incompatibilité connue pour les fichiers de cas ADAO. La
622 procédure de montée en version consiste à lire l'ancien fichier de cas ADAO avec
623 le nouveau module SALOME/ADAO, et à l'enregistrer avec un nouveau nom.
625 Il y a une incompatibilité introduite dans les fichiers de script de
626 post-processing ou d'observers. L'ancienne syntaxe pour interroger un objet
627 résultat, comme celui d'analyse "*Analysis*" (fourni dans un script à travers le
628 mot-clé "*UserPostAnalysis*"), était par exemple :
631 Analysis = ADD.get("Analysis").valueserie(-1)
632 Analysis = ADD.get("Analysis").valueserie()
634 La nouvelle syntaxe est entièrement compatible avec celle (classique) pour les
635 objets de type liste ou tuple :
638 Analysis = ADD.get("Analysis")[-1]
639 Analysis = ADD.get("Analysis")[:]
641 Les scripts de post-processing doivent être modifiés.
643 Passer de la version 6.x à la 6.y avec y > x
644 ++++++++++++++++++++++++++++++++++++++++++++
646 Il n'y a pas d'incompatibilité connue pour les fichiers de cas ADAO. La
647 procédure de montée en version consiste à lire l'ancien fichier de cas ADAO avec
648 le nouveau module SALOME/ADAO, et à l'enregistrer avec un nouveau nom.
650 Il y a une incompatibilité introduite dans les fichiers de script d'opérateur,
651 lors de la dénomination des opérateurs élémentaires utilisés pour l'opérateur
652 d'observation par script. Les nouveaux noms requis sont "*DirectOperator*",
653 "*TangentOperator*" et "*AdjointOperator*", comme décrit dans la quatrième
654 partie du chapitre :ref:`section_reference`. Les fichiers de script d'opérateur
655 doivent être modifiés.
657 .. [#] Pour de plus amples informations sur YACS, voir le *module YACS* et son aide intégrée disponible dans le menu principal *Aide* de l'environnement SALOME.