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
24 .. _section_tutorials_in_salome:
26 ================================================================================
27 **[DocU]** Tutoriaux sur l'utilisation du module ADAO dans SALOME
28 ================================================================================
30 .. |eficas_new| image:: images/eficas_new.png
33 .. |eficas_save| image:: images/eficas_save.png
36 .. |eficas_saveas| image:: images/eficas_saveas.png
39 .. |eficas_yacs| image:: images/eficas_yacs.png
43 Cette section présente quelques exemples d'utilisation du module ADAO dans
44 SALOME. Le premier montre comment construire un cas très simple d'assimilation
45 de données définissant explicitement toutes les données d'entrée requises à
46 travers l'interface utilisateur graphique EFICAS (GUI). Le second montre, sur
47 le même cas, comment définir les données d'entrée à partir de sources externes
48 à travers des scripts. On présente ici toujours des scripts Python car ils sont
49 directement insérables dans les noeuds de script de YACS, mais les fichiers
50 externes peuvent utiliser d'autres langages.
52 Ces exemples sont intentionnellement décrits de manière semblables aux
53 :ref:`section_tutorials_in_python` car ils sont similaires à ceux que l'on peut
54 traiter dans l'interface textuelle Python (TUI). Les notations mathématiques
55 utilisées ci-dessous sont expliquées dans la section :ref:`section_theory`.
57 Construire un cas d'estimation avec une définition explicite des données
58 ------------------------------------------------------------------------
60 Cet exemple très simple est un cas de démonstration, et il décrit comment
61 mettre au point un environnement d'estimation par BLUE de manière à obtenir un
62 *état estimé par méthode de moindres carrés pondérés* d'un système à partir
63 d'une observation de l'état et d'une connaissance *a priori* (ou ébauche) de
64 cet état. En d'autres termes, on cherche l'intermédiaire pondéré entre les
65 vecteurs d'observation et d'ébauche. Toutes les valeurs numériques de cet
66 exemple sont arbitraires.
68 Conditions d'expérience
69 +++++++++++++++++++++++
71 On choisit d'opérer dans un espace d'observation à 3 dimensions, i.e on dispose
72 de 3 mesures simples. La dimension 3 est choisie de manière à restreindre la
73 taille des objets numériques à entrer explicitement par l'utilisateur, mais le
74 problème n'est pas dépendant de la dimension et peut être posé en dimension
75 d'observation de 10, 100, 1000... L'observation :math:`\mathbf{y}^o` vaut 1
76 dans chaque direction, donc :
81 L'ébauche :math:`\mathbf{x}^b` de l'état , qui représente une connaissance *a
82 priori* ou une régularisation mathématique, est choisie comme valant 0 dans
83 chaque cas, ce qui donne donc :
88 La mise en oeuvre de l'assimilation de données requiert des informations sur
89 les covariances d'erreur :math:`\mathbf{R}` et :math:`\mathbf{B}`,
90 respectivement pour les variables d'erreur d'observation et d'ébauche. On
91 choisit ici des erreurs décorrélées (c'est-à-dire des matrices diagonales) et
92 d'avoir la même variance de 1 pour toutes les variables (c'est-à-dire des
93 matrices identité). On pose donc :
96 B = R = Id = [1 0 0 ; 0 1 0 ; 0 0 1]
98 Enfin, on a besoin d'un opérateur d'observation :math:`\mathbf{H}` pour
99 convertir l'état d'ébauche dans l'espace des observations. Ici, comme les
100 dimensions d'espace sont les mêmes, on peut choisir l'identité comme opérateur
104 H = Id = [1 0 0 ; 0 1 0 ; 0 0 1]
106 Avec de tels choix, l'estimateur "Best Linear Unbiased Estimator" (BLUE) sera le
107 vecteur moyen entre :math:`\mathbf{y}^o` et :math:`\mathbf{x}^b`, nommé
108 *analysis*, noté :math:`\mathbf{x}^a`, et valant :
113 Pour étendre cet exemple, on peut modifier les variances représentées par
114 :math:`\mathbf{B}` ou :math:`\mathbf{R}` indépendamment, et l'analyse
115 :math:`\mathbf{x}^a` se déplacera vers :math:`\mathbf{y}^o` ou vers
116 :math:`\mathbf{x}^b`, en proportion inverse des variances dans
117 :math:`\mathbf{B}` et :math:`\mathbf{R}`. Comme autre extension, on peut aussi
118 dire qu'il est équivalent de rechercher l'analyse à l'aide d'un algorithme de
119 BLUE ou d'un algorithme de 3DVAR.
121 Utiliser l'interface graphique (GUI) pour construire le cas ADAO
122 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
124 En premier lieu, il faut activer le module ADAO en choisissant le bouton ou le
125 menu approprié de module de SALOME, et on voit :
128 .. image:: images/adao_activate.png
132 **Activation du module ADAO dans SALOME**
134 Choisir le bouton "*Nouveau*" dans cette fenêtre. On obtient directement
135 l'interface de l'éditeur intégré de cas pour la définition de variables, en même
136 temps que l'"*Arbre d'étude*" de SALOME. On peut alors choisir le bouton
137 "*Nouveau*" |eficas_new| pour créer un nouveau cas ADAO, et on voit :
140 .. image:: images/adao_viewer.png
144 **L'éditeur intégré pour la définition de cas dans le module ADAO**
146 Ensuite, il faut remplir les variables pour construire le cas ADAO en utilisant
147 les conditions d'expérience décrites ci-dessus. L'ensemble des informations
148 techniques données au-dessus sont à insérer directement dans la définition du
149 cas ADAO, en utilisant le type *String* pour chaque variable. Lorsque la
150 définition du cas est prête, il faut l'enregistrer comme un fichier natif de
151 ype "*JDC (\*.comm)*" à un endroit quelconque dans l'arborescence de
152 l'utilisateur. Il faut bien se rappeler que d'autres fichiers seront aussi
153 créés à côté de ce premier, donc il est judicieux de faire un répertoire
154 spécifique pour ce cas, et d'enregistrer dedans le fichier. Le nom du fichier
155 apparaît dans la fenêtre de l'"*Arbre d'étude*", sous le menu "*ADAO*". La
156 définition finale du cas ressemble à :
158 .. _adao_jdcexample01:
159 .. image:: images/adao_jdcexample01.png
163 **Définition des conditions d'expérience choisies pour le cas ADAO**
165 Pour poursuivre, on a besoin de générer le schéma YACS à partir de la définition
166 du cas ADAO. Pour faire cela, on peut activer le menu contextuel par click droit
167 sur le nom du cas dans la fenêtre de l'"*Arbre d'étude*", et choisir le
168 sous-menu "*Exporter vers YACS*" (ou le bouton "*Exporter vers YACS*"
169 |eficas_yacs|) comme ci-dessous :
171 .. _adao_exporttoyacs00:
172 .. image:: images/adao_exporttoyacs.png
176 **Sous-menu contextuel "*Exporter vers YACS*" pour générer le schéma YACS à partir du cas ADAO**
178 Cette commande conduit à la génération d'un schéma YACS, à l'activation du module
179 YACS dans SALOME, et à ouvrir le nouveau schéma dans l'interface graphique du
180 module YACS [#]_. Après avoir éventuellement réorganisé les noeuds en utilisant
181 le sous-menu contextuel "*arranger les noeuds locaux*" de la vue graphique du
182 schéma YACS, on obtient la représentation suivante du schéma ADAO généré :
184 .. _yacs_generatedscheme:
185 .. image:: images/yacs_generatedscheme.png
189 **Schéma YACS généré à partir du cas ADAO**
191 Après ce point, toutes les modifications, exécutions et post-processing du
192 schéma d'assimilation de données seront effectués dans le module YACS. De façon
193 à vérifier les résultats d'une manière simple, on utilise le noeud
194 "*UserPostAnalysis*" (ou on crée ici un nouveau noeud YACS par le sous-menu
195 "*Noeud de script in-line*" dans la vue graphique de YACS).
197 Ce noeud de script va récupérer l'analyse issue de l'assimilation de données
198 depuis le port de sortie "*algoResults*" du bloc de calcul (qui donne accés à un
199 objet Python SALOME), et va l'afficher à la sortie standard.
201 Pour obtenir ceci, ce noeud de script doit comporter un port d'entrée de type
202 "*pyobj*", nommé "*Study*" par exemple, qui doit être relié graphiquement au
203 port de sortie "*algoResults*" du bloc de calcul. Ensuite, le code pour remplir
204 le noeud de script est :
207 Xa = Study.getResults().get("Analysis")[-1]
210 print("Analysis =",Xa)
213 Le schéma YACS (initial ou complété) peut être enregistré (en écrasant le schéma
214 généré si la commande ou le bouton "*Enregistrer*" sont utilisés, ou sinon avec
215 un nom nouveau par la commande "*Enregistrer sous*"). De manière pratique, la
216 mise au point d'une telle procédure de post-processing peut être réalisée dans
217 YACS pour la tester, et ensuite entièrement enregistrée dans un script Python
218 qui peut être intégré au cas ADAO en utilisant le mot-clé "*UserPostAnalysis*".
220 Ensuite, de manière classique dans YACS, le schéma doit être compilé, et être
221 exécuté. Après la fin de l'exécution, les affichages sur la sortie standard
222 sont disponibles dans la fenêtre "*fenêtre de sortie de YACS*" (ou "*YACS
223 Container Log*"), obtenue par clic droit à l'aide du menu contextuel de la
224 fenêtre "*proc*" du schéma YACS comme montré ci-dessous:
226 .. _yacs_containerlog:
227 .. image:: images/yacs_containerlog.png
231 **Menu YACS de la fenêtre de sortie, et boite de dialogue montrant la sortie**
233 On vérifie que le résultat est correct en observant si la fenêtre de sortie
234 contient la ligne suivante :
237 Analysis = [0.5, 0.5, 0.5]
239 comme montré dans l'image précédente.
241 Pour étendre cet exemple, on peut remarquer que le même problème résolu par un
242 algorithme de 3DVAR donne le même résultat. Cet algorithme peut être choisi lors
243 de l'étape de construction du cas ADAO, avant d'entrer dans l'étape YACS. Le cas
244 ADAO en 3DVAR est entièrement similaire au cas algorithmique du BLUE, comme
245 montré dans la figure suivante:
247 .. _adao_jdcexample02:
248 .. image:: images/adao_jdcexample02.png
252 **Définir un cas ADAO en 3DVAR est entièrement similaire à un cas en BLUE**
254 Il n'y a qu'une seule commande qui change, avec "*3DVAR*" dans le champ
255 "*Algorithm*" à la place de "*Blue*".
257 Construire un cas d'estimation avec une définition de données externes par scripts
258 ----------------------------------------------------------------------------------
260 Il est utile d'acquérir une partie ou la totalité des données du cas ADAO
261 depuis une définition externe, en utilisant des scripts Python pour donner
262 accès à ces données. À titre d'exemple, on construit ici un cas ADAO présentant
263 le même dispositif expérimental que dans l'exemple ci-dessus `Construire un cas
264 d'estimation avec une définition explicite des données`_, mais en utilisant des
265 données issues d'un unique fichier script Python externe.
267 En premier lieu, on écrit le fichier script suivant, utilisant des noms
268 conventionnels pour les variables requises. Ici toutes les variables sont
269 définies dans le même script, mais l'utilisateur peut choisir de séparer le
270 fichier en plusieurs autres, ou de mélanger une définition explicite des données
271 dans l'interface graphique ADAO et une définition implicite dans des fichiers
272 externes. Le fichier script actuel ressemble à :
277 # Definition of the Background as a vector
278 # ----------------------------------------
279 Background = [0, 0, 0]
281 # Definition of the Observation as a vector
282 # -----------------------------------------
283 Observation = "1 1 1"
285 # Definition of the Background Error covariance as a matrix
286 # ---------------------------------------------------------
287 BackgroundError = numpy.array([[1., 0., 0.], [0., 1., 0.], [0., 0., 1.]])
289 # Definition of the Observation Error covariance as a matrix
290 # ----------------------------------------------------------
291 ObservationError = numpy.matrix("1 0 0 ; 0 1 0 ; 0 0 1")
293 # Definition of the Observation Operator as a matrix
294 # --------------------------------------------------
295 ObservationOperator = numpy.identity(3)
297 Les noms des variables Python sont obligatoires, de manière à définir les
298 bonnes variables dans le cas ADAO, mais le script Python peut être plus
299 conséquent et définir des classes, des fonctions, des accès à des fichiers ou
300 des bases de données, etc. avec des noms différents. De plus, le fichier
301 ci-dessus présente différentes manières de définir des vecteurs ou des
302 matrices, utilisant des listes, des chaînes de caractères (comme dans Numpy ou
303 Octave), des types vecteur ou matrice de Numpy, et des fonctions spéciales de
304 Numpy. Toutes ces syntaxes sont valides.
306 Après avoir enregistré ce script dans un fichier (nommé ici "*script.py*" pour
307 l'exemple) à un endroit quelconque dans l'arborescence de l'utilisateur, on
308 utilise l'interface graphique (GUI) pour construire le cas ADAO. La procédure
309 pour compléter le cas est similaire à celle de l'exemple précédent à part le
310 fait que, au lieu de choisir l'option "*String*" pour le mot-clé "*FROM*" de
311 chaque variable, on choisit l'option "*Script*". Cela conduit à une entrée
312 "*SCRIPT_DATA/SCRIPT_FILE*" dans l'arbre graphique, permettant de choisir un
313 fichier de la manière suivante:
315 .. _adao_scriptentry01:
316 .. image:: images/adao_scriptentry01.png
320 **Définir une variable d'entrée en utilisant un fichier script externe**
322 Les autres étapes et résultats sont exactement les mêmes que dans l'exemple
323 précédent `Construire un cas d'estimation avec une définition explicite des
326 Dans la pratique, cette démarche par scripts est la manière la plus facile pour
327 récupérer des informations depuis des calculs en ligne ou préalables, depuis des
328 fichiers statiques, depuis des bases de données ou des flux informatiques,
329 chacun pouvant être dans ou hors SALOME. Cela permet aussi de modifier aisément
330 des données d'entrée, par exemple à des fin de débogage ou pour des traitements
331 répétitifs, et c'est la méthode la plus polyvalente pour paramétrer les données
332 d'entrée. **Mais attention, la méthodologie par scripts n'est pas une procédure
333 "sûre", en ce sens que des données erronées ou des erreurs dans les calculs,
334 peuvent être directement introduites dans l'exécution du cas ADAO.
335 L'utilisateur doit vérifier avec attention le contenu de ses scripts.**
337 Ajout de paramètres pour contrôler l'algorithme d'assimilation de données
338 -------------------------------------------------------------------------
340 On peut ajouter des paramètres optionnels pour contrôler le calcul de
341 l'algorithme d'assimilation de données. Ceci se fait en utilisant les
342 paramètres optionnels dans la commande "*AlgorithmParameters*" de la définition
343 du cas ADAO, qui est un mot-clé de la commande générale de cas (à choisir entre
344 "*ASSIMILATION_STUDY*", "*OPTIMIZATION_STUDY*" ou "*REDUCTION_STUDY*"). Ce
345 mot-clé nécessite une définition explicite des valeurs à partir de valeurs par
346 défaut, ou à partir d'un dictionnaire Python, contenant des paires clé/valeur.
347 La liste des paramètres optionnels possibles est donnée dans la section
348 :ref:`section_reference` et ses sous-sections. On recommande d'utiliser la
349 définition explicite de valeurs à partir de la liste par défaut de paramètres
350 optionnels, comme ici avec le "*MaximumNumberOfSteps*":
352 .. _adao_scriptentry02:
353 .. image:: images/adao_scriptentry02.png
357 **Ajouter des paramètres pour contrôler l'algorithme et les sorties**
359 Le dictionnaire peut être défini, par exemple, dans un fichier externe de
360 script Python, en utilisant le nom obligatoire de variable
361 "*AlgorithmParameters*" pour le dictionnaire. Toutes les clés dans le
362 dictionnaire sont optionnelles, elles disposent toutes d'une valeur par défaut,
363 et elles peuvent être présentes sans être utiles. Par exemple :
366 AlgorithmParameters = {
367 "Minimizer" : "LBFGSB", # Recommended
368 "MaximumNumberOfSteps" : 10,
371 Si aucune borne n'est requise sur les variables de contrôle, alors on peut
372 choisir les algorithmes de minimisation "*BFGS*" ou "*CG*" pour tous les
373 algorithmes variationnels d'assimilation de données ou d'optimisation. Pour
374 l'optimisation sous contraintes, l'algorithme "*LBFGSB*" est bien souvent plus
375 robuste, mais le "*TNC*" est parfois plus performant. De manière générale, le
376 choix de l'algorithme "*LBFGSB*" est recommandé. Ensuite le script peut être
377 ajouté au cas ADAO, dans une entrée de type fichier associé au format "*Dict*"
378 dans le mot-clé "*Parameters*".
380 Les autres étapes et résultats sont exactement les mêmes que dans l'exemple
381 précédent `Construire un cas d'estimation avec une définition explicite des
382 données`_. Le dictionnaire peut aussi être donné directement dans le champ
383 d'entrée de type chaîne de caractères pour le mot-clé.
385 Construire un cas complexe avec une définition de données externes par scripts
386 ------------------------------------------------------------------------------
388 Cet exemple plus complexe et complet peut être considéré comme un cadre de base
389 pour le traitement des entrées de l'utilisateur, qui doit ensuite être adapté à
390 chaque application réelle. Néanmoins, les squelettes de fichiers sont
391 suffisamment généraux pour avoir été utilisés pour des applications variées en
392 neutronique, mécanique des fluides... Ici, on ne s'intéresse pas aux résultats,
393 mais plus sur le contrôle de l'utilisateur des entrées et sorties dans un cas
394 ADAO. Comme précédemment, toutes les valeurs numériques de cet exemple sont
397 L'objectif est de configurer les entrées et les sortie d'un problème physique
398 d'estimation par des scripts externes Python, en utilisant un opérateur
399 non-linéaire général, en ajoutant un contrôle sur les paramètres et ainsi de
400 suite... Les scripts complets peuvent être trouvés dans le répertoire des
401 exemples de squelettes ADAO sous le nom de
402 "*External_data_definition_by_scripts*".
404 Conditions d'expérience
405 +++++++++++++++++++++++
407 On continue à opérer dans un espace à 3 dimensions, afin de limiter la taille de
408 l'objet numérique indiqué dans les scripts, mais le problème ne dépend pas de la
411 On choisit un contexte d'expériences jumelles, en utilisant un état vrai
412 :math:`\mathbf{x}^t` connu, mais de valeur arbitraire :
417 L'état d'ébauche :math:`\mathbf{x}^b`, qui représente une connaissance *a
418 priori* de l'état vrai, est construit comme une perturbation aléatoire
419 gaussienne de 20% de l'état vrai :math:`\mathbf{x}^t` pour chaque composante,
423 Xb = Xt + normal(0, 20%*Xt)
425 Pour décrire la matrice des covariances d'erreur d'ébauche math:`\mathbf{B}`, on
426 fait comme précédemment l'hypothèse d'erreurs décorrélées (c'est-à-dire, une
427 matrice diagonale, de taille 3x3 parce-que :math:`\mathbf{x}^b` est de taille 3)
428 et d'avoir la même variance de 0,1 pour toutes les variables. On obtient :
431 B = 0.1 * diagonal( length(Xb) )
433 On suppose qu'il existe un opérateur d'observation :math:`\mathbf{H}`, qui peut
434 être non linéaire. Dans une procédure réelle de recalage ou de problème inverse,
435 les codes de simulation physique sont intégrés dans l'opérateur d'observation.
436 On a également besoin de connaître son gradient par rapport à chaque variable
437 estimée, ce qui est une information rarement connue avec les codes industriels.
438 Mais on verra plus tard comment obtenir un gradient approché dans ce cas.
440 Étant en expériences jumelles, les observations :math:`\mathbf{y}^o` et leur
441 matrice de covariances d'erreurs :math:`\mathbf{R}` sont générées en utilisant
442 l'état vrai :math:`\mathbf{x}^t` et l'opérateur d'observation
448 et, avec un écart-type arbitraire de 1% sur chaque composante de l'erreur :
451 R = 0.0001 * diagonal( length(Yo) )
453 Toutes les informations requises pour l'estimation par assimilation de données
454 sont maintenant définies.
456 Squelettes des scripts décrivant les conditions d'expérience
457 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
459 On donne ici les éléments essentiels de chaque script utilisé par la suite pour
460 construire le cas ADAO. On rappelle que l'utilisation de ces scripts dans de
461 réels fichiers Python nécessite de définir correctement le chemin de modules ou
462 des codes importés (même si le module est dans le même répertoire que le
463 fichier Python qui l'importe. On doit aussi indiquer l'encodage si nécessaire,
464 etc. Les noms de fichiers indiqués pour les scripts qui suivent sont
465 arbitraires. Des exemples complets de fichiers scripts sont disponibles dans le
466 répertoire standard des exemples ADAO.
468 On définit en premier lieu l'état vrai :math:`\mathbf{x}^t` et une fonction
469 utiles à la construction de matrices, dans un fichier script Python nommé
470 ``Physical_data_and_covariance_matrices.py`` :
477 Arbitrary values and names, as a tuple of two series of same length
479 return (numpy.array([1, 2, 3]), ['Para1', 'Para2', 'Para3'])
481 def Simple_Matrix( size, diagonal=None ):
483 Diagonal matrix, with either 1 or a given vector on the diagonal
485 if diagonal is not None:
486 S = numpy.diag( diagonal )
488 S = numpy.matrix(numpy.identity(int(size)))
491 On définit ensuite l'état d'ébauche :math:`\mathbf{x}^b` comme une perturbation
492 aléatoire de l'état vrai, en ajoutant une *variable ADAO requise* à la fin du
493 script de définition, de manière à exporter la valeur définie. C'est réalisé
494 dans un fichier de script Python nommé ``Script_Background_xb.py`` :
497 from Physical_data_and_covariance_matrices import True_state
500 xt, names = True_state()
502 Standard_deviation = 0.2*xt # 20% for each variable
504 xb = xt + abs(numpy.random.normal(0.,Standard_deviation,size=(len(xt),)))
506 # Creating the required ADAO variable
507 # -----------------------------------
508 Background = list(xb)
510 De la même manière, on définit la matrice des covariances de l'erreur d'ébauche
511 :math:`\mathbf{B}` comme une matrice diagonale, de la même longueur de diagonale
512 que l'ébauche de la valeur vraie, en utilisant la fonction d'aide déjà définie.
513 C'est réalisé dans un fichier script Python nommé
514 ``Script_BackgroundError_B.py`` :
517 from Physical_data_and_covariance_matrices import True_state, Simple_Matrix
519 xt, names = True_state()
521 B = 0.1 * Simple_Matrix( size = len(xt) )
523 # Creating the required ADAO variable
524 # -----------------------------------
527 Pour poursuivre, on a besoin de l'opérateur d'observation :math:`\mathbf{H}`
528 comme une fonction de l'état. Il est ici défini dans un fichier externe nommé
529 ``"Physical_simulation_functions.py"``, qui doit contenir une fonction appelée
530 ``"DirectOperator"``. Cette fonction est une fonction utilisateur, représentant
531 de manière programmée l'opérateur :math:`\mathbf{H}`. On suppose que cette
532 fonction est donnée par l'utilisateur. Un squelette simple est donné ici par
536 def DirectOperator( XX ):
538 """ Direct non-linear simulation operator """
540 # --------------------------------------> EXAMPLE TO BE REMOVED
541 if type(XX) is type(numpy.matrix([])): # EXAMPLE TO BE REMOVED
542 HX = XX.A1.tolist() # EXAMPLE TO BE REMOVED
543 elif type(XX) is type(numpy.array([])): # EXAMPLE TO BE REMOVED
544 HX = numpy.matrix(XX).A1.tolist() # EXAMPLE TO BE REMOVED
545 else: # EXAMPLE TO BE REMOVED
546 HX = XX # EXAMPLE TO BE REMOVED
547 # --------------------------------------> EXAMPLE TO BE REMOVED
549 return numpy.array( HX )
551 On n'a pas besoin des opérateurs linéaires associés ``"TangentOperator"`` et
552 ``"AdjointOperator"`` car ils vont être approximés en utilisant les capacités
553 d'ADAO. Des informations détaillées sur ces opérateurs peuvent être trouvées
554 dans les :ref:`section_ref_operator_requirements`.
556 On insiste sur le fait que ces opérateurs non-linéaire ``"DirectOperator"``,
557 linéaire tangent ``"TangentOperator"`` et linéaire adjoint ``"AdjointOperator"``
558 proviennent de la connaissance de la physique, incluant le code de simulation de
559 référence physique, et doivent être soigneusement mis au point par l'utilisateur
560 de l'assimilation de données ou de l'optimisation. Les erreurs de simulation ou
561 d'usage des opérateurs ne peuvent pas être détectés ou corrigés par
562 l'environnement seul ADAO d'assimilation de données et d'optimisation.
564 Dans cet environnement d'expériences jumelles, l'observation
565 :math:`\mathbf{y}^o` et sa matrice des covariances d'erreur :math:`\mathbf{R}`
566 peuvent être générées. C'est réalisé dans deux fichiers de script Python, le
567 premier étant nommé ``Script_Observation_yo.py`` :
570 from Physical_data_and_covariance_matrices import True_state
571 from Physical_simulation_functions import DirectOperator
573 xt, noms = True_state()
575 yo = DirectOperator( xt )
577 # Creating the required ADAO variable
578 # -----------------------------------
579 Observation = list(yo)
581 et le second nommé ``Script_ObservationError_R.py`` :
584 from Physical_data_and_covariance_matrices import True_state, Simple_Matrix
585 from Physical_simulation_functions import DirectOperator
587 xt, names = True_state()
589 yo = DirectOperator( xt )
591 R = 0.0001 * Simple_Matrix( size = len(yo) )
593 # Creating the required ADAO variable
594 # -----------------------------------
597 Comme dans les exemples précédents, il peut être utile de définir certains
598 paramètres pour l'algorithme d'assimilation de données. Par exemple, si on
599 utilise l'algorithme standard de "*3DVAR*", les paramètres suivants peuvent être
600 définis dans un fichier de script Python nommé
601 ``Script_AlgorithmParameters.py`` :
604 # Creating the required ADAO variable
605 # -----------------------------------
606 AlgorithmParameters = {
607 "Minimizer" : "LBFGSB", # Recommended
608 "MaximumNumberOfSteps" : 15, # Number of global iterative steps
610 [ None, None ], # Bound on the first parameter
611 [ 0., 4. ], # Bound on the second parameter
612 [ 0., None ], # Bound on the third parameter
614 "StoreSupplementaryCalculations" : [
619 Enfin, il est courant de post-traiter les résultats, en les récupérant aprés la
620 phase d'assimilation de données de manière à les analyser, les afficher ou les
621 représenter. Cela nécessite d'utiliser un fichier script Python intermédiaire de
622 manière à extraire ces résultats à la fin de la procédure d'assimilation de
623 données ou d'optimisation. L'exemple suivant de fichier script Python, nommé
624 ``Script_UserPostAnalysis.py``, illustre le fait :
627 from Physical_data_and_covariance_matrices import True_state
630 xt, names = True_state()
631 xa = ADD.get("Analysis")[-1]
632 x_series = ADD.get("CurrentState")[:]
633 J = ADD.get("CostFunctionJ")[:]
635 # Verifying the results by printing
636 # ---------------------------------
639 print("xa = %s"%numpy.array(xa))
641 for i in range( len(x_series) ):
642 print("Etape %2i : J = %.5e et X = %s"%(i, J[i], x_series[i]))
645 Finalement, on obtient la description de l'ensemble des conditions
646 d'expériences à travers la série de fichiers listée ici:
648 #. ``Physical_data_and_covariance_matrices.py``
649 #. ``Physical_simulation_functions.py``
650 #. ``Script_AlgorithmParameters.py``
651 #. ``Script_BackgroundError_B.py``
652 #. ``Script_Background_xb.py``
653 #. ``Script_ObservationError_R.py``
654 #. ``Script_Observation_yo.py``
655 #. ``Script_UserPostAnalysis.py``
657 On insiste ici sur le fait que tous ces scripts sont écrits par l'utilisateur et
658 ne peuvent être testés automatiquement par ADAO. Ainsi, l'utilisateur est tenu
659 de vérifier les scripts (et en particulier leurs entrées/sorties) afin de
660 limiter les difficultés de débogage. On rappelle que: **la méthodologie par
661 scripts n'est pas une procédure "sûre", en ce sens que des données erronées ou
662 des erreurs dans les calculs, peuvent être directement introduites dans
663 l'exécution du schéma YACS.**
665 Construire la cas avec une définition de données externes par scripts
666 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
668 Tous ces scripts peuvent ensuite être utilisés pour définir le cas ADAO avec une
669 définition de données externes par des fichiers de script Python. Cela se
670 réalise de manière tout à fait similaire à la méthode décrite dans la partie
671 précédente `Construire un cas d'estimation avec une définition de données
672 externes par scripts`_. Pour chaque variable à définir, on sélectionne l'option
673 "*Script*" du mot-clé "*FROM*", ce qui conduit à une entrée
674 "*SCRIPT_DATA/SCRIPT_FILE*" dans l'arbre graphique. Pour le mot-clé
675 "*ObservationOperator*", on choisit la forme "*ScriptWithOneFunction*" et on
676 conserve la valeur par défaut de l'incrément différentiel.
678 Les autres étapes pour construire le cas ADAO sont exactement les mêmes que dans
679 la partie précédente `Construire un cas d'estimation avec une définition
680 explicite des données`_.
682 En utilisant l'opérateur linéaire simple :math:`\mathbf{H}` du fichier script
683 Python ``Physical_simulation_functions.py`` disponible dans le répertoire
684 standard des exemples, les résultats ressemblent à (cela peut dépendre du
689 xa = [ 1.000014 2.000458 3.000390]
691 Etape 0 : J = 1.81750e+03 et X = [1.014011, 2.459175, 3.390462]
692 Etape 1 : J = 1.81750e+03 et X = [1.014011, 2.459175, 3.390462]
693 Etape 2 : J = 1.79734e+01 et X = [1.010771, 2.040342, 2.961378]
694 Etape 3 : J = 1.79734e+01 et X = [1.010771, 2.040342, 2.961378]
695 Etape 4 : J = 1.81909e+00 et X = [1.000826, 2.000352, 3.000487]
696 Etape 5 : J = 1.81909e+00 et X = [1.000826, 2.000352, 3.000487]
697 Etape 6 : J = 1.81641e+00 et X = [1.000247, 2.000651, 3.000156]
698 Etape 7 : J = 1.81641e+00 et X = [1.000247, 2.000651, 3.000156]
699 Etape 8 : J = 1.81569e+00 et X = [1.000015, 2.000432, 3.000364]
700 Etape 9 : J = 1.81569e+00 et X = [1.000015, 2.000432, 3.000364]
701 Etape 10 : J = 1.81568e+00 et X = [1.000013, 2.000458, 3.000390]
704 L'état au premier pas est l'état d'ébauche :math:`\mathbf{x}^b` généré
705 aléatoirement. Au cours du calcul, ces affichages sur la sortie standard sont
706 disponibles dans la fenêtre "*fenêtre de sortie de YACS*", que l'on obtient par
707 clic droit sur la fenêtre "*proc*" du schéma YACS exécuté.
709 .. [#] 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.
