3 ================================================================================
4 Tutoriaux sur l'utilisation du module ADAO
5 ================================================================================
7 .. |eficas_new| image:: images/eficas_new.png
10 .. |eficas_save| image:: images/eficas_save.png
13 .. |eficas_saveas| image:: images/eficas_saveas.png
16 .. |eficas_yacs| image:: images/eficas_yacs.png
20 Cette section présente quelques exemples d'utilisation du module ADAO dans
21 SALOME. Le premier montre comment construire un cas simple d'assimilation de
22 données définissant explicitement toutes les données d'entrée requises à travers
23 l'interface graphique d'édition (GUI). Le second montre, sur le même cas,
24 comment définir les données d'entrée à partir de sources externes à travers des
25 scripts. On présente ici toujours des scripts Python car ils sont directement
26 insérables dans les noeuds de script de YACS, mais les fichiers externes peuvent
27 utiliser d'autres langages.
29 Les notations mathématiques utilisées ci-dessous sont expliquées dans la section
30 :ref:`section_theory`.
32 Construire un cas d'estimation avec une définition explicite des données
33 ------------------------------------------------------------------------
35 Cet exemple simple est un cas de démonstration, et il décrit comment mettre au
36 point un environnement d'estimation par BLUE de manière à obtenir un *état
37 estimé par méthode de moindres carrés pondérés* d'un système à partir d'une
38 observation de l'état et d'une connaissance *a priori* (ou ébauche) de cet état.
39 En d'autres termes, on cherche l'intermédiaire pondéré entre les vecteurs
40 d'observation et d'ébauche. Toutes les valeurs numériques de cet exemple sont
43 Conditions d'expérience
44 +++++++++++++++++++++++
46 On choisit d'opérer dans un espace à 3 dimensions. La 3D est choisie de manière
47 à restreindre la taille des objets numériques à entrer explicitement par
48 l'utilisateur, mais le problème n'est pas dépendant de la dimension et peut être
49 posé en dimension 10, 100, 1000... L'observation :math:`\mathbf{y}^o` vaut 1
50 dans chaque direction, donc::
54 L'ébauche :math:`\mathbf{x}^b` de l'état , qui représente une connaissance *a
55 priori* ou une régularisation mathématique, vaut 0 dans chaque direction, ce qui
60 La mise en oeuvre de l'assimilation de données requiert des informations sur les
61 covariances d'erreur :math:`\mathbf{R}` et :math:`\mathbf{B}`, respectivement
62 pour les variables d'observation et d'ébauche. On choisit ici des erreurs
63 décorrélées (c'est-à-dire des matrices diagonales) et d'avoir la même variance
64 de 1 pour toutes les variables (c'est-à-dire des matrices identité). On pose
67 B = R = [1 0 0 ; 0 1 0 ; 0 0 1]
69 Enfin, on a besoin d'un opérateur d'observation :math:`\mathbf{H}` pour
70 convertir l'état d'ébauche dans l'espace des observations. Ici, comme les
71 dimensions d'espace sont les mêmes, on peut choisir l'identité comme opérateur
74 H = [1 0 0 ; 0 1 0 ; 0 0 1]
76 Avec de tels choix, l'estimateur "Best Linear Unbiased Estimator" (BLUE) sera le
77 vecteur moyen entre :math:`\mathbf{y}^o` et :math:`\mathbf{x}^b`, nommé
78 *analysis*, noté :math:`\mathbf{x}^a`, et valant::
83 Pour étendre cet exemple, on peut modifier les variances représentées par
84 :math:`\mathbf{B}` ou :math:`\mathbf{R}` indépendamment, et l'analyse
85 :math:`\mathbf{x}^a` se déplacera vers :math:`\mathbf{y}^o` ou vers
86 :math:`\mathbf{x}^b`, en proportion inverse des variances dans
87 :math:`\mathbf{B}` et :math:`\mathbf{R}`. Comme autre extension, on peut aussi
88 dire qu'il est équivalent de rechercher l'analyse à l'aide d'un algorithme de
89 BLUE ou d'un algorithme de 3DVAR.
91 Utiliser l'interface graphique (GUI) pour construire le cas ADAO
92 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
94 En premier lieu, il faut activer le module ADAO en choisissant le bouton ou le
95 menu approprié de module de SALOME, et on voit :
98 .. image:: images/adao_activate.png
102 **Activation du module ADAO dans SALOME**
104 Choisir le bouton "*Nouveau*" dans cette fenêtre. On obtient directement
105 l'interface EFICAS pour la définition de variables, en même temps que l'"*Arbre
106 d'étude*" de SALOME. On peut alors choisir le bouton "*Nouveau*" |eficas_new|
107 pour créer un nouveau cas ADAO, et on voit :
110 .. image:: images/adao_viewer.png
114 **L'éditeur EFICAS pour la définition de cas dans le module ADAO**
116 Ensuite, il faut remplir les variables pour construire le cas ADAO en utilisant
117 les conditions d'expérience décrites ci-dessus. L'ensemble des informations
118 techniques données au-dessus sont à insérer directement dans la définition du
119 cas ADAO, en utilisant le type *String* pour toutes les variables. Lorsque la
120 définition du cas est prête, il faut l'enregistrer comme un fichier natif de ype
121 "*JDC (\*.comm)*" à un endroit quelconque dans l'arborescence de l'utilisateur.
122 Il faut bien se rappeler que d'autres fichiers seront aussi créés à côté de ce
123 premier, donc il est judicieux de faire un répertoire spécifique pour ce cas, et
124 d'enregistrer dedans le fichier. Le nom du fichier apparaît dans la fenêtre de
125 l'"*Arbre d'étude*", sous le menu "*ADAO*". La définition finale du cas
128 .. _adao_jdcexample01:
129 .. image:: images/adao_jdcexample01.png
133 **Définition des conditions d'expérience choisies pour le cas ADAO**
135 Pour poursuivre, on a besoin de générer le schéma YACS à partir de la définition
136 du cas ADAO. Pour faire cela, on peut activer le menu contextuel par click droit
137 sur le nom du cas dans la fenêtre de l'"*Arbre d'étude*", et choisir le
138 sous-menu "*Exporter vers YACS*" (ou le bouton "*Exporter vers YACS*"
139 |eficas_yacs|) comme ci-dessous :
141 .. _adao_exporttoyacs00:
142 .. image:: images/adao_exporttoyacs.png
146 **Sous-menu contextuel "*Exporter vers YACS*" pour générer le schéma YACS à partir du cas ADAO**
148 Cette commande conduit à la génération d'un schéma YACS, à l'activation du module
149 YACS dans SALOME, et à ouvrir le nouveau schéma dans l'interface graphique du
150 module YACS [#]_. Après avoir éventuellement réorganisé les noeuds en utilisant
151 le sous-menu contextuel "*arranger les noeuds locaux*" de la vue graphique du
152 schéma YACS, on obtient la représentation suivante du schéma ADAO généré :
154 .. _yacs_generatedscheme:
155 .. image:: images/yacs_generatedscheme.png
159 **Schéma YACS généré à partir du cas ADAO**
161 Après ce point, toutes les modifications, exécutions et post-processing du
162 schéma d'assimilation de données seront effectués dans le module YACS. De
163 manière à vérifier les résultats d'une manière simple, on crée ici un nouveau
164 noeud YACS en utilisant le sous-menu "*Noeud de script in-line*" dans la vue
165 graphique de YACS, et on le nomme "*PostProcessing*".
167 Ce noeud de script va récupérer l'analyse issue de l'assimilation de données
168 depuis le port de sortie "*algoResults*" du bloc de calcul (qui donne accés à un
169 objet Python SALOME), et va l'afficher à la sortie standard.
171 Pour obtenir ceci, ce noeud de script doit comporter un port d'entrée de type
172 "*pyobj*", nommé "*results*" par exemple, qui doit être relié graphiquement au
173 port de sortie "*algoResults*" du bloc de calcul. Ensuite, le code pour remplir
174 le noeud de script est::
176 Xa = results.ADD.get("Analysis")[-1]
179 print "Analysis =",Xa
182 Le schéma YACS complété peut être enregistré (en écrasant le schéma généré si la
183 commande ou le bouton "*Enregistrer*" sont utilisés, ou sinon avec un nom
184 nouveau par la commande "*Enregistrer sous*"). De manière pratique, la mise au
185 point d'une telle procédure de post-processing peut être réalisée dans YACS pour
186 la tester, et ensuite entièrement enregistrée dans un script Python qui peut
187 être intégré au cas ADAO en utilisant le mot-clé "*UserPostAnalysis*".
189 Ensuite, de manière classique dans YACS, le schéma doit être compilé, et ensuite
190 être exécuté. Après la fin de l'exécution, les affichages sur la sortie standard
191 sont disponibles dans la fenêtre "*fenêtre de sortie de YACS*" (ou "*YACS
192 Container Log*"), obtenue par clic droit à l'aide du menu contextuel de la
193 fenêtre "*proc*" du schéma YACS comme montré ci-dessous:
195 .. _yacs_containerlog:
196 .. image:: images/yacs_containerlog.png
200 **Menu YACS de la fenêtre de sortie, et boite de dialogue montrant la sortie**
202 On vérifie que le résultat est correct en observant si la fenêtre de sortie
203 contient la ligne suivante::
205 Analysis = [0.5, 0.5, 0.5]
207 comme montré dans l'image précédente.
209 Pour étendre cet exemple, on peut remarquer que le même problème résolu par un
210 algorithme de 3DVAR donne le même résultat. Cet algorithme peut être choisi lors
211 de l'étape de construction du cas ADAO, avant d'entrer dans l'étape YACS. Le cas
212 ADAO en 3DVAR est entièrement similaire au cas algorithmique du BLUE, comme
213 montré dans la figure suivante:
215 .. _adao_jdcexample02:
216 .. image:: images/adao_jdcexample02.png
220 **Définir un cas ADAO en 3DVAR est entièrement similaire à un cas en BLUE**
222 Il n'y a qu'une seule commande qui change, avec "*3DVAR*" dans le champ
223 "*Algorithm*" à la place de "*Blue*".
225 Construire un cas d'estimation avec une définition de données externes par scripts
226 ----------------------------------------------------------------------------------
228 Il est utile d'acquérir une partie ou la totalité des données depuis une
229 définition externe, en utilisant des scripts Python pour donner accès à ces
230 données. À titre d'exemple, on construit ici un cas ADAO présentant le même
231 dispositif expérimental que dans l'exemple ci-dessus `Construire un cas
232 d'estimation avec une définition explicite des données`_, mais en utilisant des
233 données issues d'un unique fichier script Python externe.
235 En premier lieu, on écrit le fichier script suivant, utilisant des noms
236 conventionnels pour les variables requises. Ici toutes les variables sont
237 définies dans le même script, mais l'utilisateur peut choisir de séparer le
238 fichier en plusieurs autres, ou de mélanger une définition explicite des données
239 dans l'interface graphique ADAO et une définition implicite dans des fichiers
240 externes. Le fichier script actuel ressemble à::
244 # Definition of the Background as a vector
245 # ----------------------------------------
246 Background = [0, 0, 0]
248 # Definition of the Observation as a vector
249 # -----------------------------------------
250 Observation = "1 1 1"
252 # Definition of the Background Error covariance as a matrix
253 # ---------------------------------------------------------
254 BackgroundError = numpy.array([[1., 0., 0.], [0., 1., 0.], [0., 0., 1.]])
256 # Definition of the Observation Error covariance as a matrix
257 # ----------------------------------------------------------
258 ObservationError = numpy.matrix("1 0 0 ; 0 1 0 ; 0 0 1")
260 # Definition of the Observation Operator as a matrix
261 # --------------------------------------------------
262 ObservationOperator = numpy.identity(3)
264 Les noms des variables Python sont obligatoires, de manière à définir les bonnes
265 variables dans le cas, mais le script Python peut être plus conséquent et
266 définir des classes, des fonctions, des accès à des fichiers ou des bases de
267 données, etc. avec des noms différents. De plus, le fichier ci-dessus présente
268 différentes manières de définir des vecteurs ou des matrices, utilisant des
269 listes, des chaînes de caractères (comme dans Numpy ou Octave), des types
270 vecteur ou matrice de Numpy, et des fonctions spéciales de Numpy. Toutes ces
271 syntaxes sont valides.
273 Après avoir enregistré ce script dans un fichier (nommé ici "*script.py*" pour
274 l'exemple) à un endroit quelconque dans l'arborescence de l'utilisateur, on
275 utilise l'interface graphique (GUI) pour construire le cas ADAO. La procédure
276 pour compléter le cas est similaire à celle de l'exemple précédent à part le
277 fait que, au lieu de choisir l'option "*String*" pour le mot-clé "*FROM*" de
278 chaque variable, on choisit l'option "*Script*". Cela conduit à une entrée
279 "*SCRIPT_DATA/SCRIPT_FILE*" dans l'arbre graphique, permettant de choisir un
280 fichier de la manière suivante:
282 .. _adao_scriptentry01:
283 .. image:: images/adao_scriptentry01.png
287 **Définir une variable d'entrée en utilisant un fichier script externe**
289 Les autres étapes et résultats sont exactement les mêmes que dans l'exemple
290 précédent `Construire un cas d'estimation avec une définition explicite des
293 Dans la pratique, cette démarche par scripts est la manière la plus facile pour
294 récupérer des information depuis des calculs en ligne ou préalables, depuis des
295 fichiers statiques, depuis des bases de données ou des flux informatiques,
296 chacun pouvant être dans ou hors SALOME. Cela permet aussi de modifier aisément
297 des données d'entrée, par exemple à des fin de débogage ou pour des traitements
298 répétitifs, et c'est la méthode la plus polyvalente pour paramétrer les données
299 d'entrée. **Mais attention, la méthodologie par scripts n'est pas une procédure
300 "sûre", en ce sens que des données erronées ou des erreurs dans les calculs,
301 peuvent être directement introduites dans l'exécution du schéma YACS.**
303 Ajout de paramètres pour contrôler l'algorithme d'assimilation de données
304 -------------------------------------------------------------------------
306 On peut ajouter des paramètres optionnels pour contrôler le calcul de
307 l'algorithme d'assimilation de données. Ceci se fait en utilisant le mot-clé
308 "*AlgorithmParameters*" dans la définition du cas ADAO, qui est un mot-clé de la
309 commande générale "*ASSIMILATION_STUDY*". Ce mot-clé nécessite un dictionnaire
310 Python, contenant des paires clé/valeur. La liste des paramètres optionnels
311 possibles sont donnés dans la section :ref:`section_reference`.
313 Le dictionnaire doit être défini, par exemple, dans un fichiers externe de
314 script Python, en utilisant le nom obligatoire de variable
315 "*AlgorithmParameters*" pour le dictionnaire. Toutes les clés dans le
316 dictionnaire sont optionnelles, elles disposent toutes d'une valeur par défaut,
317 et elles peuvent être présentes sans être utiles. Par exemple::
319 AlgorithmParameters = {
320 "Minimizer" : "CG", # Choix possible : "LBFGSB", "TNC", "CG", "BFGS"
321 "MaximumNumberOfSteps" : 10,
324 Si aucune borne n'est requise sur les variables de contrôle, alors on peut
325 choisir les algorithmes de minimisation "*BFGS*" ou "*CG*" pour tous les
326 algorithmes variationnels d'assimilation de données ou d'optimisation. Pour
327 l'optimisation sous contraintes, le minimiseur "*LBFGSB*" est souvent plus
328 robuste, mais le "*TNC*" est parfois plus performant.
330 Ensuite le script peut être ajouté au cas ADAO, dans une entrée de type fichier
331 pour le mot-clé "*AlgorithmParameters*", de la manière suivante:
333 .. _adao_scriptentry02:
334 .. image:: images/adao_scriptentry02.png
338 **Ajouter des paramètres pour contrôler l'algorithme et les sorties**
340 Les autres étapes et résultats sont exactement les mêmes que dans l'exemple
341 précédent `Construire un cas d'estimation avec une définition explicite des
342 données`_. Le dictionnaire peut aussi être donné directement dans le champ
343 d'entrée de type chaîne de caractères pour le mot-clé.
345 Construire un cas complexe avec une définition de données externes par scripts
346 ------------------------------------------------------------------------------
348 Cet exemple plus complexe et complet peut être considéré comme un cadre de base
349 pour le traitement des entrées de l'utilisateur, qui doit ensuite être adapté à
350 chaque application réelle. Néanmoins, les squelettes de fichiers sont
351 suffisamment généraux pour avoir été utilisés pour des applications variées en
352 neutronique, mécanique des fluides... Ici, on ne s'intéresse pas aux résultats,
353 mais plus sur le contrôle de l'utilisateur des entrées et sorties dans un cas
354 ADAO. Comme précédemment, toutes les valeurs numériques de cet exemple sont
357 L'objectif est de configurer les entrées et les sortie d'un problème physique
358 d'estimation par des scripts externes Python, en utilisant un opérateur
359 non-linéaire général, en ajoutant un contrôle sur les paramètres et ainsi de
360 suite... Les scripts complets peuvent être trouvés dans le répertoire des
361 exemples de squelettes ADAO sous le nom de
362 "*External_data_definition_by_scripts*".
364 Conditions d'expérience
365 +++++++++++++++++++++++
367 On continue à opérer dans un espace à 3 dimensions, afin de limiter la taille de
368 l'objet numérique indiqué dans les scripts, mais le problème ne dépend pas de la
371 On choisit un contexte d'expériences jumelles, en utilisant un état vrai
372 :math:`\mathbf{x}^t` connu, mais de valeur arbitraire::
376 L'état d'ébauche :math:`\mathbf{x}^b`, qui représentent une connaissance *a
377 priori* de l'état vrai, est construit comme une perturbation aléatoire
378 gaussienne de 20% de l'état vrai :math:`\mathbf{x}^t` pour chaque composante,
381 Xb = Xt + normal(0, 20%*Xt)
383 Pour décrire la matrice des covariances d'erreur d'ébauche math:`\mathbf{B}`, on
384 fait comme précédemment l'hypothèse d'erreurs décorrélées (c'est-à-dire, une
385 matrice diagonale, de taille 3x3 parce-que :math:`\mathbf{x}^b` est de taille 3)
386 et d'avoir la même variance de 0,1 pour toutes les variables. On obtient::
388 B = 0.1 * diagonal( length(Xb) )
390 On suppose qu'il existe un opérateur d'observation :math:`\mathbf{H}`, qui peut
391 être non linéaire. Dans une procédure réelle de recalage ou de problème inverse,
392 les codes de simulation physique sont intégrés dans l'opérateur d'observation.
393 On a également besoin de connaître son gradient par rapport à chaque variable
394 estimée, ce qui est une information rarement connu avec les codes industriels.
395 Mais on verra plus tard comment obtenir un gradient approché dans ce cas.
397 Étant en expériences jumelles, les observations :math:`\mathbf{y}^o` et leur
398 matrice de covariances d'erreurs :math:`\mathbf{R}` sont générées en utilisant
399 l'état vrai :math:`\mathbf{x}^t` et l'opérateur d'observation
404 et, avec un écart-type arbitraire de 1% sur chaque composante de l'erreur::
406 R = 0.0001 * diagonal( lenght(Yo) )
408 Toutes les informations requises pour l'estimation par assimilation de données
409 sont maintenant définies.
411 Squelettes des scripts décrivant les conditions d'expérience
412 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
414 On donne ici les éléments essentiels de chaque script utilisé par la suite pour
415 construire le cas ADAO. On rappelle que l'utilisation de ces scripts dans de
416 réels fichiers Python nécessite de définir correctement le chemin de modules ou
417 des codes importés (même si le module est dans le même répertoire que le fichier
418 Python qui l'importe. On indique le chemin à renseigner en utilisant la mention
419 ``"# INSERT PHYSICAL SCRIPT PATH"``), l'encodage si nécessaire, etc. Les noms de
420 fichiers indiqués pour les scripts qui suivent sont arbitraires. Des exemples
421 complets de fichiers scripts sont disponibles dans le répertoire standard des
424 On définit en premier lieu l'état vrai :math:`\mathbf{x}^t` et une fonction
425 utiles à la construction de matrices, dans un fichier script Python nommé
426 ``Physical_data_and_covariance_matrices.py``::
432 Arbitrary values and names, as a tuple of two series of same length
434 return (numpy.array([1, 2, 3]), ['Para1', 'Para2', 'Para3'])
436 def Simple_Matrix( size, diagonal=None ):
438 Diagonal matrix, with either 1 or a given vector on the diagonal
440 if diagonal is not None:
441 S = numpy.diag( diagonal )
443 S = numpy.matrix(numpy.identity(int(size)))
446 On définit ensuite l'état d'ébauche :math:`\mathbf{x}^b` comme une perturbation
447 aléatoire de l'état vrai, en ajoutant une *variable ADAO requise* à la fin du
448 script de définition, de manière à exporter la valeur définie. C'est réalisé
449 dans un fichier de script Python nommé ``Script_Background_xb.py``::
451 from Physical_data_and_covariance_matrices import True_state
454 xt, names = True_state()
456 Standard_deviation = 0.2*xt # 20% for each variable
458 xb = xt + abs(numpy.random.normal(0.,Standard_deviation,size=(len(xt),)))
460 # Creating the required ADAO variable
461 # ------------------------------------
462 Background = list(xb)
464 De la même manière, on définit la matrice des covariances de l'erreur d'ébauche
465 :math:`\mathbf{B}` comme une matrice diagonale, de la même longueur de diagonale
466 que l'ébauche de la valeur vraie, en utilisant la fonction d'aide déjà définie.
467 C'est réalisé dans un fichier script Python nommé
468 ``Script_BackgroundError_B.py``::
470 from Physical_data_and_covariance_matrices import True_state, Simple_Matrix
472 xt, names = True_state()
474 B = 0.1 * Simple_Matrix( size = len(xt) )
476 # Creating the required ADAO variable
477 # -----------------------------------
480 Pour poursuivre, on a besoin de l'opérateur d'observation :math:`\mathbf{H}`
481 comme une fonction de l'état. Il est ici défini dans un fichier externe nommé
482 ``"Physical_simulation_functions.py"``, qui doit contenir une fonction appelée
483 ``"DirectOperator"``. Cette fonction est une une fonction utilisateur,
484 représentant de manière programmée l'opérateur :math:`\mathbf{H}`. On suppose
485 que cette fonction est donnée par l'utilisateur. Un squelette simple est donné
488 def DirectOperator( XX ):
489 """ Direct non-linear simulation operator """
491 # --------------------------------------> EXAMPLE TO BE REMOVED
492 if type(XX) is type(numpy.matrix([])): # EXAMPLE TO BE REMOVED
493 HX = XX.A1.tolist() # EXAMPLE TO BE REMOVED
494 elif type(XX) is type(numpy.array([])): # EXAMPLE TO BE REMOVED
495 HX = numpy.matrix(XX).A1.tolist() # EXAMPLE TO BE REMOVED
496 else: # EXAMPLE TO BE REMOVED
497 HX = XX # EXAMPLE TO BE REMOVED
498 # --------------------------------------> EXAMPLE TO BE REMOVED
500 return numpy.array( HX )
502 On n'a pas besoin des opérateurs linéaires associés ``"TangentOperator"`` et
503 ``"AdjointOperator"`` car ils vont être approximés en utilisant les capacités
506 On insiste sur le fait que ces opérateurs non-linéaire ``"DirectOperator"``,
507 linéaire tangent ``"TangentOperator"`` et linéaire adjoint ``"AdjointOperator"``
508 proviennent de la connaissance de la physique, incluant le code de simulation de
509 référence physique, et doivent être soigneusement mis au point par l'utilisateur
510 de l'assimilation de données ou de l'optimisation. Les erreurs de simulation ou
511 d'usage des opérateurs ne peuvent pas être détectés ou corrigés par
512 l'environnement seul ADAO d'assimilation de données et d'optimisation.
514 Dans cet environnement d'expériences jumelles, l'observation
515 :math:`\mathbf{y}^o` et sa matrice des covariances d'erreur :math:`\mathbf{R}`
516 peuvent être générées. C'est réalisé dans deux fichiers de script Python, le
517 premier étant nommé ``Script_Observation_yo.py``::
519 from Physical_data_and_covariance_matrices import True_state
520 from Physical_simulation_functions import DirectOperator
522 xt, noms = True_state()
524 yo = DirectOperator( xt )
526 # Creating the required ADAO variable
527 # -----------------------------------
528 Observation = list(yo)
530 et le second nommé ``Script_ObservationError_R.py``::
532 from Physical_data_and_covariance_matrices import True_state, Simple_Matrix
533 from Physical_simulation_functions import DirectOperator
535 xt, names = True_state()
537 yo = DirectOperator( xt )
539 R = 0.0001 * Simple_Matrix( size = len(yo) )
541 # Creating the required ADAO variable
542 # -----------------------------------
545 Comme dans les exemples précédents, il peut être utile de définir certains
546 paramètres pour l'algorithme d'assimilation de données. Par exemple, si on
547 utilise l'algorithme standard de "*3DVAR*", les paramètres suivants peuvent être
548 définis dans un fichier de script Python nommé
549 ``Script_AlgorithmParameters.py``::
551 # Creating the required ADAO variable
552 # -----------------------------------
553 AlgorithmParameters = {
554 "Minimizer" : "TNC", # Possible : "LBFGSB", "TNC", "CG", "BFGS"
555 "MaximumNumberOfSteps" : 15, # Number of global iterative steps
557 [ None, None ], # Bound on the first parameter
558 [ 0., 4. ], # Bound on the second parameter
559 [ 0., None ], # Bound on the third parameter
563 Enfin, il est courant de post-traiter les résultats, en les récupérant aprés la
564 phase d'assimilation de données de manière à les analyser, les afficher ou les
565 représenter. Cela nécessite d'utiliser un fichier script Python intermédiaire de
566 manière à extraire ces résultats à la fin de la procédure d'assimilation de
567 données ou d'optimisation. L'exemple suivant de fichier script Python, nommé
568 ``Script_UserPostAnalysis.py``, illustre le fait::
570 from Physical_data_and_covariance_matrices import True_state
573 xt, names = True_state()
574 xa = ADD.get("Analysis")[-1]
575 x_series = ADD.get("CurrentState")[:]
576 J = ADD.get("CostFunctionJ")[:]
578 # Verifying the results by printing
579 # ---------------------------------
582 print "xa = %s"%numpy.array(xa)
584 for i in range( len(x_series) ):
585 print "Etape %2i : J = %.5e et X = %s"%(i, J[i], x_series[i])
588 Finalement, on obtient la description de l'ensemble des conditions
589 d'expériences à travers la série de fichiers listée ici:
591 #. ``Physical_data_and_covariance_matrices.py``
592 #. ``Physical_simulation_functions.py``
593 #. ``Script_AlgorithmParameters.py``
594 #. ``Script_BackgroundError_B.py``
595 #. ``Script_Background_xb.py``
596 #. ``Script_ObservationError_R.py``
597 #. ``Script_Observation_yo.py``
598 #. ``Script_UserPostAnalysis.py``
600 On insiste ici sur le fait que tous ces scripts sont écrits par l'utilisateur et
601 ne peuvent être testés automatiquement par ADAO. Ainsi, l'utilisateur est tenu
602 de vérifier les scripts (et en particulier leurs entrées/sorties) afin de
603 limiter les difficultés de débogage. On rappelle que: **la méthodologie par
604 scripts n'est pas une procédure "sûre", en ce sens que des données erronées ou
605 des erreurs dans les calculs, peuvent être directement introduites dans
606 l'exécution du schéma YACS.**
608 Construire la cas avec une définition de données externes par scripts
609 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
611 Tous ces scripts peuvent ensuite être utilisés pour définir le cas ADAO avec une
612 définition de données externes par des fichiers de script Python. Cela se
613 réalise de manière tout à fait similaire à la méthode décrite dans la partie
614 précédente `Construire un cas d'estimation avec une définition de données
615 externes par scripts`_. Pour chaque variable à définir, on sélectionne l'option
616 "*Script*" du mot-clé "*FROM*", ce qui conduit à une entrée
617 "*SCRIPT_DATA/SCRIPT_FILE*" dans l'arbre graphique. Pour le mot-clé
618 "*ObservationOperator*", on choisit la forme "*ScriptWithOneFunction*" et on
619 conserve la valeur par défaut de l'incrément différentiel.
621 Les autres étapes pour construire le cas ADAO sont exactement les mêmes que dans
622 la partie précédente `Construire un cas d'estimation avec une définition
623 explicite des données`_.
625 En utilisant l'opérateur linéaire simple :math:`\mathbf{H}` du fichier script
626 Python ``Physical_simulation_functions.py`` disponible dans le répertoire
627 standard des exemples, les résultats ressemblent à::
630 xa = [ 1.000014 2.000458 3.000390]
632 Etape 0 : J = 1.81750e+03 et X = [1.014011, 2.459175, 3.390462]
633 Etape 1 : J = 1.81750e+03 et X = [1.014011, 2.459175, 3.390462]
634 Etape 2 : J = 1.79734e+01 et X = [1.010771, 2.040342, 2.961378]
635 Etape 3 : J = 1.79734e+01 et X = [1.010771, 2.040342, 2.961378]
636 Etape 4 : J = 1.81909e+00 et X = [1.000826, 2.000352, 3.000487]
637 Etape 5 : J = 1.81909e+00 et X = [1.000826, 2.000352, 3.000487]
638 Etape 6 : J = 1.81641e+00 et X = [1.000247, 2.000651, 3.000156]
639 Etape 7 : J = 1.81641e+00 et X = [1.000247, 2.000651, 3.000156]
640 Etape 8 : J = 1.81569e+00 et X = [1.000015, 2.000432, 3.000364]
641 Etape 9 : J = 1.81569e+00 et X = [1.000015, 2.000432, 3.000364]
642 Etape 10 : J = 1.81568e+00 et X = [1.000013, 2.000458, 3.000390]
645 L'état au premier pas est l'état d'ébauche :math:`\mathbf{x}^b` généré
646 aléatoirement. Au cours du calcul, ces affichages sur la sortie standard sont
647 disponibles dans la fenêtre "*fenêtre de sortie de YACS*", que l'on obtient par
648 clic droit sur la fenêtre "*proc*" du schéma YACS exécuté.
650 .. [#] Pour de plus amples informations sur YACS, voir le *Guide utilisateur du module YACS* disponible dans le menu principal *Aide* de l'environnement SALOME.
