2 Copyright (C) 2008-2024 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 et interopérabilité
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 .. _section_advanced_convert_JDC:
38 Convertir et exécuter un fichier de commandes ADAO (JDC) par l'intermédiaire d'un script Shell
39 ----------------------------------------------------------------------------------------------
41 Il est possible de convertir et exécuter une fichier de commandes ADAO (JDC, ou
42 paire de fichiers ".comm/.py", qui se trouvent dans le répertoire ``<Répertoire
43 du fichier JDC ADAO>``) automatiquement en utilisant un script de commandes
44 Shell "type" contenant toutes les étapes requises. Si la commande principale de
45 lancement de SALOME, nommée ``salome``, n'est pas couramment accessible dans un
46 terminal standard, l'utilisateur doit savoir où se trouvent les principaux
47 fichiers de lancement de SALOME, et en particulier ce fichier ``salome``. Le
48 répertoire dans lequel ce fichier réside est symboliquement nommé ``<Répertoire
49 principal d'installation de SALOME>`` et doit être remplacé par le bon dans le
50 modèle "type" de fichier Shell.
52 Lorsqu'un fichier de commande ADAO est construit par l'interface d'édition
53 graphique d'ADAO et est enregistré, s'il est nommé par exemple
54 "EtudeAdao1.comm", alors un fichier compagnon nommé "EtudeAdao1.py" est
55 automatiquement créé dans le même répertoire. Il est nommé ``<Fichier Python
56 ADAO>`` dans le modèle "type", et il est converti vers YACS comme un ``<Schéma
57 xml YACS ADAO>`` sous la forme d'un fichier en ".xml" nommé "EtudeAdao1.xml".
58 Ensuite, ce dernier peut être exécuté en mode console en utilisant l'ordre
59 standard du mode console de YACS (voir la documentation YACS pour de plus amples
62 Dans tous les exemples de fichiers de commandes Shell de lancement, on choisit
63 de démarrer et arrêter le serveur d'application SALOME dans le même script. Ce
64 n'est pas indispensable, mais c'est utile pour éviter des sessions SALOME en
67 L'exemple le plus simple consiste uniquement à lancer l'exécution d'un schéma
68 YACS donné, qui a préalablement été généré par l'utilisateur en interface
69 graphique. Dans ce cas, en ayant pris soin de remplacer les textes contenus
70 entre les symboles ``<...>``, il suffit d'enregistrer le script de commandes
75 USERDIR="<Répertoire du fichier JDC ADAO>"
76 SALOMEDIR="<Répertoire principal d'installation de SALOME>"
77 $SALOMEDIR/salome start -k -t
78 $SALOMEDIR/salome shell -- "driver $USERDIR/<Schéma xml YACS ADAO>"
79 $SALOMEDIR/salome shell killSalome.py
81 Il faut ensuite le rendre exécutable pour l'exécuter.
83 Un exemple un peu plus complet consiste à lancer l'exécution d'un schéma YACS
84 indiqué par l'utilisateur, en ayant préalablement vérifié sa disponibilité. Pour
85 cela, en remplaçant le texte ``<Répertoire principal d'installation de
86 SALOME>``, il suffit d'enregistrer le script de commandes Shell suivant :
92 echo -e "\nUsage: $0 <Schéma xml YACS ADAO>\n"
97 if (test ! -e $USERFILE)
99 echo -e "\nErreur : le fichier XML nommé $USERFILE n'existe pas.\n"
102 SALOMEDIR="<Répertoire principal d'installation de SALOME>"
103 $SALOMEDIR/salome start -k -t
104 $SALOMEDIR/salome shell -- "driver $USERFILE"
105 $SALOMEDIR/salome shell killSalome.py
108 Un autre exemple de script consiste à ajouter la conversion du fichier de
109 commandes ADAO (JDC, ou paire de fichiers ".comm/.py") en un schéma YACS associé
110 (fichier ".xml"). A la fin du script, on choisit aussi de supprimer le fichier
111 de ``<Schéma xml YACS ADAO>`` car c'est un fichier généré. Pour cela, en ayant
112 bien pris soin de remplacer le texte ``<Répertoire principal d'installation de
113 SALOME>``, il suffit d'enregistrer le script de commandes Shell suivant :
119 echo -e "\nUsage: $0 <Cas .comm/.py ADAO>\n"
123 F=`basename -s .comm $1`
124 F=`basename -s .py $F`
127 if (test ! -e $USERFILE.py)
129 echo -e "\nErreur : le fichier PY nommé $USERFILE.py n'existe pas.\n"
132 SALOMEDIR="<Répertoire principal d'installation de SALOME>"
133 $SALOMEDIR/salome start -k -t
134 $SALOMEDIR/salome shell -- "python $SALOMEDIR/bin/AdaoYacsSchemaCreator.py $USERFILE.py $USERFILE.xml"
135 $SALOMEDIR/salome shell -- "driver $USERFILE.xml"
136 $SALOMEDIR/salome shell killSalome.py
140 Dans tous les cas, les sorties standard et d'erreur se font dans le terminal de
143 .. _section_advanced_YACS_tui:
145 Exécuter un schéma de calcul ADAO dans YACS en utilisant le mode "texte" (TUI YACS)
146 -----------------------------------------------------------------------------------
148 Cette section décrit comment exécuter en mode TUI (Text User Interface) YACS un
149 schéma de calcul YACS, obtenu dans l'interface graphique par la fonction
150 "*Exporter vers YACS*" d'ADAO. Cela utilise le mode texte standard de YACS, qui
151 est rapidement rappelé ici (voir la documentation YACS pour de plus amples
152 informations) à travers un exemple simple. Comme décrit dans la documentation,
153 un schéma XML peut être chargé en python. On donne ici une séquence complète de
154 commandes pour tester la validité du schéma avant de l'exécuter, ajoutant des
155 lignes supplémentaires initiales pour charger de manière explicite le catalogue
156 de types pour éviter d'obscures difficultés :
159 #-*- coding: utf-8 -*-
163 SALOMERuntime.RuntimeSALOME_setRuntime()
165 r = pilot.getRuntime()
166 xmlLoader = loader.YACSLoader()
167 xmlLoader.registerProcCataLoader()
169 catalogAd = r.loadCatalog("proc", "<Schéma xml YACS ADAO>")
170 r.addCatalog(catalogAd)
175 p = xmlLoader.load("<Schéma xml YACS ADAO>")
177 print("IO exception:",ex)
179 logger = p.getLogger("parser")
180 if not logger.isEmpty():
181 print("The imported file has errors :")
182 print(logger.getStr())
185 print("Le schéma n'est pas valide et ne peut pas être exécuté")
186 print(p.getErrorReport())
188 info=pilot.LinkInfo(pilot.LinkInfo.ALL_DONT_STOP)
189 p.checkConsistency(info)
190 if info.areWarningsOrErrors():
191 print("Le schéma n'est pas cohérent et ne peut pas être exécuté")
192 print(info.getGlobalRepr())
194 e = pilot.ExecutorSwig()
196 if p.getEffectiveState() != pilot.DONE:
197 print(p.getErrorReport())
199 Cette démarche permet par exemple d'éditer le schéma YACS XML en mode texte TUI,
200 ou de rassembler les résultats pour un usage ultérieur.
202 .. _section_advanced_R:
204 Exécuter un calcul ADAO en environnement R en utilisant l'interface TUI ADAO
205 ----------------------------------------------------------------------------
208 .. index:: single: rPython
209 .. index:: single: reticulate
211 Pour étendre les possibilités d'analyse et de traitement, il est possible
212 d'utiliser les calculs ADAO dans l'environnement **R** (voir [R]_ pour plus de
213 détails). Ce dernier est disponible dans SALOME en lançant l'interpréteur R
214 dans le shell "``salome shell``". Il faut de plus disposer, en R, du package
215 "*rPython*" (ou du package "*reticulate*", plus récent), qui peut si nécessaire
216 être installé par l'utilisateur à l'aide de la commande R suivante :
219 #-*- coding: utf-8 -*-
221 # IMPORTANT : à exécuter dans l'interpréteur R
222 # --------------------------------------------
223 install.packages("rPython")
225 On se reportera à la documentation [GilBellosta15]_ pour de plus amples
226 renseignements sur ce package.
228 Les calculs ADAO définis en interface textuelle (API/TUI, voir la
229 :ref:`section_tui`) peuvent alors être interprétés depuis l'environnement R, en
230 utilisant des données et des informations depuis R. La démarche est illustrée
231 sur :ref:`subsection_tui_example`, proposé dans la description de l'interface
232 API/TUI. Dans l'interpréteur R, on peut exécuter les commandes suivantes,
233 directement issues de l'exemple simple :
236 #-*- coding: utf-8 -*-
238 # IMPORTANT : à exécuter dans l'interpréteur R
239 # --------------------------------------------
242 from numpy import array
243 from adao import adaoBuilder
244 case = adaoBuilder.New()
245 case.set( 'AlgorithmParameters', Algorithm='3DVAR' )
246 case.set( 'Background', Vector=[0, 1, 2] )
247 case.set( 'BackgroundError', ScalarSparseMatrix=1.0 )
248 case.set( 'Observation', Vector=array([0.5, 1.5, 2.5]) )
249 case.set( 'ObservationError', DiagonalSparseMatrix='1 1 1' )
250 case.set( 'ObservationOperator', Matrix='1 0 0;0 2 0;0 0 3' )
251 case.set( 'Observer', Variable='Analysis', Template='ValuePrinter' )
255 dont le résultat est :
258 Analysis [ 0.25000264 0.79999797 0.94999939]
260 Dans la rédaction des calculs ADAO exécutés depuis R, il convient d'être très
261 attentif au bon usage des guillemets simples et doubles, qui ne doivent pas
262 collisionner entre les deux langages.
264 Les données peuvent venir l'environnement R et doivent être rangées dans des
265 variables correctement assignées, pour être utilisées ensuite en Python pour
266 ADAO. On se reportera à la documentation [GilBellosta15]_ pour la mise en
267 oeuvre. On peut transformer l'exemple ci-dessus pour utiliser des données
268 provenant de R pour alimenter les trois variables d'ébauche, d'observation et
269 d'opérateur d'observation. On récupère à la fin l'état optimal dans une variable
270 R aussi. Les autres lignes sont identiques. L'exemple devient ainsi :
273 #-*- coding: utf-8 -*-
275 # IMPORTANT : à exécuter dans l'interpréteur R
276 # --------------------------------------------
281 yo <- c(0.5, 1.5, 2.5)
282 h <- '1 0 0;0 2 0;0 0 3'
287 python.assign( "xb", xb )
288 python.assign( "yo", yo )
289 python.assign( "h", h )
291 from numpy import array
292 from adao import adaoBuilder
293 case = adaoBuilder.New()
294 case.set( 'AlgorithmParameters', Algorithm='3DVAR' )
295 case.set( 'Background', Vector=xb )
296 case.set( 'BackgroundError', ScalarSparseMatrix=1.0 )
297 case.set( 'Observation', Vector=array(yo) )
298 case.set( 'ObservationError', DiagonalSparseMatrix='1 1 1' )
299 case.set( 'ObservationOperator', Matrix=str(h) )
300 case.set( 'Observer', Variable='Analysis', Template='ValuePrinter' )
302 xa = list(case.get('Analysis')[-1])
307 xa <- python.get("xa")
309 On remarquera les conversions explicite de type ``str`` et ``list`` pour
310 s'assurer que les données sont bien transmises en type standards connus du
311 package "*rPython*". De plus, ce sont les données qui peuvent être transférées
312 entre les deux langages, et pas des fonctions ou méthodes. Il convient donc
313 d'élaborer en Python de manière générique les fonctions d'exécution requises par
314 ADAO, et de leur transmettre ensuite de manière correcte les données disponibles
317 Les cas plus complets, proposés dans les :ref:`subsection_tui_advanced`, peuvent
318 être exécutés de la même manière, et ils donnent le même résultat que dans
319 l'interface API/TUI en Python standard.
321 .. _section_advanced_eficas_gui:
323 Utiliser l'interface graphique EFICAS d'ADAO comme une commande TUI d'ADAO
324 --------------------------------------------------------------------------
326 Pour faciliter l'édition rapide avec EFICAS d'ADAO d'un fichier de commandes
327 ADAO (JDC, ou paire de fichiers ".comm/.py", qui se trouvent ensemble dans un
328 répertoire d'étude de l'utilisateur), on peut lancer l'interface graphique
329 directement depuis l'interpréteur Python. Pour cela, dans un interpréteur
330 Python obtenu depuis le "SALOME shell", on utilise les commandes suivantes :
333 from adao import adaoBuilder
336 Pour mémoire, le moyen le plus simple d'obtenir un interpréteur Python inclu
337 dans une session "SALOME shell" est de lancer la commande suivante dans un
340 $SALOMEDIR/salome shell -- python
342 avec ``SALOMEDIR`` le ``<Répertoire principal d'installation de SALOME>``.
344 Si nécessaire, des messages explicites permettent d'identifier les variables
345 d'environnement requises qui seraient absentes. **Cette commande ne doit
346 néanmoins pas être lancée dans la console Python de SALOME** (car dans ce cas
347 il suffit d'activer le module puisque l'on est déjà dans l'interface
348 graphique...) ou dans une installation Python indépendante, mais elle peut
349 l'être dans une session "SALOME shell" obtenue depuis le menu
350 "Outils/Extensions" de SALOME.
352 .. _section_advanced_execution_mode:
354 Changer le mode par défaut d'exécution de noeuds dans YACS
355 ----------------------------------------------------------
357 .. index:: single: YACS
358 .. index:: single: ExecuteInContainer
360 Diverses raisons peuvent conduire à vouloir modifier le mode par défaut
361 d'exécution de noeuds dans YACS (voir [#]_ pour le bon usage de ces
362 possibilités). Cela peut être pour des raisons de performances, ou par exemple
363 pour des raisons de conflits de ressources.
365 On peut vouloir utiliser ce changement de mode d'exécution pour étendre l'usage
366 des ressources de calcul locales ou pour déporter les calculs d'un noeud qui le
367 nécessite. C'est en particulier le cas d'un noeud qui devrait utiliser une
368 ressource de simulation disponible sur un cluster par exemple.
370 Par ailleurs, les divers calculs qui sont menés (opérateurs fournis par
371 l'utilisateur, fonctions de restitution des résultats, etc.) peuvent aussi
372 présenter des conflits s'ils sont exécutés dans un processus unique, et en
373 particulier dans le processus principal de SALOME. C'est le fonctionnement par
374 défaut de YACS pour des raisons de performances et de simplicité. Il est
375 néanmoins recommandé de changer ce fonctionnement lorsque l'on rencontre des
376 instabilités d'exécution ou des messages d'erreur au niveau de l'interface
379 Dans tous les cas, dans le schéma YACS en édition, il suffit de changer le mode
380 d'exécution du ou des noeuds qui le nécessitent. Il faut les exécuter dans un
381 nouveau conteneur créé pour l'occasion (il ne suffit pas d'utiliser le
382 conteneur par défaut, il faut explicitement en créer un nouveau) et dont les
383 caractéristiques sont adaptées à l'usage visé. La démarche est donc la suivante
386 #. Créer un nouveau conteneur YACS, par utilisation du menu contextuel des "*Containers*" dans la vue arborescente du schéma YACS (usuellement à gauche),
387 #. 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,
388 #. Sélectionner graphiquement dans la vue centrale le noeud dont on veut changer le mode d'exécution,
389 #. 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*"),
390 #. Enregistrer le schéma YACS modifié.
392 On peut répéter cette démarche pour chaque noeud qui le nécessite, en
393 réutilisant le même nouveau conteneur pour tous les noeuds, ou en créant un
394 nouveau conteneur pour chaque noeud.
396 Une manière plus générale pour imposer une exécution globale dans un conteneur
397 séparé est d'utiliser une variable nommée "*ExecuteInContainer*". Cette
398 variable est disponible pour les cas ADAO via l'interface graphique (GUI) ou
399 l'interface scriptée (elle est par exemple présente par défaut dans la
400 :ref:`section_ref_assimilation_keywords`).
404 Ce changement de mode d'exécution est extrêmement puissant et souple. Il est
405 donc recommandé à l'utilisateur à la fois de l'utiliser, et en même temps
406 d'être attentif à l'interaction des différents choix qu'il effectue, pour
407 éviter par exemple une dégradation involontaire des performances, ou des
408 conflits informatiques compliqués à diagnostiquer.
410 .. _section_advanced_observer:
412 Obtenir des informations sur des variables spéciales au cours d'un calcul ADAO
413 ------------------------------------------------------------------------------
415 .. index:: single: Observer
416 .. index:: single: Observer Template
418 Certaines variables spéciales internes à l'optimisation, utilisées au cours des
419 calculs, peuvent être surveillées durant un calcul ADAO. Ces variables peuvent
420 être affichées, tracées, enregistrées, etc. C'est réalisable en utilisant des
421 "*observer*", qui sont des commandes rassemblées sous forme de scripts, chacun
422 associé à une variable.
424 Des modèles ("templates") sont disponibles lors de l'édition le cas ADAO dans
425 l'éditeur graphique. Ces scripts simples peuvent être adaptés par l'utilisateur,
426 soit dans l'étape d'édition intégrée, ou dans l'étape d'édition avant
427 l'exécution, pour améliorer l'adaptation du calcul ADAO dans le superviseur
428 d'exécution de SALOME.
430 Pour mettre en oeuvre ces "*observer*" de manière efficace, on se reportera aux
431 :ref:`section_ref_observers_requirements`.
433 .. _section_advanced_logging:
435 Obtenir plus d'information lors du déroulement d'un calcul
436 ----------------------------------------------------------
438 .. index:: single: Logging
439 .. index:: single: Debug
440 .. index:: single: setDebug
442 Lors du déroulement d'un calcul, des données et messages utiles sont
443 disponibles. Il y a deux manières d'obtenir ces informations.
445 La première, et la manière préférentielle, est d'utiliser la variable interne
446 "*Debug*" disponible dans chaque cas ADAO. Elle est atteignable dans
447 l'interface graphique d'édition (GUI) du module comme dans l'interface
448 textuelle (TUI). La mettre à "*1*" permet d'envoyer des messages dans la
449 fenêtre de sortie de l'exécution dans YACS ("*YACS Container Log*").
451 La seconde consiste à utiliser le module Python natif "*logging*" (voir la
452 documentation Python http://docs.python.org/library/logging.html pour de plus
453 amples informations sur ce module). Dans l'ensemble du schéma YACS,
454 principalement à travers les entrées sous forme de scripts, l'utilisateur peut
455 fixer le niveau de logging en accord avec les besoins d'informations détaillées.
456 Les différents niveaux de logging sont : "*DEBUG*", "*INFO*", "*WARNING*",
457 "*ERROR*", "*CRITICAL*". Toutes les informations associées à un niveau sont
458 affichées à tous les niveaux au-dessus de celui-ci (inclus). La méthode la plus
459 facile consiste à changer le niveau de surveillance en utilisant les lignes
464 logging.getLogger().setLevel(logging.DEBUG)
466 Le niveau par défaut standard de surveillance par logging est "*WARNING*", le
467 niveau par défaut dans le module ADAO est "*INFO*".
469 Il est aussi recommandé d'inclure de la surveillance par logging ou des
470 mécanismes de débogage dans le code de simulation physique de l'utilisateur, et
471 de les exploiter en conjonction avec les deux méthodes précédentes. Néanmoins,
472 il convient d'être prudent dans le stockage de "grosses" variables car cela
473 coûte du temps ou de la mémoire, quel que soit le niveau de surveillance choisi
474 (c'est-à-dire même si ces variables ne sont pas affichées).
476 .. _subsection_ref_parallel_df:
478 Accélérer les calculs de dérivées numériques en utilisant un mode parallèle
479 ---------------------------------------------------------------------------
481 .. index:: single: EnableMultiProcessing
482 .. index:: single: NumberOfProcesses
484 Lors de la définition d'un opérateur, comme décrit dans le chapitre des
485 :ref:`section_ref_operator_requirements`, l'utilisateur peut choisir la forme
486 fonctionnelle "*ScriptWithOneFunction*". Cette forme conduit explicitement à
487 approximer les opérateurs tangent et adjoint (s'ils sont nécessaires) par un
488 calcul par différences finies. Cela requiert de nombreux appels à l'opérateur
489 direct (qui est la fonction définie par l'utilisateur), au moins autant de fois
490 que la dimension du vecteur d'état. Ce sont ces appels qui peuvent être
491 potentiellement exécutés en parallèle.
493 Sous certaines conditions (décrites juste après), il est possible d'accélérer
494 les calculs de dérivées numériques en utilisant un mode parallèle pour
495 l'approximation par différences finies. Lors de la définition d'un cas ADAO,
496 c'est effectué en ajoutant le mot-clé optionnel "*EnableMultiProcessing*", mis
497 à "*1*" ou à "*True*". Ce mot-clé est inclus à la commande
498 "*SCRIPTWITHONEFUNCTION*" dans la définition de l'opérateur par interface
499 graphique, ou aux "*Parameters*" accompagnant la commande "*OneFunction*" par
500 interface textuelle. Par défaut, ce mode parallèle est désactivé
501 ("*EnableMultiProcessing=0*"). Le mode parallèle utilise uniquement des
502 ressources locales (à la fois multi-coeurs ou multi-processeurs) de
503 l'ordinateur sur lequel l'exécution est en train de se dérouler, demandant par
504 défaut autant de ressources que disponible. Si nécessaire, on peut réduire les
505 ressources disponibles en limitant le nombre possible de processus parallèles
506 grâce au mot-clé optionnel "*NumberOfProcesses*", que l'on met au nombre
507 maximal souhaité (ou à "*0*" pour le contrôle automatique, qui est la valeur
510 Les principales conditions pour réaliser ces calculs parallèles viennent de la
511 fonction définie par l'utilisateur, qui représente l'opérateur direct. Cette
512 fonction doit au moins être "thread safe" pour être exécutée dans un
513 environnement Python parallèle (notions au-delà du cadre de ce paragraphe). Il
514 n'est pas évident de donner des règles générales, donc il est recommandé, à
515 l'utilisateur qui active ce parallélisme interne, de vérifier soigneusement sa
516 fonction et les résultats obtenus.
518 D'un point de vue utilisateur, certaines conditions, qui doivent être réunies
519 pour mettre en place des calculs parallèles pour les approximations des
520 opérateurs tangent et adjoint, sont les suivantes :
522 #. La dimension du vecteur d'état est supérieure à 2 ou 3.
523 #. Le calcul unitaire de la fonction utilisateur directe "dure un certain temps", c'est-à-dire plus que quelques minutes.
524 #. 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).
525 #. 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.
526 #. 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.
528 Si ces conditions sont satisfaites, l'utilisateur peut choisir d'activer le
529 parallélisme interne pour le calcul des dérivées numériques. Malgré la
530 simplicité d'activation, obtenue en définissant une variable seulement,
531 l'utilisateur est fortement invité à vérifier les résultats de ses calculs. Il
532 faut au moins les effectuer une fois avec le parallélisme activé, et une autre
533 fois avec le parallélisme désactivé, pour comparer les résultats. Si cette mise
534 en oeuvre échoue à un moment ou à un autre, il faut savoir que ce schéma de
535 parallélisme fonctionne pour des codes complexes, comme *Code_Aster* dans
536 *SalomeMeca* [SalomeMeca]_ par exemple. Donc, si cela ne marche pas dans votre
537 cas, vérifiez bien votre fonction d'opérateur avant et pendant l'activation du
542 En cas de doute, il est recommandé de NE PAS ACTIVER ce parallélisme.
544 On rappelle aussi qu'il faut choisir dans YACS un container par défaut de type
545 "*multi*" pour le lancement du schéma, pour permettre une exécution
546 véritablement parallèle.
548 .. _subsection_iterative_convergence_control:
550 Contrôler la convergence pour des cas de calculs et algorithmes itératifs
551 -------------------------------------------------------------------------
553 .. index:: single: Convergence
554 .. index:: single: Convergence itérative
556 Il existe de nombreuses raisons de vouloir contrôler la convergence des cas de
557 calculs ou algorithmes disponibles dans ADAO. Par exemple, on peut vouloir de
558 la *reproductibilité* des solutions optimales, une *qualité* certifiée, une
559 *stabilité* des conditions de recherche optimale en études, une *économie du
560 temps de calcul* global, etc. De plus, on remarque que les méthodes utilisées
561 dans ADAO sont fréquemment itératives, renforçant l'intérêt de ce contrôle de
564 Par défaut, **les cas de calculs ou algorithmes disponibles dans ADAO donnent
565 accès à de multiples moyens de contrôler leur convergence, spécialement adaptés
566 à chaque méthode**. Ces moyens de contrôle sont issus de la théorie classique
567 de l'optimisation et des capacités de chaque algorithme. Les valeurs par défaut
568 des contrôles sont choisies pour assurer une recherche optimale de qualité sur
569 des fonctions de simulation aux comportements "*standards*" (régularité,
570 qualité physique et numérique...), ce qui n'est pas forcément la propriété
571 principale des simulations réelles en raison de contraintes variées. Il est
572 donc tout à fait normal d'adapter les critères de convergence aux cas d'études
573 rencontrés, mais c'est une démarche d'expertise que d'établir la bonne
576 Il existe des manières assez génériques de contrôler la recherche optimale et
577 la convergence des algorithmes. On en indique ici les plus utiles, de manière
578 non exhaustive, et avec l'importante réserve qu'il y a fréquemment des
579 exceptions aux recommandations formulées. Pour aller plus loin, ces
580 informations génériques sont impérativement à compléter par les informations
581 spécifiques à chaque algorithme ou cas de calcul, indiquées dans la
582 documentation des différents :ref:`section_reference_assimilation`.
584 **Un premier moyen est de limiter le nombre d'itérations par défaut dans les
585 processus de recherches itératives**. Même si ce n'est pas la meilleure manière
586 théorique de contrôler l'algorithme, elle est très efficace dans un processus
587 d'étude réelle. Pour cela, le mot-clé "*MaximumNumberOfIterations*" existe dans
588 tous les cas de calculs qui le supportent, et sa valeur par défaut est
589 usuellement fixée à un équivalent de l'infini pour que ce ne soit pas le
590 critère d'arrêt. C'est le cas pour les calculs à base de méthodes
591 variationnelles comme les :ref:`section_ref_algorithm_3DVAR`,
592 :ref:`section_ref_algorithm_4DVAR` et
593 :ref:`section_ref_algorithm_NonLinearLeastSquares`, mais c'est aussi le cas
594 pour d'autres comme les :ref:`section_ref_algorithm_DerivativeFreeOptimization`
595 ou :ref:`section_ref_algorithm_QuantileRegression`. Dans la pratique, on
596 recommande une valeur comprise entre 10 et 30 pour rendre ce paramètre de
597 contrôle effectif et obtenir quand même une recherche optimale de bonne
598 qualité. Pour une recherche optimale de qualité suffisante, il convient de ne
599 pas fixer cette restriction trop strictement, c'est-à-dire qu'une limite à 30
600 itérations devrait être plus favorable qu'une limite à 10 itérations.
602 **Un second moyen de contrôle de la convergence est d'adapter la tolérance de
603 décroissance relative dans la minimisation de la fonctionnelle de coût
604 considérée**. Cette tolérance est contrôlée par le mot-clé
605 "*CostDecrementTolerance*" dans les algorithmes qui le supportent. La valeur
606 par défaut est plutôt stricte, elle est choisie pour un contrôle théorique de
607 convergence lorsque les simulations numériques sont d'une qualité numérique
608 importante. Dans la pratique, elle peut être adaptée sans hésitation pour
609 valoir entre :math:`10^{-5}` et :math:`10^{-2}`. Cette adaptation permet en
610 particulier de réduire ou d'éviter les difficultés de recherche optimale qui se
611 manifestent par de nombreuses itérations successives portant sur des états
614 **Un troisième moyen d'améliorer la convergence est d'adapter le réglage par
615 défaut de l'approximation par différences finies, essentiellement pour
616 l'opérateur d'observation et une représentation en mono-opérateur**. Le
617 contrôle de cette propriété se fait à l'aide du mot-clé
618 "*DifferentialIncrement*" qui paramètre la définition à l'aide de la
619 :ref:`section_ref_operator_one`. Sa valeur par défaut est de :math:`10^{-2}`
620 (ou 1%), et il peut généralement être ajusté entre :math:`10^{-5}` et
621 :math:`10^{-3}` (même s'il est sage de vérifier soigneusement la pertinence de
622 sa valeur, il est aisé dans ADAO de modifier ce paramètre). Le critère de
623 convergence doit ensuite être ajusté de telle sorte qu'il ne surpasse pas
624 l'ordre de grandeur de cette approximation. En pratique, on peut se contenter
625 de fixer le critère "*CostDecrementTolerance*" à peu près à la même précision
626 (c'est-à-dire avec un ordre de grandeur de plus ou de moins) que le critère
627 "*DifferentialIncrement*". Ce moyen d'amélioration est aussi à compléter
628 d'analyses à l'aide des :ref:`section_ref_algorithm_LinearityTest` et
629 :ref:`section_ref_algorithm_GradientTest`.
631 Par expérience, il n'est *a priori* pas recommandé d'utiliser d'autres moyens
632 de contrôler la convergence, même s'il en existe. Ces ajustements de paramètres
633 sont simples à mettre en œuvre, et il est favorable de les essayer (en
634 expériences jumelles ou pas) car ils résolvent de nombreux problèmes rencontrés
637 .. [#] 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.