doc/fr/tui.rst

   1 ..
   2    Copyright (C) 2008-2015 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 .. index:: single: TUI
  25 .. index:: single: API/TUI
  26 .. _section_tui:
  27
  28 ================================================================================
  29 **[DocR]** Interface de programmation textuelle pour l'utilisateur (API/TUI)
  30 ================================================================================
  31
  32 .. warning::
  33
  34   dans sa présente version, cette interface de programmation textuelle (TUI) est
  35   expérimentale, et reste donc susceptible de changements dans les prochaines
  36   versions.
  37
  38 Cette section présente des méthodes avancées d'usage du module ADAO à l'aide de
  39 son interface de programmation textuelle (API/TUI). Cette interface permet de
  40 créer un objet de calcul de manière similaire à la construction d'un cas par
  41 l'interface graphique (GUI). Dans le cas où l'on désire réaliser à la main le
  42 cas de calcul TUI, on recommande de bien s'appuyer sur l'ensemble de la
  43 documentation du module ADAO, et de se reporter si nécessaire à l'interface
  44 graphique (GUI), pour disposer de l'ensemble des éléments permettant de
  45 renseigner correctement les commandes.
  46
  47 .. _subsection_tui_creating:
  48
  49 Création de cas de calcul TUI ADAO et exemples
  50 ----------------------------------------------
  51
  52 .. _subsection_tui_example:
  53
  54 Un exemple simple de création d'un cas de calcul TUI ADAO
  55 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
  56
  57 Pour introduire l'interface TUI, on commence par un exemple simple mais complet
  58 de cas de calcul ADAO. Toutes les données sont explicitement définies dans le
  59 corps du script pour faciliter la lecture. L'ensemble des commandes est le
  60 suivant::
  61
  62     from numpy import *
  63     import adaoBuilder
  64     case = adaoBuilder.New()
  65     case.set( 'AlgorithmParameters', Algorithm='3DVAR' )
  66     case.set( 'Background',          Vector=[0, 1, 2] )
  67     case.set( 'BackgroundError',     ScalarSparseMatrix=1.0 )
  68     case.set( 'Observation',         Vector=array([0.5, 1.5, 2.5]) )
  69     case.set( 'ObservationError',    DiagonalSparseMatrix='1 1 1' )
  70     case.set( 'ObservationOperator', Matrix='1 0 0;0 2 0;0 0 3' )
  71     case.set( 'Observer',            Variable="Analysis", Template="ValuePrinter" )
  72     case.execute()
  73
  74 Le résultat de l'exécution de ces commandes dans SALOME (dans le shell SALOME,
  75 dans la console Python de l'interface, ou par le menu d'exécution d'un script)
  76 est le suivant::
  77
  78     Analysis [ 0.25000264  0.79999797  0.94999939]
  79
  80 Création détaillée d'un cas de calcul TUI ADAO
  81 ++++++++++++++++++++++++++++++++++++++++++++++
  82
  83 On décrit ici plus en détail les différentes étapes de création d'un cas de
  84 calcul TUI ADAO. Les commandes elles-mêmes sont détaillées juste après dans
  85 l':ref:`subsection_tui_commands`.
  86
  87 L'initialisation et la création d'une étude se fait par les commandes suivantes,
  88 le nom ``case`` de l'objet du cas de calcul TUI ADAO étant quelconque, au choix
  89 de l'utilisateur::
  90
  91     from numpy import *
  92     import adaoBuilder
  93     case = adaoBuilder.New()
  94
  95 Il est recommandé d'importer par principe le module ``numpy``, sous cette forme
  96 particulière ``from ... import *``, pour faciliter ensuite son usage dans les
  97 commandes elle-mêmes.
  98
  99 Ensuite, le cas doit être construit par une préparation et un enregistrement des
 100 données définissant l'étude. L'ordre de ces commande n'a pas d'importance, il
 101 suffit que les concepts requis par l'algorithme utilisé soient présentes. On se
 102 reportera à :ref:`section_reference` et à ses sous-parties pour avoir le détail
 103 des commandes par algorithme. Ici, on définit successivement l'algorithme
 104 d'assimilation de données ou d'optimisation choisi et ses paramètres, puis
 105 l'ébauche :math:`\mathbf{x}^b` et sa covariance d'erreurs :math:`\mathbf{B}`, et
 106 enfin l'observation :math:`\mathbf{y}^o` et sa covariance d'erreurs
 107 :math:`\mathbf{R}`::
 108
 109     case.set( 'AlgorithmParameters', Algorithm='3DVAR' )
 110     #
 111     case.set( 'Background',          Vector=[0, 1, 2] )
 112     case.set( 'BackgroundError',     ScalarSparseMatrix=1.0 )
 113     #
 114     case.set( 'Observation',         Vector=array([0.5, 1.5, 2.5]) )
 115     case.set( 'ObservationError',    DiagonalSparseMatrix='1 1 1' )
 116
 117 On remarque que l'on peut donner en entrée des quantités vectorielles des objets
 118 de type ``list``, ``tuple``, ``array`` ou ``matrix`` de Numpy.
 119
 120 On doit ensuite définir les opérateurs :math:`H` d'observation et éventuellement
 121 :math:`M` d'évolution. Dans tous les cas, linéaire ou non-linéaire, on peut les
 122 définir comme des fonctions. Dans le cas simple d'un opérateur linéaire, on peut
 123 aussi le définir à l'aide de la matrice qui correspond à l'opérateur linéaire.
 124 Dans le cas présent le plus simple d'opérateur linéaire, on utilise la syntaxe
 125 suivante pour un opérateur de :math:`\mathbf{R}^3` sur lui-même::
 126
 127     case.ObservationOperator(Matrix = "1 0 0;0 2 0;0 0 3")
 128
 129 Dans le cas beaucoup plus courant d'un opérateur non-linéaire, il doit être
 130 préalablement disponible sous la forme d'une fonction Python connue dans
 131 l'espace de nommage courant. L'exemple suivant montre une fonction (qui réalise
 132 ici le même opérateur linéaire que ci-dessus) et l'enregistre dans le cas ADAO::
 133
 134     def fonction(x):
 135         import numpy
 136         __x = numpy.matrix(numpy.ravel(numpy.matrix(x))).T
 137         __H = numpy.matrix("1 0 0;0 2 0;0 0 3")
 138         return __H * __x
 139     #
 140     case.set( 'ObservationOperator',
 141         DirectFunction = fonction,
 142         Parameters = {"useApproximatedDerivatives":True},
 143         )
 144
 145 Pour connaître les résultats intermédiaire ou finaux du calcul du cas, on peut
 146 ajouter des observers, qui permettent d'associer l'exécution d'un script à une
 147 variable interne ou finale du calcul. On se reportera à la description de la
 148 manière d':ref:`section_advanced_observer`, et à la :ref:`section_reference`
 149 pour savoir quelles sont les quantités observables. Cette association
 150 d'observers avec une quantité existante se fait de manière similaire à la
 151 définition des données du calcul::
 152
 153     case.set( 'Observer', Variable="Analysis", Template="ValuePrinter" )
 154
 155 Enfin, lorsque toutes les informations requises sont disponibles dans le cas
 156 ``case`` de calcul ADAO, on peut en demander l'exécution de manière très
 157 simple dans l'environnement de l'interpréteur Python::
 158
 159     case.execute()
 160
 161 Au final, on obtient le script très compact proposé précédemment dans
 162 :ref:`subsection_tui_example`.
 163
 164 Fournir des données de calcul plus complexes
 165 ++++++++++++++++++++++++++++++++++++++++++++
 166
 167 Une telle interface s'écrivant en Python, il est possible d'utiliser toute la
 168 puissance du langage pour entrer des données plus complexes qu'une déclaration
 169 explicite.
 170
 171 L'enregistrement des données d'entrées supporte différents types de variables,
 172 mais surtout, ces entrées peuvent recevoir des variables courantes disponibles
 173 dans l'espace de nommage du script. Il est donc aisé d'utiliser des variables
 174 calculées préalablement ou obtenues par l'import de scripts "utilisateur". Si
 175 par exemple les observations sont disponibles sous la forme d'une liste dans un
 176 fichier Python externe nommé ``observations.py`` sous le nom ``table``, il
 177 suffit de réaliser les opérations suivantes pour enregistrer les observations
 178 dans le cas de calcul TUI ADAO::
 179
 180     from observations import table
 181     case.set( 'Observation', Vector=table )
 182
 183 La première ligne importe la variable ``table`` depuis le fichier externe, et la
 184 seconde enregistre directement cette table comme la donnée "*Observation*".
 185
 186 La simplicité de cet enregistrement montre bien la facilité d'obtenir les
 187 données de calcul depuis des sources externes, fichiers ou flux informatiques
 188 atteignables en Python. Comme d'habitude, il est recommandé à l'utilisateur de
 189 vérifier ses données avant de les enregistrer dans le cas de calcul TUI ADAO
 190 pour éviter les erreurs compliquées à corriger.
 191
 192 Obtenir et utiliser les résultats de calcul de manière plus riche
 193 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 194
 195 De la même manière, il est possible d'obtenir et traiter les résultats de calcul
 196 de manière plus riche, pour enchaîner sur des post-traitements après le calcul
 197 en TUI.
 198
 199 Les variables de résultats de calcul, ou les variables internes issues de
 200 l'optimisation sont disponible à travers la méthode ``get`` du cas de calcul TUI
 201 ADAO, qui renvoie un objet de type liste de la variable demandée. On se
 202 reportera aux :ref:`section_ref_output_variables` pour une description détaillée
 203 sur ce sujet.
 204
 205 A titre d'exemple, on donne quelques lignes de script qui permettent d'obtenir
 206 le nombre d'itérations de l'optimisation et la valeur optimale ainsi que sa
 207 taille::
 208
 209     print
 210     print "    Nombre d'iterations :",len(case.get("CostFunctionJ"))
 211     Xa = case.get("Analysis")
 212     print "    Analyse optimale  :",Xa[-1]
 213     print "    Taille de l'analyse :",len(Xa[-1])
 214     print
 215
 216 Ces lignes peuvent être très simplement additionnées à l'exemple initial de cas
 217 de calcul TUI ADAO proposé dans :ref:`subsection_tui_example`.
 218
 219 De même que pour l'entrée des données, la simplicité de récupération des
 220 résultats permet d'envisager aisément des post-traitements enchaînés, pour
 221 utiliser par exemple de la visualisation avec MatPlotLib ou PARAVIS [PARAVIS]_,
 222 de l'adaptation de maillage avec HOMARD [HOMARD]_, ou pour d'autres calculs.
 223
 224 .. _subsection_tui_commands:
 225
 226 Ensemble des commandes disponibles en interface textuelle TUI
 227 -------------------------------------------------------------
 228
 229 Dans l'interface TUI du module ADAO, on suit les conventions et recommandations
 230 courantes en Python pour la distinction entre ce qui est public, et ce qui est
 231 privé ou réservé car relevant des détails d'implémentation. De manière pratique,
 232 tout nom d'objet ou de fonction commençant par au moins un signe "_" est privé
 233 au sens courant de programmation ("*private*"). Néanmoins, l'absence d'un tel
 234 signe au début d'un nom ne le désigne pas comme public. De manière générale, en
 235 Python, et contrairement à d'autres langages, on peut accéder aux objets ou aux
 236 fonction privés. Cela peut parfois être utile, mais un tel usage dans vos codes
 237 conduira à des plantages sans avertissement lors de futures versions. Il est
 238 donc fortement recommandé de ne pas le faire.
 239
 240 Pour clarifier et faciliter l'utilisation du module pour du script, **cette
 241 section définit donc l'interface de programmation (API) textuelle publique pour
 242 l'utilisateur (TUI) de manière complète et limitative**. L'usage en script
 243 d'objets ou fonctions ADAO autres que ceux qui sont définis ici est fortement
 244 déconseillé, car cela conduira vraisemblablement à des plantages sans
 245 avertissement lors de futures versions.
 246
 247 Syntaxes d'appel équivalentes pour les commandes TUI
 248 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 249
 250 La définition des données lors de la création de cas de calcul TUI ADAO supporte
 251 **deux syntaxes entièrement équivalentes**. On peut :
 252
 253 - soit utiliser la commande ``set`` et comme premier argument le concept
 254   ``XXXXX`` sur laquelle appliquer la commande dont les arguments suivent,
 255 - soit utiliser la commande ``setXXXXX`` contenant les arguments de la commande
 256   à appliquer.
 257
 258 Pour illustrer cette équivalence, on prend l'exemple des deux commandes
 259 suivantes qui conduisent au même résultat::
 260
 261     case.set( 'Background', Vector=[0, 1, 2] )
 262
 263 et::
 264
 265     case.setBackground( Vector=[0, 1, 2] )
 266
 267 Le choix de l'une ou l'autre des syntaxes est librement laissé à l'utilisateur,
 268 selon son contexte d'usage. Dans la suite, par souci de clarté, on définit les
 269 commandes selon la seconde syntaxe.
 270
 271 Définir les données de calcul
 272 +++++++++++++++++++++++++++++
 273
 274 Les commandes qui suivent permettent de définir les données d'un cas de calcul
 275 TUI ADAO. Le pseudo-type des arguments est similaire et compatible avec ceux des
 276 entrées en interface GUI, décrits dans la section des
 277 :ref:`section_reference_entry` et en particulier par la
 278 :ref:`section_ref_entry_types`. La vérification de l'adéquation des grandeurs se
 279 fait soit lors de leur définition, soit lors de l'exécution.
 280
 281 Dans chaque commande, le mot-clé booléen "*Stored*" permet d'indiquer si l'on
 282 veut éventuellement la stocker la grandeur définie pour en disposer en en cours
 283 de calcul ou en sortie. Le choix par défaut est de ne pas stocker, et il est
 284 recommandé de conserver cette valeur par défaut. En effet, pour un cas de calcul
 285 TUI, on dispose déjà souvent des grandeurs données en entrées qui sont présentes
 286 dans l'espace de nommage courant du cas.
 287
 288 Les commandes disponibles sont les suivantes :
 289
 290 .. index:: single: setBackground
 291
 292 **setBackground** (*Vector , VectorSerie , Stored*)
 293     Cette commande permet de définir l'ébauche :math:`\mathbf{x}^b`. Selon les
 294     algorithmes, on peut définir un vecteur simple par "*Vector*", ou une liste
 295     de vecteurs par "*VectorSerie*".
 296
 297 .. index:: single: setBackgroundError
 298
 299 **setBackgroundError** (*Matrix, ScalarSparseMatrix, DiagonalSparseMatrix, Stored*)
 300     Cette commande permet de définir la matrice :math:`\mathbf{B}` des
 301     covariance des erreurs d'ébauche. La matrice peut être définie de manière
 302     complète par "*Matrix*", ou de manière parcimonieuse comme une matrice
 303     diagonale dont on donne la variance unique sur la diagonale par
 304     "*ScalarSparseMatrix*", ou comme une matrice diagonale dont on donne le
 305     vecteur des variances situé sur la diagonale par "*DiagonalSparseMatrix*".
 306
 307 .. index:: single: setCheckingPoint
 308
 309 **setCheckingPoint** (*Vector, VectorSerie, Stored*)
 310     Cette commande permet de définir un point courant :math:`\mathbf{x}` utilisé
 311     pour un algorithme de vérification. Selon les algorithmes, on peut définir
 312     un vecteur simple par "Vector", ou une liste de vecteurs par "VectorSerie".
 313
 314 .. index:: single: setControlModel
 315
 316 **setControlModel** (*Matrix, DirectFunction, ThreeFunctions, Parameters, Stored*)
 317     Cette commande permet de définir l'opérateur de contrôle :math:`O`, qui
 318     décrit un contrôle d'entrée linéaire externe de l'opérateur d'évolution ou
 319     d'observation. On se reportera :ref:`section_ref_operator_control`. Sa
 320     valeur est définie comme un objet de type fonction ou de type "*Matrix*".
 321     Dans le cas d'une fonction, différentes formes fonctionnelles peuvent être
 322     utilisées, comme décrit dans la section
 323     :ref:`section_ref_operator_requirements`, et entrées par "*DirectFunction*"
 324     ou "*ThreeFunctions*". Les paramètres de contrôle de l'approximation
 325     numérique de l'opérateur adjoint, dans le cas "*DirectFunction*", peuvent
 326     être renseignés par un dictionnaire dans "*Parameters*". Les entrées
 327     potentielles de ce dictionnaire de paramètres sont
 328     "*DifferentialIncrement*", "*CenteredFiniteDifference*",
 329     "*EnableMultiProcessing*", "*NumberOfProcesses*" (similaires à celles de
 330     l'interface graphique).
 331
 332 .. index:: single: setControlInput
 333
 334 **setControlInput** (*Vector, VectorSerie, Stored*)
 335     Cette commande permet de définir le vecteur de contrôle :math:`\mathbf{u}`.
 336     Selon les algorithmes, on peut définir un vecteur simple par "Vector", ou
 337     une liste de vecteurs par "VectorSerie".
 338
 339 .. index:: single: setEvolutionError
 340
 341 **setEvolutionError** (*Matrix, ScalarSparseMatrix, DiagonalSparseMatrix, Stored*)
 342     Cette commande permet de définir la matrice :math:`\mathbf{Q}` des
 343     covariance des erreurs d'évolution. La matrice peut être définie de manière
 344     complète par "*Matrix*", ou de manière parcimonieuse comme une matrice
 345     diagonale dont on donne la variance unique sur la diagonale par
 346     "*ScalarSparseMatrix*", ou comme une matrice diagonale dont on donne le
 347     vecteur des variances situé sur la diagonale par "*DiagonalSparseMatrix*".
 348
 349 .. index:: single: setEvolutionModel
 350
 351 **setEvolutionModel** (*Matrix, DirectFunction, ThreeFunctions, Parameters, Stored*)
 352     Cette commande permet de définir l'opérateur d'evolution :math:`M`, qui
 353     décrit un pas élémentaire d'évolution. Sa valeur est définie comme un objet
 354     de type fonction ou de type "*Matrix*". Dans le cas d'une fonction,
 355     différentes formes fonctionnelles peuvent être utilisées, comme décrit dans
 356     la section :ref:`section_ref_operator_requirements`, et entrées par
 357     "*DirectFunction*" ou "*ThreeFunctions*". Les paramètres de contrôle de
 358     l'approximation numérique de l'opérateur adjoint, dans le cas
 359     "*DirectFunction*", peuvent être renseignés par un dictionnaire dans
 360     "*Parameters*". Les entrées potentielles de ce dictionnaire de paramètres
 361     sont "*DifferentialIncrement*", "*CenteredFiniteDifference*",
 362     "*EnableMultiProcessing*", "*NumberOfProcesses*" (similaires à celles de
 363     l'interface graphique).
 364
 365 .. index:: single: setObservation
 366
 367 **setObservation** (*Vector, VectorSerie, Stored*)
 368     Cette commande permet de définir le vecteur d'observation
 369     :math:`\mathbf{y}^o`. Selon les cas, on peut définir un vecteur simple par
 370     "Vector", ou une liste de vecteurs par "VectorSerie".
 371
 372 .. index:: single: setObservationError
 373
 374 **setObservationError** (*Matrix, ScalarSparseMatrix, DiagonalSparseMatrix, Stored*)
 375     Cette commande permet de définir la matrice :math:`\mathbf{R}` des
 376     covariance des erreurs d'observation. La matrice peut être définie de
 377     manière complète par "*Matrix*", ou de manière parcimonieuse comme une
 378     matrice diagonale dont on donne la variance unique sur la diagonale par
 379     "*ScalarSparseMatrix*", ou comme une matrice diagonale dont on donne le
 380     vecteur des variances situé sur la diagonale par "*DiagonalSparseMatrix*".
 381
 382 .. index:: single: setObservationOperator
 383
 384 **setObservationOperator** (*Matrix, DirectFunction, ThreeFunctions, Parameters, Stored*)
 385     Cette commande permet de définir l'opérateur d'observation :math:`H`, qui
 386     transforme les paramètres d'entrée :math:`\mathbf{x}` en résultats
 387     :math:`\mathbf{y}` qui sont à comparer aux observations
 388     :math:`\mathbf{y}^o`. Sa valeur est définie comme un objet de type fonction
 389     ou de type "*Matrix*". Dans le cas d'une fonction, différentes formes
 390     fonctionnelles peuvent être utilisées, comme décrit dans la section
 391     :ref:`section_ref_operator_requirements`, et entrées par "*DirectFunction*"
 392     ou "*ThreeFunctions*". Les paramètres de contrôle de l'approximation
 393     numérique de l'opérateur adjoint, dans le cas "*DirectFunction*", peuvent
 394     être renseignés par un dictionnaire dans "*Parameters*". Les entrées
 395     potentielles de ce dictionnaire de paramètres sont "*DifferentialIncrement*",
 396     "*CenteredFiniteDifference*", "*EnableMultiProcessing*",
 397     "*NumberOfProcesses*" (similaires à celles de l'interface graphique).
 398
 399 .. index:: single: set
 400
 401 **set** (*Concept,...*)
 402     Cette commande permet de disposer d'une syntaxe équivalente pour toutes les
 403     commandes de ce paragraphe. Son premier argument est le nom du concept à
 404     définir (par exemple "*Background*" ou "*ObservationOperator*"), sur lequel
 405     s'applique ensuite les arguments qui suivent, qui sont les mêmes que dans
 406     les commandes individuelles ci-dessus.
 407
 408 Paramétrer le calcul, les sorties, etc.
 409 +++++++++++++++++++++++++++++++++++++++
 410
 411 .. index:: single: setAlgorithmParameters
 412
 413 **setAlgorithmParameters** (*Algorithm, Parameters*)
 414     Cette commande permet de choisir l'algorithme de calcul ou de vérification
 415     par l'argument "*Algorithm*" sous la forme d'un nom d'algorithme (on se
 416     reportera utilement aux listes des :ref:`section_reference_assimilation` et
 417     des :ref:`section_reference_checking`), et de définir les paramètres de
 418     calcul par l'argument "*Parameters*".
 419
 420 .. index:: single: setDebug
 421
 422 **setDebug** ()
 423     Cette commande permet d'activer le mode d'information détaillé lors de
 424     l'exécution.
 425
 426 .. index:: single: setNoDebug
 427
 428 **setNoDebug** ()
 429     Cette commande permet de désactiver le mode d'information détaillé lors de
 430     l'exécution.
 431
 432 .. index:: single: setObserver
 433
 434 **setObserver** (*Variable, Template, String, Info*)
 435     Cette commande permet de définir un observer sur une variable courante ou
 436     finale du calcul.  On se reportera à la description de la manière
 437     d':ref:`section_advanced_observer`, et à la :ref:`section_reference` pour
 438     savoir quelles sont les quantités observables. On définit par "*String*" le
 439     corps de l'observer par une chaine de caractères incluant si nécessaire des
 440     sauts de lignes. On recommande d'utiliser les patrons disponibles par
 441     l'argument "*Template*". On dispose des patrons simples suivants :
 442     "*ValuePrinter*", "*ValueSeriePrinter*", "*ValueSaver*",
 443     "*ValueSerieSaver*", "*ValuePrinterAndSaver*",
 444     "*ValueSeriePrinterAndSaver*", "*ValueGnuPlotter*",
 445     "*ValueSerieGnuPlotter*".
 446
 447 Effectuer le calcul
 448 +++++++++++++++++++
 449
 450 .. index:: single: executePythonScheme
 451
 452 **executePythonScheme** ()
 453     Cette commande lance le calcul complet dans l'environnement de
 454     l'interpréteur Python courant, sans interaction avec YACS. Les sorties
 455     standard et d'erreur sont celles de l'interpréteur Python. On dispose si
 456     nécessaire du parallélisme interne des algorithmes dans ADAO et du
 457     parallélisme interne du ou des codes de simulation utilisé.
 458
 459 .. index:: single: generateYACSscheme
 460
 461 **executeYACSScheme** (*File*)
 462     Cete commande génère le schéma YACS [YACS]_ du cas de calcul dans le fichier
 463     requis "*File*", et en lance l'exécution dans l'interpréteur YACS, comme on
 464     peut le réaliser en utilisant l'éditeur standard de cas ADAO. Les sorties
 465     standard et d'erreur sont celles de l'interpréteur YACS. On dispose si
 466     nécessaire du parallélisme de noeuds et blocs dans YACS, du parallélisme
 467     interne des algorithmes dans ADAO et du parallélisme interne du ou des codes
 468     de simulation utilisé.
 469
 470 .. index:: single: execute
 471
 472 **execute** ()
 473     Cette commande est un raccourci utilisateur pour "*executePythonScheme*".
 474
 475 Obtenir séparément les résultats de calcul
 476 ++++++++++++++++++++++++++++++++++++++++++
 477
 478 .. index:: single: get
 479
 480 **get** (*Concept*)
 481     Cette commande permet d'extraire explicitement les variables disponibles en
 482     sortie du cas de calcul TUI ADAO pour les utiliser dans la suite du
 483     scripting, par exemple en visualisation. Elle a pour argument le nom d'un
 484     variable dans "*Concept*", et renvoie en retour la grandeur sous la forme
 485     d'une liste (même s'il n'y en a qu'un exemplaire) de cette variable de
 486     base. Pour connaître la liste des variables et les utiliser, on se
 487     reportera à l':ref:`subsection_r_o_v_Inventaire`, et plus généralement à la
 488     fois aux :ref:`section_ref_output_variables` et aux documentations
 489     individuelles des algorithmes.
 490
 491 .. Exemples plus avancés de cas de calcul TUI ADAO
 492 .. -----------------------------------------------
 493
 494 .. Equivalences entre l'interface graphique (GUI) et l'interface textuelle (TUI)
 495 .. -----------------------------------------------------------------------------
 496
 497 .. [HOMARD] Pour de plus amples informations sur HOMARD, voir le *module HOMARD* et son aide intégrée disponible dans le menu principal *Aide* de l'environnement SALOME.
 498
 499 .. [PARAVIS] Pour de plus amples informations sur PARAVIS, voir le *module PARAVIS* et son aide intégrée disponible dans le menu principal *Aide* de l'environnement SALOME.
 500
 501 .. [YACS] 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.