Salome HOME
Rewriting and completing reference documentation ([DocR]
[modules/adao.git] / doc / fr / examples.rst
1 ..
2    Copyright (C) 2008-2014 EDF R&D
3
4    This file is part of SALOME ADAO module.
5
6    This library is free software; you can redistribute it and/or
7    modify it under the terms of the GNU Lesser General Public
8    License as published by the Free Software Foundation; either
9    version 2.1 of the License, or (at your option) any later version.
10
11    This library is distributed in the hope that it will be useful,
12    but WITHOUT ANY WARRANTY; without even the implied warranty of
13    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
14    Lesser General Public License for more details.
15
16    You should have received a copy of the GNU Lesser General Public
17    License along with this library; if not, write to the Free Software
18    Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307 USA
19
20    See http://www.salome-platform.org/ or email : webmaster.salome@opencascade.com
21
22    Author: Jean-Philippe Argaud, jean-philippe.argaud@edf.fr, EDF R&D
23
24 .. _section_examples:
25
26 ================================================================================
27 **[DocU]** Tutoriaux sur l'utilisation du module ADAO
28 ================================================================================
29
30 .. |eficas_new| image:: images/eficas_new.png
31    :align: middle
32    :scale: 50%
33 .. |eficas_save| image:: images/eficas_save.png
34    :align: middle
35    :scale: 50%
36 .. |eficas_saveas| image:: images/eficas_saveas.png
37    :align: middle
38    :scale: 50%
39 .. |eficas_yacs| image:: images/eficas_yacs.png
40    :align: middle
41    :scale: 50%
42
43 Cette section présente quelques exemples d'utilisation du module ADAO dans
44 SALOME. Le premier montre comment construire un cas simple d'assimilation de
45 données définissant explicitement toutes les données d'entrée requises à travers
46 l'interface graphique d'édition (GUI). Le second montre, sur le même cas,
47 comment définir les données d'entrée à partir de sources externes à travers des
48 scripts. On présente ici toujours des scripts Python car ils sont directement
49 insérables dans les noeuds de script de YACS, mais les fichiers externes peuvent
50 utiliser d'autres langages.
51
52 Les notations mathématiques utilisées ci-dessous sont expliquées dans la section
53 :ref:`section_theory`.
54
55 Construire un cas d'estimation avec une définition explicite des données
56 ------------------------------------------------------------------------
57
58 Cet exemple simple est un cas de démonstration, et il décrit comment mettre au
59 point un environnement d'estimation par BLUE de manière à obtenir un *état
60 estimé par méthode de moindres carrés pondérés* d'un système à partir d'une
61 observation de l'état et d'une connaissance *a priori* (ou ébauche) de cet état.
62 En d'autres termes, on cherche l'intermédiaire pondéré entre les vecteurs
63 d'observation et d'ébauche. Toutes les valeurs numériques de cet exemple sont
64 arbitraires.
65
66 Conditions d'expérience
67 +++++++++++++++++++++++
68
69 On choisit d'opérer dans un espace à 3 dimensions. La 3D est choisie de manière
70 à restreindre la taille des objets numériques à entrer explicitement par
71 l'utilisateur, mais le problème n'est pas dépendant de la dimension et peut être
72 posé en dimension 10, 100, 1000... L'observation :math:`\mathbf{y}^o` vaut 1
73 dans chaque direction, donc::
74
75     Yo = [1 1 1]
76
77 L'ébauche :math:`\mathbf{x}^b` de l'état , qui représente une connaissance *a
78 priori* ou une régularisation mathématique, vaut 0 dans chaque direction, ce qui
79 donne donc::
80
81     Xb = [0 0 0]
82
83 La mise en oeuvre de l'assimilation de données requiert des informations sur les
84 covariances d'erreur :math:`\mathbf{R}` et :math:`\mathbf{B}`, respectivement
85 pour les variables d'observation et d'ébauche. On choisit ici des erreurs
86 décorrélées (c'est-à-dire des matrices diagonales) et d'avoir la même variance
87 de 1 pour toutes les variables (c'est-à-dire des matrices identité). On pose
88 donc::
89
90     B = R = [1 0 0 ; 0 1 0 ; 0 0 1]
91
92 Enfin, on a besoin d'un opérateur d'observation :math:`\mathbf{H}` pour
93 convertir l'état d'ébauche dans l'espace des observations. Ici, comme les
94 dimensions d'espace sont les mêmes, on peut choisir l'identité comme opérateur
95 d'observation::
96
97     H = [1 0 0 ; 0 1 0 ; 0 0 1]
98
99 Avec de tels choix, l'estimateur "Best Linear Unbiased Estimator" (BLUE) sera le
100 vecteur moyen entre :math:`\mathbf{y}^o` et :math:`\mathbf{x}^b`, nommé
101 *analysis*, noté :math:`\mathbf{x}^a`, et valant::
102
103
104     Xa = [0.5 0.5 0.5]
105
106 Pour étendre cet exemple, on peut modifier les variances représentées par
107 :math:`\mathbf{B}` ou :math:`\mathbf{R}` indépendamment, et l'analyse
108 :math:`\mathbf{x}^a` se déplacera vers :math:`\mathbf{y}^o` ou vers
109 :math:`\mathbf{x}^b`, en proportion inverse des variances dans
110 :math:`\mathbf{B}` et :math:`\mathbf{R}`. Comme autre extension, on peut aussi
111 dire qu'il est équivalent de rechercher l'analyse à l'aide d'un algorithme de
112 BLUE ou d'un algorithme de 3DVAR.
113
114 Utiliser l'interface graphique (GUI) pour construire le cas ADAO
115 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
116
117 En premier lieu, il faut activer le module ADAO en choisissant le bouton ou le
118 menu approprié de module de SALOME, et on voit :
119
120   .. _adao_activate2:
121   .. image:: images/adao_activate.png
122     :align: center
123     :width: 100%
124   .. centered::
125     **Activation du module ADAO dans SALOME**
126
127 Choisir le bouton "*Nouveau*" dans cette fenêtre. On obtient directement
128 l'interface EFICAS pour la définition de variables, en même temps que l'"*Arbre
129 d'étude*" de SALOME. On peut alors choisir le bouton "*Nouveau*" |eficas_new|
130 pour créer un nouveau cas ADAO, et on voit :
131
132   .. _adao_viewer:
133   .. image:: images/adao_viewer.png
134     :align: center
135     :width: 100%
136   .. centered::
137     **L'éditeur EFICAS pour la définition de cas dans le module ADAO**
138
139 Ensuite, il faut remplir les variables pour construire le cas ADAO en utilisant
140 les conditions d'expérience décrites ci-dessus. L'ensemble des informations
141 techniques données au-dessus sont à insérer directement dans la définition du
142 cas ADAO, en utilisant le type *String* pour toutes les variables. Lorsque la
143 définition du cas est prête, il faut l'enregistrer comme un fichier natif de ype
144 "*JDC (\*.comm)*" à un endroit quelconque dans l'arborescence de l'utilisateur.
145 Il faut bien se rappeler que d'autres fichiers seront aussi créés à côté de ce
146 premier, donc il est judicieux de faire un répertoire spécifique pour ce cas, et
147 d'enregistrer dedans le fichier. Le nom du fichier apparaît dans la fenêtre de
148 l'"*Arbre d'étude*", sous le menu "*ADAO*". La définition finale du cas
149 ressemble à :
150
151   .. _adao_jdcexample01:
152   .. image:: images/adao_jdcexample01.png
153     :align: center
154     :width: 100%
155   .. centered::
156     **Définition des conditions d'expérience choisies pour le cas ADAO**
157
158 Pour poursuivre, on a besoin de générer le schéma YACS à partir de la définition
159 du cas ADAO. Pour faire cela, on peut activer le menu contextuel par click droit
160 sur le nom du cas dans la fenêtre de l'"*Arbre d'étude*", et choisir le
161 sous-menu "*Exporter vers YACS*" (ou le bouton "*Exporter vers YACS*"
162 |eficas_yacs|) comme ci-dessous :
163
164   .. _adao_exporttoyacs00:
165   .. image:: images/adao_exporttoyacs.png
166     :align: center
167     :scale: 75%
168   .. centered::
169     **Sous-menu contextuel "*Exporter vers YACS*" pour générer le schéma YACS à partir du cas ADAO**
170
171 Cette commande conduit à la génération d'un schéma YACS, à l'activation du module
172 YACS dans SALOME, et à ouvrir le nouveau schéma dans l'interface graphique du
173 module YACS [#]_. Après avoir éventuellement réorganisé les noeuds en utilisant
174 le sous-menu contextuel "*arranger les noeuds locaux*" de la vue graphique du
175 schéma YACS, on obtient la représentation suivante du schéma ADAO généré :
176
177   .. _yacs_generatedscheme:
178   .. image:: images/yacs_generatedscheme.png
179     :align: center
180     :width: 100%
181   .. centered::
182     **Schéma YACS généré à partir du cas ADAO**
183
184 Après ce point, toutes les modifications, exécutions et post-processing du
185 schéma d'assimilation de données seront effectués dans le module YACS. De
186 manière à vérifier les résultats d'une manière simple, on crée ici un nouveau
187 noeud YACS en utilisant le sous-menu "*Noeud de script in-line*" dans la vue
188 graphique de YACS, et on le nomme "*PostProcessing*".
189
190 Ce noeud de script va récupérer l'analyse issue de l'assimilation de données
191 depuis le port de sortie "*algoResults*" du bloc de calcul (qui donne accés à un
192 objet Python SALOME), et va l'afficher à la sortie standard.
193
194 Pour obtenir ceci, ce noeud de script doit comporter un port d'entrée de type
195 "*pyobj*", nommé "*results*" par exemple, qui doit être relié graphiquement au
196 port de sortie "*algoResults*" du bloc de calcul. Ensuite, le code pour remplir
197 le noeud de script est::
198
199     Xa = results.ADD.get("Analysis")[-1]
200
201     print
202     print "Analysis =",Xa
203     print
204
205 Le schéma YACS complété peut être enregistré (en écrasant le schéma généré si la
206 commande ou le bouton "*Enregistrer*" sont utilisés, ou sinon avec un nom
207 nouveau par la commande "*Enregistrer sous*"). De manière pratique, la mise au
208 point d'une telle procédure de post-processing peut être réalisée dans YACS pour
209 la tester, et ensuite entièrement enregistrée dans un script Python qui peut
210 être intégré au cas ADAO en utilisant le mot-clé "*UserPostAnalysis*".
211
212 Ensuite, de manière classique dans YACS, le schéma doit être compilé, et ensuite
213 être exécuté. Après la fin de l'exécution, les affichages sur la sortie standard
214 sont disponibles dans la fenêtre "*fenêtre de sortie de YACS*" (ou "*YACS
215 Container Log*"), obtenue par clic droit à l'aide du menu contextuel de la
216 fenêtre "*proc*" du schéma YACS comme montré ci-dessous:
217
218   .. _yacs_containerlog:
219   .. image:: images/yacs_containerlog.png
220     :align: center
221     :width: 100%
222   .. centered::
223     **Menu YACS de la fenêtre de sortie, et boite de dialogue montrant la sortie**
224
225 On vérifie que le résultat est correct en observant si la fenêtre de sortie
226 contient la ligne suivante::
227
228     Analysis = [0.5, 0.5, 0.5]
229
230 comme montré dans l'image précédente.
231
232 Pour étendre cet exemple, on peut remarquer que le même problème résolu par un
233 algorithme de 3DVAR donne le même résultat. Cet algorithme peut être choisi lors
234 de l'étape de construction du cas ADAO, avant d'entrer dans l'étape YACS. Le cas
235 ADAO en 3DVAR est entièrement similaire au cas algorithmique du BLUE, comme
236 montré dans la figure suivante:
237
238   .. _adao_jdcexample02:
239   .. image:: images/adao_jdcexample02.png
240     :align: center
241     :width: 100%
242   .. centered::
243     **Définir un cas ADAO en 3DVAR est entièrement similaire à un cas en BLUE**
244
245 Il n'y a qu'une seule commande qui change, avec "*3DVAR*" dans le champ
246 "*Algorithm*" à la place de "*Blue*".
247
248 Construire un cas d'estimation avec une définition de données externes par scripts
249 ----------------------------------------------------------------------------------
250
251 Il est utile d'acquérir une partie ou la totalité des données depuis une
252 définition externe, en utilisant des scripts Python pour donner accès à ces
253 données. À titre d'exemple, on construit ici un cas ADAO présentant le même
254 dispositif expérimental que dans l'exemple ci-dessus `Construire un cas
255 d'estimation avec une définition explicite des données`_, mais en utilisant des
256 données issues d'un unique fichier script Python externe.
257
258 En premier lieu, on écrit le fichier script suivant, utilisant des noms
259 conventionnels pour les variables requises. Ici toutes les variables sont
260 définies dans le même script, mais l'utilisateur peut choisir de séparer le
261 fichier en plusieurs autres, ou de mélanger une définition explicite des données
262 dans l'interface graphique ADAO et une définition implicite dans des fichiers
263 externes. Le fichier script actuel ressemble à::
264
265     import numpy
266     #
267     # Definition of the Background as a vector
268     # ----------------------------------------
269     Background = [0, 0, 0]
270     #
271     # Definition of the Observation as a vector
272     # -----------------------------------------
273     Observation = "1 1 1"
274     #
275     # Definition of the Background Error covariance as a matrix
276     # ---------------------------------------------------------
277     BackgroundError = numpy.array([[1., 0., 0.], [0., 1., 0.], [0., 0., 1.]])
278     #
279     # Definition of the Observation Error covariance as a matrix
280     # ----------------------------------------------------------
281     ObservationError = numpy.matrix("1 0 0 ; 0 1 0 ; 0 0 1")
282     #
283     # Definition of the Observation Operator as a matrix
284     # --------------------------------------------------
285     ObservationOperator = numpy.identity(3)
286
287 Les noms des variables Python sont obligatoires, de manière à définir les bonnes
288 variables dans le cas, mais le script Python peut être plus conséquent et
289 définir des classes, des fonctions, des accès à des fichiers ou des bases de
290 données, etc. avec des noms différents. De plus, le fichier ci-dessus présente
291 différentes manières de définir des vecteurs ou des matrices, utilisant des
292 listes, des chaînes de caractères (comme dans Numpy ou Octave), des types
293 vecteur ou matrice de Numpy, et des fonctions spéciales de Numpy. Toutes ces
294 syntaxes sont valides.
295
296 Après avoir enregistré ce script dans un fichier (nommé ici "*script.py*" pour
297 l'exemple) à un endroit quelconque dans l'arborescence de l'utilisateur, on
298 utilise l'interface graphique (GUI) pour construire le cas ADAO. La procédure
299 pour compléter le cas est similaire à celle de l'exemple précédent à part le
300 fait que, au lieu de choisir l'option "*String*" pour le mot-clé "*FROM*" de
301 chaque variable, on choisit l'option "*Script*". Cela conduit à une entrée
302 "*SCRIPT_DATA/SCRIPT_FILE*" dans l'arbre graphique, permettant de choisir un
303 fichier de la manière suivante:
304
305   .. _adao_scriptentry01:
306   .. image:: images/adao_scriptentry01.png
307     :align: center
308     :width: 100%
309   .. centered::
310     **Définir une variable d'entrée en utilisant un fichier script externe**
311
312 Les autres étapes et résultats sont exactement les mêmes que dans l'exemple
313 précédent `Construire un cas d'estimation avec une définition explicite des
314 données`_.
315
316 Dans la pratique, cette démarche par scripts est la manière la plus facile pour
317 récupérer des information depuis des calculs en ligne ou préalables, depuis des
318 fichiers statiques, depuis des bases de données ou des flux informatiques,
319 chacun pouvant être dans ou hors SALOME. Cela permet aussi de modifier aisément
320 des données d'entrée, par exemple à des fin de débogage ou pour des traitements
321 répétitifs, et c'est la méthode la plus polyvalente pour paramétrer les données
322 d'entrée. **Mais attention, la méthodologie par scripts n'est pas une procédure
323 "sûre", en ce sens que des données erronées ou des erreurs dans les calculs,
324 peuvent être directement introduites dans l'exécution du schéma YACS.
325 L'utilisateur doit vérifier avec attention le contenu de ses scripts.**
326
327 Ajout de paramètres pour contrôler l'algorithme d'assimilation de données
328 -------------------------------------------------------------------------
329
330 On peut ajouter des paramètres optionnels pour contrôler le calcul de
331 l'algorithme d'assimilation de données. Ceci se fait en utilisant le mot-clé
332 "*AlgorithmParameters*" dans la définition du cas ADAO, qui est un mot-clé de la
333 commande générale "*ASSIMILATION_STUDY*". Ce mot-clé nécessite un dictionnaire
334 Python, contenant des paires clé/valeur. La liste des paramètres optionnels
335 possibles sont donnés dans la section :ref:`section_reference`.
336
337 Le dictionnaire doit être défini, par exemple, dans un fichiers externe de
338 script Python, en utilisant le nom obligatoire de variable
339 "*AlgorithmParameters*" pour le dictionnaire. Toutes les clés dans le
340 dictionnaire sont optionnelles, elles disposent toutes d'une valeur par défaut,
341 et elles peuvent être présentes sans être utiles. Par exemple::
342
343     AlgorithmParameters = {
344         "Minimizer" : "CG", # Choix possible : "LBFGSB", "TNC", "CG", "BFGS"
345         "MaximumNumberOfSteps" : 10,
346         }
347
348 Si aucune borne n'est requise sur les variables de contrôle, alors on peut
349 choisir les algorithmes de minimisation "*BFGS*" ou "*CG*" pour tous les
350 algorithmes variationnels d'assimilation de données ou d'optimisation. Pour
351 l'optimisation sous contraintes, l'algorithme "*LBFGSB*" est bien souvent plus
352 robuste, mais le "*TNC*" est parfois plus performant.
353
354 Ensuite le script peut être ajouté au cas ADAO, dans une entrée de type fichier
355 pour le mot-clé "*AlgorithmParameters*", de la manière suivante:
356
357   .. _adao_scriptentry02:
358   .. image:: images/adao_scriptentry02.png
359     :align: center
360     :width: 100%
361   .. centered::
362     **Ajouter des paramètres pour contrôler l'algorithme et les sorties**
363
364 Les autres étapes et résultats sont exactement les mêmes que dans l'exemple
365 précédent `Construire un cas d'estimation avec une définition explicite des
366 données`_. Le dictionnaire peut aussi être donné directement dans le champ
367 d'entrée de type chaîne de caractères pour le mot-clé.
368
369 Construire un cas complexe avec une définition de données externes par scripts
370 ------------------------------------------------------------------------------
371
372 Cet exemple plus complexe et complet peut être considéré comme un cadre de base
373 pour le traitement des entrées de l'utilisateur, qui doit ensuite être adapté à
374 chaque application réelle. Néanmoins, les squelettes de fichiers sont
375 suffisamment généraux pour avoir été utilisés pour des applications variées en
376 neutronique, mécanique des fluides... Ici, on ne s'intéresse pas aux résultats,
377 mais plus sur le contrôle de l'utilisateur des entrées et sorties dans un cas
378 ADAO. Comme précédemment, toutes les valeurs numériques de cet exemple sont
379 arbitraires.
380
381 L'objectif est de configurer les entrées et les sortie d'un problème physique
382 d'estimation par des scripts externes Python, en utilisant un opérateur
383 non-linéaire général, en ajoutant un contrôle sur les paramètres et ainsi de
384 suite... Les scripts complets peuvent être trouvés dans le répertoire des
385 exemples de squelettes ADAO sous le nom de
386 "*External_data_definition_by_scripts*".
387
388 Conditions d'expérience
389 +++++++++++++++++++++++
390
391 On continue à opérer dans un espace à 3 dimensions, afin de limiter la taille de
392 l'objet numérique indiqué dans les scripts, mais le problème ne dépend pas de la
393 dimension.
394
395 On choisit un contexte d'expériences jumelles, en utilisant un état vrai
396 :math:`\mathbf{x}^t` connu, mais de valeur arbitraire::
397
398     Xt = [1 2 3]
399
400 L'état d'ébauche :math:`\mathbf{x}^b`, qui représentent une connaissance *a
401 priori* de l'état vrai, est construit comme une perturbation aléatoire
402 gaussienne de 20% de l'état vrai :math:`\mathbf{x}^t` pour chaque composante,
403 qui est::
404
405     Xb = Xt + normal(0, 20%*Xt)
406
407 Pour décrire la matrice des covariances d'erreur d'ébauche math:`\mathbf{B}`, on
408 fait comme précédemment l'hypothèse d'erreurs décorrélées (c'est-à-dire, une
409 matrice diagonale, de taille 3x3 parce-que :math:`\mathbf{x}^b` est de taille 3)
410 et d'avoir la même variance de 0,1 pour toutes les variables. On obtient::
411
412     B = 0.1 * diagonal( length(Xb) )
413
414 On suppose qu'il existe un opérateur d'observation :math:`\mathbf{H}`, qui peut
415 être non linéaire. Dans une procédure réelle de recalage ou de problème inverse,
416 les codes de simulation physique sont intégrés dans l'opérateur d'observation.
417 On a également besoin de connaître son gradient par rapport à chaque variable
418 estimée, ce qui est une information rarement connu avec les codes industriels.
419 Mais on verra plus tard comment obtenir un gradient approché dans ce cas.
420
421 Étant en expériences jumelles, les observations :math:`\mathbf{y}^o` et leur
422 matrice de covariances d'erreurs :math:`\mathbf{R}` sont générées en utilisant
423 l'état vrai :math:`\mathbf{x}^t` et l'opérateur d'observation
424 :math:`\mathbf{H}`::
425
426     Yo = H( Xt )
427
428 et, avec un écart-type arbitraire de 1% sur chaque composante de l'erreur::
429
430     R = 0.0001 * diagonal( lenght(Yo) )
431
432 Toutes les informations requises pour l'estimation par assimilation de données
433 sont maintenant définies.
434
435 Squelettes des scripts décrivant les conditions d'expérience
436 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
437
438 On donne ici les éléments essentiels de chaque script utilisé par la suite pour
439 construire le cas ADAO. On rappelle que l'utilisation de ces scripts dans de
440 réels fichiers Python nécessite de définir correctement le chemin de modules ou
441 des codes importés (même si le module est dans le même répertoire que le fichier
442 Python qui l'importe. On indique le chemin à renseigner en utilisant la mention
443 ``"# INSERT PHYSICAL SCRIPT PATH"``), l'encodage si nécessaire, etc. Les noms de
444 fichiers indiqués pour les scripts qui suivent sont arbitraires. Des exemples
445 complets de fichiers scripts sont disponibles dans le répertoire standard des
446 exemples ADAO.
447
448 On définit en premier lieu l'état vrai :math:`\mathbf{x}^t` et une fonction
449 utiles à la construction de matrices, dans un fichier script Python nommé
450 ``Physical_data_and_covariance_matrices.py``::
451
452     import numpy
453     #
454     def True_state():
455         """
456         Arbitrary values and names, as a tuple of two series of same length
457         """
458         return (numpy.array([1, 2, 3]), ['Para1', 'Para2', 'Para3'])
459     #
460     def Simple_Matrix( size, diagonal=None ):
461         """
462         Diagonal matrix, with either 1 or a given vector on the diagonal
463         """
464         if diagonal is not None:
465             S = numpy.diag( diagonal )
466         else:
467             S = numpy.matrix(numpy.identity(int(size)))
468         return S
469
470 On définit ensuite l'état d'ébauche :math:`\mathbf{x}^b` comme une perturbation
471 aléatoire de l'état vrai, en ajoutant une *variable ADAO requise* à la fin du
472 script de définition, de manière à exporter la valeur définie. C'est réalisé
473 dans un fichier de script Python nommé ``Script_Background_xb.py``::
474
475     from Physical_data_and_covariance_matrices import True_state
476     import numpy
477     #
478     xt, names = True_state()
479     #
480     Standard_deviation = 0.2*xt # 20% for each variable
481     #
482     xb = xt + abs(numpy.random.normal(0.,Standard_deviation,size=(len(xt),)))
483     #
484     # Creating the required ADAO variable
485     # ------------------------------------
486     Background = list(xb)
487
488 De la même manière, on définit la matrice des covariances de l'erreur d'ébauche
489 :math:`\mathbf{B}` comme une matrice diagonale, de la même longueur de diagonale
490 que l'ébauche de la valeur vraie, en utilisant la fonction d'aide déjà définie.
491 C'est réalisé dans un fichier script Python nommé
492 ``Script_BackgroundError_B.py``::
493
494     from Physical_data_and_covariance_matrices import True_state, Simple_Matrix
495     #
496     xt, names = True_state()
497     #
498     B = 0.1 * Simple_Matrix( size = len(xt) )
499     #
500     # Creating the required ADAO variable
501     # -----------------------------------
502     BackgroundError = B
503
504 Pour poursuivre, on a besoin de l'opérateur d'observation :math:`\mathbf{H}`
505 comme une fonction de l'état. Il est ici défini dans un fichier externe nommé 
506 ``"Physical_simulation_functions.py"``, qui doit contenir une fonction appelée
507 ``"DirectOperator"``. Cette fonction est une une fonction utilisateur,
508 représentant de manière programmée l'opérateur :math:`\mathbf{H}`. On suppose
509 que cette fonction est donnée par l'utilisateur. Un squelette simple est donné
510 ici par facilité::
511
512     def DirectOperator( XX ):
513         """ Direct non-linear simulation operator """
514         #
515         # --------------------------------------> EXAMPLE TO BE REMOVED
516         if type(XX) is type(numpy.matrix([])):  # EXAMPLE TO BE REMOVED
517             HX = XX.A1.tolist()                 # EXAMPLE TO BE REMOVED
518         elif type(XX) is type(numpy.array([])): # EXAMPLE TO BE REMOVED
519             HX = numpy.matrix(XX).A1.tolist()   # EXAMPLE TO BE REMOVED
520         else:                                   # EXAMPLE TO BE REMOVED
521             HX = XX                             # EXAMPLE TO BE REMOVED
522         # --------------------------------------> EXAMPLE TO BE REMOVED
523         #
524         return numpy.array( HX )
525
526 On n'a pas besoin des opérateurs linéaires associés ``"TangentOperator"`` et
527 ``"AdjointOperator"`` car ils vont être approximés en utilisant les capacités
528 d'ADAO.
529
530 On insiste sur le fait que ces opérateurs non-linéaire ``"DirectOperator"``,
531 linéaire tangent ``"TangentOperator"`` et linéaire adjoint ``"AdjointOperator"``
532 proviennent de la connaissance de la physique, incluant le code de simulation de
533 référence physique, et doivent être soigneusement mis au point par l'utilisateur
534 de l'assimilation de données ou de l'optimisation. Les erreurs de simulation ou
535 d'usage des opérateurs ne peuvent pas être détectés ou corrigés par
536 l'environnement seul ADAO d'assimilation de données et d'optimisation.
537
538 Dans cet environnement d'expériences jumelles, l'observation
539 :math:`\mathbf{y}^o` et sa matrice des covariances d'erreur :math:`\mathbf{R}`
540 peuvent être générées. C'est réalisé dans deux fichiers de script Python, le
541 premier étant nommé ``Script_Observation_yo.py``::
542
543     from Physical_data_and_covariance_matrices import True_state
544     from Physical_simulation_functions import DirectOperator
545     #
546     xt, noms = True_state()
547     #
548     yo = DirectOperator( xt )
549     #
550     # Creating the required ADAO variable
551     # -----------------------------------
552     Observation = list(yo)
553
554 et le second nommé ``Script_ObservationError_R.py``::
555
556     from Physical_data_and_covariance_matrices import True_state, Simple_Matrix
557     from Physical_simulation_functions import DirectOperator
558     #
559     xt, names = True_state()
560     #
561     yo = DirectOperator( xt )
562     #
563     R  = 0.0001 * Simple_Matrix( size = len(yo) )
564     #
565     # Creating the required ADAO variable
566     # -----------------------------------
567     ObservationError = R
568
569 Comme dans les exemples précédents, il peut être utile de définir certains
570 paramètres pour l'algorithme d'assimilation de données. Par exemple, si on
571 utilise l'algorithme standard de "*3DVAR*", les paramètres suivants peuvent être
572 définis dans un fichier de script Python nommé
573 ``Script_AlgorithmParameters.py``::
574
575     # Creating the required ADAO variable
576     # -----------------------------------
577     AlgorithmParameters = {
578         "Minimizer" : "TNC",         # Possible : "LBFGSB", "TNC", "CG", "BFGS"
579         "MaximumNumberOfSteps" : 15, # Number of global iterative steps
580         "Bounds" : [
581             [ None, None ],          # Bound on the first parameter
582             [ 0., 4. ],              # Bound on the second parameter
583             [ 0., None ],            # Bound on the third parameter
584             ],
585     }
586
587 Enfin, il est courant de post-traiter les résultats, en les récupérant aprés la
588 phase d'assimilation de données de manière à les analyser, les afficher ou les
589 représenter. Cela nécessite d'utiliser un fichier script Python intermédiaire de
590 manière à extraire ces résultats à la fin de la procédure d'assimilation de
591 données ou d'optimisation. L'exemple suivant de fichier script Python, nommé
592 ``Script_UserPostAnalysis.py``, illustre le fait::
593
594     from Physical_data_and_covariance_matrices import True_state
595     import numpy
596     #
597     xt, names   = True_state()
598     xa          = ADD.get("Analysis")[-1]
599     x_series    = ADD.get("CurrentState")[:]
600     J           = ADD.get("CostFunctionJ")[:]
601     #
602     # Verifying the results by printing
603     # ---------------------------------
604     print
605     print "xt = %s"%xt
606     print "xa = %s"%numpy.array(xa)
607     print
608     for i in range( len(x_series) ):
609         print "Etape %2i : J = %.5e  et  X = %s"%(i, J[i], x_series[i])
610     print
611
612 Finalement, on obtient la description de l'ensemble des conditions
613 d'expériences à travers la série de fichiers listée ici:
614
615 #.      ``Physical_data_and_covariance_matrices.py``
616 #.      ``Physical_simulation_functions.py``
617 #.      ``Script_AlgorithmParameters.py``
618 #.      ``Script_BackgroundError_B.py``
619 #.      ``Script_Background_xb.py``
620 #.      ``Script_ObservationError_R.py``
621 #.      ``Script_Observation_yo.py``
622 #.      ``Script_UserPostAnalysis.py``
623
624 On insiste ici sur le fait que tous ces scripts sont écrits par l'utilisateur et
625 ne peuvent être testés automatiquement par ADAO. Ainsi, l'utilisateur est tenu
626 de vérifier les scripts (et en particulier leurs entrées/sorties) afin de
627 limiter les difficultés de débogage. On rappelle que: **la méthodologie par
628 scripts n'est pas une procédure "sûre", en ce sens que des données erronées ou
629 des erreurs dans les calculs, peuvent être directement introduites dans
630 l'exécution du schéma YACS.**
631
632 Construire la cas avec une définition de données externes par scripts
633 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
634
635 Tous ces scripts peuvent ensuite être utilisés pour définir le cas ADAO avec une
636 définition de données externes par des fichiers de script Python. Cela se
637 réalise de manière tout à fait similaire à la méthode décrite dans la partie
638 précédente `Construire un cas d'estimation avec une définition de données
639 externes par scripts`_. Pour chaque variable à définir, on sélectionne l'option
640 "*Script*"  du mot-clé "*FROM*", ce qui conduit à une entrée
641 "*SCRIPT_DATA/SCRIPT_FILE*" dans l'arbre graphique. Pour le mot-clé
642 "*ObservationOperator*", on choisit la forme "*ScriptWithOneFunction*" et on
643 conserve la valeur par défaut de l'incrément différentiel.
644
645 Les autres étapes pour construire le cas ADAO sont exactement les mêmes que dans
646 la partie précédente `Construire un cas d'estimation avec une définition
647 explicite des données`_.
648
649 En utilisant l'opérateur linéaire simple :math:`\mathbf{H}` du fichier script
650 Python ``Physical_simulation_functions.py`` disponible dans le répertoire
651 standard des exemples, les résultats ressemblent à::
652
653     xt = [1 2 3]
654     xa = [ 1.000014    2.000458  3.000390]
655
656     Etape  0 : J = 1.81750e+03  et  X = [1.014011, 2.459175, 3.390462]
657     Etape  1 : J = 1.81750e+03  et  X = [1.014011, 2.459175, 3.390462]
658     Etape  2 : J = 1.79734e+01  et  X = [1.010771, 2.040342, 2.961378]
659     Etape  3 : J = 1.79734e+01  et  X = [1.010771, 2.040342, 2.961378]
660     Etape  4 : J = 1.81909e+00  et  X = [1.000826, 2.000352, 3.000487]
661     Etape  5 : J = 1.81909e+00  et  X = [1.000826, 2.000352, 3.000487]
662     Etape  6 : J = 1.81641e+00  et  X = [1.000247, 2.000651, 3.000156]
663     Etape  7 : J = 1.81641e+00  et  X = [1.000247, 2.000651, 3.000156]
664     Etape  8 : J = 1.81569e+00  et  X = [1.000015, 2.000432, 3.000364]
665     Etape  9 : J = 1.81569e+00  et  X = [1.000015, 2.000432, 3.000364]
666     Etape 10 : J = 1.81568e+00  et  X = [1.000013, 2.000458, 3.000390]
667     ...
668
669 L'état au premier pas est l'état d'ébauche :math:`\mathbf{x}^b` généré
670 aléatoirement. Au cours du calcul, ces affichages sur la sortie standard sont
671 disponibles dans la fenêtre "*fenêtre de sortie de YACS*", que l'on obtient par
672 clic droit sur la fenêtre "*proc*" du schéma YACS exécuté.
673
674 .. [#] Pour de plus amples informations sur YACS, voir le *Guide utilisateur du module YACS* disponible dans le menu principal *Aide* de l'environnement SALOME.