From 0a7e156b0513dfcf70fdbcb7e058910afe7f659a Mon Sep 17 00:00:00 2001 From: Jean-Philippe ARGAUD Date: Sun, 4 Jun 2017 23:26:02 +0200 Subject: [PATCH] Python 3 compatibility improvement (doc) --- doc/fr/advanced.rst | 423 ++++++------- doc/fr/bibliography.rst | 24 +- doc/fr/conf.py | 5 +- doc/fr/examples.rst | 524 ++++++++-------- doc/fr/glossary.rst | 106 ++-- doc/fr/index.rst | 66 +- doc/fr/intro.rst | 40 +- doc/fr/license.rst | 10 +- doc/fr/methodology.rst | 286 ++++----- doc/fr/ref_algorithm_3DVAR.rst | 294 ++++----- doc/fr/ref_algorithm_4DVAR.rst | 208 +++---- doc/fr/ref_algorithm_AdjointTest.rst | 116 ++-- doc/fr/ref_algorithm_Blue.rst | 198 +++--- ...f_algorithm_DerivativeFreeOptimization.rst | 192 +++--- doc/fr/ref_algorithm_EnsembleBlue.rst | 108 ++-- doc/fr/ref_algorithm_ExtendedBlue.rst | 200 +++--- doc/fr/ref_algorithm_ExtendedKalmanFilter.rst | 140 ++--- doc/fr/ref_algorithm_FunctionTest.rst | 96 +-- doc/fr/ref_algorithm_GradientTest.rst | 178 +++--- doc/fr/ref_algorithm_KalmanFilter.rst | 132 ++-- doc/fr/ref_algorithm_LinearLeastSquares.rst | 100 +-- doc/fr/ref_algorithm_LinearityTest.rst | 212 +++---- .../ref_algorithm_NonLinearLeastSquares.rst | 190 +++--- doc/fr/ref_algorithm_ObserverTest.rst | 38 +- ...ef_algorithm_ParticleSwarmOptimization.rst | 198 +++--- doc/fr/ref_algorithm_QuantileRegression.rst | 148 ++--- doc/fr/ref_algorithm_SamplingTest.rst | 194 +++--- doc/fr/ref_algorithm_TangentTest.rst | 132 ++-- .../ref_algorithm_UnscentedKalmanFilter.rst | 154 ++--- doc/fr/ref_assimilation_keywords.rst | 154 ++--- doc/fr/ref_checking_keywords.rst | 102 ++-- doc/fr/ref_covariance_requirements.rst | 86 +-- doc/fr/ref_entry_types.rst | 68 +-- doc/fr/ref_observers_requirements.rst | 172 +++--- doc/fr/ref_operator_requirements.rst | 256 ++++---- doc/fr/ref_options_AlgorithmParameters.rst | 90 +-- doc/fr/ref_output_variables.rst | 294 ++++----- doc/fr/reference.rst | 68 +-- doc/fr/theory.rst | 440 +++++++------- doc/fr/tui.rst | 569 +++++++++--------- doc/fr/using.rst | 240 ++++---- 41 files changed, 3626 insertions(+), 3625 deletions(-) diff --git a/doc/fr/advanced.rst b/doc/fr/advanced.rst index 0600f88..d06f804 100644 --- a/doc/fr/advanced.rst +++ b/doc/fr/advanced.rst @@ -24,88 +24,88 @@ .. _section_advanced: ================================================================================ -**[DocU]** Usages avancés du module ADAO +**[DocU]** Usages avancés du module ADAO ================================================================================ -Cette section présente des méthodes avancées d'usage du module ADAO, comment +Cette section présente des méthodes avancées d'usage du module ADAO, comment obtenir plus d'information lors d'un calcul, ou comment l'utiliser sans -l'interface graphique (GUI). Cela nécessite de savoir comment trouver les -fichiers ou les commandes incluses dans l'installation complète de SALOME. Tous -les noms à remplacer par l'utilisateur sont indiqués par la syntaxe ``<...>``. +l'interface graphique (GUI). Cela nécessite de savoir comment trouver les +fichiers ou les commandes incluses dans l'installation complète de SALOME. Tous +les noms à remplacer par l'utilisateur sont indiqués par la syntaxe ``<...>``. -Convertir et exécuter un fichier de commandes ADAO (JDC) par l'intermédiaire d'un script Shell +Convertir et exécuter un fichier de commandes ADAO (JDC) par l'intermédiaire d'un script Shell ---------------------------------------------------------------------------------------------- -Il est possible de convertir et exécuter une fichier de commandes ADAO (JDC, ou -paire de fichiers ".comm/.py", qui se trouvent dans le répertoire ````) automatiquement en utilisant un script de commandes -Shell "type" contenant toutes les étapes requises. Si la commande principale de -lancement de SALOME, nommée ``salome``, n'est pas couramment accessible dans un -terminal courant, l'utilisateur doit savoir où se trouvent les principaux +Shell "type" contenant toutes les étapes requises. Si la commande principale de +lancement de SALOME, nommée ``salome``, n'est pas couramment accessible dans un +terminal courant, l'utilisateur doit savoir où se trouvent les principaux fichiers de lancement de SALOME, et en particulier ce fichier ``salome``. Le -répertoire dans lequel ce fichier réside est symboliquement nommé ```` et doit être remplacé par le bon dans le -modèle "type" de fichier Shell. - -Lorsqu'un fichier de commande ADAO est construit par l'interface d'édition -graphique d'ADAO et est enregistré, s'il est nommé par exemple -"EtudeAdao1.comm", alors un fichier compagnon nommé "EtudeAdao1.py" est -automatiquement créé dans la même répertoire. Il est nommé ```` dans le modèle "type", et il est converti vers YACS comme un ```` sous la forme d'un fichier en ".xml" nommé "EtudeAdao1.xml". -Ensuite, ce dernier peut être exécuté en mode console en utilisant l'ordre +répertoire dans lequel ce fichier réside est symboliquement nommé ```` et doit être remplacé par le bon dans le +modèle "type" de fichier Shell. + +Lorsqu'un fichier de commande ADAO est construit par l'interface d'édition +graphique d'ADAO et est enregistré, s'il est nommé par exemple +"EtudeAdao1.comm", alors un fichier compagnon nommé "EtudeAdao1.py" est +automatiquement créé dans la même répertoire. Il est nommé ```` dans le modèle "type", et il est converti vers YACS comme un ```` sous la forme d'un fichier en ".xml" nommé "EtudeAdao1.xml". +Ensuite, ce dernier peut être exécuté en mode console en utilisant l'ordre standard du mode console de YACS (voir la documentation YACS pour de plus amples informations). Dans tous les exemples de fichiers de commandes Shell de lancement, on choisit -de démarrer et arrêter le serveur d'application SALOME dans le même script. Ce -n'est pas indispensable, mais c'est utile pour éviter des sessions SALOME en +de démarrer et arrêter le serveur d'application SALOME dans le même script. Ce +n'est pas indispensable, mais c'est utile pour éviter des sessions SALOME en attente. -L'exemple le plus simple consiste uniquement à lancer l'exécution d'un schéma -YACS donné, qui a préalablement été généré par l'utilisateur en interface +L'exemple le plus simple consiste uniquement à lancer l'exécution d'un schéma +YACS donné, qui a préalablement été généré par l'utilisateur en interface graphique. Dans ce cas, en ayant pris soin de remplacer les textes contenus entre les symboles ``<...>``, il suffit d'enregistrer le script de commandes Shell suivant:: #!/bin/bash - USERDIR="" - SALOMEDIR="" + USERDIR="" + SALOMEDIR="" $SALOMEDIR/salome start -k -t - $SALOMEDIR/salome shell -- "driver $USERDIR/" + $SALOMEDIR/salome shell -- "driver $USERDIR/" $SALOMEDIR/salome shell killSalome.py -Il faut ensuite le rendre exécutable pour l'exécuter. +Il faut ensuite le rendre exécutable pour l'exécuter. -Un exemple une peu plus complet consiste à lancer l'exécution d'un schéma YACS -indiqué par l'utilisateur, en ayant préalablement vérifié sa disponibilité. Pour -cela, en remplaçant le texte ````, il suffit d'enregistrer le script de commandes Shell suivant:: #!/bin/bash if (test $# != 1) then - echo -e "\nUsage: $0 \n" + echo -e "\nUsage: $0 \n" exit else USERFILE="$1" fi if (test ! -e $USERFILE) then - echo -e "\nErreur : le fichier XML nommé $USERFILE n'existe pas.\n" + echo -e "\nErreur : le fichier XML nommé $USERFILE n'existe pas.\n" exit else - SALOMEDIR="" + SALOMEDIR="" $SALOMEDIR/salome start -k -t $SALOMEDIR/salome shell -- "driver $USERFILE" $SALOMEDIR/salome shell killSalome.py fi -Un autre exemple de script consiste à ajouter la conversion du fichier de -commandes ADAO (JDC, ou paire de fichiers ".comm/.py") en un schéma YACS associé +Un autre exemple de script consiste à ajouter la conversion du fichier de +commandes ADAO (JDC, ou paire de fichiers ".comm/.py") en un schéma YACS associé (fichier ".xml"). A la fin du script, on choisit aussi de supprimer le fichier -de ```` car c'est un fichier généré. Pour cela, en ayant -bien pris soin de remplacer le texte ```` car c'est un fichier généré. Pour cela, en ayant +bien pris soin de remplacer le texte ````, il suffit d'enregistrer le script de commandes Shell suivant:: #!/bin/bash @@ -121,10 +121,10 @@ SALOME>``, il suffit d'enregistrer le script de commandes Shell suivant:: fi if (test ! -e $USERFILE.py) then - echo -e "\nErreur : le fichier PY nommé $USERFILE.py n'existe pas.\n" + echo -e "\nErreur : le fichier PY nommé $USERFILE.py n'existe pas.\n" exit else - SALOMEDIR="" + SALOMEDIR="" $SALOMEDIR/salome start -k -t $SALOMEDIR/salome shell -- "python $SALOMEDIR/bin/salome/AdaoYacsSchemaCreator.py $USERFILE.py $USERFILE.xml" $SALOMEDIR/salome shell -- "driver $USERFILE.xml" @@ -135,20 +135,20 @@ SALOME>``, il suffit d'enregistrer le script de commandes Shell suivant:: Dans tous les cas, les sorties standard et d'erreur se font dans le terminal de lancement. -Exécuter un schéma de calcul ADAO dans YACS en utilisant le mode "texte" (TUI YACS) +Exécuter un schéma de calcul ADAO dans YACS en utilisant le mode "texte" (TUI YACS) ----------------------------------------------------------------------------------- -Cette section décrit comment exécuter en mode TUI (Text User Interface) YACS un -schéma de calcul YACS, obtenu dans l'interface graphique par la fonction +Cette section décrit comment exécuter en mode TUI (Text User Interface) YACS un +schéma de calcul YACS, obtenu dans l'interface graphique par la fonction "*Exporter vers YACS*" d'ADAO. Cela utilise le mode texte standard de YACS, qui -est rapidement rappelé ici (voir la documentation YACS pour de plus amples -informations) à travers un exemple simple. Comme décrit dans la documentation, -un schéma XML peut être chargé en python. On donne ici une séquence complète de -commandes pour tester la validité du schéma avant de l'exécuter, ajoutant des -lignes supplémentaires initiales pour charger de manière explicite le catalogue -de types pour éviter d'obscures difficultés:: - - #-*-coding:iso-8859-1-*- +est rapidement rappelé ici (voir la documentation YACS pour de plus amples +informations) à travers un exemple simple. Comme décrit dans la documentation, +un schéma XML peut être chargé en python. On donne ici une séquence complète de +commandes pour tester la validité du schéma avant de l'exécuter, ajoutant des +lignes supplémentaires initiales pour charger de manière explicite le catalogue +de types pour éviter d'obscures difficultés:: + + #-*- coding: utf-8 -*- import pilot import SALOMERuntime import loader @@ -158,13 +158,13 @@ de types pour xmlLoader = loader.YACSLoader() xmlLoader.registerProcCataLoader() try: - catalogAd = r.loadCatalog("proc", "") + catalogAd = r.loadCatalog("proc", "") + r.addCatalog(catalogAd) except: - pass - r.addCatalog(catalogAd) + pass try: - p = xmlLoader.load("") + p = xmlLoader.load("") except IOError,ex: print "IO exception:",ex @@ -174,13 +174,13 @@ de types pour print logger.getStr() if not p.isValid(): - print "Le schéma n'est pas valide et ne peut pas être exécuté" + print "Le schéma n'est pas valide et ne peut pas être exécuté" print p.getErrorReport() info=pilot.LinkInfo(pilot.LinkInfo.ALL_DONT_STOP) p.checkConsistency(info) if info.areWarningsOrErrors(): - print "Le schéma n'est pas cohérent et ne peut pas être exécuté" + print "Le schéma n'est pas cohérent et ne peut pas être exécuté" print info.getGlobalRepr() e = pilot.ExecutorSwig() @@ -188,43 +188,43 @@ de types pour if p.getEffectiveState() != pilot.DONE: print p.getErrorReport() -Cette démarche permet par exemple d'éditer le schéma YACS XML en mode texte TUI, -ou de rassembler les résultats pour un usage ultérieur. +Cette démarche permet par exemple d'éditer le schéma YACS XML en mode texte TUI, +ou de rassembler les résultats pour un usage ultérieur. .. _section_advanced_R: -Exécuter un calcul ADAO en environnement R en utilisant l'interface TUI ADAO +Exécuter un calcul ADAO en environnement R en utilisant l'interface TUI ADAO ---------------------------------------------------------------------------- .. index:: single: R .. index:: single: rPython -Pour étendre les possibilités d'analyse et de traitement, il est possible +Pour étendre les possibilités d'analyse et de traitement, il est possible d'utiliser les calculs ADAO dans l'environnement **R** (voir [R]_ pour plus de -détails). Ce dernier est disponible dans SALOME en lançant l'interpréteur R dans +détails). Ce dernier est disponible dans SALOME en lançant l'interpréteur R dans le shell "``salome shell``". Il faut de plus disposer, en R, du package -"*rPython*", qui peut si nécessaire être installé par l'utilisateur à l'aide de +"*rPython*", qui peut si nécessaire être installé par l'utilisateur à l'aide de la commande R suivante:: - #-*-coding:iso-8859-1-*- + #-*- coding: utf-8 -*- # - # IMPORTANT : à exécuter dans l'interpréteur R + # IMPORTANT : à exécuter dans l'interpréteur R # -------------------------------------------- install.packages("rPython") -On se reportera à la documentation [GilBellosta15]_ pour de plus amples +On se reportera à la documentation [GilBellosta15]_ pour de plus amples renseignements sur ce package. -Les calculs ADAO définis en interface textuelle (API/TUI, voir la -:ref:`section_tui`) peuvent alors être interprétés depuis l'environnement R, en -utilisant des données et des informations depuis R. La démarche est illustrée -sur :ref:`subsection_tui_example`, proposé dans la description de l'interface -API/TUI. Dans l'interpréteur R, on peut exécuter les commandes suivantes, +Les calculs ADAO définis en interface textuelle (API/TUI, voir la +:ref:`section_tui`) peuvent alors être interprétés depuis l'environnement R, en +utilisant des données et des informations depuis R. La démarche est illustrée +sur :ref:`subsection_tui_example`, proposé dans la description de l'interface +API/TUI. Dans l'interpréteur R, on peut exécuter les commandes suivantes, directement issues de l'exemple simple:: - #-*-coding:iso-8859-1-*- + #-*- coding: utf-8 -*- # - # IMPORTANT : à exécuter dans l'interpréteur R + # IMPORTANT : à exécuter dans l'interpréteur R # -------------------------------------------- library(rPython) python.exec(" @@ -241,25 +241,25 @@ directement issues de l'exemple simple:: case.execute() ") -dont le résultat est:: +dont le résultat est:: Analysis [ 0.25000264 0.79999797 0.94999939] -Dans la rédaction des calculs ADAO exécutés depuis R, il convient d'être très +Dans la rédaction des calculs ADAO exécutés depuis R, il convient d'être très attentif au bon usage des guillemets simples et doubles, qui ne doivent pas collisionner entre les deux langages. -Les données peuvent venir l'environnement R et doivent être rangées dans des -variables correctement assignées, pour être utilisées ensuite en Python pour -ADAO. On se reportera à la documentation [GilBellosta15]_ pour la mise en -oeuvre. On peut transformer l'exemple ci-dessus pour utiliser des données -provenant de R pour alimenter les trois variables d'ébauche, d'observation et -d'opérateur d'observation. On récupère à la fin l'état optimal dans une variable +Les données peuvent venir l'environnement R et doivent être rangées dans des +variables correctement assignées, pour être utilisées ensuite en Python pour +ADAO. On se reportera à la documentation [GilBellosta15]_ pour la mise en +oeuvre. On peut transformer l'exemple ci-dessus pour utiliser des données +provenant de R pour alimenter les trois variables d'ébauche, d'observation et +d'opérateur d'observation. On récupère à la fin l'état optimal dans une variable R aussi. Les autres lignes sont identiques. L'exemple devient ainsi:: - #-*-coding:iso-8859-1-*- + #-*- coding: utf-8 -*- # - # IMPORTANT : à exécuter dans l'interpréteur R + # IMPORTANT : à exécuter dans l'interpréteur R # -------------------------------------------- # # Variables R @@ -294,170 +294,171 @@ R aussi. Les autres lignes sont identiques. L'exemple devient ainsi:: xa <- python.get("xa") On remarquera les conversions explicite de type ``str`` et ``list`` pour -s'assurer que les données sont bien transmises en type standards connus du -package "*rPython*". De plus, ce sont les données qui peuvent être transférées -entre les deux langages, et pas des fonctions ou méthodes. Il convient donc -d'élaborer en Python de manière générique les fonctions d'exécution requises par -ADAO, et de leur transmettre ensuite de manière correcte les données disponibles +s'assurer que les données sont bien transmises en type standards connus du +package "*rPython*". De plus, ce sont les données qui peuvent être transférées +entre les deux langages, et pas des fonctions ou méthodes. Il convient donc +d'élaborer en Python de manière générique les fonctions d'exécution requises par +ADAO, et de leur transmettre ensuite de manière correcte les données disponibles en R. -Les cas plus complets, proposés dans les :ref:`subsection_tui_advanced`, peuvent -être exécutés de la même manière, et ils donnent le même résultat que dans +Les cas plus complets, proposés dans les :ref:`subsection_tui_advanced`, peuvent +être exécutés de la même manière, et ils donnent le même résultat que dans l'interface API/TUI en Python standard. .. _section_advanced_observer: -Obtenir des informations sur des variables spéciales au cours d'un calcul ADAO en YACS +Obtenir des informations sur des variables spéciales au cours d'un calcul ADAO en YACS -------------------------------------------------------------------------------------- .. index:: single: Observer .. index:: single: Observer Template -Certaines variables spéciales internes à l'optimisation, utilisées au cours des -calculs, peuvent être surveillées durant un calcul ADAO. Ces variables peuvent -être affichées, tracées, enregistrées, etc. C'est réalisable en utilisant des -"*observer*", qui sont des scripts, chacun associé à une variable. +Certaines variables spéciales internes à l'optimisation, utilisées au cours des +calculs, peuvent être surveillées durant un calcul ADAO. Ces variables peuvent +être affichées, tracées, enregistrées, etc. C'est réalisable en utilisant des +"*observer*", qui sont des commandes rassemblées sous forme de scripts, chacun +associé à une variable. -Des modèles ("templates") sont disponibles lors de l'édition le cas ADAO dans -l'éditeur graphique. Ces scripts simples peuvent être adaptés par l'utilisateur, -soit dans l'étape d'édition intégrée, ou dans l'étape d'édition avant -l'exécution, pour améliorer l'adaptation du calcul ADAO dans le superviseur -d'exécution de SALOME. +Des modèles ("templates") sont disponibles lors de l'édition le cas ADAO dans +l'éditeur graphique. Ces scripts simples peuvent être adaptés par l'utilisateur, +soit dans l'étape d'édition intégrée, ou dans l'étape d'édition avant +l'exécution, pour améliorer l'adaptation du calcul ADAO dans le superviseur +d'exécution de SALOME. -Pour mettre en oeuvre ces "*observer*" de manière efficace, on se reportera aux +Pour mettre en oeuvre ces "*observer*" de manière efficace, on se reportera aux :ref:`ref_observers_requirements`. -Obtenir plus d'information lors du déroulement d'un calcul +Obtenir plus d'information lors du déroulement d'un calcul ---------------------------------------------------------- .. index:: single: Logging -Lors du déroulement d'un calcul, des données et messages utiles sont -disponibles. Il y a deux manières d'obtenir ces informations. +Lors du déroulement d'un calcul, des données et messages utiles sont +disponibles. Il y a deux manières d'obtenir ces informations. -La première, et la manière préférentielle, est d'utiliser la variable interne +La première, et la manière préférentielle, est d'utiliser la variable interne "*Debug*" disponible dans chaque cas ADAO. Elle est atteignable dans l'interface -graphique d'édition du module. La mettre à "*1*" permet d'envoyer des messages -dans la fenêtre de sortie de l'exécution dans YACS ("*YACS Container Log*"). +graphique d'édition du module. La mettre à "*1*" permet d'envoyer des messages +dans la fenêtre de sortie de l'exécution dans YACS ("*YACS Container Log*"). -La seconde consiste à utiliser le module Python natif "*logging*" (voir la +La seconde consiste à utiliser le module Python natif "*logging*" (voir la documentation Python http://docs.python.org/library/logging.html pour de plus -amples informations sur ce module). Dans l'ensemble du schéma YACS, -principalement à travers les entrées sous forme de scripts, l'utilisateur peut -fixer le niveau de logging en accord avec les besoins d'informations détaillées. -Les différents niveaux de logging sont : "*DEBUG*", "*INFO*", "*WARNING*", -"*ERROR*", "*CRITICAL*". Toutes les informations associées à un niveau sont -affichées à tous les niveaux au-dessus de celui-ci (inclut). La méthode la plus -facile consiste à changer le niveau de surveillance en utilisant les lignes +amples informations sur ce module). Dans l'ensemble du schéma YACS, +principalement à travers les entrées sous forme de scripts, l'utilisateur peut +fixer le niveau de logging en accord avec les besoins d'informations détaillées. +Les différents niveaux de logging sont : "*DEBUG*", "*INFO*", "*WARNING*", +"*ERROR*", "*CRITICAL*". Toutes les informations associées à un niveau sont +affichées à tous les niveaux au-dessus de celui-ci (inclut). La méthode la plus +facile consiste à changer le niveau de surveillance en utilisant les lignes Python suivantes:: import logging logging.getLogger().setLevel(logging.DEBUG) -Le niveau par défaut standard de surveillance par logging est "*WARNING*", le -niveau par défaut dans le module ADAO est "*INFO*". +Le niveau par défaut standard de surveillance par logging est "*WARNING*", le +niveau par défaut dans le module ADAO est "*INFO*". -Il est aussi recommandé d'inclure de la surveillance par logging ou des -mécanismes de débogage dans le code de simulation, et de les utiliser en -conjonction avec les deux méthodes précédentes. Néanmoins, il convient d'être -prudent dans le stockage de "grosses" variables car cela coûte du temps, -quel que soit le niveau de surveillance choisi (c'est-à-dire même si ces -variables ne sont pas affichées). +Il est aussi recommandé d'inclure de la surveillance par logging ou des +mécanismes de débogage dans le code de simulation, et de les utiliser en +conjonction avec les deux méthodes précédentes. Néanmoins, il convient d'être +prudent dans le stockage de "grosses" variables car cela coûte du temps, +quel que soit le niveau de surveillance choisi (c'est-à-dire même si ces +variables ne sont pas affichées). .. _subsection_ref_parallel_df: -Accélérer les calculs de dérivées numériques en utilisant un mode parallèle +Accélérer les calculs de dérivées numériques en utilisant un mode parallèle --------------------------------------------------------------------------- .. index:: single: EnableMultiProcessing .. index:: single: NumberOfProcesses -Lors de la définition d'un opérateur, comme décrit dans le chapitre des +Lors de la définition d'un opérateur, comme décrit dans le chapitre des :ref:`section_ref_operator_requirements`, l'utilisateur peut choisir la forme -fonctionnelle "*ScriptWithOneFunction*". Cette forme conduit explicitement à -approximer les opérateurs tangent et adjoint par un calcul par différences -finies. Il requiert de nombreux appels à l'opérateur direct (fonction définie -par l'utilisateur), au moins autant de fois que la dimension du vecteur d'état. -Ce sont ces appels qui peuvent être potentiellement exécutés en parallèle. - -Sous certaines conditions, il est alors possible d'accélérer les calculs de -dérivées numériques en utilisant un mode parallèle pour l'approximation par -différences finies. Lors de la définition d'un cas ADAO, c'est effectué en -ajoutant le mot-clé optionnel "*EnableMultiProcessing*", mis à "1", de la -commande "*SCRIPTWITHONEFUNCTION*" dans la définition de l'opérateur. Le mode -parallèle utilise uniquement des ressources locales (à la fois multi-coeurs ou +fonctionnelle "*ScriptWithOneFunction*". Cette forme conduit explicitement à +approximer les opérateurs tangent et adjoint par un calcul par différences +finies. Il requiert de nombreux appels à l'opérateur direct (fonction définie +par l'utilisateur), au moins autant de fois que la dimension du vecteur d'état. +Ce sont ces appels qui peuvent être potentiellement exécutés en parallèle. + +Sous certaines conditions, il est alors possible d'accélérer les calculs de +dérivées numériques en utilisant un mode parallèle pour l'approximation par +différences finies. Lors de la définition d'un cas ADAO, c'est effectué en +ajoutant le mot-clé optionnel "*EnableMultiProcessing*", mis à "1", de la +commande "*SCRIPTWITHONEFUNCTION*" dans la définition de l'opérateur. Le mode +parallèle utilise uniquement des ressources locales (à la fois multi-coeurs ou multi-processeurs) de l'ordinateur sur lequel SALOME est en train de tourner, -demandant autant de ressources que disponible. Si nécessaire, on peut réduire +demandant autant de ressources que disponible. Si nécessaire, on peut réduire les ressources disponibles en limitant le nombre possible de processus -parallèles grâce au mot-clé optionnel "*NumberOfProcesses*", que l'on met au -maximum souhaité (ou à "0" pour le contrôle automatique, qui est la valeur par -défaut). Par défaut, ce mode parallèle est désactivé +parallèles grâce au mot-clé optionnel "*NumberOfProcesses*", que l'on met au +maximum souhaité (ou à "0" pour le contrôle automatique, qui est la valeur par +défaut). Par défaut, ce mode parallèle est désactivé ("*EnableMultiProcessing=0*"). -Les principales conditions pour réaliser ces calculs parallèles viennent de la -fonction définie par l'utilisateur, qui représente l'opérateur direct. Cette -fonction doit au moins être "thread safe" pour être exécutée dans un -environnement Python parallèle (notions au-delà du cadre de ce paragraphe). Il -n'est pas évident de donner des règles générales, donc il est recommandé, à -l'utilisateur qui active ce parallélisme interne, de vérifier soigneusement sa -fonction et les résultats obtenus. +Les principales conditions pour réaliser ces calculs parallèles viennent de la +fonction définie par l'utilisateur, qui représente l'opérateur direct. Cette +fonction doit au moins être "thread safe" pour être exécutée dans un +environnement Python parallèle (notions au-delà du cadre de ce paragraphe). Il +n'est pas évident de donner des règles générales, donc il est recommandé, à +l'utilisateur qui active ce parallélisme interne, de vérifier soigneusement sa +fonction et les résultats obtenus. -D'un point de vue utilisateur, certaines conditions, qui doivent être réunies -pour mettre en place des calculs parallèles pour les approximations des -opérateurs tangent et adjoint, sont les suivantes : +D'un point de vue utilisateur, certaines conditions, qui doivent être réunies +pour mettre en place des calculs parallèles pour les approximations des +opérateurs tangent et adjoint, sont les suivantes : -#. La dimension du vecteur d'état est supérieure à 2 ou 3. -#. Le calcul unitaire de la fonction utilisateur directe "dure un certain temps", c'est-à-dire plus que quelques minutes. -#. La fonction utilisateur directe n'utilise pas déjà du parallélisme (ou l'exécution parallèle est désactivée dans le calcul de l'utilisateur). -#. La fonction utilisateur directe n'effectue pas d'accès en lecture/écriture à des ressources communes, principalement des données stockées, des fichiers de sortie ou des espaces mémoire. -#. Les "*observer*" ajoutés par l'utilisateur n'effectuent pas d'accès en lecture/écriture à des ressources communes, comme des fichiers ou des espaces mémoire. +#. La dimension du vecteur d'état est supérieure à 2 ou 3. +#. Le calcul unitaire de la fonction utilisateur directe "dure un certain temps", c'est-à-dire plus que quelques minutes. +#. La fonction utilisateur directe n'utilise pas déjà du parallélisme (ou l'exécution parallèle est désactivée dans le calcul de l'utilisateur). +#. La fonction utilisateur directe n'effectue pas d'accès en lecture/écriture à des ressources communes, principalement des données stockées, des fichiers de sortie ou des espaces mémoire. +#. Les "*observer*" ajoutés par l'utilisateur n'effectuent pas d'accès en lecture/écriture à des ressources communes, comme des fichiers ou des espaces mémoire. Si ces conditions sont satisfaites, l'utilisateur peut choisir d'activer le -parallélisme interne pour le calcul des dérivées numériques. Malgré la -simplicité d'activation, obtenue en définissant une variable seulement, -l'utilisateur est fortement invité à vérifier les résultats de ses calculs. Il -faut au moins les effectuer une fois avec le parallélisme activé, et une autre -fois avec le parallélisme désactivé, pour comparer les résultats. Si cette mise -en oeuvre échoue à un moment ou à un autre, il faut savoir que ce schéma de -parallélisme fonctionne pour des codes complexes, comme *Code_Aster* dans +parallélisme interne pour le calcul des dérivées numériques. Malgré la +simplicité d'activation, obtenue en définissant une variable seulement, +l'utilisateur est fortement invité à vérifier les résultats de ses calculs. Il +faut au moins les effectuer une fois avec le parallélisme activé, et une autre +fois avec le parallélisme désactivé, pour comparer les résultats. Si cette mise +en oeuvre échoue à un moment ou à un autre, il faut savoir que ce schéma de +parallélisme fonctionne pour des codes complexes, comme *Code_Aster* dans *SalomeMeca* [SalomeMeca]_ par exemple. Donc, si cela ne marche pas dans votre -cas, vérifiez bien votre fonction d'opérateur avant et pendant l'activation du -parallélisme... +cas, vérifiez bien votre fonction d'opérateur avant et pendant l'activation du +parallélisme... .. warning:: - en cas de doute, il est recommandé de NE PAS ACTIVER ce parallélisme. + en cas de doute, il est recommandé de NE PAS ACTIVER ce parallélisme. -On rappelle aussi qu'il faut choisir dans YACS un container par défaut de type -"*multi*" pour le lancement du schéma, pour permettre une exécution -véritablement parallèle. +On rappelle aussi qu'il faut choisir dans YACS un container par défaut de type +"*multi*" pour le lancement du schéma, pour permettre une exécution +véritablement parallèle. -Passer d'une version d'ADAO à une nouvelle +Passer d'une version d'ADAO à une nouvelle ------------------------------------------ .. index:: single: Version -Le module ADAO et ses fichiers de cas ".comm" sont identifiés par des versions, -avec des caractéristiques "Major", "Minor" et "Revision". Une version -particulière est numérotée "Major.Minor.Revision", avec un lien fort avec la -numérotation de la plateforme SALOME. +Le module ADAO et ses fichiers de cas ".comm" sont identifiés par des versions, +avec des caractéristiques "Major", "Minor" et "Revision". Une version +particulière est numérotée "Major.Minor.Revision", avec un lien fort avec la +numérotation de la plateforme SALOME. Chaque version "Major.Minor.Revision" du module ADAO peut lire les fichiers de -cas ADAO de la précédente version mineure "Major.Minor-1.*". En général, elle +cas ADAO de la précédente version mineure "Major.Minor-1.*". En général, elle peut aussi lire les fichiers de cas de toutes les versions mineures "Major.*.*" d'une branche majeure, mais ce n'est pas obligatoirement vrai pour toutes les -commandes ou tous les mots-clés. En général aussi, un fichier de cas ADAO d'une -version ne peut pas être lu par une précédente version mineure ou majeure du +commandes ou tous les mots-clés. En général aussi, un fichier de cas ADAO d'une +version ne peut pas être lu par une précédente version mineure ou majeure du module ADAO. -Passer de la version 8.x à la 8.y avec x < y +Passer de la version 8.x à la 8.y avec x < y ++++++++++++++++++++++++++++++++++++++++++++ -Il n'y a pas d'incompatibilité connue pour les fichiers de cas ADAO. La -procédure de montée en version consiste à lire l'ancien fichier de cas ADAO -avec le nouveau module SALOME/ADAO, et à l'enregistrer avec un nouveau nom. +Il n'y a pas d'incompatibilité connue pour les fichiers de cas ADAO. La +procédure de montée en version consiste à lire l'ancien fichier de cas ADAO +avec le nouveau module SALOME/ADAO, et à l'enregistrer avec un nouveau nom. -Pour faciliter les futures évolutions, il est fortement recommandé de veiller à +Pour faciliter les futures évolutions, il est fortement recommandé de veiller à ce que vos fichiers scripts utilisateurs utilisent une syntaxe compatibible avec Python 2 et avec Python 3. En particulier, on recommande d'utiliser la syntaxe fonctionnelle pour les "*print*" et non pas la syntaxe "*commande*", comme par @@ -473,59 +474,59 @@ ou:: x, unit = 1., "cm" print( "x = {0} {1}".format(str(x),str(unit)) ) -plutôt que:: +plutôt que:: # Python 2 uniquement x, unit = 1., "cm" print "x =", x, unit -Passer de la version 7.8 à la 8.1 +Passer de la version 7.8 à la 8.1 +++++++++++++++++++++++++++++++++ -Il n'y a pas d'incompatibilité connue pour les fichiers de cas ADAO. La -procédure de montée en version consiste à lire l'ancien fichier de cas ADAO -avec le nouveau module SALOME/ADAO, et à l'enregistrer avec un nouveau nom. +Il n'y a pas d'incompatibilité connue pour les fichiers de cas ADAO. La +procédure de montée en version consiste à lire l'ancien fichier de cas ADAO +avec le nouveau module SALOME/ADAO, et à l'enregistrer avec un nouveau nom. -Passer de la version 7.x à la 7.y avec x < y +Passer de la version 7.x à la 7.y avec x < y ++++++++++++++++++++++++++++++++++++++++++++ -Il n'y a pas d'incompatibilité connue pour les fichiers de cas ADAO. La -procédure de montée en version consiste à lire l'ancien fichier de cas ADAO -avec le nouveau module SALOME/ADAO, et à l'enregistrer avec un nouveau nom. +Il n'y a pas d'incompatibilité connue pour les fichiers de cas ADAO. La +procédure de montée en version consiste à lire l'ancien fichier de cas ADAO +avec le nouveau module SALOME/ADAO, et à l'enregistrer avec un nouveau nom. -Passer de la version 6.6 à la 7.2 +Passer de la version 6.6 à la 7.2 +++++++++++++++++++++++++++++++++ -Il n'y a pas d'incompatibilité connue pour les fichiers de cas ADAO. La -procédure de montée en version consiste à lire l'ancien fichier de cas ADAO avec -le nouveau module SALOME/ADAO, et à l'enregistrer avec un nouveau nom. +Il n'y a pas d'incompatibilité connue pour les fichiers de cas ADAO. La +procédure de montée en version consiste à lire l'ancien fichier de cas ADAO avec +le nouveau module SALOME/ADAO, et à l'enregistrer avec un nouveau nom. -Il y a une incompatibilité introduite dans les fichiers de script de +Il y a une incompatibilité introduite dans les fichiers de script de post-processing ou d'observers. L'ancienne syntaxe pour interroger un objet -résultat, comme celui d'analyse "*Analysis*" (fourni dans un script à travers le -mot-clé "*UserPostAnalysis*"), était par exemple:: +résultat, comme celui d'analyse "*Analysis*" (fourni dans un script à travers le +mot-clé "*UserPostAnalysis*"), était par exemple:: Analysis = ADD.get("Analysis").valueserie(-1) Analysis = ADD.get("Analysis").valueserie() -La nouvelle syntaxe est entièrement compatible avec celle (classique) pour les +La nouvelle syntaxe est entièrement compatible avec celle (classique) pour les objets de type liste ou tuple:: Analysis = ADD.get("Analysis")[-1] Analysis = ADD.get("Analysis")[:] -Les scripts de post-processing doivent être modifiés. +Les scripts de post-processing doivent être modifiés. -Passer de la version 6.x à la 6.y avec x < y +Passer de la version 6.x à la 6.y avec x < y ++++++++++++++++++++++++++++++++++++++++++++ -Il n'y a pas d'incompatibilité connue pour les fichiers de cas ADAO. La -procédure de montée en version consiste à lire l'ancien fichier de cas ADAO avec -le nouveau module SALOME/ADAO, et à l'enregistrer avec un nouveau nom. +Il n'y a pas d'incompatibilité connue pour les fichiers de cas ADAO. La +procédure de montée en version consiste à lire l'ancien fichier de cas ADAO avec +le nouveau module SALOME/ADAO, et à l'enregistrer avec un nouveau nom. -Il y a une incompatibilité introduite dans les fichiers de script d'opérateur, -lors de la dénomination des opérateurs élémentaires utilisés pour l'opérateur +Il y a une incompatibilité introduite dans les fichiers de script d'opérateur, +lors de la dénomination des opérateurs élémentaires utilisés pour l'opérateur d'observation par script. Les nouveaux noms requis sont "*DirectOperator*", -"*TangentOperator*" et "*AdjointOperator*", comme décrit dans la quatrième -partie du chapitre :ref:`section_reference`. Les fichiers de script d'opérateur -doivent être modifiés. +"*TangentOperator*" et "*AdjointOperator*", comme décrit dans la quatrième +partie du chapitre :ref:`section_reference`. Les fichiers de script d'opérateur +doivent être modifiés. diff --git a/doc/fr/bibliography.rst b/doc/fr/bibliography.rst index b178ab6..49a480a 100644 --- a/doc/fr/bibliography.rst +++ b/doc/fr/bibliography.rst @@ -33,7 +33,7 @@ Bibliographie .. [Bouttier99] Bouttier B., Courtier P., *Data assimilation concepts and methods*, Meteorological Training Course Lecture Series, ECMWF, 1999 -.. [Bocquet04] Bocquet M., *Introduction aux principes et méthodes de l'assimilation de données en géophysique*, Lecture Notes, 2014 +.. [Bocquet04] Bocquet M., *Introduction aux principes et méthodes de l'assimilation de données en géophysique*, Lecture Notes, 2014 .. [Buchinsky98] Buchinsky M., *Recent Advances in Quantile Regression Models: A Practical Guidline for Empirical Research*, Journal of Human Resources, 33(1), pp.88-126, 1998 @@ -73,7 +73,7 @@ Bibliographie .. [Salome] *SALOME The Open Source Integration Platform for Numerical Simulation*, http://www.salome-platform.org/ -.. [SalomeMeca] *Salome_Meca et Code_Aster, Analyse des Structures et Thermomécanique pour les Etudes et la Recherche*, http://www.code-aster.org/ +.. [SalomeMeca] *Salome_Meca et Code_Aster, Analyse des Structures et Thermomécanique pour les Etudes et la Recherche*, http://www.code-aster.org/ .. [Tarantola87] Tarantola A., *Inverse Problem: Theory Methods for Data Fitting and Parameter Estimation*, Elsevier, 1987 @@ -81,23 +81,23 @@ Bibliographie .. [Tikhonov77] Tikhonov A. N., Arsenin V. Y., *Solution of Ill-posed Problems*, Winston & Sons, 1977 -.. [WikipediaDA] Wikipédia, *Data assimilation*, http://en.wikipedia.org/wiki/Data_assimilation +.. [WikipediaDA] Wikipédia, *Data assimilation*, http://en.wikipedia.org/wiki/Data_assimilation -.. [WikipediaMO] Wikipédia, *Mathematical optimization*, https://en.wikipedia.org/wiki/Mathematical_optimization +.. [WikipediaMO] Wikipédia, *Mathematical optimization*, https://en.wikipedia.org/wiki/Mathematical_optimization -.. [WikipediaND] Wikipédia, *Nondimensionalization*, https://en.wikipedia.org/wiki/Nondimensionalization +.. [WikipediaND] Wikipédia, *Nondimensionalization*, https://en.wikipedia.org/wiki/Nondimensionalization -.. [WikipediaPSO] Wikipédia, *Particle swarm optimization*, https://en.wikipedia.org/wiki/Particle_swarm_optimization +.. [WikipediaPSO] Wikipédia, *Particle swarm optimization*, https://en.wikipedia.org/wiki/Particle_swarm_optimization -.. [WikipediaQR] Wikipédia, *Quantile regression*, https://en.wikipedia.org/wiki/Quantile_regression +.. [WikipediaQR] Wikipédia, *Quantile regression*, https://en.wikipedia.org/wiki/Quantile_regression -.. [WikipediaTI] Wikipédia, *Tikhonov regularization*, https://en.wikipedia.org/wiki/Tikhonov_regularization +.. [WikipediaTI] Wikipédia, *Tikhonov regularization*, https://en.wikipedia.org/wiki/Tikhonov_regularization -.. [WikipediaUKF] Wikipédia, *Unscented Kalman filter*, https://en.wikipedia.org/wiki/Unscented_Kalman_filter +.. [WikipediaUKF] Wikipédia, *Unscented Kalman filter*, https://en.wikipedia.org/wiki/Unscented_Kalman_filter .. [Zhu97] Zhu C., Byrd R. H., Nocedal J., *L-BFGS-B: Algorithm 778: L-BFGS-B, FORTRAN routines for large scale bound constrained optimization*, ACM Transactions on Mathematical Software, 23(4), pp.550-560, 1997 -*Nota Bene* : un lien vers la version française de chaque page Wikipédia se -trouve dans le sous-menu "*Languages*". Les deux versions sont complémentaires -car, même si souvent le contenu en anglais est plus fourni, les informations +*Nota Bene* : un lien vers la version française de chaque page Wikipédia se +trouve dans le sous-menu "*Languages*". Les deux versions sont complémentaires +car, même si souvent le contenu en anglais est plus fourni, les informations disponibles dans chaque langue ne sont pas identiques. diff --git a/doc/fr/conf.py b/doc/fr/conf.py index fbd166e..c1b7007 100644 --- a/doc/fr/conf.py +++ b/doc/fr/conf.py @@ -1,4 +1,5 @@ # -*- coding: utf-8 -*- +# # Copyright (C) 2008-2017 EDF R&D # # This file is part of SALOME ADAO module @@ -55,7 +56,7 @@ templates_path = ['_templates'] source_suffix = '.rst' # The encoding of source files. -#source_encoding = 'utf-8' +source_encoding = 'utf-8' # The master toctree document. master_doc = 'index' @@ -219,8 +220,6 @@ latex_documents = [ # If false, no module index is generated. #latex_use_modindex = True -source_encoding = 'iso-8859-15' - # -- Options for Epub output --------------------------------------------------- # Bibliographic Dublin Core info. diff --git a/doc/fr/examples.rst b/doc/fr/examples.rst index d86e013..636c026 100644 --- a/doc/fr/examples.rst +++ b/doc/fr/examples.rst @@ -40,82 +40,82 @@ :align: middle :scale: 50% -Cette section présente quelques exemples d'utilisation du module ADAO dans +Cette section présente quelques exemples d'utilisation du module ADAO dans SALOME. Le premier montre comment construire un cas simple d'assimilation de -données définissant explicitement toutes les données d'entrée requises à travers -l'interface graphique d'édition (GUI). Le second montre, sur le même cas, -comment définir les données d'entrée à partir de sources externes à travers des -scripts. On présente ici toujours des scripts Python car ils sont directement -insérables dans les noeuds de script de YACS, mais les fichiers externes peuvent +données définissant explicitement toutes les données d'entrée requises à travers +l'interface graphique d'édition (GUI). Le second montre, sur le même cas, +comment définir les données d'entrée à partir de sources externes à travers des +scripts. On présente ici toujours des scripts Python car ils sont directement +insérables dans les noeuds de script de YACS, mais les fichiers externes peuvent utiliser d'autres langages. -Les notations mathématiques utilisées ci-dessous sont expliquées dans la section +Les notations mathématiques utilisées ci-dessous sont expliquées dans la section :ref:`section_theory`. -Construire un cas d'estimation avec une définition explicite des données +Construire un cas d'estimation avec une définition explicite des données ------------------------------------------------------------------------ -Cet exemple simple est un cas de démonstration, et il décrit comment mettre au -point un environnement d'estimation par BLUE de manière à obtenir un *état -estimé par méthode de moindres carrés pondérés* d'un système à partir d'une -observation de l'état et d'une connaissance *a priori* (ou ébauche) de cet état. -En d'autres termes, on cherche l'intermédiaire pondéré entre les vecteurs -d'observation et d'ébauche. Toutes les valeurs numériques de cet exemple sont +Cet exemple simple est un cas de démonstration, et il décrit comment mettre au +point un environnement d'estimation par BLUE de manière à obtenir un *état +estimé par méthode de moindres carrés pondérés* d'un système à partir d'une +observation de l'état et d'une connaissance *a priori* (ou ébauche) de cet état. +En d'autres termes, on cherche l'intermédiaire pondéré entre les vecteurs +d'observation et d'ébauche. Toutes les valeurs numériques de cet exemple sont arbitraires. -Conditions d'expérience +Conditions d'expérience +++++++++++++++++++++++ -On choisit d'opérer dans un espace à 3 dimensions. La 3D est choisie de manière -à restreindre la taille des objets numériques à entrer explicitement par -l'utilisateur, mais le problème n'est pas dépendant de la dimension et peut être -posé en dimension 10, 100, 1000... L'observation :math:`\mathbf{y}^o` vaut 1 +On choisit d'opérer dans un espace à 3 dimensions. La 3D est choisie de manière +à restreindre la taille des objets numériques à entrer explicitement par +l'utilisateur, mais le problème n'est pas dépendant de la dimension et peut être +posé en dimension 10, 100, 1000... L'observation :math:`\mathbf{y}^o` vaut 1 dans chaque direction, donc:: Yo = [1 1 1] -L'ébauche :math:`\mathbf{x}^b` de l'état , qui représente une connaissance *a -priori* ou une régularisation mathématique, vaut 0 dans chaque direction, ce qui +L'ébauche :math:`\mathbf{x}^b` de l'état , qui représente une connaissance *a +priori* ou une régularisation mathématique, vaut 0 dans chaque direction, ce qui donne donc:: Xb = [0 0 0] -La mise en oeuvre de l'assimilation de données requiert des informations sur les +La mise en oeuvre de l'assimilation de données requiert des informations sur les covariances d'erreur :math:`\mathbf{R}` et :math:`\mathbf{B}`, respectivement -pour les variables d'observation et d'ébauche. On choisit ici des erreurs -décorrélées (c'est-à-dire des matrices diagonales) et d'avoir la même variance -de 1 pour toutes les variables (c'est-à-dire des matrices identité). On pose +pour les variables d'observation et d'ébauche. On choisit ici des erreurs +décorrélées (c'est-à-dire des matrices diagonales) et d'avoir la même variance +de 1 pour toutes les variables (c'est-à-dire des matrices identité). On pose donc:: B = R = [1 0 0 ; 0 1 0 ; 0 0 1] -Enfin, on a besoin d'un opérateur d'observation :math:`\mathbf{H}` pour -convertir l'état d'ébauche dans l'espace des observations. Ici, comme les -dimensions d'espace sont les mêmes, on peut choisir l'identité comme opérateur +Enfin, on a besoin d'un opérateur d'observation :math:`\mathbf{H}` pour +convertir l'état d'ébauche dans l'espace des observations. Ici, comme les +dimensions d'espace sont les mêmes, on peut choisir l'identité comme opérateur d'observation:: H = [1 0 0 ; 0 1 0 ; 0 0 1] Avec de tels choix, l'estimateur "Best Linear Unbiased Estimator" (BLUE) sera le -vecteur moyen entre :math:`\mathbf{y}^o` et :math:`\mathbf{x}^b`, nommé -*analysis*, noté :math:`\mathbf{x}^a`, et valant:: +vecteur moyen entre :math:`\mathbf{y}^o` et :math:`\mathbf{x}^b`, nommé +*analysis*, noté :math:`\mathbf{x}^a`, et valant:: Xa = [0.5 0.5 0.5] -Pour étendre cet exemple, on peut modifier les variances représentées par -:math:`\mathbf{B}` ou :math:`\mathbf{R}` indépendamment, et l'analyse -:math:`\mathbf{x}^a` se déplacera vers :math:`\mathbf{y}^o` ou vers +Pour étendre cet exemple, on peut modifier les variances représentées par +:math:`\mathbf{B}` ou :math:`\mathbf{R}` indépendamment, et l'analyse +:math:`\mathbf{x}^a` se déplacera vers :math:`\mathbf{y}^o` ou vers :math:`\mathbf{x}^b`, en proportion inverse des variances dans :math:`\mathbf{B}` et :math:`\mathbf{R}`. Comme autre extension, on peut aussi -dire qu'il est équivalent de rechercher l'analyse à l'aide d'un algorithme de +dire qu'il est équivalent de rechercher l'analyse à l'aide d'un algorithme de BLUE ou d'un algorithme de 3DVAR. Utiliser l'interface graphique (GUI) pour construire le cas ADAO ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ En premier lieu, il faut activer le module ADAO en choisissant le bouton ou le -menu approprié de module de SALOME, et on voit : +menu approprié de module de SALOME, et on voit : .. _adao_activate2: .. image:: images/adao_activate.png @@ -124,40 +124,40 @@ menu appropri .. centered:: **Activation du module ADAO dans SALOME** -Choisir le bouton "*Nouveau*" dans cette fenêtre. On obtient directement -l'interface de l'éditeur intégré de cas pour la définition de variables, en même -temps que l'"*Arbre d'étude*" de SALOME. On peut alors choisir le bouton -"*Nouveau*" |eficas_new| pour créer un nouveau cas ADAO, et on voit : +Choisir le bouton "*Nouveau*" dans cette fenêtre. On obtient directement +l'interface de l'éditeur intégré de cas pour la définition de variables, en même +temps que l'"*Arbre d'étude*" de SALOME. On peut alors choisir le bouton +"*Nouveau*" |eficas_new| pour créer un nouveau cas ADAO, et on voit : .. _adao_viewer: .. image:: images/adao_viewer.png :align: center :width: 100% .. centered:: - **L'éditeur intégré pour la définition de cas dans le module ADAO** + **L'éditeur intégré pour la définition de cas dans le module ADAO** Ensuite, il faut remplir les variables pour construire le cas ADAO en utilisant -les conditions d'expérience décrites ci-dessus. L'ensemble des informations -techniques données au-dessus sont à insérer directement dans la définition du +les conditions d'expérience décrites ci-dessus. L'ensemble des informations +techniques données au-dessus sont à insérer directement dans la définition du cas ADAO, en utilisant le type *String* pour toutes les variables. Lorsque la -définition du cas est prête, il faut l'enregistrer comme un fichier natif de ype -"*JDC (\*.comm)*" à un endroit quelconque dans l'arborescence de l'utilisateur. -Il faut bien se rappeler que d'autres fichiers seront aussi créés à côté de ce -premier, donc il est judicieux de faire un répertoire spécifique pour ce cas, et -d'enregistrer dedans le fichier. Le nom du fichier apparaît dans la fenêtre de -l'"*Arbre d'étude*", sous le menu "*ADAO*". La définition finale du cas -ressemble à : +définition du cas est prête, il faut l'enregistrer comme un fichier natif de ype +"*JDC (\*.comm)*" à un endroit quelconque dans l'arborescence de l'utilisateur. +Il faut bien se rappeler que d'autres fichiers seront aussi créés à côté de ce +premier, donc il est judicieux de faire un répertoire spécifique pour ce cas, et +d'enregistrer dedans le fichier. Le nom du fichier apparaît dans la fenêtre de +l'"*Arbre d'étude*", sous le menu "*ADAO*". La définition finale du cas +ressemble à : .. _adao_jdcexample01: .. image:: images/adao_jdcexample01.png :align: center :width: 100% .. centered:: - **Définition des conditions d'expérience choisies pour le cas ADAO** + **Définition des conditions d'expérience choisies pour le cas ADAO** -Pour poursuivre, on a besoin de générer le schéma YACS à partir de la définition +Pour poursuivre, on a besoin de générer le schéma YACS à partir de la définition du cas ADAO. Pour faire cela, on peut activer le menu contextuel par click droit -sur le nom du cas dans la fenêtre de l'"*Arbre d'étude*", et choisir le +sur le nom du cas dans la fenêtre de l'"*Arbre d'étude*", et choisir le sous-menu "*Exporter vers YACS*" (ou le bouton "*Exporter vers YACS*" |eficas_yacs|) comme ci-dessous : @@ -166,33 +166,33 @@ sous-menu "*Exporter vers YACS*" (ou le bouton "*Exporter vers YACS*" :align: center :scale: 75% .. centered:: - **Sous-menu contextuel "*Exporter vers YACS*" pour générer le schéma YACS à partir du cas ADAO** + **Sous-menu contextuel "*Exporter vers YACS*" pour générer le schéma YACS à partir du cas ADAO** -Cette commande conduit à la génération d'un schéma YACS, à l'activation du module -YACS dans SALOME, et à ouvrir le nouveau schéma dans l'interface graphique du -module YACS [#]_. Après avoir éventuellement réorganisé les noeuds en utilisant +Cette commande conduit à la génération d'un schéma YACS, à l'activation du module +YACS dans SALOME, et à ouvrir le nouveau schéma dans l'interface graphique du +module YACS [#]_. Après avoir éventuellement réorganisé les noeuds en utilisant le sous-menu contextuel "*arranger les noeuds locaux*" de la vue graphique du -schéma YACS, on obtient la représentation suivante du schéma ADAO généré : +schéma YACS, on obtient la représentation suivante du schéma ADAO généré : .. _yacs_generatedscheme: .. image:: images/yacs_generatedscheme.png :align: center :width: 100% .. centered:: - **Schéma YACS généré à partir du cas ADAO** + **Schéma YACS généré à partir du cas ADAO** -Après ce point, toutes les modifications, exécutions et post-processing du -schéma d'assimilation de données seront effectués dans le module YACS. De -manière à vérifier les résultats d'une manière simple, on utilise le noeud -"*UserPostAnalysis*" (ou on crée ici un nouveau noeud YACS par le sous-menu +Après ce point, toutes les modifications, exécutions et post-processing du +schéma d'assimilation de données seront effectués dans le module YACS. De +manière à vérifier les résultats d'une manière simple, on utilise le noeud +"*UserPostAnalysis*" (ou on crée ici un nouveau noeud YACS par le sous-menu "*Noeud de script in-line*" dans la vue graphique de YACS). -Ce noeud de script va récupérer l'analyse issue de l'assimilation de données -depuis le port de sortie "*algoResults*" du bloc de calcul (qui donne accés à un -objet Python SALOME), et va l'afficher à la sortie standard. +Ce noeud de script va récupérer l'analyse issue de l'assimilation de données +depuis le port de sortie "*algoResults*" du bloc de calcul (qui donne accés à un +objet Python SALOME), et va l'afficher à la sortie standard. -Pour obtenir ceci, ce noeud de script doit comporter un port d'entrée de type -"*pyobj*", nommé "*Study*" par exemple, qui doit être relié graphiquement au +Pour obtenir ceci, ce noeud de script doit comporter un port d'entrée de type +"*pyobj*", nommé "*Study*" par exemple, qui doit être relié graphiquement au port de sortie "*algoResults*" du bloc de calcul. Ensuite, le code pour remplir le noeud de script est:: @@ -202,65 +202,65 @@ le noeud de script est:: print "Analysis =",Xa print -Le schéma YACS (initial ou complété) peut être enregistré (en écrasant le schéma -généré si la commande ou le bouton "*Enregistrer*" sont utilisés, ou sinon avec -un nom nouveau par la commande "*Enregistrer sous*"). De manière pratique, la -mise au point d'une telle procédure de post-processing peut être réalisée dans -YACS pour la tester, et ensuite entièrement enregistrée dans un script Python -qui peut être intégré au cas ADAO en utilisant le mot-clé "*UserPostAnalysis*". +Le schéma YACS (initial ou complété) peut être enregistré (en écrasant le schéma +généré si la commande ou le bouton "*Enregistrer*" sont utilisés, ou sinon avec +un nom nouveau par la commande "*Enregistrer sous*"). De manière pratique, la +mise au point d'une telle procédure de post-processing peut être réalisée dans +YACS pour la tester, et ensuite entièrement enregistrée dans un script Python +qui peut être intégré au cas ADAO en utilisant le mot-clé "*UserPostAnalysis*". -Ensuite, de manière classique dans YACS, le schéma doit être compilé, et ensuite -être exécuté. Après la fin de l'exécution, les affichages sur la sortie standard -sont disponibles dans la fenêtre "*fenêtre de sortie de YACS*" (ou "*YACS -Container Log*"), obtenue par clic droit à l'aide du menu contextuel de la -fenêtre "*proc*" du schéma YACS comme montré ci-dessous: +Ensuite, de manière classique dans YACS, le schéma doit être compilé, et ensuite +être exécuté. Après la fin de l'exécution, les affichages sur la sortie standard +sont disponibles dans la fenêtre "*fenêtre de sortie de YACS*" (ou "*YACS +Container Log*"), obtenue par clic droit à l'aide du menu contextuel de la +fenêtre "*proc*" du schéma YACS comme montré ci-dessous: .. _yacs_containerlog: .. image:: images/yacs_containerlog.png :align: center :width: 100% .. centered:: - **Menu YACS de la fenêtre de sortie, et boite de dialogue montrant la sortie** + **Menu YACS de la fenêtre de sortie, et boite de dialogue montrant la sortie** -On vérifie que le résultat est correct en observant si la fenêtre de sortie +On vérifie que le résultat est correct en observant si la fenêtre de sortie contient la ligne suivante:: Analysis = [0.5, 0.5, 0.5] -comme montré dans l'image précédente. +comme montré dans l'image précédente. -Pour étendre cet exemple, on peut remarquer que le même problème résolu par un -algorithme de 3DVAR donne le même résultat. Cet algorithme peut être choisi lors -de l'étape de construction du cas ADAO, avant d'entrer dans l'étape YACS. Le cas -ADAO en 3DVAR est entièrement similaire au cas algorithmique du BLUE, comme -montré dans la figure suivante: +Pour étendre cet exemple, on peut remarquer que le même problème résolu par un +algorithme de 3DVAR donne le même résultat. Cet algorithme peut être choisi lors +de l'étape de construction du cas ADAO, avant d'entrer dans l'étape YACS. Le cas +ADAO en 3DVAR est entièrement similaire au cas algorithmique du BLUE, comme +montré dans la figure suivante: .. _adao_jdcexample02: .. image:: images/adao_jdcexample02.png :align: center :width: 100% .. centered:: - **Définir un cas ADAO en 3DVAR est entièrement similaire à un cas en BLUE** + **Définir un cas ADAO en 3DVAR est entièrement similaire à un cas en BLUE** Il n'y a qu'une seule commande qui change, avec "*3DVAR*" dans le champ -"*Algorithm*" à la place de "*Blue*". +"*Algorithm*" à la place de "*Blue*". -Construire un cas d'estimation avec une définition de données externes par scripts +Construire un cas d'estimation avec une définition de données externes par scripts ---------------------------------------------------------------------------------- -Il est utile d'acquérir une partie ou la totalité des données depuis une -définition externe, en utilisant des scripts Python pour donner accès à ces -données. À titre d'exemple, on construit ici un cas ADAO présentant le même -dispositif expérimental que dans l'exemple ci-dessus `Construire un cas -d'estimation avec une définition explicite des données`_, mais en utilisant des -données issues d'un unique fichier script Python externe. +Il est utile d'acquérir une partie ou la totalité des données depuis une +définition externe, en utilisant des scripts Python pour donner accès à ces +données. À titre d'exemple, on construit ici un cas ADAO présentant le même +dispositif expérimental que dans l'exemple ci-dessus `Construire un cas +d'estimation avec une définition explicite des données`_, mais en utilisant des +données issues d'un unique fichier script Python externe. -En premier lieu, on écrit le fichier script suivant, utilisant des noms +En premier lieu, on écrit le fichier script suivant, utilisant des noms conventionnels pour les variables requises. Ici toutes les variables sont -définies dans le même script, mais l'utilisateur peut choisir de séparer le -fichier en plusieurs autres, ou de mélanger une définition explicite des données -dans l'interface graphique ADAO et une définition implicite dans des fichiers -externes. Le fichier script actuel ressemble à:: +définies dans le même script, mais l'utilisateur peut choisir de séparer le +fichier en plusieurs autres, ou de mélanger une définition explicite des données +dans l'interface graphique ADAO et une définition implicite dans des fichiers +externes. Le fichier script actuel ressemble à:: import numpy # @@ -284,58 +284,58 @@ externes. Le fichier script actuel ressemble # -------------------------------------------------- ObservationOperator = numpy.identity(3) -Les noms des variables Python sont obligatoires, de manière à définir les bonnes -variables dans le cas, mais le script Python peut être plus conséquent et -définir des classes, des fonctions, des accès à des fichiers ou des bases de -données, etc. avec des noms différents. De plus, le fichier ci-dessus présente -différentes manières de définir des vecteurs ou des matrices, utilisant des -listes, des chaînes de caractères (comme dans Numpy ou Octave), des types -vecteur ou matrice de Numpy, et des fonctions spéciales de Numpy. Toutes ces +Les noms des variables Python sont obligatoires, de manière à définir les bonnes +variables dans le cas, mais le script Python peut être plus conséquent et +définir des classes, des fonctions, des accès à des fichiers ou des bases de +données, etc. avec des noms différents. De plus, le fichier ci-dessus présente +différentes manières de définir des vecteurs ou des matrices, utilisant des +listes, des chaînes de caractères (comme dans Numpy ou Octave), des types +vecteur ou matrice de Numpy, et des fonctions spéciales de Numpy. Toutes ces syntaxes sont valides. -Après avoir enregistré ce script dans un fichier (nommé ici "*script.py*" pour -l'exemple) à un endroit quelconque dans l'arborescence de l'utilisateur, on -utilise l'interface graphique (GUI) pour construire le cas ADAO. La procédure -pour compléter le cas est similaire à celle de l'exemple précédent à part le -fait que, au lieu de choisir l'option "*String*" pour le mot-clé "*FROM*" de -chaque variable, on choisit l'option "*Script*". Cela conduit à une entrée +Après avoir enregistré ce script dans un fichier (nommé ici "*script.py*" pour +l'exemple) à un endroit quelconque dans l'arborescence de l'utilisateur, on +utilise l'interface graphique (GUI) pour construire le cas ADAO. La procédure +pour compléter le cas est similaire à celle de l'exemple précédent à part le +fait que, au lieu de choisir l'option "*String*" pour le mot-clé "*FROM*" de +chaque variable, on choisit l'option "*Script*". Cela conduit à une entrée "*SCRIPT_DATA/SCRIPT_FILE*" dans l'arbre graphique, permettant de choisir un -fichier de la manière suivante: +fichier de la manière suivante: .. _adao_scriptentry01: .. image:: images/adao_scriptentry01.png :align: center :width: 100% .. centered:: - **Définir une variable d'entrée en utilisant un fichier script externe** - -Les autres étapes et résultats sont exactement les mêmes que dans l'exemple -précédent `Construire un cas d'estimation avec une définition explicite des -données`_. - -Dans la pratique, cette démarche par scripts est la manière la plus facile pour -récupérer des information depuis des calculs en ligne ou préalables, depuis des -fichiers statiques, depuis des bases de données ou des flux informatiques, -chacun pouvant être dans ou hors SALOME. Cela permet aussi de modifier aisément -des données d'entrée, par exemple à des fin de débogage ou pour des traitements -répétitifs, et c'est la méthode la plus polyvalente pour paramétrer les données -d'entrée. **Mais attention, la méthodologie par scripts n'est pas une procédure -"sûre", en ce sens que des données erronées ou des erreurs dans les calculs, -peuvent être directement introduites dans l'exécution du schéma YACS. -L'utilisateur doit vérifier avec attention le contenu de ses scripts.** - -Ajout de paramètres pour contrôler l'algorithme d'assimilation de données + **Définir une variable d'entrée en utilisant un fichier script externe** + +Les autres étapes et résultats sont exactement les mêmes que dans l'exemple +précédent `Construire un cas d'estimation avec une définition explicite des +données`_. + +Dans la pratique, cette démarche par scripts est la manière la plus facile pour +récupérer des information depuis des calculs en ligne ou préalables, depuis des +fichiers statiques, depuis des bases de données ou des flux informatiques, +chacun pouvant être dans ou hors SALOME. Cela permet aussi de modifier aisément +des données d'entrée, par exemple à des fin de débogage ou pour des traitements +répétitifs, et c'est la méthode la plus polyvalente pour paramétrer les données +d'entrée. **Mais attention, la méthodologie par scripts n'est pas une procédure +"sûre", en ce sens que des données erronées ou des erreurs dans les calculs, +peuvent être directement introduites dans l'exécution du schéma YACS. +L'utilisateur doit vérifier avec attention le contenu de ses scripts.** + +Ajout de paramètres pour contrôler l'algorithme d'assimilation de données ------------------------------------------------------------------------- -On peut ajouter des paramètres optionnels pour contrôler le calcul de -l'algorithme d'assimilation de données. Ceci se fait en utilisant les paramètres -optionnels dans la commande "*AlgorithmParameters*" de la définition du cas -ADAO, qui est un mot-clé de la commande générale "*ASSIMILATION_STUDY*". Ce -mot-clé nécessite une définition explicite des valeurs à partir de valeurs par -défaut, ou à partir d'un dictionnaire Python, contenant des paires clé/valeur. -La liste des paramètres optionnels possibles sont donnés dans la section +On peut ajouter des paramètres optionnels pour contrôler le calcul de +l'algorithme d'assimilation de données. Ceci se fait en utilisant les paramètres +optionnels dans la commande "*AlgorithmParameters*" de la définition du cas +ADAO, qui est un mot-clé de la commande générale "*ASSIMILATION_STUDY*". Ce +mot-clé nécessite une définition explicite des valeurs à partir de valeurs par +défaut, ou à partir d'un dictionnaire Python, contenant des paires clé/valeur. +La liste des paramètres optionnels possibles sont donnés dans la section :ref:`section_reference` et ses sous-sections. On recommande d'utiliser la -définition explicite de valeurs à partir de la liste par défaut de paramètres +définition explicite de valeurs à partir de la liste par défaut de paramètres optionnels, comme ici avec le "*MaximumNumberOfSteps*": .. _adao_scriptentry02: @@ -343,114 +343,114 @@ optionnels, comme ici avec le "*MaximumNumberOfSteps*": :align: center :width: 100% .. centered:: - **Ajouter des paramètres pour contrôler l'algorithme et les sorties** + **Ajouter des paramètres pour contrôler l'algorithme et les sorties** -Le dictionnaire peut être défini, par exemple, dans un fichiers externe de +Le dictionnaire peut être défini, par exemple, dans un fichiers externe de script Python, en utilisant le nom obligatoire de variable -"*AlgorithmParameters*" pour le dictionnaire. Toutes les clés dans le -dictionnaire sont optionnelles, elles disposent toutes d'une valeur par défaut, -et elles peuvent être présentes sans être utiles. Par exemple:: +"*AlgorithmParameters*" pour le dictionnaire. Toutes les clés dans le +dictionnaire sont optionnelles, elles disposent toutes d'une valeur par défaut, +et elles peuvent être présentes sans être utiles. Par exemple:: AlgorithmParameters = { "Minimizer" : "LBFGSB", # Recommended "MaximumNumberOfSteps" : 10, } -Si aucune borne n'est requise sur les variables de contrôle, alors on peut +Si aucune borne n'est requise sur les variables de contrôle, alors on peut choisir les algorithmes de minimisation "*BFGS*" ou "*CG*" pour tous les -algorithmes variationnels d'assimilation de données ou d'optimisation. Pour +algorithmes variationnels d'assimilation de données ou d'optimisation. Pour l'optimisation sous contraintes, l'algorithme "*LBFGSB*" est bien souvent plus -robuste, mais le "*TNC*" est parfois plus performant. De manière générale, le -choix de l'algorithme "*LBFGSB*" est recommandé. Ensuite le script peut être -ajouté au cas ADAO, dans une entrée de type fichier associé au format "*Dict*" -dans le mot-clé "*Parameters*". +robuste, mais le "*TNC*" est parfois plus performant. De manière générale, le +choix de l'algorithme "*LBFGSB*" est recommandé. Ensuite le script peut être +ajouté au cas ADAO, dans une entrée de type fichier associé au format "*Dict*" +dans le mot-clé "*Parameters*". -Les autres étapes et résultats sont exactement les mêmes que dans l'exemple -précédent `Construire un cas d'estimation avec une définition explicite des -données`_. Le dictionnaire peut aussi être donné directement dans le champ -d'entrée de type chaîne de caractères pour le mot-clé. +Les autres étapes et résultats sont exactement les mêmes que dans l'exemple +précédent `Construire un cas d'estimation avec une définition explicite des +données`_. Le dictionnaire peut aussi être donné directement dans le champ +d'entrée de type chaîne de caractères pour le mot-clé. -Construire un cas complexe avec une définition de données externes par scripts +Construire un cas complexe avec une définition de données externes par scripts ------------------------------------------------------------------------------ -Cet exemple plus complexe et complet peut être considéré comme un cadre de base -pour le traitement des entrées de l'utilisateur, qui doit ensuite être adapté à -chaque application réelle. Néanmoins, les squelettes de fichiers sont -suffisamment généraux pour avoir été utilisés pour des applications variées en -neutronique, mécanique des fluides... Ici, on ne s'intéresse pas aux résultats, -mais plus sur le contrôle de l'utilisateur des entrées et sorties dans un cas -ADAO. Comme précédemment, toutes les valeurs numériques de cet exemple sont +Cet exemple plus complexe et complet peut être considéré comme un cadre de base +pour le traitement des entrées de l'utilisateur, qui doit ensuite être adapté à +chaque application réelle. Néanmoins, les squelettes de fichiers sont +suffisamment généraux pour avoir été utilisés pour des applications variées en +neutronique, mécanique des fluides... Ici, on ne s'intéresse pas aux résultats, +mais plus sur le contrôle de l'utilisateur des entrées et sorties dans un cas +ADAO. Comme précédemment, toutes les valeurs numériques de cet exemple sont arbitraires. -L'objectif est de configurer les entrées et les sortie d'un problème physique -d'estimation par des scripts externes Python, en utilisant un opérateur -non-linéaire général, en ajoutant un contrôle sur les paramètres et ainsi de -suite... Les scripts complets peuvent être trouvés dans le répertoire des +L'objectif est de configurer les entrées et les sortie d'un problème physique +d'estimation par des scripts externes Python, en utilisant un opérateur +non-linéaire général, en ajoutant un contrôle sur les paramètres et ainsi de +suite... Les scripts complets peuvent être trouvés dans le répertoire des exemples de squelettes ADAO sous le nom de "*External_data_definition_by_scripts*". -Conditions d'expérience +Conditions d'expérience +++++++++++++++++++++++ -On continue à opérer dans un espace à 3 dimensions, afin de limiter la taille de -l'objet numérique indiqué dans les scripts, mais le problème ne dépend pas de la +On continue à opérer dans un espace à 3 dimensions, afin de limiter la taille de +l'objet numérique indiqué dans les scripts, mais le problème ne dépend pas de la dimension. -On choisit un contexte d'expériences jumelles, en utilisant un état vrai +On choisit un contexte d'expériences jumelles, en utilisant un état vrai :math:`\mathbf{x}^t` connu, mais de valeur arbitraire:: Xt = [1 2 3] -L'état d'ébauche :math:`\mathbf{x}^b`, qui représentent une connaissance *a -priori* de l'état vrai, est construit comme une perturbation aléatoire -gaussienne de 20% de l'état vrai :math:`\mathbf{x}^t` pour chaque composante, +L'état d'ébauche :math:`\mathbf{x}^b`, qui représentent une connaissance *a +priori* de l'état vrai, est construit comme une perturbation aléatoire +gaussienne de 20% de l'état vrai :math:`\mathbf{x}^t` pour chaque composante, qui est:: Xb = Xt + normal(0, 20%*Xt) -Pour décrire la matrice des covariances d'erreur d'ébauche math:`\mathbf{B}`, on -fait comme précédemment l'hypothèse d'erreurs décorrélées (c'est-à-dire, une +Pour décrire la matrice des covariances d'erreur d'ébauche math:`\mathbf{B}`, on +fait comme précédemment l'hypothèse d'erreurs décorrélées (c'est-à-dire, une matrice diagonale, de taille 3x3 parce-que :math:`\mathbf{x}^b` est de taille 3) -et d'avoir la même variance de 0,1 pour toutes les variables. On obtient:: +et d'avoir la même variance de 0,1 pour toutes les variables. On obtient:: B = 0.1 * diagonal( length(Xb) ) -On suppose qu'il existe un opérateur d'observation :math:`\mathbf{H}`, qui peut -être non linéaire. Dans une procédure réelle de recalage ou de problème inverse, -les codes de simulation physique sont intégrés dans l'opérateur d'observation. -On a également besoin de connaître son gradient par rapport à chaque variable -estimée, ce qui est une information rarement connu avec les codes industriels. -Mais on verra plus tard comment obtenir un gradient approché dans ce cas. +On suppose qu'il existe un opérateur d'observation :math:`\mathbf{H}`, qui peut +être non linéaire. Dans une procédure réelle de recalage ou de problème inverse, +les codes de simulation physique sont intégrés dans l'opérateur d'observation. +On a également besoin de connaître son gradient par rapport à chaque variable +estimée, ce qui est une information rarement connu avec les codes industriels. +Mais on verra plus tard comment obtenir un gradient approché dans ce cas. -Étant en expériences jumelles, les observations :math:`\mathbf{y}^o` et leur -matrice de covariances d'erreurs :math:`\mathbf{R}` sont générées en utilisant -l'état vrai :math:`\mathbf{x}^t` et l'opérateur d'observation +Étant en expériences jumelles, les observations :math:`\mathbf{y}^o` et leur +matrice de covariances d'erreurs :math:`\mathbf{R}` sont générées en utilisant +l'état vrai :math:`\mathbf{x}^t` et l'opérateur d'observation :math:`\mathbf{H}`:: Yo = H( Xt ) -et, avec un écart-type arbitraire de 1% sur chaque composante de l'erreur:: +et, avec un écart-type arbitraire de 1% sur chaque composante de l'erreur:: R = 0.0001 * diagonal( length(Yo) ) -Toutes les informations requises pour l'estimation par assimilation de données -sont maintenant définies. +Toutes les informations requises pour l'estimation par assimilation de données +sont maintenant définies. -Squelettes des scripts décrivant les conditions d'expérience +Squelettes des scripts décrivant les conditions d'expérience ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -On donne ici les éléments essentiels de chaque script utilisé par la suite pour +On donne ici les éléments essentiels de chaque script utilisé par la suite pour construire le cas ADAO. On rappelle que l'utilisation de ces scripts dans de -réels fichiers Python nécessite de définir correctement le chemin de modules ou -des codes importés (même si le module est dans le même répertoire que le fichier -Python qui l'importe. On indique le chemin à renseigner en utilisant la mention -``"# INSERT PHYSICAL SCRIPT PATH"``), l'encodage si nécessaire, etc. Les noms de -fichiers indiqués pour les scripts qui suivent sont arbitraires. Des exemples -complets de fichiers scripts sont disponibles dans le répertoire standard des +réels fichiers Python nécessite de définir correctement le chemin de modules ou +des codes importés (même si le module est dans le même répertoire que le fichier +Python qui l'importe. On indique le chemin à renseigner en utilisant la mention +``"# INSERT PHYSICAL SCRIPT PATH"``), l'encodage si nécessaire, etc. Les noms de +fichiers indiqués pour les scripts qui suivent sont arbitraires. Des exemples +complets de fichiers scripts sont disponibles dans le répertoire standard des exemples ADAO. -On définit en premier lieu l'état vrai :math:`\mathbf{x}^t` et une fonction -utiles à la construction de matrices, dans un fichier script Python nommé +On définit en premier lieu l'état vrai :math:`\mathbf{x}^t` et une fonction +utiles à la construction de matrices, dans un fichier script Python nommé ``Physical_data_and_covariance_matrices.py``:: import numpy @@ -471,10 +471,10 @@ utiles S = numpy.matrix(numpy.identity(int(size))) return S -On définit ensuite l'état d'ébauche :math:`\mathbf{x}^b` comme une perturbation -aléatoire de l'état vrai, en ajoutant une *variable ADAO requise* à la fin du -script de définition, de manière à exporter la valeur définie. C'est réalisé -dans un fichier de script Python nommé ``Script_Background_xb.py``:: +On définit ensuite l'état d'ébauche :math:`\mathbf{x}^b` comme une perturbation +aléatoire de l'état vrai, en ajoutant une *variable ADAO requise* à la fin du +script de définition, de manière à exporter la valeur définie. C'est réalisé +dans un fichier de script Python nommé ``Script_Background_xb.py``:: from Physical_data_and_covariance_matrices import True_state import numpy @@ -489,10 +489,10 @@ dans un fichier de script Python nomm # ------------------------------------ Background = list(xb) -De la même manière, on définit la matrice des covariances de l'erreur d'ébauche -:math:`\mathbf{B}` comme une matrice diagonale, de la même longueur de diagonale -que l'ébauche de la valeur vraie, en utilisant la fonction d'aide déjà définie. -C'est réalisé dans un fichier script Python nommé +De la même manière, on définit la matrice des covariances de l'erreur d'ébauche +:math:`\mathbf{B}` comme une matrice diagonale, de la même longueur de diagonale +que l'ébauche de la valeur vraie, en utilisant la fonction d'aide déjà définie. +C'est réalisé dans un fichier script Python nommé ``Script_BackgroundError_B.py``:: from Physical_data_and_covariance_matrices import True_state, Simple_Matrix @@ -505,13 +505,13 @@ C'est r # ----------------------------------- BackgroundError = B -Pour poursuivre, on a besoin de l'opérateur d'observation :math:`\mathbf{H}` -comme une fonction de l'état. Il est ici défini dans un fichier externe nommé -``"Physical_simulation_functions.py"``, qui doit contenir une fonction appelée +Pour poursuivre, on a besoin de l'opérateur d'observation :math:`\mathbf{H}` +comme une fonction de l'état. Il est ici défini dans un fichier externe nommé +``"Physical_simulation_functions.py"``, qui doit contenir une fonction appelée ``"DirectOperator"``. Cette fonction est une une fonction utilisateur, -représentant de manière programmée l'opérateur :math:`\mathbf{H}`. On suppose -que cette fonction est donnée par l'utilisateur. Un squelette simple est donné -ici par facilité:: +représentant de manière programmée l'opérateur :math:`\mathbf{H}`. On suppose +que cette fonction est donnée par l'utilisateur. Un squelette simple est donné +ici par facilité:: def DirectOperator( XX ): """ Direct non-linear simulation operator """ @@ -527,22 +527,22 @@ ici par facilit # return numpy.array( HX ) -On n'a pas besoin des opérateurs linéaires associés ``"TangentOperator"`` et -``"AdjointOperator"`` car ils vont être approximés en utilisant les capacités +On n'a pas besoin des opérateurs linéaires associés ``"TangentOperator"`` et +``"AdjointOperator"`` car ils vont être approximés en utilisant les capacités d'ADAO. -On insiste sur le fait que ces opérateurs non-linéaire ``"DirectOperator"``, -linéaire tangent ``"TangentOperator"`` et linéaire adjoint ``"AdjointOperator"`` +On insiste sur le fait que ces opérateurs non-linéaire ``"DirectOperator"``, +linéaire tangent ``"TangentOperator"`` et linéaire adjoint ``"AdjointOperator"`` proviennent de la connaissance de la physique, incluant le code de simulation de -référence physique, et doivent être soigneusement mis au point par l'utilisateur -de l'assimilation de données ou de l'optimisation. Les erreurs de simulation ou -d'usage des opérateurs ne peuvent pas être détectés ou corrigés par -l'environnement seul ADAO d'assimilation de données et d'optimisation. +référence physique, et doivent être soigneusement mis au point par l'utilisateur +de l'assimilation de données ou de l'optimisation. Les erreurs de simulation ou +d'usage des opérateurs ne peuvent pas être détectés ou corrigés par +l'environnement seul ADAO d'assimilation de données et d'optimisation. -Dans cet environnement d'expériences jumelles, l'observation +Dans cet environnement d'expériences jumelles, l'observation :math:`\mathbf{y}^o` et sa matrice des covariances d'erreur :math:`\mathbf{R}` -peuvent être générées. C'est réalisé dans deux fichiers de script Python, le -premier étant nommé ``Script_Observation_yo.py``:: +peuvent être générées. C'est réalisé dans deux fichiers de script Python, le +premier étant nommé ``Script_Observation_yo.py``:: from Physical_data_and_covariance_matrices import True_state from Physical_simulation_functions import DirectOperator @@ -555,7 +555,7 @@ premier # ----------------------------------- Observation = list(yo) -et le second nommé ``Script_ObservationError_R.py``:: +et le second nommé ``Script_ObservationError_R.py``:: from Physical_data_and_covariance_matrices import True_state, Simple_Matrix from Physical_simulation_functions import DirectOperator @@ -570,10 +570,10 @@ et le second nomm # ----------------------------------- ObservationError = R -Comme dans les exemples précédents, il peut être utile de définir certains -paramètres pour l'algorithme d'assimilation de données. Par exemple, si on -utilise l'algorithme standard de "*3DVAR*", les paramètres suivants peuvent être -définis dans un fichier de script Python nommé +Comme dans les exemples précédents, il peut être utile de définir certains +paramètres pour l'algorithme d'assimilation de données. Par exemple, si on +utilise l'algorithme standard de "*3DVAR*", les paramètres suivants peuvent être +définis dans un fichier de script Python nommé ``Script_AlgorithmParameters.py``:: # Creating the required ADAO variable @@ -588,11 +588,11 @@ d ], } -Enfin, il est courant de post-traiter les résultats, en les récupérant aprés la -phase d'assimilation de données de manière à les analyser, les afficher ou les -représenter. Cela nécessite d'utiliser un fichier script Python intermédiaire de -manière à extraire ces résultats à la fin de la procédure d'assimilation de -données ou d'optimisation. L'exemple suivant de fichier script Python, nommé +Enfin, il est courant de post-traiter les résultats, en les récupérant aprés la +phase d'assimilation de données de manière à les analyser, les afficher ou les +représenter. Cela nécessite d'utiliser un fichier script Python intermédiaire de +manière à extraire ces résultats à la fin de la procédure d'assimilation de +données ou d'optimisation. L'exemple suivant de fichier script Python, nommé ``Script_UserPostAnalysis.py``, illustre le fait:: from Physical_data_and_covariance_matrices import True_state @@ -614,7 +614,7 @@ donn print Finalement, on obtient la description de l'ensemble des conditions -d'expériences à travers la série de fichiers listée ici: +d'expériences à travers la série de fichiers listée ici: #. ``Physical_data_and_covariance_matrices.py`` #. ``Physical_simulation_functions.py`` @@ -625,34 +625,34 @@ d'exp #. ``Script_Observation_yo.py`` #. ``Script_UserPostAnalysis.py`` -On insiste ici sur le fait que tous ces scripts sont écrits par l'utilisateur et -ne peuvent être testés automatiquement par ADAO. Ainsi, l'utilisateur est tenu -de vérifier les scripts (et en particulier leurs entrées/sorties) afin de -limiter les difficultés de débogage. On rappelle que: **la méthodologie par -scripts n'est pas une procédure "sûre", en ce sens que des données erronées ou -des erreurs dans les calculs, peuvent être directement introduites dans -l'exécution du schéma YACS.** +On insiste ici sur le fait que tous ces scripts sont écrits par l'utilisateur et +ne peuvent être testés automatiquement par ADAO. Ainsi, l'utilisateur est tenu +de vérifier les scripts (et en particulier leurs entrées/sorties) afin de +limiter les difficultés de débogage. On rappelle que: **la méthodologie par +scripts n'est pas une procédure "sûre", en ce sens que des données erronées ou +des erreurs dans les calculs, peuvent être directement introduites dans +l'exécution du schéma YACS.** -Construire la cas avec une définition de données externes par scripts +Construire la cas avec une définition de données externes par scripts +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -Tous ces scripts peuvent ensuite être utilisés pour définir le cas ADAO avec une -définition de données externes par des fichiers de script Python. Cela se -réalise de manière tout à fait similaire à la méthode décrite dans la partie -précédente `Construire un cas d'estimation avec une définition de données -externes par scripts`_. Pour chaque variable à définir, on sélectionne l'option -"*Script*" du mot-clé "*FROM*", ce qui conduit à une entrée -"*SCRIPT_DATA/SCRIPT_FILE*" dans l'arbre graphique. Pour le mot-clé +Tous ces scripts peuvent ensuite être utilisés pour définir le cas ADAO avec une +définition de données externes par des fichiers de script Python. Cela se +réalise de manière tout à fait similaire à la méthode décrite dans la partie +précédente `Construire un cas d'estimation avec une définition de données +externes par scripts`_. Pour chaque variable à définir, on sélectionne l'option +"*Script*" du mot-clé "*FROM*", ce qui conduit à une entrée +"*SCRIPT_DATA/SCRIPT_FILE*" dans l'arbre graphique. Pour le mot-clé "*ObservationOperator*", on choisit la forme "*ScriptWithOneFunction*" et on -conserve la valeur par défaut de l'incrément différentiel. +conserve la valeur par défaut de l'incrément différentiel. -Les autres étapes pour construire le cas ADAO sont exactement les mêmes que dans -la partie précédente `Construire un cas d'estimation avec une définition -explicite des données`_. +Les autres étapes pour construire le cas ADAO sont exactement les mêmes que dans +la partie précédente `Construire un cas d'estimation avec une définition +explicite des données`_. -En utilisant l'opérateur linéaire simple :math:`\mathbf{H}` du fichier script -Python ``Physical_simulation_functions.py`` disponible dans le répertoire -standard des exemples, les résultats ressemblent à:: +En utilisant l'opérateur linéaire simple :math:`\mathbf{H}` du fichier script +Python ``Physical_simulation_functions.py`` disponible dans le répertoire +standard des exemples, les résultats ressemblent à:: xt = [1 2 3] xa = [ 1.000014 2.000458 3.000390] @@ -670,9 +670,9 @@ standard des exemples, les r Etape 10 : J = 1.81568e+00 et X = [1.000013, 2.000458, 3.000390] ... -L'état au premier pas est l'état d'ébauche :math:`\mathbf{x}^b` généré -aléatoirement. Au cours du calcul, ces affichages sur la sortie standard sont -disponibles dans la fenêtre "*fenêtre de sortie de YACS*", que l'on obtient par -clic droit sur la fenêtre "*proc*" du schéma YACS exécuté. +L'état au premier pas est l'état d'ébauche :math:`\mathbf{x}^b` généré +aléatoirement. Au cours du calcul, ces affichages sur la sortie standard sont +disponibles dans la fenêtre "*fenêtre de sortie de YACS*", que l'on obtient par +clic droit sur la fenêtre "*proc*" du schéma YACS exécuté. -.. [#] 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. +.. [#] 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. diff --git a/doc/fr/glossary.rst b/doc/fr/glossary.rst index eddcd73..b3a72aa 100644 --- a/doc/fr/glossary.rst +++ b/doc/fr/glossary.rst @@ -30,99 +30,99 @@ Glossaire :sorted: cas - Un cas ADAO est défini par un jeu de données et de choix, rassemblés par - l'intermédiaire de l'interface utilisateur du module. Les données sont les - mesures physiques qui doivent être techniquement disponibles avant ou - pendant l'exécution du cas. Le (ou les) code(s) de simulation et la - méthode d'assimilation de données ou d'optimisation, ainsi que leurs - paramètres, doivent être choisis, ils définissent les propriétés - d'exécution du cas. - - itération - Une itération a lieu lorsque l'on utilise des méthodes d'optimisation - itératives (par exemple le 3DVAR), et c'est entièrement caché à - l'intérieur du noeud principal de type YACS OptimizerLoop nommé - "*compute_bloc*". Néanmoins, l'utilisateur peut observer le processus - itératif à l'aide de la fenêtre "*YACS Container Log*", qui est mise à - jour au fur et à mesure du déroulement du calcul, et en utilisant des - "*Observers*" attachés à des variables de calcul. + Un cas ADAO est défini par un jeu de données et de choix, rassemblés par + l'intermédiaire de l'interface utilisateur du module. Les données sont les + mesures physiques qui doivent être techniquement disponibles avant ou + pendant l'exécution du cas. Le (ou les) code(s) de simulation et la + méthode d'assimilation de données ou d'optimisation, ainsi que leurs + paramètres, doivent être choisis, ils définissent les propriétés + d'exécution du cas. + + itération + Une itération a lieu lorsque l'on utilise des méthodes d'optimisation + itératives (par exemple le 3DVAR), et c'est entièrement caché à + l'intérieur du noeud principal de type YACS OptimizerLoop nommé + "*compute_bloc*". Néanmoins, l'utilisateur peut observer le processus + itératif à l'aide de la fenêtre "*YACS Container Log*", qui est mise à + jour au fur et à mesure du déroulement du calcul, et en utilisant des + "*Observers*" attachés à des variables de calcul. APosterioriCovariance - Mot-clé indiquant la matrice de covariance des erreurs *a posteriori* + Mot-clé indiquant la matrice de covariance des erreurs *a posteriori* d'analyse. APosterioriCorrelations - Mot-clé indiquant la matrice de corrélation des erreurs *a posteriori* + Mot-clé indiquant la matrice de corrélation des erreurs *a posteriori* d'analyse. APosterioriVariances - Mot-clé indiquant la matrice diagonale des variances des erreurs *a + Mot-clé indiquant la matrice diagonale des variances des erreurs *a posteriori* d'analyse. APosterioriStandardDeviations - Mot-clé indiquant la matrice diagonale des écarts-types des erreurs *a + Mot-clé indiquant la matrice diagonale des écarts-types des erreurs *a posteriori* d'analyse. BMA (Background minus Analysis) - Différence entre l'état d'ébauche et l'état optimal estimé, notée + Différence entre l'état d'ébauche et l'état optimal estimé, notée :math:`\mathbf{x}^b - \mathbf{x}^a`. OMA (Observation minus Analysis) - Différence entre les observations et le résultat de la simulation basée - sur l'état optimal estimé, l'analyse, filtré pour être compatible avec les - observations, notée :math:`\mathbf{y}^o - \mathbf{H}\mathbf{x}^a`. + Différence entre les observations et le résultat de la simulation basée + sur l'état optimal estimé, l'analyse, filtré pour être compatible avec les + observations, notée :math:`\mathbf{y}^o - \mathbf{H}\mathbf{x}^a`. OMB (Observation minus Background) - Différence entre les observations et le résultat de la simulation basée - sur l'état d'ébauche, filtré pour être compatible avec les observations, - notée :math:`\mathbf{y}^o - \mathbf{H}\mathbf{x}^b`. + Différence entre les observations et le résultat de la simulation basée + sur l'état d'ébauche, filtré pour être compatible avec les observations, + notée :math:`\mathbf{y}^o - \mathbf{H}\mathbf{x}^b`. SigmaBck2 - Mot-clé indiquant le paramètre de Desroziers-Ivanov mesurant la - consistance de la partie due à l'ébauche dans l'estimation optimale d'état - par assimilation de données. Sa valeur peut être comparée à 1, une "bonne" - estimation conduisant à un paramètre "proche" de 1. + Mot-clé indiquant le paramètre de Desroziers-Ivanov mesurant la + consistance de la partie due à l'ébauche dans l'estimation optimale d'état + par assimilation de données. Sa valeur peut être comparée à 1, une "bonne" + estimation conduisant à un paramètre "proche" de 1. SigmaObs2 - Mot-clé indiquant le paramètre de Desroziers-Ivanov mesurant la - consistance de la partie due à l'observation dans l'estimation optimale - d'état par assimilation de données. Sa valeur peut être comparée à 1, une - "bonne" estimation conduisant à un paramètre "proche" de 1. + Mot-clé indiquant le paramètre de Desroziers-Ivanov mesurant la + consistance de la partie due à l'observation dans l'estimation optimale + d'état par assimilation de données. Sa valeur peut être comparée à 1, une + "bonne" estimation conduisant à un paramètre "proche" de 1. MahalanobisConsistency - Mot-clé indiquant le paramètre de Mahalanobis mesurant la consistance de - l'estimation optimale d'état par assimilation de données. Sa valeur peut - être comparée à 1, une "bonne" estimation conduisant à un paramètre + Mot-clé indiquant le paramètre de Mahalanobis mesurant la consistance de + l'estimation optimale d'état par assimilation de données. Sa valeur peut + être comparée à 1, une "bonne" estimation conduisant à un paramètre "proche" de 1. analyse - L'état optimal estimé par une procédure d'assimilation de données ou + L'état optimal estimé par une procédure d'assimilation de données ou d'optimisation. background - C'est le terme anglais pour désigner l'ébauche. - - ébauche - C'est l'état du système connu *a priori*, qui n'est pas optimal, et qui - est utilisé comme une estimation grossière, ou "la meilleure connue", + C'est le terme anglais pour désigner l'ébauche. + + ébauche + C'est l'état du système connu *a priori*, qui n'est pas optimal, et qui + est utilisé comme une estimation grossière, ou "la meilleure connue", avant une estimation optimale. innovation - Différence entre les observations et le résultat de la simulation basée - sur l'état d'ébauche, filtré pour être compatible avec les observations. - C'est similaire à OMB dans les cas statiques. + Différence entre les observations et le résultat de la simulation basée + sur l'état d'ébauche, filtré pour être compatible avec les observations. + C'est similaire à OMB dans les cas statiques. CostFunctionJ - Mot-clé indiquant la fonction de minimisation, notée :math:`J`. + Mot-clé indiquant la fonction de minimisation, notée :math:`J`. CostFunctionJo - Mot-clé indiquant la partie due aux observations dans la fonction de - minimisation, notée :math:`J^o`. + Mot-clé indiquant la partie due aux observations dans la fonction de + minimisation, notée :math:`J^o`. CostFunctionJb - Mot-clé indiquant la partie due à l'ébauche dans la fonction de - minimisation, notée :math:`J^b`. + Mot-clé indiquant la partie due à l'ébauche dans la fonction de + minimisation, notée :math:`J^b`. CurrentState - Mot-clé indiquant l'état courant utilisé au cours du déroulement d'un + Mot-clé indiquant l'état courant utilisé au cours du déroulement d'un algorithme d'optimisation. diff --git a/doc/fr/index.rst b/doc/fr/index.rst index 476a66e..5658a7f 100644 --- a/doc/fr/index.rst +++ b/doc/fr/index.rst @@ -31,50 +31,50 @@ Documentation ADAO :align: center :alt: Logo ADAO -Le module ADAO fournit des fonctionnalités d'**assimilation de données et -d'optimisation** dans un contexte SALOME. Il est basé sur l'utilisation d'autres -modules, à savoir YACS et EFICAS, et sur l'utilisation d'une bibliothèque et des -outils génériques sous-jacents d'assimilation de données. +Le module ADAO fournit des fonctionnalités d'**assimilation de données et +d'optimisation** dans un contexte SALOME. Il est basé sur l'utilisation d'autres +modules, à savoir YACS et EFICAS, et sur l'utilisation d'une bibliothèque et des +outils génériques sous-jacents d'assimilation de données. -En bref, l'assimilation de données est un cadre méthodologique pour calculer -l'estimation optimale de la valeur réelle (inaccessible) de l'état d'un système +En bref, l'assimilation de données est un cadre méthodologique pour calculer +l'estimation optimale de la valeur réelle (inaccessible) de l'état d'un système au cours du temps. Il utilise des informations provenant de mesures -expérimentales, ou observations, et de modèles numériques *a priori*, y compris -des informations sur leurs erreurs. Certaines des méthodes incluses dans ce -cadre sont également connues sous les noms d'*estimation des paramètres*, de -*problèmes inverses*, d'*estimation bayésienne*, d'*interpolation optimale*, -etc. De plus amples détails peuvent être trouvés dans la partie proposant +expérimentales, ou observations, et de modèles numériques *a priori*, y compris +des informations sur leurs erreurs. Certaines des méthodes incluses dans ce +cadre sont également connues sous les noms d'*estimation des paramètres*, de +*problèmes inverses*, d'*estimation bayésienne*, d'*interpolation optimale*, +etc. De plus amples détails peuvent être trouvés dans la partie proposant :ref:`section_theory`. -La documentation de ce module est divisée en plusieurs grandes catégories, -relatives à la documentation théorique (indiquée dans le titre par **[DocT]**), -à la documentation utilisateur (indiquée dans le titre par **[DocU]**), et à la -documentation de référence (indiquée dans le titre par **[DocR]**). +La documentation de ce module est divisée en plusieurs grandes catégories, +relatives à la documentation théorique (indiquée dans le titre par **[DocT]**), +à la documentation utilisateur (indiquée dans le titre par **[DocU]**), et à la +documentation de référence (indiquée dans le titre par **[DocR]**). -La première partie est l':ref:`section_intro`. La seconde partie présente -:ref:`section_theory`, et à leurs concepts, et la partie suivante décrit la -:ref:`section_methodology`. Pour un utilisateur courant, la quatrième partie -explique comment :ref:`section_using`, et la cinquième partie présente des +La première partie est l':ref:`section_intro`. La seconde partie présente +:ref:`section_theory`, et à leurs concepts, et la partie suivante décrit la +:ref:`section_methodology`. Pour un utilisateur courant, la quatrième partie +explique comment :ref:`section_using`, et la cinquième partie présente des exemples d'utilisation sous la forme de :ref:`section_examples`. Les -utilisateurs intéressés par un accès rapide au module peuvent s'arrêter avant la -lecture de la suite, mais un usage utile du module nécessite de lire et de -revenir régulièrement aux quatrième et septième parties. La sixième partie +utilisateurs intéressés par un accès rapide au module peuvent s'arrêter avant la +lecture de la suite, mais un usage utile du module nécessite de lire et de +revenir régulièrement aux quatrième et septième parties. La sixième partie indique les :ref:`section_advanced`, avec l'obtention de renseignements -supplémentaires ou l'usage par scripts d'exécution sans interface utilisateur -graphique (GUI). La septième partie détaille la :ref:`section_reference`, avec -quatre sous-parties principales qui suivent, la dernière décrivant une +supplémentaires ou l'usage par scripts d'exécution sans interface utilisateur +graphique (GUI). La septième partie détaille la :ref:`section_reference`, avec +quatre sous-parties principales qui suivent, la dernière décrivant une :ref:`section_tui` du module. Enfin, pour respecter les exigences de licence du module, n'oubliez pas de lire la partie :ref:`section_license`. -Dans cette documentation, on utilise les notations standards de l'algèbre -linéaire, de l'assimilation de données (comme décrit dans [Ide97]_) et de -l'optimisation. En particulier, les vecteurs sont écrits horizontalement ou -verticalement sans faire la différence. Les matrices sont écrites soit -normalement, ou avec une notation condensée, consistant à utiliser un espace -pour séparer les valeurs, et un "``;``" pour séparer les lignes de la matrice, -de façon continue sur une ligne. +Dans cette documentation, on utilise les notations standards de l'algèbre +linéaire, de l'assimilation de données (comme décrit dans [Ide97]_) et de +l'optimisation. En particulier, les vecteurs sont écrits horizontalement ou +verticalement sans faire la différence. Les matrices sont écrites soit +normalement, ou avec une notation condensée, consistant à utiliser un espace +pour séparer les valeurs, et un "``;``" pour séparer les lignes de la matrice, +de façon continue sur une ligne. -Table des matières +Table des matières ------------------ .. toctree:: diff --git a/doc/fr/intro.rst b/doc/fr/intro.rst index 3123786..f6d96fe 100644 --- a/doc/fr/intro.rst +++ b/doc/fr/intro.rst @@ -24,26 +24,26 @@ .. _section_intro: ================================================================================ -Introduction à ADAO +Introduction à ADAO ================================================================================ -Le but du module ADAO est **d'aider à l'usage de l'assimilation de données ou de +Le but du module ADAO est **d'aider à l'usage de l'assimilation de données ou de l'optimisation en lien avec d'autres modules ou codes de simulation dans -SALOME**. Le module ADAO fournit une interface à des algorithmes classiques -d'assimilation de données ou d'optimisation, et permet d'intégrer leur usage -dans une étude SALOME. Les modules de calcul ou de simulation doivent fournir -une ou plusieurs méthodes d'appel spécifiques afin d'être appelable dans le -cadre SALOME/ADAO, et tous les modules SALOME peuvent être utilisés grace à -l'intégration dans YACS de ADAO. - -Son principal objectif est de **permettre l'usage de diverses méthodes standards -d'assimilation de données ou d'optimisation, tout en restant facile à utiliser -et en fournissant une démarche pour aider à la mise en oeuvre**. Pour -l'utilisateur final, qui a préalablement recueilli les informations sur son -problème physique, l'environnement lui permet d'avoir une démarche de type -"souris\&click" pour construire un cas ADAO valide et pour l'évaluer. - -Le module couvre une grande variété d'applications pratiques, de façon robuste, -permettant des applications réelles, mais aussi d'effectuer de l'expérimentation -méthodologique rapide. Son évolutivité, des points de vue méthodologique et -numérique, permettra l'extension de son domaine d'application. +SALOME**. Le module ADAO fournit une interface à des algorithmes classiques +d'assimilation de données ou d'optimisation, et permet d'intégrer leur usage +dans une étude SALOME. Les modules de calcul ou de simulation doivent fournir +une ou plusieurs méthodes d'appel spécifiques afin d'être appelable dans le +cadre SALOME/ADAO, et tous les modules SALOME peuvent être utilisés grace à +l'intégration dans YACS de ADAO. + +Son principal objectif est de **permettre l'usage de diverses méthodes standards +d'assimilation de données ou d'optimisation, tout en restant facile à utiliser +et en fournissant une démarche pour aider à la mise en oeuvre**. Pour +l'utilisateur final, qui a préalablement recueilli les informations sur son +problème physique, l'environnement lui permet d'avoir une démarche de type +"souris\&click" pour construire un cas ADAO valide et pour l'évaluer. + +Le module couvre une grande variété d'applications pratiques, de façon robuste, +permettant des applications réelles, mais aussi d'effectuer de l'expérimentation +méthodologique rapide. Son évolutivité, des points de vue méthodologique et +numérique, permettra l'extension de son domaine d'application. diff --git a/doc/fr/license.rst b/doc/fr/license.rst index 5b62cd2..1581aba 100644 --- a/doc/fr/license.rst +++ b/doc/fr/license.rst @@ -32,7 +32,7 @@ Licence et conditions d'utilisation pour le module .. index:: single: ADAO La licence pour ce module est la GNU Lesser General Public License (Lesser GPL), -tel qu'il est déclaré ici et dans les fichiers sources:: +tel qu'il est déclaré ici et dans les fichiers sources:: @@ -54,18 +54,18 @@ tel qu'il est d See http://www.salome-platform.org/ or email : webmaster.salome@opencascade.com -En outre, on demande que toute publication ou présentation décrivant des travaux +En outre, on demande que toute publication ou présentation décrivant des travaux utilisant ce module, ou tout produit commercial ou non l'utilisant, cite au -moins l'une des références ci-dessous : +moins l'une des références ci-dessous : * *ADAO, a SALOME module for Data Assimilation and Optimization*, http://www.salome-platform.org/ - * *ADAO, un module SALOME pour l'Assimilation de Données et l'Aide à + * *ADAO, un module SALOME pour l'Assimilation de Données et l'Aide à l'Optimisation*, http://www.salome-platform.org/ * *SALOME The Open Source Integration Platform for Numerical Simulation*, http://www.salome-platform.org/ -La documentation du module est également couverte par la licence et l'obligation +La documentation du module est également couverte par la licence et l'obligation de citation. diff --git a/doc/fr/methodology.rst b/doc/fr/methodology.rst index b4694a9..cb03145 100644 --- a/doc/fr/methodology.rst +++ b/doc/fr/methodology.rst @@ -24,20 +24,20 @@ .. _section_methodology: =========================================================================================== -**[DocT]** Méthodologie pour élaborer une étude d'Assimilation de Données ou d'Optimisation +**[DocT]** Méthodologie pour élaborer une étude d'Assimilation de Données ou d'Optimisation =========================================================================================== -Cette section présente un méthodologie générique pour construire une étude -d'Assimilation de Données ou d'Optimisation. Elle décrit les étapes -conceptuelles pour établir de manière indépendante cette étude. Elle est -indépendante de tout outil, mais le module ADAO permet de mettre en oeuvre -efficacement une telle étude. +Cette section présente un méthodologie générique pour construire une étude +d'Assimilation de Données ou d'Optimisation. Elle décrit les étapes +conceptuelles pour établir de manière indépendante cette étude. Elle est +indépendante de tout outil, mais le module ADAO permet de mettre en oeuvre +efficacement une telle étude. -Procédure logique pour une étude +Procédure logique pour une étude -------------------------------- -Pour une étude générique d'Assimilation de Données ou d'Optimisation, les -principales étapes méthodologiques peuvent être les suivantes: +Pour une étude générique d'Assimilation de Données ou d'Optimisation, les +principales étapes méthodologiques peuvent être les suivantes: - :ref:`section_m_step1` - :ref:`section_m_step2` @@ -47,194 +47,194 @@ principales - :ref:`section_m_step6` - :ref:`section_m_step7` -Chaque étape est détaillée dans la section suivante. +Chaque étape est détaillée dans la section suivante. -Procédure détaillée pour une étude +Procédure détaillée pour une étude ---------------------------------- .. _section_m_step1: -ÉTAPE 1: Spécifier la résolution du système physique et les paramètres à ajuster +ÉTAPE 1: Spécifier la résolution du système physique et les paramètres à ajuster ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -Une source essentielle de connaissance du système physique étudié est la -simulation numérique. Elle est souvent disponible à travers un ou des cas de -calcul, et elle est symbolisée par un **opérateur de simulation** (précédemment -inclus dans :math:`H`). Un cas de calcul standard rassemble des hypothèses de -modèles, une implémentation numérique, des capacités de calcul, etc. de manière -à représenter le comportement du système physique. De plus, un cas de calcul est -caractérisé par exemple par ses besoins en temps de calcul et en mémoire, par la -taille de ses données et de ses résultats, etc. La connaissance de tous ces -éléments est primordiale dans la mise au point d'une étude d'assimilation de -données ou d'optimisation. - -Pour établir correctement une étude, il faut aussi choisir les inconnues -d'optimisation incluses dans la simulation. Fréquemment, cela peut être à l'aide -de modèles physiques dont les paramètres peuvent être ajustés. De plus, il est -toujours utile d'ajouter une connaissance de type sensibilité, comme par exemple -celle de la simulation par rapport aux paramètres qui peuvent être ajustés. Des -éléments plus généraux, comme la stabilité ou la régularité de la simulation par -rapport aux inconnues en entrée, sont aussi d'un grand intérêt. - -En pratique, les méthodes d'optimisation peuvent requérir une information de +Une source essentielle de connaissance du système physique étudié est la +simulation numérique. Elle est souvent disponible à travers un ou des cas de +calcul, et elle est symbolisée par un **opérateur de simulation** (précédemment +inclus dans :math:`H`). Un cas de calcul standard rassemble des hypothèses de +modèles, une implémentation numérique, des capacités de calcul, etc. de manière +à représenter le comportement du système physique. De plus, un cas de calcul est +caractérisé par exemple par ses besoins en temps de calcul et en mémoire, par la +taille de ses données et de ses résultats, etc. La connaissance de tous ces +éléments est primordiale dans la mise au point d'une étude d'assimilation de +données ou d'optimisation. + +Pour établir correctement une étude, il faut aussi choisir les inconnues +d'optimisation incluses dans la simulation. Fréquemment, cela peut être à l'aide +de modèles physiques dont les paramètres peuvent être ajustés. De plus, il est +toujours utile d'ajouter une connaissance de type sensibilité, comme par exemple +celle de la simulation par rapport aux paramètres qui peuvent être ajustés. Des +éléments plus généraux, comme la stabilité ou la régularité de la simulation par +rapport aux inconnues en entrée, sont aussi d'un grand intérêt. + +En pratique, les méthodes d'optimisation peuvent requérir une information de type gradient de la simulation par rapport aux inconnues. Dans ce cas, le -gradient explicite du code doit être donné, ou le gradient numérique doit être -établi. Sa qualité est en relation avec la stabilité ou la régularité du code de -simulation, et elle doit être vérifiée avec soin avant de mettre en oeuvre les -calculs d'optimisation. Des conditions spécifiques doivent être utilisées pour -ces vérifications. - -Un **opérateur d'observation** est toujours requis, en complément à l'opérateur -de simulation. Cet opérateur d'observation, noté :math:`H` ou inclus dedans, -doit convertir les sorties de la simulation numérique en quelque-chose qui est -directement comparable aux observations. C'est un opérateur essentiel, car il +gradient explicite du code doit être donné, ou le gradient numérique doit être +établi. Sa qualité est en relation avec la stabilité ou la régularité du code de +simulation, et elle doit être vérifiée avec soin avant de mettre en oeuvre les +calculs d'optimisation. Des conditions spécifiques doivent être utilisées pour +ces vérifications. + +Un **opérateur d'observation** est toujours requis, en complément à l'opérateur +de simulation. Cet opérateur d'observation, noté :math:`H` ou inclus dedans, +doit convertir les sorties de la simulation numérique en quelque-chose qui est +directement comparable aux observations. C'est un opérateur essentiel, car il est le moyen pratique de comparer les simulations et les observations. C'est -usuellement réalisé par échantillonnage, projection ou intégration, des sorties -de simulation, mais cela peut être plus compliqué. Souvent, du fait que -l'opérateur d'observation fasse directement suite à celui de simulation dans un -schéma simple d'assimilation de données, cet opérateur d'observation utilise -fortement les capacités de post-traitement et d'extraction du code de +usuellement réalisé par échantillonnage, projection ou intégration, des sorties +de simulation, mais cela peut être plus compliqué. Souvent, du fait que +l'opérateur d'observation fasse directement suite à celui de simulation dans un +schéma simple d'assimilation de données, cet opérateur d'observation utilise +fortement les capacités de post-traitement et d'extraction du code de simulation. .. _section_m_step2: -ÉTAPE 2: Spécifier les critères de qualification des résultats physiques +ÉTAPE 2: Spécifier les critères de qualification des résultats physiques ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -Comme les systèmes étudiés ont une réalité physique, il est important d'exprimer -les **information physiques qui peuvent aider à qualifier un état simulé du -système**. Il y a deux grand types d'informations qui conduisent à des critères -permettant la qualification et la quantification de résultats d'optimisation. +Comme les systèmes étudiés ont une réalité physique, il est important d'exprimer +les **information physiques qui peuvent aider à qualifier un état simulé du +système**. Il y a deux grand types d'informations qui conduisent à des critères +permettant la qualification et la quantification de résultats d'optimisation. -Premièrement, provenant d'une connaissance mathématique ou numérique, un grand +Premièrement, provenant d'une connaissance mathématique ou numérique, un grand nombre d'indicateurs standards permettent de qualifier, en relatif ou en absolu, -l'intérêt d'un état optimal. Par exemple, des équations d'équilibre ou des -conditions de fermeture sont des mesures complémentaires de la qualité d'un état -du système. Des critères bien choisis comme des RMS, des RMSE, des extrema de -champs, des intégrales, etc. permettent d'évaluer la qualité d'un état optimisé. - -Deuxièmement, provenant d'une connaissance physique ou expérimentale, des -informations utiles peuvent être obtenus à partir de l'interprétation des -résultats d'optimisation. En particulier, la validité physique ou l'intérêt -technique permettent d'évaluer l'intérêt de résultats des résultats numériques +l'intérêt d'un état optimal. Par exemple, des équations d'équilibre ou des +conditions de fermeture sont des mesures complémentaires de la qualité d'un état +du système. Des critères bien choisis comme des RMS, des RMSE, des extrema de +champs, des intégrales, etc. permettent d'évaluer la qualité d'un état optimisé. + +Deuxièmement, provenant d'une connaissance physique ou expérimentale, des +informations utiles peuvent être obtenus à partir de l'interprétation des +résultats d'optimisation. En particulier, la validité physique ou l'intérêt +technique permettent d'évaluer l'intérêt de résultats des résultats numériques de l'optimisation. Pour obtenir une information signifiante de ces deux types de connaissances, il -est recommandé, si possible, de construire des critères numériques pour -faciliter l'évaluation de la qualité globale des résultats numériques +est recommandé, si possible, de construire des critères numériques pour +faciliter l'évaluation de la qualité globale des résultats numériques .. _section_m_step3: -ÉTAPE 3: Identifier et décrire les observations disponibles +ÉTAPE 3: Identifier et décrire les observations disponibles +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -En tant que seconde source d'information principale à propos du système physique -à étudier, les **observations, ou mesures,** notées :math:`\mathbf{y}^o`, -doivent être décrites avec soin. La qualité des mesures, leur erreurs -intrinsèques, leur particularités, sont importantes à connaître, pour pouvoir -introduire ces informations dans les calculs d'assimilation de données ou +En tant que seconde source d'information principale à propos du système physique +à étudier, les **observations, ou mesures,** notées :math:`\mathbf{y}^o`, +doivent être décrites avec soin. La qualité des mesures, leur erreurs +intrinsèques, leur particularités, sont importantes à connaître, pour pouvoir +introduire ces informations dans les calculs d'assimilation de données ou d'optimisation. -Les observations doivent non seulement être disponibles, mais aussi doivent -pouvoir être introduites efficacement dans l'environnement numérique de calcul -ou d'optimisation. Ainsi l'environnement d'accès numérique aux observations est -fondamental pour faciliter l'usage effectif de mesures variées et de sources +Les observations doivent non seulement être disponibles, mais aussi doivent +pouvoir être introduites efficacement dans l'environnement numérique de calcul +ou d'optimisation. Ainsi l'environnement d'accès numérique aux observations est +fondamental pour faciliter l'usage effectif de mesures variées et de sources diverses, et pour encourager des essais extensifs utilisant des mesures. -L'environnement d'accès numérique intègre la disponibilité de bases de données -ou pas, les formats de données, les interfaces d'accès, etc. +L'environnement d'accès numérique intègre la disponibilité de bases de données +ou pas, les formats de données, les interfaces d'accès, etc. .. _section_m_step4: -ÉTAPE 4: Spécifier les éléments de modélisation de l'AD/Optimisation (covariances, ébauche...) +ÉTAPE 4: Spécifier les éléments de modélisation de l'AD/Optimisation (covariances, ébauche...) ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -Des éléments supplémentaires de modélisation en Assimilation de Données ou en -Optimisation permettent d'améliorer l'information à propos de la représentation -détaillée du système physique étudié. +Des éléments supplémentaires de modélisation en Assimilation de Données ou en +Optimisation permettent d'améliorer l'information à propos de la représentation +détaillée du système physique étudié. -La connaissance *a-priori* de l'état du système peut être représentée en -utilisant l'**ébauche**, notée :math:`\mathbf{x}^b`, et la **matrice de -covariance des erreurs d'ébauche**, notée :math:`\mathbf{B}`. Ces informations -sont extrêmement importantes à compléter, en particulier pour obtenir des -résultats signifiants en Assimilation de Données. +La connaissance *a-priori* de l'état du système peut être représentée en +utilisant l'**ébauche**, notée :math:`\mathbf{x}^b`, et la **matrice de +covariance des erreurs d'ébauche**, notée :math:`\mathbf{B}`. Ces informations +sont extrêmement importantes à compléter, en particulier pour obtenir des +résultats signifiants en Assimilation de Données. -Par ailleurs, des informations sur les erreurs d'observation peuvent être -utilisées pour compléter la **matrice de covariance des erreurs d'observation**, -notée :math:`\mathbf{R}`. Comme pour :math:`\mathbf{B}`, il est recommandé -d'utiliser des informations soigneusement vérifiées pour renseigner ces matrices +Par ailleurs, des informations sur les erreurs d'observation peuvent être +utilisées pour compléter la **matrice de covariance des erreurs d'observation**, +notée :math:`\mathbf{R}`. Comme pour :math:`\mathbf{B}`, il est recommandé +d'utiliser des informations soigneusement vérifiées pour renseigner ces matrices de covariances. -Dans le cas de simulations dynamiques, il est de plus nécessaire de définir un -**opérateur d'évolution** et la **matrice de covariance des erreurs -d'évolution** associée. +Dans le cas de simulations dynamiques, il est de plus nécessaire de définir un +**opérateur d'évolution** et la **matrice de covariance des erreurs +d'évolution** associée. .. _section_m_step5: -ÉTAPE 5: Choisir l'algorithme d'optimisation et ses paramètres +ÉTAPE 5: Choisir l'algorithme d'optimisation et ses paramètres ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -L'Assimilation de Données ou l'Optimisation demandent de résoudre un problème -d'optimisation, le plus souvent sous la forme d'un problème de minimisation. -Selon la disponibilité du gradient de la fonction coût en fonction des -paramètres d'optimisation, la classe recommandée de méthodes sera différente. -Les méthodes d'optimisation variationnelles ou avec linéarisation locale -nécessitent ce gradient. A l'opposé, les méthodes sans dérivées ne nécessitent -pas ce gradient, mais présentent souvent un coût de calcul notablement -supérieur. - -A l'intérieur même d'une classe de méthodes d'optimisation, pour chaque méthode, -il y a usuellement un compromis à faire entre les *"capacités génériques de la -méthode"* et ses *"performances particulières sur un problème spécifique"*. Les -méthodes les plus génériques, comme par exemple la minimisation variationnelle -utilisant l':ref:`section_ref_algorithm_3DVAR`, présentent de remarquables -propriétés numériques d'efficacité, de robustesse et de fiabilité, ce qui -conduit à les recommander indépendamment du problème à résoudre. De plus, il est -souvent difficile de régler les paramètres d'une méthode d'optimisation, donc la -méthodes la plus robuste est souvent celle qui présente le moins de paramètres. -Au final, au moins au début, il est recommandé d'utiliser les méthodes les plus -génériques et de changer le moins possible les paramètres par défaut connus. +L'Assimilation de Données ou l'Optimisation demandent de résoudre un problème +d'optimisation, le plus souvent sous la forme d'un problème de minimisation. +Selon la disponibilité du gradient de la fonction coût en fonction des +paramètres d'optimisation, la classe recommandée de méthodes sera différente. +Les méthodes d'optimisation variationnelles ou avec linéarisation locale +nécessitent ce gradient. A l'opposé, les méthodes sans dérivées ne nécessitent +pas ce gradient, mais présentent souvent un coût de calcul notablement +supérieur. + +A l'intérieur même d'une classe de méthodes d'optimisation, pour chaque méthode, +il y a usuellement un compromis à faire entre les *"capacités génériques de la +méthode"* et ses *"performances particulières sur un problème spécifique"*. Les +méthodes les plus génériques, comme par exemple la minimisation variationnelle +utilisant l':ref:`section_ref_algorithm_3DVAR`, présentent de remarquables +propriétés numériques d'efficacité, de robustesse et de fiabilité, ce qui +conduit à les recommander indépendamment du problème à résoudre. De plus, il est +souvent difficile de régler les paramètres d'une méthode d'optimisation, donc la +méthodes la plus robuste est souvent celle qui présente le moins de paramètres. +Au final, au moins au début, il est recommandé d'utiliser les méthodes les plus +génériques et de changer le moins possible les paramètres par défaut connus. .. _section_m_step6: -ÉTAPE 6: Conduire les calculs d'optimisation et obtenir les résultats +ÉTAPE 6: Conduire les calculs d'optimisation et obtenir les résultats +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -Après avoir mis au point une étude d'Assimilation de Données ou d'Optimisation, -les calculs doivent être conduits de manière efficace. +Après avoir mis au point une étude d'Assimilation de Données ou d'Optimisation, +les calculs doivent être conduits de manière efficace. Comme l'optimisation requiert usuellement un grand nombre de simulations -physiques élémentaires du système, les calculs sont souvent effectués dans un +physiques élémentaires du système, les calculs sont souvent effectués dans un environnement de calculs hautes performances (HPC, ou Hight Performance -Computing) pour réduire le temps complet d'utilisateur. Même si le problème -d'optimisation est petit, le temps de simulation du système physique peut être -long, nécessitant des ressources de calcul conséquentes. Ces besoins doivent -être pris en compte suffisamment tôt dans la procédure d'étude pour être -satisfaits sans nécessiter un effort trop important. - -Pour la même raison de besoins de calculs importants, il est aussi important de -préparer soigneusement les sorties de la procédure d'optimisation. L'état +Computing) pour réduire le temps complet d'utilisateur. Même si le problème +d'optimisation est petit, le temps de simulation du système physique peut être +long, nécessitant des ressources de calcul conséquentes. Ces besoins doivent +être pris en compte suffisamment tôt dans la procédure d'étude pour être +satisfaits sans nécessiter un effort trop important. + +Pour la même raison de besoins de calculs importants, il est aussi important de +préparer soigneusement les sorties de la procédure d'optimisation. L'état optimal est la principale information requise, mais un grand nombre d'autres -informations spéciales peuvent être obtenues au cours du calcul d'optimisation -ou à la fin: évaluation des erreurs, états intermédiaires, indicateurs de -qualité, etc. Toutes ces informations, nécessitant parfois des calculs -additionnels, doivent être connues et demandées au début du processus +informations spéciales peuvent être obtenues au cours du calcul d'optimisation +ou à la fin: évaluation des erreurs, états intermédiaires, indicateurs de +qualité, etc. Toutes ces informations, nécessitant parfois des calculs +additionnels, doivent être connues et demandées au début du processus d'optimisation. .. _section_m_step7: -ÉTAPE 7: Exploiter les résultats et qualifier leur pertinence physique +ÉTAPE 7: Exploiter les résultats et qualifier leur pertinence physique ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -Une fois les résultats obtenus, ils doivent être interprétés en termes de -significations physique et numérique. Même si la démarche d'optimisation donne -toujours un nouvel état optimal qui est au moins aussi bon que l'état *a -priori*, et le plus souvent meilleur, cet état optimal doit par exemple être -vérifié par rapport aux critères de qualité identifiés au moment de -:ref:`section_m_step2`. Cela peut conduire à des études statistiques ou -numériques de manière à évaluer l'intérêt d'un état optimal pour représenter la -système physique. - -Au-delà de cette analyse qui doit être réalisée pour chaque étude d'Assimilation -de Données ou d'Optimisation, il est très utile d'exploiter les résultats -d'optimisation comme une partie intégrée dans une étude plus complète du système -physique d'intérêt. +Une fois les résultats obtenus, ils doivent être interprétés en termes de +significations physique et numérique. Même si la démarche d'optimisation donne +toujours un nouvel état optimal qui est au moins aussi bon que l'état *a +priori*, et le plus souvent meilleur, cet état optimal doit par exemple être +vérifié par rapport aux critères de qualité identifiés au moment de +:ref:`section_m_step2`. Cela peut conduire à des études statistiques ou +numériques de manière à évaluer l'intérêt d'un état optimal pour représenter la +système physique. + +Au-delà de cette analyse qui doit être réalisée pour chaque étude d'Assimilation +de Données ou d'Optimisation, il est très utile d'exploiter les résultats +d'optimisation comme une partie intégrée dans une étude plus complète du système +physique d'intérêt. diff --git a/doc/fr/ref_algorithm_3DVAR.rst b/doc/fr/ref_algorithm_3DVAR.rst index 25bbc6a..e352aea 100644 --- a/doc/fr/ref_algorithm_3DVAR.rst +++ b/doc/fr/ref_algorithm_3DVAR.rst @@ -30,13 +30,13 @@ Algorithme de calcul "*3DVAR*" Description +++++++++++ -Cet algorithme réalise une estimation d'état par minimisation variationnelle de -la fonctionnelle :math:`J` d'écart classique en assimilation de données +Cet algorithme réalise une estimation d'état par minimisation variationnelle de +la fonctionnelle :math:`J` d'écart classique en assimilation de données statique: .. math:: J(\mathbf{x})=(\mathbf{x}-\mathbf{x}^b)^T.\mathbf{B}^{-1}.(\mathbf{x}-\mathbf{x}^b)+(\mathbf{y}^o-H(\mathbf{x}))^T.\mathbf{R}^{-1}.(\mathbf{y}^o-H(\mathbf{x})) -qui est usuellement désignée comme la fonctionnelle "*3D-VAR*" (voir par exemple +qui est usuellement désignée comme la fonctionnelle "*3D-VAR*" (voir par exemple [Talagrand97]_). Commandes requises et optionnelles @@ -60,114 +60,114 @@ Commandes requises et optionnelles .. index:: single: NumberOfSamplesForQuantiles .. index:: single: SimulationForQuantiles -Les commandes requises générales, disponibles dans l'interface en édition, sont +Les commandes requises générales, disponibles dans l'interface en édition, sont les suivantes: Background - *Commande obligatoire*. Elle définit le vecteur d'ébauche ou - d'initialisation, noté précédemment :math:`\mathbf{x}^b`. Sa valeur est - définie comme un objet de type "*Vector*" ou de type "*VectorSerie*". + *Commande obligatoire*. Elle définit le vecteur d'ébauche ou + d'initialisation, noté précédemment :math:`\mathbf{x}^b`. Sa valeur est + définie comme un objet de type "*Vector*" ou de type "*VectorSerie*". BackgroundError - *Commande obligatoire*. Elle définit la matrice de covariance des erreurs - d'ébauche, notée précédemment :math:`\mathbf{B}`. Sa valeur est définie + *Commande obligatoire*. Elle définit la matrice de covariance des erreurs + d'ébauche, notée précédemment :math:`\mathbf{B}`. Sa valeur est définie comme un objet de type "*Matrix*", de type "*ScalarSparseMatrix*", ou de type "*DiagonalSparseMatrix*". Observation - *Commande obligatoire*. Elle définit le vecteur d'observation utilisé en - assimilation de données ou en optimisation, et noté précédemment - :math:`\mathbf{y}^o`. Sa valeur est définie comme un objet de type "*Vector*" + *Commande obligatoire*. Elle définit le vecteur d'observation utilisé en + assimilation de données ou en optimisation, et noté précédemment + :math:`\mathbf{y}^o`. Sa valeur est définie comme un objet de type "*Vector*" ou de type "*VectorSerie*". ObservationError - *Commande obligatoire*. Elle définit la matrice de covariance des erreurs - d'ébauche, notée précédemment :math:`\mathbf{R}`. Sa valeur est définie + *Commande obligatoire*. Elle définit la matrice de covariance des erreurs + d'ébauche, notée précédemment :math:`\mathbf{R}`. Sa valeur est définie comme un objet de type "*Matrix*", de type "*ScalarSparseMatrix*", ou de type "*DiagonalSparseMatrix*". ObservationOperator - *Commande obligatoire*. Elle indique l'opérateur d'observation, noté - précédemment :math:`H`, qui transforme les paramètres d'entrée - :math:`\mathbf{x}` en résultats :math:`\mathbf{y}` qui sont à comparer aux - observations :math:`\mathbf{y}^o`. Sa valeur est définie comme un objet de + *Commande obligatoire*. Elle indique l'opérateur d'observation, noté + précédemment :math:`H`, qui transforme les paramètres d'entrée + :math:`\mathbf{x}` en résultats :math:`\mathbf{y}` qui sont à comparer aux + observations :math:`\mathbf{y}^o`. Sa valeur est définie comme un objet de type "*Function*" ou de type "*Matrix*". Dans le cas du type "*Function*", - différentes formes fonctionnelles peuvent être utilisées, comme décrit dans - la section :ref:`section_ref_operator_requirements`. Si un contrôle - :math:`U` est inclus dans le modèle d'observation, l'opérateur doit être - appliqué à une paire :math:`(X,U)`. - -Les commandes optionnelles générales, disponibles dans l'interface en édition, -sont indiquées dans la :ref:`section_ref_assimilation_keywords`. De plus, les -paramètres de la commande "*AlgorithmParameters*" permettent d'indiquer les -options particulières, décrites ci-après, de l'algorithme. On se reportera à la + différentes formes fonctionnelles peuvent être utilisées, comme décrit dans + la section :ref:`section_ref_operator_requirements`. Si un contrôle + :math:`U` est inclus dans le modèle d'observation, l'opérateur doit être + appliqué à une paire :math:`(X,U)`. + +Les commandes optionnelles générales, disponibles dans l'interface en édition, +sont indiquées dans la :ref:`section_ref_assimilation_keywords`. De plus, les +paramètres de la commande "*AlgorithmParameters*" permettent d'indiquer les +options particulières, décrites ci-après, de l'algorithme. On se reportera à la :ref:`section_ref_options_Algorithm_Parameters` pour le bon usage de cette commande. Les options de l'algorithme sont les suivantes: Minimizer - Cette clé permet de changer le minimiseur pour l'optimiseur. Le choix par - défaut est "LBFGSB", et les choix possibles sont "LBFGSB" (minimisation non - linéaire sous contraintes, voir [Byrd95]_, [Morales11]_ et [Zhu97]_), "TNC" - (minimisation non linéaire sous contraintes), "CG" (minimisation non - linéaire sans contraintes), "BFGS" (minimisation non linéaire sans - contraintes), "NCG" (minimisation de type gradient conjugué de Newton). Il - est fortement conseillé de conserver la valeur par défaut. + Cette clé permet de changer le minimiseur pour l'optimiseur. Le choix par + défaut est "LBFGSB", et les choix possibles sont "LBFGSB" (minimisation non + linéaire sous contraintes, voir [Byrd95]_, [Morales11]_ et [Zhu97]_), "TNC" + (minimisation non linéaire sous contraintes), "CG" (minimisation non + linéaire sans contraintes), "BFGS" (minimisation non linéaire sans + contraintes), "NCG" (minimisation de type gradient conjugué de Newton). Il + est fortement conseillé de conserver la valeur par défaut. Exemple : ``{"Minimizer":"LBFGSB"}`` Bounds - Cette clé permet de définir des bornes supérieure et inférieure pour chaque - variable d'état optimisée. Les bornes doivent être données par une liste de - liste de paires de bornes inférieure/supérieure pour chaque variable, avec + Cette clé permet de définir des bornes supérieure et inférieure pour chaque + variable d'état optimisée. Les bornes doivent être données par une liste de + liste de paires de bornes inférieure/supérieure pour chaque variable, avec une valeur ``None`` chaque fois qu'il n'y a pas de borne. Les bornes peuvent - toujours être spécifiées, mais seuls les optimiseurs sous contraintes les + toujours être spécifiées, mais seuls les optimiseurs sous contraintes les prennent en compte. Exemple : ``{"Bounds":[[2.,5.],[1.e-2,10.],[-30.,None],[None,None]]}`` MaximumNumberOfSteps - Cette clé indique le nombre maximum d'itérations possibles en optimisation - itérative. Le défaut est 15000, qui est très similaire à une absence de - limite sur les itérations. Il est ainsi recommandé d'adapter ce paramètre - aux besoins pour des problèmes réels. Pour certains optimiseurs, le nombre - de pas effectif d'arrêt peut être légèrement différent de la limite à cause - d'exigences de contrôle interne de l'algorithme. + Cette clé indique le nombre maximum d'itérations possibles en optimisation + itérative. Le défaut est 15000, qui est très similaire à une absence de + limite sur les itérations. Il est ainsi recommandé d'adapter ce paramètre + aux besoins pour des problèmes réels. Pour certains optimiseurs, le nombre + de pas effectif d'arrêt peut être légèrement différent de la limite à cause + d'exigences de contrôle interne de l'algorithme. Exemple : ``{"MaximumNumberOfSteps":100}`` CostDecrementTolerance - Cette clé indique une valeur limite, conduisant à arrêter le processus - itératif d'optimisation lorsque la fonction coût décroît moins que cette - tolérance au dernier pas. Le défaut est de 1.e-7, et il est recommandé - de l'adapter aux besoins pour des problèmes réels. + Cette clé indique une valeur limite, conduisant à arrêter le processus + itératif d'optimisation lorsque la fonction coût décroît moins que cette + tolérance au dernier pas. Le défaut est de 1.e-7, et il est recommandé + de l'adapter aux besoins pour des problèmes réels. Exemple : ``{"CostDecrementTolerance":1.e-7}`` ProjectedGradientTolerance - Cette clé indique une valeur limite, conduisant à arrêter le processus - itératif d'optimisation lorsque toutes les composantes du gradient projeté - sont en-dessous de cette limite. C'est utilisé uniquement par les - optimiseurs sous contraintes. Le défaut est -1, qui désigne le défaut - interne de chaque optimiseur (usuellement 1.e-5), et il n'est pas recommandé + Cette clé indique une valeur limite, conduisant à arrêter le processus + itératif d'optimisation lorsque toutes les composantes du gradient projeté + sont en-dessous de cette limite. C'est utilisé uniquement par les + optimiseurs sous contraintes. Le défaut est -1, qui désigne le défaut + interne de chaque optimiseur (usuellement 1.e-5), et il n'est pas recommandé de le changer. Exemple : ``{"ProjectedGradientTolerance":-1}`` GradientNormTolerance - Cette clé indique une valeur limite, conduisant à arrêter le processus - itératif d'optimisation lorsque la norme du gradient est en dessous de cette - limite. C'est utilisé uniquement par les optimiseurs sans contraintes. Le - défaut est 1.e-5 et il n'est pas recommandé de le changer. + Cette clé indique une valeur limite, conduisant à arrêter le processus + itératif d'optimisation lorsque la norme du gradient est en dessous de cette + limite. C'est utilisé uniquement par les optimiseurs sans contraintes. Le + défaut est 1.e-5 et il n'est pas recommandé de le changer. Exemple : ``{"GradientNormTolerance":1.e-5}`` StoreSupplementaryCalculations - Cette liste indique les noms des variables supplémentaires qui peuvent être - disponibles à la fin de l'algorithme. Cela implique potentiellement des - calculs ou du stockage coûteux. La valeur par défaut est une liste vide, - aucune de ces variables n'étant calculée et stockée par défaut. Les noms + Cette liste indique les noms des variables supplémentaires qui peuvent être + disponibles à la fin de l'algorithme. Cela implique potentiellement des + calculs ou du stockage coûteux. La valeur par défaut est une liste vide, + aucune de ces variables n'étant calculée et stockée par défaut. Les noms possibles sont dans la liste suivante : ["APosterioriCorrelations", "APosterioriCovariance", "APosterioriStandardDeviations", "APosterioriVariances", "BMA", "CostFunctionJ", "CostFunctionJb", @@ -181,222 +181,222 @@ Les options de l'algorithme sont les suivantes: Exemple : ``{"StoreSupplementaryCalculations":["BMA", "Innovation"]}`` Quantiles - Cette liste indique les valeurs de quantile, entre 0 et 1, à estimer par - simulation autour de l'état optimal. L'échantillonnage utilise des tirages - aléatoires gaussiens multivariés, dirigés par la matrice de covariance a - posteriori. Cette option n'est utile que si le calcul supplémentaire - "SimulationQuantiles" a été choisi. La valeur par défaut est une liste vide. + Cette liste indique les valeurs de quantile, entre 0 et 1, à estimer par + simulation autour de l'état optimal. L'échantillonnage utilise des tirages + aléatoires gaussiens multivariés, dirigés par la matrice de covariance a + posteriori. Cette option n'est utile que si le calcul supplémentaire + "SimulationQuantiles" a été choisi. La valeur par défaut est une liste vide. Exemple : ``{"Quantiles":[0.1,0.9]}`` SetSeed - Cette clé permet de donner un nombre entier pour fixer la graine du - générateur aléatoire utilisé pour générer l'ensemble. Un valeur pratique est - par exemple 1000. Par défaut, la graine est laissée non initialisée, et elle - utilise ainsi l'initialisation par défaut de l'ordinateur. + Cette clé permet de donner un nombre entier pour fixer la graine du + générateur aléatoire utilisé pour générer l'ensemble. Un valeur pratique est + par exemple 1000. Par défaut, la graine est laissée non initialisée, et elle + utilise ainsi l'initialisation par défaut de l'ordinateur. Exemple : ``{"SetSeed":1000}`` NumberOfSamplesForQuantiles - Cette clé indique le nombre de simulations effectuées pour estimer les - quantiles. Cette option n'est utile que si le calcul supplémentaire - "SimulationQuantiles" a été choisi. Le défaut est 100, ce qui suffit souvent - pour une estimation correcte de quantiles courants à 5%, 10%, 90% ou 95%. + Cette clé indique le nombre de simulations effectuées pour estimer les + quantiles. Cette option n'est utile que si le calcul supplémentaire + "SimulationQuantiles" a été choisi. Le défaut est 100, ce qui suffit souvent + pour une estimation correcte de quantiles courants à 5%, 10%, 90% ou 95%. Exemple : ``{"NumberOfSamplesForQuantiles":100}`` SimulationForQuantiles - Cette clé indique le type de simulation, linéaire (avec l'opérateur - d'observation tangent appliqué sur des incréments de perturbations autour de - l'état optimal) ou non-linéaire (avec l'opérateur d'observation standard - appliqué aux états perturbés), que l'on veut faire pour chaque perturbation. - Cela change essentiellement le temps de chaque simulation élémentaire, - usuellement plus long en non-linéaire qu'en linéaire. Cette option n'est - utile que si le calcul supplémentaire "SimulationQuantiles" a été choisi. La - valeur par défaut est "Linear", et les choix possibles sont "Linear" et + Cette clé indique le type de simulation, linéaire (avec l'opérateur + d'observation tangent appliqué sur des incréments de perturbations autour de + l'état optimal) ou non-linéaire (avec l'opérateur d'observation standard + appliqué aux états perturbés), que l'on veut faire pour chaque perturbation. + Cela change essentiellement le temps de chaque simulation élémentaire, + usuellement plus long en non-linéaire qu'en linéaire. Cette option n'est + utile que si le calcul supplémentaire "SimulationQuantiles" a été choisi. La + valeur par défaut est "Linear", et les choix possibles sont "Linear" et "NonLinear". Exemple : ``{"SimulationForQuantiles":"Linear"}`` -Informations et variables disponibles à la fin de l'algorithme +Informations et variables disponibles à la fin de l'algorithme ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -En sortie, après exécution de l'algorithme, on dispose d'informations et de +En sortie, après exécution de l'algorithme, on dispose d'informations et de variables issues du calcul. La description des -:ref:`section_ref_output_variables` indique la manière de les obtenir par la -méthode nommée ``get`` de la variable "*ADD*" du post-processing. Les variables -d'entrée, mises à disposition de l'utilisateur en sortie pour faciliter -l'écriture des procédures de post-processing, sont décrites dans +:ref:`section_ref_output_variables` indique la manière de les obtenir par la +méthode nommée ``get`` de la variable "*ADD*" du post-processing. Les variables +d'entrée, mises à disposition de l'utilisateur en sortie pour faciliter +l'écriture des procédures de post-processing, sont décrites dans l':ref:`subsection_r_o_v_Inventaire`. Les sorties non conditionnelles de l'algorithme sont les suivantes: Analysis - *Liste de vecteurs*. Chaque élément est un état optimal :math:`\mathbf{x}*` + *Liste de vecteurs*. Chaque élément est un état optimal :math:`\mathbf{x}*` en optimisation ou une analyse :math:`\mathbf{x}^a` en assimilation de - données. + données. Exemple : ``Xa = ADD.get("Analysis")[-1]`` CostFunctionJ - *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart + *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart :math:`J`. Exemple : ``J = ADD.get("CostFunctionJ")[:]`` CostFunctionJb - *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart - :math:`J^b`, c'est-à-dire de la partie écart à l'ébauche. + *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart + :math:`J^b`, c'est-à-dire de la partie écart à l'ébauche. Exemple : ``Jb = ADD.get("CostFunctionJb")[:]`` CostFunctionJo - *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart - :math:`J^o`, c'est-à-dire de la partie écart à l'observation. + *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart + :math:`J^o`, c'est-à-dire de la partie écart à l'observation. Exemple : ``Jo = ADD.get("CostFunctionJo")[:]`` Les sorties conditionnelles de l'algorithme sont les suivantes: APosterioriCorrelations - *Liste de matrices*. Chaque élément est une matrice de corrélations des - erreurs *a posteriori* de l'état optimal, issue de la matrice + *Liste de matrices*. Chaque élément est une matrice de corrélations des + erreurs *a posteriori* de l'état optimal, issue de la matrice :math:`\mathbf{A}*` des covariances. Exemple : ``C = ADD.get("APosterioriCorrelations")[-1]`` APosterioriCovariance - *Liste de matrices*. Chaque élément est une matrice :math:`\mathbf{A}*` de - covariances des erreurs *a posteriori* de l'état optimal. + *Liste de matrices*. Chaque élément est une matrice :math:`\mathbf{A}*` de + covariances des erreurs *a posteriori* de l'état optimal. Exemple : ``A = ADD.get("APosterioriCovariance")[-1]`` APosterioriStandardDeviations - *Liste de matrices*. Chaque élément est une matrice diagonale d'écarts-types - des erreurs *a posteriori* de l'état optimal, issue de la matrice + *Liste de matrices*. Chaque élément est une matrice diagonale d'écarts-types + des erreurs *a posteriori* de l'état optimal, issue de la matrice :math:`\mathbf{A}*` des covariances. Exemple : ``S = ADD.get("APosterioriStandardDeviations")[-1]`` APosterioriVariances - *Liste de matrices*. Chaque élément est une matrice diagonale de variances - des erreurs *a posteriori* de l'état optimal, issue de la matrice + *Liste de matrices*. Chaque élément est une matrice diagonale de variances + des erreurs *a posteriori* de l'état optimal, issue de la matrice :math:`\mathbf{A}*` des covariances. Exemple : ``V = ADD.get("APosterioriVariances")[-1]`` BMA - *Liste de vecteurs*. Chaque élément est un vecteur d'écart entre - l'ébauche et l'état optimal. + *Liste de vecteurs*. Chaque élément est un vecteur d'écart entre + l'ébauche et l'état optimal. Exemple : ``bma = ADD.get("BMA")[-1]`` CostFunctionJAtCurrentOptimum - *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart - :math:`J`. A chaque pas, la valeur correspond à l'état optimal trouvé depuis - le début. + *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart + :math:`J`. A chaque pas, la valeur correspond à l'état optimal trouvé depuis + le début. Exemple : ``JACO = ADD.get("CostFunctionJAtCurrentOptimum")[:]`` CostFunctionJbAtCurrentOptimum - *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart - :math:`J^b`, c'est-à-dire de la partie écart à l'ébauche. A chaque pas, la - valeur correspond à l'état optimal trouvé depuis le début. + *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart + :math:`J^b`, c'est-à-dire de la partie écart à l'ébauche. A chaque pas, la + valeur correspond à l'état optimal trouvé depuis le début. Exemple : ``JbACO = ADD.get("CostFunctionJbAtCurrentOptimum")[:]`` CostFunctionJoAtCurrentOptimum - *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart - :math:`J^o`, c'est-à-dire de la partie écart à l'observation. A chaque pas, - la valeur correspond à l'état optimal trouvé depuis le début. + *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart + :math:`J^o`, c'est-à-dire de la partie écart à l'observation. A chaque pas, + la valeur correspond à l'état optimal trouvé depuis le début. Exemple : ``JoACO = ADD.get("CostFunctionJoAtCurrentOptimum")[:]`` CurrentOptimum - *Liste de vecteurs*. Chaque élément est le vecteur d'état optimal au pas de - temps courant au cours du déroulement de l'algorithme d'optimisation. Ce - n'est pas nécessairement le dernier état. + *Liste de vecteurs*. Chaque élément est le vecteur d'état optimal au pas de + temps courant au cours du déroulement de l'algorithme d'optimisation. Ce + n'est pas nécessairement le dernier état. Exemple : ``Xo = ADD.get("CurrentOptimum")[:]`` CurrentState - *Liste de vecteurs*. Chaque élément est un vecteur d'état courant utilisé - au cours du déroulement de l'algorithme d'optimisation. + *Liste de vecteurs*. Chaque élément est un vecteur d'état courant utilisé + au cours du déroulement de l'algorithme d'optimisation. Exemple : ``Xs = ADD.get("CurrentState")[:]`` IndexOfOptimum - *Liste d'entiers*. Chaque élément est l'index d'itération de l'optimum - obtenu au cours du déroulement de l'algorithme d'optimisation. Ce n'est pas - nécessairement le numéro de la dernière itération. + *Liste d'entiers*. Chaque élément est l'index d'itération de l'optimum + obtenu au cours du déroulement de l'algorithme d'optimisation. Ce n'est pas + nécessairement le numéro de la dernière itération. Exemple : ``i = ADD.get("IndexOfOptimum")[-1]`` Innovation - *Liste de vecteurs*. Chaque élément est un vecteur d'innovation, qui est - en statique l'écart de l'optimum à l'ébauche, et en dynamique l'incrément - d'évolution. + *Liste de vecteurs*. Chaque élément est un vecteur d'innovation, qui est + en statique l'écart de l'optimum à l'ébauche, et en dynamique l'incrément + d'évolution. Exemple : ``d = ADD.get("Innovation")[-1]`` InnovationAtCurrentState - *Liste de vecteurs*. Chaque élément est un vecteur d'innovation à l'état + *Liste de vecteurs*. Chaque élément est un vecteur d'innovation à l'état courant. Exemple : ``ds = ADD.get("InnovationAtCurrentState")[-1]`` MahalanobisConsistency - *Liste de valeurs*. Chaque élément est une valeur de l'indicateur de - qualité de Mahalanobis. + *Liste de valeurs*. Chaque élément est une valeur de l'indicateur de + qualité de Mahalanobis. Exemple : ``m = ADD.get("MahalanobisConsistency")[-1]`` OMA - *Liste de vecteurs*. Chaque élément est un vecteur d'écart entre - l'observation et l'état optimal dans l'espace des observations. + *Liste de vecteurs*. Chaque élément est un vecteur d'écart entre + l'observation et l'état optimal dans l'espace des observations. Exemple : ``oma = ADD.get("OMA")[-1]`` OMB - *Liste de vecteurs*. Chaque élément est un vecteur d'écart entre - l'observation et l'état d'ébauche dans l'espace des observations. + *Liste de vecteurs*. Chaque élément est un vecteur d'écart entre + l'observation et l'état d'ébauche dans l'espace des observations. Exemple : ``omb = ADD.get("OMB")[-1]`` SigmaObs2 - *Liste de valeurs*. Chaque élément est une valeur de l'indicateur de - qualité :math:`(\sigma^o)^2` de la partie observation. + *Liste de valeurs*. Chaque élément est une valeur de l'indicateur de + qualité :math:`(\sigma^o)^2` de la partie observation. Exemple : ``so2 = ADD.get("SigmaObs")[-1]`` SimulatedObservationAtBackground - *Liste de vecteurs*. Chaque élément est un vecteur d'observation simulé à - partir de l'ébauche :math:`\mathbf{x}^b`. + *Liste de vecteurs*. Chaque élément est un vecteur d'observation simulé à + partir de l'ébauche :math:`\mathbf{x}^b`. Exemple : ``hxb = ADD.get("SimulatedObservationAtBackground")[-1]`` SimulatedObservationAtCurrentOptimum - *Liste de vecteurs*. Chaque élément est un vecteur d'observation simulé à - partir de l'état optimal au pas de temps courant au cours du déroulement de - l'algorithme d'optimisation, c'est-à-dire dans l'espace des observations. + *Liste de vecteurs*. Chaque élément est un vecteur d'observation simulé à + partir de l'état optimal au pas de temps courant au cours du déroulement de + l'algorithme d'optimisation, c'est-à-dire dans l'espace des observations. Exemple : ``hxo = ADD.get("SimulatedObservationAtCurrentOptimum")[-1]`` SimulatedObservationAtCurrentState - *Liste de vecteurs*. Chaque élément est un vecteur d'observation simulé à - partir de l'état courant, c'est-à-dire dans l'espace des observations. + *Liste de vecteurs*. Chaque élément est un vecteur d'observation simulé à + partir de l'état courant, c'est-à-dire dans l'espace des observations. Exemple : ``hxs = ADD.get("SimulatedObservationAtCurrentState")[-1]`` SimulatedObservationAtOptimum - *Liste de vecteurs*. Chaque élément est un vecteur d'observation simulé à - partir de l'analyse ou de l'état optimal :math:`\mathbf{x}^a`. + *Liste de vecteurs*. Chaque élément est un vecteur d'observation simulé à + partir de l'analyse ou de l'état optimal :math:`\mathbf{x}^a`. Exemple : ``hxa = ADD.get("SimulatedObservationAtOptimum")[-1]`` SimulationQuantiles - *Liste de vecteurs*. Chaque élément est un vecteur correspondant à l'état - observé qui réalise le quantile demandé, dans le même ordre que les + *Liste de vecteurs*. Chaque élément est un vecteur correspondant à l'état + observé qui réalise le quantile demandé, dans le même ordre que les quantiles requis par l'utilisateur. Exemple : ``sQuantiles = ADD.get("SimulationQuantiles")[:]`` @@ -404,12 +404,12 @@ Les sorties conditionnelles de l'algorithme sont les suivantes: Voir aussi ++++++++++ -Références vers d'autres sections : +Références vers d'autres sections : - :ref:`section_ref_algorithm_Blue` - :ref:`section_ref_algorithm_ExtendedBlue` - :ref:`section_ref_algorithm_LinearityTest` -Références bibliographiques : +Références bibliographiques : - [Byrd95]_ - [Morales11]_ - [Talagrand97]_ diff --git a/doc/fr/ref_algorithm_4DVAR.rst b/doc/fr/ref_algorithm_4DVAR.rst index 35fd801..749d8be 100644 --- a/doc/fr/ref_algorithm_4DVAR.rst +++ b/doc/fr/ref_algorithm_4DVAR.rst @@ -29,21 +29,21 @@ Algorithme de calcul "*4DVAR*" .. warning:: - dans sa présente version, cet algorithme est expérimental, et reste donc + dans sa présente version, cet algorithme est expérimental, et reste donc susceptible de changements dans les prochaines versions. Description +++++++++++ -Cet algorithme réalise une estimation de l'état d'un système dynamique, par une -méthode de minimisation variationnelle de la fonctionnelle :math:`J` d'écart -classique en assimilation de données : +Cet algorithme réalise une estimation de l'état d'un système dynamique, par une +méthode de minimisation variationnelle de la fonctionnelle :math:`J` d'écart +classique en assimilation de données : .. math:: J(\mathbf{x})=(\mathbf{x}-\mathbf{x}^b)^T.\mathbf{B}^{-1}.(\mathbf{x}-\mathbf{x}^b)+\sum_{t\in T}(\mathbf{y^o}(t)-H(\mathbf{x},t))^T.\mathbf{R}^{-1}.(\mathbf{y^o}(t)-H(\mathbf{x},t)) -qui est usuellement désignée comme la fonctionnelle "*4D-VAR*" (voir par exemple -[Talagrand97]_). Il est bien adapté aux cas d'opérateurs d'observation et -d'évolution non-linéaires, son domaine d'application est comparable aux +qui est usuellement désignée comme la fonctionnelle "*4D-VAR*" (voir par exemple +[Talagrand97]_). Il est bien adapté aux cas d'opérateurs d'observation et +d'évolution non-linéaires, son domaine d'application est comparable aux algorithmes de filtrage de Kalman et en particulier l':ref:`section_ref_algorithm_ExtendedKalmanFilter` ou l':ref:`section_ref_algorithm_UnscentedKalmanFilter`. @@ -66,230 +66,230 @@ Commandes requises et optionnelles .. index:: single: GradientNormTolerance .. index:: single: StoreSupplementaryCalculations -Les commandes requises générales, disponibles dans l'interface en édition, sont +Les commandes requises générales, disponibles dans l'interface en édition, sont les suivantes: Background - *Commande obligatoire*. Elle définit le vecteur d'ébauche ou - d'initialisation, noté précédemment :math:`\mathbf{x}^b`. Sa valeur est - définie comme un objet de type "*Vector*" ou de type "*VectorSerie*". + *Commande obligatoire*. Elle définit le vecteur d'ébauche ou + d'initialisation, noté précédemment :math:`\mathbf{x}^b`. Sa valeur est + définie comme un objet de type "*Vector*" ou de type "*VectorSerie*". BackgroundError - *Commande obligatoire*. Elle définit la matrice de covariance des erreurs - d'ébauche, notée précédemment :math:`\mathbf{B}`. Sa valeur est définie + *Commande obligatoire*. Elle définit la matrice de covariance des erreurs + d'ébauche, notée précédemment :math:`\mathbf{B}`. Sa valeur est définie comme un objet de type "*Matrix*", de type "*ScalarSparseMatrix*", ou de type "*DiagonalSparseMatrix*". Observation - *Commande obligatoire*. Elle définit le vecteur d'observation utilisé en - assimilation de données ou en optimisation, et noté précédemment - :math:`\mathbf{y}^o`. Sa valeur est définie comme un objet de type "*Vector*" + *Commande obligatoire*. Elle définit le vecteur d'observation utilisé en + assimilation de données ou en optimisation, et noté précédemment + :math:`\mathbf{y}^o`. Sa valeur est définie comme un objet de type "*Vector*" ou de type "*VectorSerie*". ObservationError - *Commande obligatoire*. Elle définit la matrice de covariance des erreurs - d'ébauche, notée précédemment :math:`\mathbf{R}`. Sa valeur est définie + *Commande obligatoire*. Elle définit la matrice de covariance des erreurs + d'ébauche, notée précédemment :math:`\mathbf{R}`. Sa valeur est définie comme un objet de type "*Matrix*", de type "*ScalarSparseMatrix*", ou de type "*DiagonalSparseMatrix*". ObservationOperator - *Commande obligatoire*. Elle indique l'opérateur d'observation, noté - précédemment :math:`H`, qui transforme les paramètres d'entrée - :math:`\mathbf{x}` en résultats :math:`\mathbf{y}` qui sont à comparer aux - observations :math:`\mathbf{y}^o`. Sa valeur est définie comme un objet de + *Commande obligatoire*. Elle indique l'opérateur d'observation, noté + précédemment :math:`H`, qui transforme les paramètres d'entrée + :math:`\mathbf{x}` en résultats :math:`\mathbf{y}` qui sont à comparer aux + observations :math:`\mathbf{y}^o`. Sa valeur est définie comme un objet de type "*Function*" ou de type "*Matrix*". Dans le cas du type "*Function*", - différentes formes fonctionnelles peuvent être utilisées, comme décrit dans - la section :ref:`section_ref_operator_requirements`. Si un contrôle - :math:`U` est inclus dans le modèle d'observation, l'opérateur doit être - appliqué à une paire :math:`(X,U)`. - -Les commandes optionnelles générales, disponibles dans l'interface en édition, -sont indiquées dans la :ref:`section_ref_assimilation_keywords`. De plus, les -paramètres de la commande "*AlgorithmParameters*" permettent d'indiquer les -options particulières, décrites ci-après, de l'algorithme. On se reportera à la + différentes formes fonctionnelles peuvent être utilisées, comme décrit dans + la section :ref:`section_ref_operator_requirements`. Si un contrôle + :math:`U` est inclus dans le modèle d'observation, l'opérateur doit être + appliqué à une paire :math:`(X,U)`. + +Les commandes optionnelles générales, disponibles dans l'interface en édition, +sont indiquées dans la :ref:`section_ref_assimilation_keywords`. De plus, les +paramètres de la commande "*AlgorithmParameters*" permettent d'indiquer les +options particulières, décrites ci-après, de l'algorithme. On se reportera à la :ref:`section_ref_options_Algorithm_Parameters` pour le bon usage de cette commande. Les options de l'algorithme sont les suivantes: Minimizer - Cette clé permet de changer le minimiseur pour l'optimiseur. Le choix par - défaut est "LBFGSB", et les choix possibles sont "LBFGSB" (minimisation non - linéaire sous contraintes, voir [Byrd95]_, [Morales11]_ et [Zhu97]_), "TNC" - (minimisation non linéaire sous contraintes), "CG" (minimisation non - linéaire sans contraintes), "BFGS" (minimisation non linéaire sans - contraintes), "NCG" (minimisation de type gradient conjugué de Newton). Il - est fortement conseillé de conserver la valeur par défaut. + Cette clé permet de changer le minimiseur pour l'optimiseur. Le choix par + défaut est "LBFGSB", et les choix possibles sont "LBFGSB" (minimisation non + linéaire sous contraintes, voir [Byrd95]_, [Morales11]_ et [Zhu97]_), "TNC" + (minimisation non linéaire sous contraintes), "CG" (minimisation non + linéaire sans contraintes), "BFGS" (minimisation non linéaire sans + contraintes), "NCG" (minimisation de type gradient conjugué de Newton). Il + est fortement conseillé de conserver la valeur par défaut. Exemple : ``{"Minimizer":"LBFGSB"}`` Bounds - Cette clé permet de définir des bornes supérieure et inférieure pour chaque - variable d'état optimisée. Les bornes doivent être données par une liste de - liste de paires de bornes inférieure/supérieure pour chaque variable, avec + Cette clé permet de définir des bornes supérieure et inférieure pour chaque + variable d'état optimisée. Les bornes doivent être données par une liste de + liste de paires de bornes inférieure/supérieure pour chaque variable, avec une valeur ``None`` chaque fois qu'il n'y a pas de borne. Les bornes peuvent - toujours être spécifiées, mais seuls les optimiseurs sous contraintes les + toujours être spécifiées, mais seuls les optimiseurs sous contraintes les prennent en compte. Exemple : ``{"Bounds":[[2.,5.],[1.e-2,10.],[-30.,None],[None,None]]}`` ConstrainedBy - Cette clé permet d'indiquer la méthode de prise en compte des contraintes de + Cette clé permet d'indiquer la méthode de prise en compte des contraintes de bornes. La seule disponible est "EstimateProjection", qui projete - l'estimation de l'état courant sur les contraintes de bornes. + l'estimation de l'état courant sur les contraintes de bornes. Exemple : ``{"ConstrainedBy":"EstimateProjection"}`` MaximumNumberOfSteps - Cette clé indique le nombre maximum d'itérations possibles en optimisation - itérative. Le défaut est 15000, qui est très similaire à une absence de - limite sur les itérations. Il est ainsi recommandé d'adapter ce paramètre - aux besoins pour des problèmes réels. Pour certains optimiseurs, le nombre - de pas effectif d'arrêt peut être légèrement différent de la limite à cause - d'exigences de contrôle interne de l'algorithme. + Cette clé indique le nombre maximum d'itérations possibles en optimisation + itérative. Le défaut est 15000, qui est très similaire à une absence de + limite sur les itérations. Il est ainsi recommandé d'adapter ce paramètre + aux besoins pour des problèmes réels. Pour certains optimiseurs, le nombre + de pas effectif d'arrêt peut être légèrement différent de la limite à cause + d'exigences de contrôle interne de l'algorithme. Exemple : ``{"MaximumNumberOfSteps":100}`` CostDecrementTolerance - Cette clé indique une valeur limite, conduisant à arrêter le processus - itératif d'optimisation lorsque la fonction coût décroît moins que cette - tolérance au dernier pas. Le défaut est de 1.e-7, et il est recommandé - de l'adapter aux besoins pour des problèmes réels. + Cette clé indique une valeur limite, conduisant à arrêter le processus + itératif d'optimisation lorsque la fonction coût décroît moins que cette + tolérance au dernier pas. Le défaut est de 1.e-7, et il est recommandé + de l'adapter aux besoins pour des problèmes réels. Exemple : ``{"CostDecrementTolerance":1.e-7}`` EstimationOf - Cette clé permet de choisir le type d'estimation à réaliser. Cela peut être - soit une estimation de l'état, avec la valeur "State", ou une estimation de - paramètres, avec la valeur "Parameters". Le choix par défaut est "State". + Cette clé permet de choisir le type d'estimation à réaliser. Cela peut être + soit une estimation de l'état, avec la valeur "State", ou une estimation de + paramètres, avec la valeur "Parameters". Le choix par défaut est "State". Exemple : ``{"EstimationOf":"Parameters"}`` ProjectedGradientTolerance - Cette clé indique une valeur limite, conduisant à arrêter le processus - itératif d'optimisation lorsque toutes les composantes du gradient projeté - sont en-dessous de cette limite. C'est utilisé uniquement par les - optimiseurs sous contraintes. Le défaut est -1, qui désigne le défaut - interne de chaque optimiseur (usuellement 1.e-5), et il n'est pas recommandé + Cette clé indique une valeur limite, conduisant à arrêter le processus + itératif d'optimisation lorsque toutes les composantes du gradient projeté + sont en-dessous de cette limite. C'est utilisé uniquement par les + optimiseurs sous contraintes. Le défaut est -1, qui désigne le défaut + interne de chaque optimiseur (usuellement 1.e-5), et il n'est pas recommandé de le changer. Exemple : ``{"ProjectedGradientTolerance":-1}`` GradientNormTolerance - Cette clé indique une valeur limite, conduisant à arrêter le processus - itératif d'optimisation lorsque la norme du gradient est en dessous de cette - limite. C'est utilisé uniquement par les optimiseurs sans contraintes. Le - défaut est 1.e-5 et il n'est pas recommandé de le changer. + Cette clé indique une valeur limite, conduisant à arrêter le processus + itératif d'optimisation lorsque la norme du gradient est en dessous de cette + limite. C'est utilisé uniquement par les optimiseurs sans contraintes. Le + défaut est 1.e-5 et il n'est pas recommandé de le changer. Exemple : ``{"GradientNormTolerance":1.e-5}`` StoreSupplementaryCalculations - Cette liste indique les noms des variables supplémentaires qui peuvent être - disponibles à la fin de l'algorithme. Cela implique potentiellement des - calculs ou du stockage coûteux. La valeur par défaut est une liste vide, - aucune de ces variables n'étant calculée et stockée par défaut. Les noms + Cette liste indique les noms des variables supplémentaires qui peuvent être + disponibles à la fin de l'algorithme. Cela implique potentiellement des + calculs ou du stockage coûteux. La valeur par défaut est une liste vide, + aucune de ces variables n'étant calculée et stockée par défaut. Les noms possibles sont dans la liste suivante : ["BMA", "CostFunctionJ", "CostFunctionJb", "CostFunctionJo", "CostFunctionJAtCurrentOptimum", "CurrentOptimum", "CurrentState", "IndexOfOptimum"]. Exemple : ``{"StoreSupplementaryCalculations":["BMA", "CurrentState"]}`` -Informations et variables disponibles à la fin de l'algorithme +Informations et variables disponibles à la fin de l'algorithme ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -En sortie, après exécution de l'algorithme, on dispose d'informations et de +En sortie, après exécution de l'algorithme, on dispose d'informations et de variables issues du calcul. La description des -:ref:`section_ref_output_variables` indique la manière de les obtenir par la -méthode nommée ``get`` de la variable "*ADD*" du post-processing. Les variables -d'entrée, mises à disposition de l'utilisateur en sortie pour faciliter -l'écriture des procédures de post-processing, sont décrites dans +:ref:`section_ref_output_variables` indique la manière de les obtenir par la +méthode nommée ``get`` de la variable "*ADD*" du post-processing. Les variables +d'entrée, mises à disposition de l'utilisateur en sortie pour faciliter +l'écriture des procédures de post-processing, sont décrites dans l':ref:`subsection_r_o_v_Inventaire`. Les sorties non conditionnelles de l'algorithme sont les suivantes: Analysis - *Liste de vecteurs*. Chaque élément est un état optimal :math:`\mathbf{x}*` + *Liste de vecteurs*. Chaque élément est un état optimal :math:`\mathbf{x}*` en optimisation ou une analyse :math:`\mathbf{x}^a` en assimilation de - données. + données. Exemple : ``Xa = ADD.get("Analysis")[-1]`` CostFunctionJ - *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart + *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart :math:`J`. Exemple : ``J = ADD.get("CostFunctionJ")[:]`` CostFunctionJb - *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart - :math:`J^b`, c'est-à-dire de la partie écart à l'ébauche. + *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart + :math:`J^b`, c'est-à-dire de la partie écart à l'ébauche. Exemple : ``Jb = ADD.get("CostFunctionJb")[:]`` CostFunctionJo - *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart - :math:`J^o`, c'est-à-dire de la partie écart à l'observation. + *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart + :math:`J^o`, c'est-à-dire de la partie écart à l'observation. Exemple : ``Jo = ADD.get("CostFunctionJo")[:]`` Les sorties conditionnelles de l'algorithme sont les suivantes: BMA - *Liste de vecteurs*. Chaque élément est un vecteur d'écart entre - l'ébauche et l'état optimal. + *Liste de vecteurs*. Chaque élément est un vecteur d'écart entre + l'ébauche et l'état optimal. Exemple : ``bma = ADD.get("BMA")[-1]`` CostFunctionJAtCurrentOptimum - *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart - :math:`J`. A chaque pas, la valeur correspond à l'état optimal trouvé depuis - le début. + *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart + :math:`J`. A chaque pas, la valeur correspond à l'état optimal trouvé depuis + le début. Exemple : ``JACO = ADD.get("CostFunctionJAtCurrentOptimum")[:]`` CostFunctionJbAtCurrentOptimum - *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart - :math:`J^b`, c'est-à-dire de la partie écart à l'ébauche. A chaque pas, la - valeur correspond à l'état optimal trouvé depuis le début. + *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart + :math:`J^b`, c'est-à-dire de la partie écart à l'ébauche. A chaque pas, la + valeur correspond à l'état optimal trouvé depuis le début. Exemple : ``JbACO = ADD.get("CostFunctionJbAtCurrentOptimum")[:]`` CostFunctionJoAtCurrentOptimum - *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart - :math:`J^o`, c'est-à-dire de la partie écart à l'observation. A chaque pas, - la valeur correspond à l'état optimal trouvé depuis le début. + *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart + :math:`J^o`, c'est-à-dire de la partie écart à l'observation. A chaque pas, + la valeur correspond à l'état optimal trouvé depuis le début. Exemple : ``JoACO = ADD.get("CostFunctionJoAtCurrentOptimum")[:]`` CurrentOptimum - *Liste de vecteurs*. Chaque élément est le vecteur d'état optimal au pas de - temps courant au cours du déroulement de l'algorithme d'optimisation. Ce - n'est pas nécessairement le dernier état. + *Liste de vecteurs*. Chaque élément est le vecteur d'état optimal au pas de + temps courant au cours du déroulement de l'algorithme d'optimisation. Ce + n'est pas nécessairement le dernier état. Exemple : ``Xo = ADD.get("CurrentOptimum")[:]`` CurrentState - *Liste de vecteurs*. Chaque élément est un vecteur d'état courant utilisé - au cours du déroulement de l'algorithme d'optimisation. + *Liste de vecteurs*. Chaque élément est un vecteur d'état courant utilisé + au cours du déroulement de l'algorithme d'optimisation. Exemple : ``Xs = ADD.get("CurrentState")[:]`` IndexOfOptimum - *Liste d'entiers*. Chaque élément est l'index d'itération de l'optimum - obtenu au cours du déroulement de l'algorithme d'optimisation. Ce n'est pas - nécessairement le numéro de la dernière itération. + *Liste d'entiers*. Chaque élément est l'index d'itération de l'optimum + obtenu au cours du déroulement de l'algorithme d'optimisation. Ce n'est pas + nécessairement le numéro de la dernière itération. Exemple : ``i = ADD.get("IndexOfOptimum")[-1]`` Voir aussi ++++++++++ -Références vers d'autres sections : +Références vers d'autres sections : - :ref:`section_ref_algorithm_3DVAR` - :ref:`section_ref_algorithm_KalmanFilter` - :ref:`section_ref_algorithm_ExtendedKalmanFilter` -Références bibliographiques : +Références bibliographiques : - [Byrd95]_ - [Morales11]_ - [Talagrand97]_ diff --git a/doc/fr/ref_algorithm_AdjointTest.rst b/doc/fr/ref_algorithm_AdjointTest.rst index 6a3f99d..734824d 100644 --- a/doc/fr/ref_algorithm_AdjointTest.rst +++ b/doc/fr/ref_algorithm_AdjointTest.rst @@ -24,23 +24,23 @@ .. index:: single: AdjointTest .. _section_ref_algorithm_AdjointTest: -Algorithme de vérification "*AdjointTest*" +Algorithme de vérification "*AdjointTest*" ------------------------------------------ Description +++++++++++ -Cet algorithme permet de vérifier la qualité de l'opérateur adjoint, en -calculant un résidu dont les propriétés théoriques sont connues. +Cet algorithme permet de vérifier la qualité de l'opérateur adjoint, en +calculant un résidu dont les propriétés théoriques sont connues. -On observe le résidu suivant, qui est la différence de deux produits scalaires : +On observe le résidu suivant, qui est la différence de deux produits scalaires : .. math:: R(\alpha) = | < TangentF_x(\mathbf{dx}) , \mathbf{y} > - < \mathbf{dx} , AdjointF_x(\mathbf{y}) > | -qui doit rester constamment égal à zéro à la précision du calcul. On prend +qui doit rester constamment égal à zéro à la précision du calcul. On prend :math:`\mathbf{dx}_0=Normal(0,\mathbf{x})` et :math:`\mathbf{dx}=\alpha*\mathbf{dx}_0`. :math:`F` est le code de calcul. -:math:`\mathbf{y}` doit être dans l'image de :math:`F`. S'il n'est pas donné, on +:math:`\mathbf{y}` doit être dans l'image de :math:`F`. S'il n'est pas donné, on prend :math:`\mathbf{y} = F(\mathbf{x})`. Commandes requises et optionnelles @@ -55,117 +55,117 @@ Commandes requises et optionnelles .. index:: single: SetSeed .. index:: single: StoreSupplementaryCalculations -Les commandes requises générales, disponibles dans l'interface en édition, sont +Les commandes requises générales, disponibles dans l'interface en édition, sont les suivantes: CheckingPoint - *Commande obligatoire*. Elle définit le vecteur utilisé comme l'état autour - duquel réaliser le test requis, noté :math:`\mathbf{x}` et similaire à - l'ébauche :math:`\mathbf{x}^b`. Sa valeur est définie comme un objet de type + *Commande obligatoire*. Elle définit le vecteur utilisé comme l'état autour + duquel réaliser le test requis, noté :math:`\mathbf{x}` et similaire à + l'ébauche :math:`\mathbf{x}^b`. Sa valeur est définie comme un objet de type "*Vector*". ObservationOperator - *Commande obligatoire*. Elle indique l'opérateur d'observation, notée - précédemment :math:`H`, qui transforme les paramètres d'entrée - :math:`\mathbf{x}` en résultats :math:`\mathbf{y}` qui sont à comparer aux - observations :math:`\mathbf{y}^o`. Sa valeur est définie comme un objet de - type "*Function*". Différentes formes fonctionnelles peuvent être - utilisées, comme décrit dans la section - :ref:`section_ref_operator_requirements`. Si un contrôle :math:`U` est - inclus dans le modèle d'observation, l'opérateur doit être appliqué à une + *Commande obligatoire*. Elle indique l'opérateur d'observation, notée + précédemment :math:`H`, qui transforme les paramètres d'entrée + :math:`\mathbf{x}` en résultats :math:`\mathbf{y}` qui sont à comparer aux + observations :math:`\mathbf{y}^o`. Sa valeur est définie comme un objet de + type "*Function*". Différentes formes fonctionnelles peuvent être + utilisées, comme décrit dans la section + :ref:`section_ref_operator_requirements`. Si un contrôle :math:`U` est + inclus dans le modèle d'observation, l'opérateur doit être appliqué à une paire :math:`(X,U)`. -Les commandes optionnelles générales, disponibles dans l'interface en édition, -sont indiquées dans la :ref:`section_ref_checking_keywords`. De plus, les -paramètres de la commande "*AlgorithmParameters*" permettent d'indiquer les -options particulières, décrites ci-après, de l'algorithme. On se reportera à la +Les commandes optionnelles générales, disponibles dans l'interface en édition, +sont indiquées dans la :ref:`section_ref_checking_keywords`. De plus, les +paramètres de la commande "*AlgorithmParameters*" permettent d'indiquer les +options particulières, décrites ci-après, de l'algorithme. On se reportera à la :ref:`section_ref_options_Algorithm_Parameters` pour le bon usage de cette commande. Les options de l'algorithme sont les suivantes: AmplitudeOfInitialDirection - Cette clé indique la mise à l'échelle de la perturbation initiale construite - comme un vecteur utilisé pour la dérivée directionnelle autour du point - nominal de vérification. La valeur par défaut est de 1, ce qui signifie pas - de mise à l'échelle. + Cette clé indique la mise à l'échelle de la perturbation initiale construite + comme un vecteur utilisé pour la dérivée directionnelle autour du point + nominal de vérification. La valeur par défaut est de 1, ce qui signifie pas + de mise à l'échelle. Exemple : ``{"AmplitudeOfInitialDirection":0.5}`` EpsilonMinimumExponent - Cette clé indique la valeur de l'exposant minimal du coefficient en - puissance de 10 qui doit être utilisé pour faire décroître le multiplicateur - de l'incrément. La valeur par défaut est de -8, et elle doit être entre 0 et - -20. Par exemple, la valeur par défaut conduit à calculer le résidu de la - formule avec un incrément fixe multiplié par 1.e0 jusqu'à 1.e-8. + Cette clé indique la valeur de l'exposant minimal du coefficient en + puissance de 10 qui doit être utilisé pour faire décroître le multiplicateur + de l'incrément. La valeur par défaut est de -8, et elle doit être entre 0 et + -20. Par exemple, la valeur par défaut conduit à calculer le résidu de la + formule avec un incrément fixe multiplié par 1.e0 jusqu'à 1.e-8. Exemple : ``{"EpsilonMinimumExponent":-12}`` InitialDirection - Cette clé indique la direction vectorielle utilisée pour la dérivée - directionnelle autour du point nominal de vérification. Cela doit être un - vecteur. Si elle n'est pas spécifiée, la direction par défaut est une - perturbation par défaut autour de zéro de la même taille vectorielle que le - point de vérification. + Cette clé indique la direction vectorielle utilisée pour la dérivée + directionnelle autour du point nominal de vérification. Cela doit être un + vecteur. Si elle n'est pas spécifiée, la direction par défaut est une + perturbation par défaut autour de zéro de la même taille vectorielle que le + point de vérification. Exemple : ``{"InitialDirection":[0.1,0.1,100.,3}`` SetSeed - Cette clé permet de donner un nombre entier pour fixer la graine du - générateur aléatoire utilisé pour générer l'ensemble. Un valeur pratique est - par exemple 1000. Par défaut, la graine est laissée non initialisée, et elle - utilise ainsi l'initialisation par défaut de l'ordinateur. + Cette clé permet de donner un nombre entier pour fixer la graine du + générateur aléatoire utilisé pour générer l'ensemble. Un valeur pratique est + par exemple 1000. Par défaut, la graine est laissée non initialisée, et elle + utilise ainsi l'initialisation par défaut de l'ordinateur. Exemple : ``{"SetSeed":1000}`` StoreSupplementaryCalculations - Cette liste indique les noms des variables supplémentaires qui peuvent être - disponibles à la fin de l'algorithme. Cela implique potentiellement des - calculs ou du stockage coûteux. La valeur par défaut est une liste vide, - aucune de ces variables n'étant calculée et stockée par défaut. Les noms + Cette liste indique les noms des variables supplémentaires qui peuvent être + disponibles à la fin de l'algorithme. Cela implique potentiellement des + calculs ou du stockage coûteux. La valeur par défaut est une liste vide, + aucune de ces variables n'étant calculée et stockée par défaut. Les noms possibles sont dans la liste suivante : ["CurrentState", "Residu", "SimulatedObservationAtCurrentState"]. Exemple : ``{"StoreSupplementaryCalculations":["CurrentState"]}`` -Informations et variables disponibles à la fin de l'algorithme +Informations et variables disponibles à la fin de l'algorithme ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -En sortie, après exécution de l'algorithme, on dispose d'informations et de +En sortie, après exécution de l'algorithme, on dispose d'informations et de variables issues du calcul. La description des -:ref:`section_ref_output_variables` indique la manière de les obtenir par la -méthode nommée ``get`` de la variable "*ADD*" du post-processing. Les variables -d'entrée, mises à disposition de l'utilisateur en sortie pour faciliter -l'écriture des procédures de post-processing, sont décrites dans +:ref:`section_ref_output_variables` indique la manière de les obtenir par la +méthode nommée ``get`` de la variable "*ADD*" du post-processing. Les variables +d'entrée, mises à disposition de l'utilisateur en sortie pour faciliter +l'écriture des procédures de post-processing, sont décrites dans l':ref:`subsection_r_o_v_Inventaire`. Les sorties non conditionnelles de l'algorithme sont les suivantes: Residu - *Liste de valeurs*. Chaque élément est la valeur du résidu particulier - vérifié lors d'un algorithme de vérification, selon l'ordre des tests - effectués. + *Liste de valeurs*. Chaque élément est la valeur du résidu particulier + vérifié lors d'un algorithme de vérification, selon l'ordre des tests + effectués. Exemple : ``r = ADD.get("Residu")[:]`` Les sorties conditionnelles de l'algorithme sont les suivantes: CurrentState - *Liste de vecteurs*. Chaque élément est un vecteur d'état courant utilisé - au cours du déroulement de l'algorithme d'optimisation. + *Liste de vecteurs*. Chaque élément est un vecteur d'état courant utilisé + au cours du déroulement de l'algorithme d'optimisation. Exemple : ``Xs = ADD.get("CurrentState")[:]`` SimulatedObservationAtCurrentState - *Liste de vecteurs*. Chaque élément est un vecteur d'observation simulé à - partir de l'état courant, c'est-à-dire dans l'espace des observations. + *Liste de vecteurs*. Chaque élément est un vecteur d'observation simulé à + partir de l'état courant, c'est-à-dire dans l'espace des observations. Exemple : ``hxs = ADD.get("SimulatedObservationAtCurrentState")[-1]`` Voir aussi ++++++++++ -Références vers d'autres sections : +Références vers d'autres sections : - :ref:`section_ref_algorithm_FunctionTest` - :ref:`section_ref_algorithm_LinearityTest` - :ref:`section_ref_algorithm_TangentTest` diff --git a/doc/fr/ref_algorithm_Blue.rst b/doc/fr/ref_algorithm_Blue.rst index 6955896..df69b13 100644 --- a/doc/fr/ref_algorithm_Blue.rst +++ b/doc/fr/ref_algorithm_Blue.rst @@ -30,17 +30,17 @@ Algorithme de calcul "*Blue*" Description +++++++++++ -Cet algorithme réalise une estimation de type BLUE (Best Linear Unbiased -Estimator) de l'état d'un système. De manière précise, c'est un estimateur +Cet algorithme réalise une estimation de type BLUE (Best Linear Unbiased +Estimator) de l'état d'un système. De manière précise, c'est un estimateur d'Aitken. Cet algorithme est toujours le plus rapide de l'ensemble des algorithmes -d'assimilation d'ADAO. Il est théoriquement réservé aux cas d'opérateurs -d'observation linéaires, même s'il fonctionne parfois dans les cas "faiblement" -non-linéaires. On peut vérifier la linéarité de l'opérateur d'observation à +d'assimilation d'ADAO. Il est théoriquement réservé aux cas d'opérateurs +d'observation linéaires, même s'il fonctionne parfois dans les cas "faiblement" +non-linéaires. On peut vérifier la linéarité de l'opérateur d'observation à l'aide de l':ref:`section_ref_algorithm_LinearityTest`. -En cas de non-linéarité, même peu marquée, on lui préférera aisément +En cas de non-linéarité, même peu marquée, on lui préférera aisément l':ref:`section_ref_algorithm_ExtendedBlue` ou l':ref:`section_ref_algorithm_3DVAR`. @@ -59,57 +59,57 @@ Commandes requises et optionnelles .. index:: single: NumberOfSamplesForQuantiles .. index:: single: SimulationForQuantiles -Les commandes requises générales, disponibles dans l'interface en édition, sont +Les commandes requises générales, disponibles dans l'interface en édition, sont les suivantes: Background - *Commande obligatoire*. Elle définit le vecteur d'ébauche ou - d'initialisation, noté précédemment :math:`\mathbf{x}^b`. Sa valeur est - définie comme un objet de type "*Vector*" ou de type "*VectorSerie*". + *Commande obligatoire*. Elle définit le vecteur d'ébauche ou + d'initialisation, noté précédemment :math:`\mathbf{x}^b`. Sa valeur est + définie comme un objet de type "*Vector*" ou de type "*VectorSerie*". BackgroundError - *Commande obligatoire*. Elle définit la matrice de covariance des erreurs - d'ébauche, notée précédemment :math:`\mathbf{B}`. Sa valeur est définie + *Commande obligatoire*. Elle définit la matrice de covariance des erreurs + d'ébauche, notée précédemment :math:`\mathbf{B}`. Sa valeur est définie comme un objet de type "*Matrix*", de type "*ScalarSparseMatrix*", ou de type "*DiagonalSparseMatrix*". Observation - *Commande obligatoire*. Elle définit le vecteur d'observation utilisé en - assimilation de données ou en optimisation, et noté précédemment - :math:`\mathbf{y}^o`. Sa valeur est définie comme un objet de type "*Vector*" + *Commande obligatoire*. Elle définit le vecteur d'observation utilisé en + assimilation de données ou en optimisation, et noté précédemment + :math:`\mathbf{y}^o`. Sa valeur est définie comme un objet de type "*Vector*" ou de type "*VectorSerie*". ObservationError - *Commande obligatoire*. Elle définit la matrice de covariance des erreurs - d'ébauche, notée précédemment :math:`\mathbf{R}`. Sa valeur est définie + *Commande obligatoire*. Elle définit la matrice de covariance des erreurs + d'ébauche, notée précédemment :math:`\mathbf{R}`. Sa valeur est définie comme un objet de type "*Matrix*", de type "*ScalarSparseMatrix*", ou de type "*DiagonalSparseMatrix*". ObservationOperator - *Commande obligatoire*. Elle indique l'opérateur d'observation, noté - précédemment :math:`H`, qui transforme les paramètres d'entrée - :math:`\mathbf{x}` en résultats :math:`\mathbf{y}` qui sont à comparer aux - observations :math:`\mathbf{y}^o`. Sa valeur est définie comme un objet de + *Commande obligatoire*. Elle indique l'opérateur d'observation, noté + précédemment :math:`H`, qui transforme les paramètres d'entrée + :math:`\mathbf{x}` en résultats :math:`\mathbf{y}` qui sont à comparer aux + observations :math:`\mathbf{y}^o`. Sa valeur est définie comme un objet de type "*Function*" ou de type "*Matrix*". Dans le cas du type "*Function*", - différentes formes fonctionnelles peuvent être utilisées, comme décrit dans - la section :ref:`section_ref_operator_requirements`. Si un contrôle - :math:`U` est inclus dans le modèle d'observation, l'opérateur doit être - appliqué à une paire :math:`(X,U)`. - -Les commandes optionnelles générales, disponibles dans l'interface en édition, -sont indiquées dans la :ref:`section_ref_assimilation_keywords`. De plus, les -paramètres de la commande "*AlgorithmParameters*" permettent d'indiquer les -options particulières, décrites ci-après, de l'algorithme. On se reportera à la + différentes formes fonctionnelles peuvent être utilisées, comme décrit dans + la section :ref:`section_ref_operator_requirements`. Si un contrôle + :math:`U` est inclus dans le modèle d'observation, l'opérateur doit être + appliqué à une paire :math:`(X,U)`. + +Les commandes optionnelles générales, disponibles dans l'interface en édition, +sont indiquées dans la :ref:`section_ref_assimilation_keywords`. De plus, les +paramètres de la commande "*AlgorithmParameters*" permettent d'indiquer les +options particulières, décrites ci-après, de l'algorithme. On se reportera à la :ref:`section_ref_options_Algorithm_Parameters` pour le bon usage de cette commande. Les options de l'algorithme sont les suivantes: StoreSupplementaryCalculations - Cette liste indique les noms des variables supplémentaires qui peuvent être - disponibles à la fin de l'algorithme. Cela implique potentiellement des - calculs ou du stockage coûteux. La valeur par défaut est une liste vide, - aucune de ces variables n'étant calculée et stockée par défaut. Les noms + Cette liste indique les noms des variables supplémentaires qui peuvent être + disponibles à la fin de l'algorithme. Cela implique potentiellement des + calculs ou du stockage coûteux. La valeur par défaut est une liste vide, + aucune de ces variables n'étant calculée et stockée par défaut. Les noms possibles sont dans la liste suivante : ["APosterioriCorrelations", "APosterioriCovariance", "APosterioriStandardDeviations", "APosterioriVariances", "BMA", "OMA", "OMB", "CurrentState", @@ -121,165 +121,165 @@ Les options de l'algorithme sont les suivantes: Exemple : ``{"StoreSupplementaryCalculations":["BMA", "Innovation"]}`` Quantiles - Cette liste indique les valeurs de quantile, entre 0 et 1, à estimer par - simulation autour de l'état optimal. L'échantillonnage utilise des tirages - aléatoires gaussiens multivariés, dirigés par la matrice de covariance a - posteriori. Cette option n'est utile que si le calcul supplémentaire - "SimulationQuantiles" a été choisi. La valeur par défaut est une liste vide. + Cette liste indique les valeurs de quantile, entre 0 et 1, à estimer par + simulation autour de l'état optimal. L'échantillonnage utilise des tirages + aléatoires gaussiens multivariés, dirigés par la matrice de covariance a + posteriori. Cette option n'est utile que si le calcul supplémentaire + "SimulationQuantiles" a été choisi. La valeur par défaut est une liste vide. Exemple : ``{"Quantiles":[0.1,0.9]}`` SetSeed - Cette clé permet de donner un nombre entier pour fixer la graine du - générateur aléatoire utilisé pour générer l'ensemble. Un valeur pratique est - par exemple 1000. Par défaut, la graine est laissée non initialisée, et elle - utilise ainsi l'initialisation par défaut de l'ordinateur. + Cette clé permet de donner un nombre entier pour fixer la graine du + générateur aléatoire utilisé pour générer l'ensemble. Un valeur pratique est + par exemple 1000. Par défaut, la graine est laissée non initialisée, et elle + utilise ainsi l'initialisation par défaut de l'ordinateur. Exemple : ``{"SetSeed":1000}`` NumberOfSamplesForQuantiles - Cette clé indique le nombre de simulations effectuées pour estimer les - quantiles. Cette option n'est utile que si le calcul supplémentaire - "SimulationQuantiles" a été choisi. Le défaut est 100, ce qui suffit souvent - pour une estimation correcte de quantiles courants à 5%, 10%, 90% ou 95%. + Cette clé indique le nombre de simulations effectuées pour estimer les + quantiles. Cette option n'est utile que si le calcul supplémentaire + "SimulationQuantiles" a été choisi. Le défaut est 100, ce qui suffit souvent + pour une estimation correcte de quantiles courants à 5%, 10%, 90% ou 95%. Exemple : ``{"NumberOfSamplesForQuantiles":100}`` SimulationForQuantiles - Cette clé indique le type de simulation, linéaire (avec l'opérateur - d'observation tangent appliqué sur des incréments de perturbations autour de - l'état optimal) ou non-linéaire (avec l'opérateur d'observation standard - appliqué aux états perturbés), que l'on veut faire pour chaque perturbation. - Cela change essentiellement le temps de chaque simulation élémentaire, - usuellement plus long en non-linéaire qu'en linéaire. Cette option n'est - utile que si le calcul supplémentaire "SimulationQuantiles" a été choisi. La - valeur par défaut est "Linear", et les choix possibles sont "Linear" et + Cette clé indique le type de simulation, linéaire (avec l'opérateur + d'observation tangent appliqué sur des incréments de perturbations autour de + l'état optimal) ou non-linéaire (avec l'opérateur d'observation standard + appliqué aux états perturbés), que l'on veut faire pour chaque perturbation. + Cela change essentiellement le temps de chaque simulation élémentaire, + usuellement plus long en non-linéaire qu'en linéaire. Cette option n'est + utile que si le calcul supplémentaire "SimulationQuantiles" a été choisi. La + valeur par défaut est "Linear", et les choix possibles sont "Linear" et "NonLinear". Exemple : ``{"SimulationForQuantiles":"Linear"}`` -Informations et variables disponibles à la fin de l'algorithme +Informations et variables disponibles à la fin de l'algorithme ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -En sortie, après exécution de l'algorithme, on dispose d'informations et de +En sortie, après exécution de l'algorithme, on dispose d'informations et de variables issues du calcul. La description des -:ref:`section_ref_output_variables` indique la manière de les obtenir par la -méthode nommée ``get`` de la variable "*ADD*" du post-processing. Les variables -d'entrée, mises à disposition de l'utilisateur en sortie pour faciliter -l'écriture des procédures de post-processing, sont décrites dans +:ref:`section_ref_output_variables` indique la manière de les obtenir par la +méthode nommée ``get`` de la variable "*ADD*" du post-processing. Les variables +d'entrée, mises à disposition de l'utilisateur en sortie pour faciliter +l'écriture des procédures de post-processing, sont décrites dans l':ref:`subsection_r_o_v_Inventaire`. Les sorties non conditionnelles de l'algorithme sont les suivantes: Analysis - *Liste de vecteurs*. Chaque élément est un état optimal :math:`\mathbf{x}*` + *Liste de vecteurs*. Chaque élément est un état optimal :math:`\mathbf{x}*` en optimisation ou une analyse :math:`\mathbf{x}^a` en assimilation de - données. + données. Exemple : ``Xa = ADD.get("Analysis")[-1]`` Les sorties conditionnelles de l'algorithme sont les suivantes: APosterioriCorrelations - *Liste de matrices*. Chaque élément est une matrice de corrélation des - erreurs *a posteriori* de l'état optimal. + *Liste de matrices*. Chaque élément est une matrice de corrélation des + erreurs *a posteriori* de l'état optimal. Exemple : ``C = ADD.get("APosterioriCorrelations")[-1]`` APosterioriCovariance - *Liste de matrices*. Chaque élément est une matrice :math:`\mathbf{A}*` de - covariances des erreurs *a posteriori* de l'état optimal. + *Liste de matrices*. Chaque élément est une matrice :math:`\mathbf{A}*` de + covariances des erreurs *a posteriori* de l'état optimal. Exemple : ``A = ADD.get("APosterioriCovariance")[-1]`` APosterioriStandardDeviations - *Liste de matrices*. Chaque élément est une matrice d'écart-types des - erreurs *a posteriori* de l'état optimal. + *Liste de matrices*. Chaque élément est une matrice d'écart-types des + erreurs *a posteriori* de l'état optimal. Exemple : ``E = ADD.get("APosterioriStandardDeviations")[-1]`` APosterioriVariances - *Liste de matrices*. Chaque élément est une matrice de variances des erreurs - *a posteriori* de l'état optimal. + *Liste de matrices*. Chaque élément est une matrice de variances des erreurs + *a posteriori* de l'état optimal. Exemple : ``V = ADD.get("APosterioriVariances")[-1]`` BMA - *Liste de vecteurs*. Chaque élément est un vecteur d'écart entre - l'ébauche et l'état optimal. + *Liste de vecteurs*. Chaque élément est un vecteur d'écart entre + l'ébauche et l'état optimal. Exemple : ``bma = ADD.get("BMA")[-1]`` CostFunctionJ - *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart + *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart :math:`J`. Exemple : ``J = ADD.get("CostFunctionJ")[:]`` CostFunctionJb - *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart - :math:`J^b`, c'est-à-dire de la partie écart à l'ébauche. + *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart + :math:`J^b`, c'est-à-dire de la partie écart à l'ébauche. Exemple : ``Jb = ADD.get("CostFunctionJb")[:]`` CostFunctionJo - *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart - :math:`J^o`, c'est-à-dire de la partie écart à l'observation. + *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart + :math:`J^o`, c'est-à-dire de la partie écart à l'observation. Exemple : ``Jo = ADD.get("CostFunctionJo")[:]`` Innovation - *Liste de vecteurs*. Chaque élément est un vecteur d'innovation, qui est - en statique l'écart de l'optimum à l'ébauche, et en dynamique l'incrément - d'évolution. + *Liste de vecteurs*. Chaque élément est un vecteur d'innovation, qui est + en statique l'écart de l'optimum à l'ébauche, et en dynamique l'incrément + d'évolution. Exemple : ``d = ADD.get("Innovation")[-1]`` MahalanobisConsistency - *Liste de valeurs*. Chaque élément est une valeur de l'indicateur de - qualité de Mahalanobis. + *Liste de valeurs*. Chaque élément est une valeur de l'indicateur de + qualité de Mahalanobis. Exemple : ``m = ADD.get("MahalanobisConsistency")[-1]`` OMA - *Liste de vecteurs*. Chaque élément est un vecteur d'écart entre - l'observation et l'état optimal dans l'espace des observations. + *Liste de vecteurs*. Chaque élément est un vecteur d'écart entre + l'observation et l'état optimal dans l'espace des observations. Exemple : ``oma = ADD.get("OMA")[-1]`` OMB - *Liste de vecteurs*. Chaque élément est un vecteur d'écart entre - l'observation et l'état d'ébauche dans l'espace des observations. + *Liste de vecteurs*. Chaque élément est un vecteur d'écart entre + l'observation et l'état d'ébauche dans l'espace des observations. Exemple : ``omb = ADD.get("OMB")[-1]`` SigmaBck2 - *Liste de valeurs*. Chaque élément est une valeur de l'indicateur de - qualité :math:`(\sigma^b)^2` de la partie ébauche. + *Liste de valeurs*. Chaque élément est une valeur de l'indicateur de + qualité :math:`(\sigma^b)^2` de la partie ébauche. Exemple : ``sb2 = ADD.get("SigmaBck")[-1]`` SigmaObs2 - *Liste de valeurs*. Chaque élément est une valeur de l'indicateur de - qualité :math:`(\sigma^o)^2` de la partie observation. + *Liste de valeurs*. Chaque élément est une valeur de l'indicateur de + qualité :math:`(\sigma^o)^2` de la partie observation. Exemple : ``so2 = ADD.get("SigmaObs")[-1]`` SimulatedObservationAtBackground - *Liste de vecteurs*. Chaque élément est un vecteur d'observation simulé à - partir de l'ébauche :math:`\mathbf{x}^b`. + *Liste de vecteurs*. Chaque élément est un vecteur d'observation simulé à + partir de l'ébauche :math:`\mathbf{x}^b`. Exemple : ``hxb = ADD.get("SimulatedObservationAtBackground")[-1]`` SimulatedObservationAtOptimum - *Liste de vecteurs*. Chaque élément est un vecteur d'observation simulé à - partir de l'analyse ou de l'état optimal :math:`\mathbf{x}^a`. + *Liste de vecteurs*. Chaque élément est un vecteur d'observation simulé à + partir de l'analyse ou de l'état optimal :math:`\mathbf{x}^a`. Exemple : ``hxa = ADD.get("SimulatedObservationAtOptimum")[-1]`` SimulationQuantiles - *Liste de vecteurs*. Chaque élément est un vecteur correspondant à l'état - observé qui réalise le quantile demandé, dans le même ordre que les + *Liste de vecteurs*. Chaque élément est un vecteur correspondant à l'état + observé qui réalise le quantile demandé, dans le même ordre que les quantiles requis par l'utilisateur. Exemple : ``sQuantiles = ADD.get("SimulationQuantiles")[:]`` @@ -287,10 +287,10 @@ Les sorties conditionnelles de l'algorithme sont les suivantes: Voir aussi ++++++++++ -Références vers d'autres sections : +Références vers d'autres sections : - :ref:`section_ref_algorithm_ExtendedBlue` - :ref:`section_ref_algorithm_3DVAR` - :ref:`section_ref_algorithm_LinearityTest` -Références bibliographiques : +Références bibliographiques : - [Bouttier99]_ diff --git a/doc/fr/ref_algorithm_DerivativeFreeOptimization.rst b/doc/fr/ref_algorithm_DerivativeFreeOptimization.rst index aafe52f..6f0bde3 100644 --- a/doc/fr/ref_algorithm_DerivativeFreeOptimization.rst +++ b/doc/fr/ref_algorithm_DerivativeFreeOptimization.rst @@ -29,22 +29,22 @@ Algorithme de calcul "*DerivativeFreeOptimization*" .. warning:: - dans sa présente version, cet algorithme est expérimental, et reste donc + dans sa présente version, cet algorithme est expérimental, et reste donc susceptible de changements dans les prochaines versions. Description +++++++++++ -Cet algorithme réalise une estimation d'état d'un système par minimisation d'une -fonctionnelle d'écart :math:`J` sans gradient. C'est une méthode qui n'utilise -pas les dérivées de la fonctionnelle d'écart. Elle entre, par exemple, dans la -même catégorie que l':ref:`section_ref_algorithm_ParticleSwarmOptimization`. +Cet algorithme réalise une estimation d'état d'un système par minimisation d'une +fonctionnelle d'écart :math:`J` sans gradient. C'est une méthode qui n'utilise +pas les dérivées de la fonctionnelle d'écart. Elle entre, par exemple, dans la +même catégorie que l':ref:`section_ref_algorithm_ParticleSwarmOptimization`. -C'est une méthode d'optimisation permettant la recherche du minimum global d'une +C'est une méthode d'optimisation permettant la recherche du minimum global d'une fonctionnelle d'erreur :math:`J` quelconque de type :math:`L^1`, :math:`L^2` ou -:math:`L^{\infty}`, avec ou sans pondérations. La fonctionnelle d'erreur par -défaut est celle de moindres carrés pondérés augmentés, classiquement utilisée -en assimilation de données. +:math:`L^{\infty}`, avec ou sans pondérations. La fonctionnelle d'erreur par +défaut est celle de moindres carrés pondérés augmentés, classiquement utilisée +en assimilation de données. Commandes requises et optionnelles ++++++++++++++++++++++++++++++++++ @@ -63,130 +63,130 @@ Commandes requises et optionnelles .. index:: single: QualityCriterion .. index:: single: StoreSupplementaryCalculations -Les commandes requises générales, disponibles dans l'interface en édition, sont +Les commandes requises générales, disponibles dans l'interface en édition, sont les suivantes: Background - *Commande obligatoire*. Elle définit le vecteur d'ébauche ou - d'initialisation, noté précédemment :math:`\mathbf{x}^b`. Sa valeur est - définie comme un objet de type "*Vector*" ou de type "*VectorSerie*". + *Commande obligatoire*. Elle définit le vecteur d'ébauche ou + d'initialisation, noté précédemment :math:`\mathbf{x}^b`. Sa valeur est + définie comme un objet de type "*Vector*" ou de type "*VectorSerie*". BackgroundError - *Commande obligatoire*. Elle définit la matrice de covariance des erreurs - d'ébauche, notée précédemment :math:`\mathbf{B}`. Sa valeur est définie + *Commande obligatoire*. Elle définit la matrice de covariance des erreurs + d'ébauche, notée précédemment :math:`\mathbf{B}`. Sa valeur est définie comme un objet de type "*Matrix*", de type "*ScalarSparseMatrix*", ou de type "*DiagonalSparseMatrix*". Observation - *Commande obligatoire*. Elle définit le vecteur d'observation utilisé en - assimilation de données ou en optimisation, et noté précédemment - :math:`\mathbf{y}^o`. Sa valeur est définie comme un objet de type "*Vector*" + *Commande obligatoire*. Elle définit le vecteur d'observation utilisé en + assimilation de données ou en optimisation, et noté précédemment + :math:`\mathbf{y}^o`. Sa valeur est définie comme un objet de type "*Vector*" ou de type "*VectorSerie*". ObservationError - *Commande obligatoire*. Elle définit la matrice de covariance des erreurs - d'ébauche, notée précédemment :math:`\mathbf{R}`. Sa valeur est définie + *Commande obligatoire*. Elle définit la matrice de covariance des erreurs + d'ébauche, notée précédemment :math:`\mathbf{R}`. Sa valeur est définie comme un objet de type "*Matrix*", de type "*ScalarSparseMatrix*", ou de type "*DiagonalSparseMatrix*". ObservationOperator - *Commande obligatoire*. Elle indique l'opérateur d'observation, noté - précédemment :math:`H`, qui transforme les paramètres d'entrée - :math:`\mathbf{x}` en résultats :math:`\mathbf{y}` qui sont à comparer aux - observations :math:`\mathbf{y}^o`. Sa valeur est définie comme un objet de + *Commande obligatoire*. Elle indique l'opérateur d'observation, noté + précédemment :math:`H`, qui transforme les paramètres d'entrée + :math:`\mathbf{x}` en résultats :math:`\mathbf{y}` qui sont à comparer aux + observations :math:`\mathbf{y}^o`. Sa valeur est définie comme un objet de type "*Function*" ou de type "*Matrix*". Dans le cas du type "*Function*", - différentes formes fonctionnelles peuvent être utilisées, comme décrit dans - la section :ref:`section_ref_operator_requirements`. Si un contrôle - :math:`U` est inclus dans le modèle d'observation, l'opérateur doit être - appliqué à une paire :math:`(X,U)`. - -Les commandes optionnelles générales, disponibles dans l'interface en édition, -sont indiquées dans la :ref:`section_ref_assimilation_keywords`. De plus, les -paramètres de la commande "*AlgorithmParameters*" permettent d'indiquer les -options particulières, décrites ci-après, de l'algorithme. On se reportera à la + différentes formes fonctionnelles peuvent être utilisées, comme décrit dans + la section :ref:`section_ref_operator_requirements`. Si un contrôle + :math:`U` est inclus dans le modèle d'observation, l'opérateur doit être + appliqué à une paire :math:`(X,U)`. + +Les commandes optionnelles générales, disponibles dans l'interface en édition, +sont indiquées dans la :ref:`section_ref_assimilation_keywords`. De plus, les +paramètres de la commande "*AlgorithmParameters*" permettent d'indiquer les +options particulières, décrites ci-après, de l'algorithme. On se reportera à la :ref:`section_ref_options_Algorithm_Parameters` pour le bon usage de cette commande. Les options de l'algorithme sont les suivantes: Minimizer - Cette clé permet de changer le minimiseur pour l'optimiseur. Le choix par - défaut est "BOBYQA", et les choix possibles sont + Cette clé permet de changer le minimiseur pour l'optimiseur. Le choix par + défaut est "BOBYQA", et les choix possibles sont "BOBYQA" (minimisation avec ou sans contraintes par approximation quadratique [Powell09]_), - "COBYLA" (minimisation avec ou sans contraintes par approximation linéaire [Powell94]_ [Powell98]_). - "NEWUOA" (minimisation avec ou sans contraintes par approximation quadratique itérative [Powell04]_), - "POWELL" (minimisation sans contraintes de type directions conjuguées [Powell64]_), + "COBYLA" (minimisation avec ou sans contraintes par approximation linéaire [Powell94]_ [Powell98]_). + "NEWUOA" (minimisation avec ou sans contraintes par approximation quadratique itérative [Powell04]_), + "POWELL" (minimisation sans contraintes de type directions conjuguées [Powell64]_), "SIMPLEX" (minimisation avec ou sans contraintes de type simplexe ou Nelder-Mead, voir [Nelder65]_), "SUBPLEX" (minimisation avec ou sans contraintes de type simplexe sur une suite de sous-espaces [Rowan90]_). - Remarque : la méthode "POWELL" effectue une optimisation par boucles - imbriquées interne/externe, conduisant ainsi à un contrôle relaché du - nombre d'évaluations de la fonctionnelle à optimiser. Si un contrôle précis - du nombre d'évaluations de cette fonctionnelle est requis, il faut choisir + Remarque : la méthode "POWELL" effectue une optimisation par boucles + imbriquées interne/externe, conduisant ainsi à un contrôle relaché du + nombre d'évaluations de la fonctionnelle à optimiser. Si un contrôle précis + du nombre d'évaluations de cette fonctionnelle est requis, il faut choisir un autre minimiseur. Exemple : ``{"Minimizer":"BOBYQA"}`` Bounds - Cette clé permet de définir des bornes supérieure et inférieure pour chaque - variable d'état optimisée. Les bornes doivent être données par une liste de - liste de paires de bornes inférieure/supérieure pour chaque variable, avec + Cette clé permet de définir des bornes supérieure et inférieure pour chaque + variable d'état optimisée. Les bornes doivent être données par une liste de + liste de paires de bornes inférieure/supérieure pour chaque variable, avec une valeur ``None`` chaque fois qu'il n'y a pas de borne. Les bornes peuvent - toujours être spécifiées, mais seuls les optimiseurs sous contraintes les + toujours être spécifiées, mais seuls les optimiseurs sous contraintes les prennent en compte. Exemple : ``{"Bounds":[[2.,5.],[1.e-2,10.],[-30.,None],[None,None]]}`` MaximumNumberOfSteps - Cette clé indique le nombre maximum d'itérations possibles en optimisation - itérative. Le défaut est 15000, qui est une limite arbitraire. Il est ainsi - fortement recommandé d'adapter ce paramètre aux besoins pour des problèmes - réels. Pour certains optimiseurs, le nombre de pas effectif d'arrêt peut - être légèrement différent de la limite à cause d'exigences de contrôle + Cette clé indique le nombre maximum d'itérations possibles en optimisation + itérative. Le défaut est 15000, qui est une limite arbitraire. Il est ainsi + fortement recommandé d'adapter ce paramètre aux besoins pour des problèmes + réels. Pour certains optimiseurs, le nombre de pas effectif d'arrêt peut + être légèrement différent de la limite à cause d'exigences de contrôle interne de l'algorithme. Exemple : ``{"MaximumNumberOfSteps":50}`` MaximumNumberOfFunctionEvaluations - Cette clé indique le nombre maximum d'évaluations possibles de la - fonctionnelle à optimiser. Le défaut est de 15000, qui est une limite - arbitraire. Il est ainsi recommandé d'adapter ce paramètre aux besoins pour - des problèmes réels. Pour certains optimiseurs, le nombre effectif - d'évaluations à l'arrêt peut être légèrement différent de la limite à cause - d'exigences de déroulement interne de l'algorithme. + Cette clé indique le nombre maximum d'évaluations possibles de la + fonctionnelle à optimiser. Le défaut est de 15000, qui est une limite + arbitraire. Il est ainsi recommandé d'adapter ce paramètre aux besoins pour + des problèmes réels. Pour certains optimiseurs, le nombre effectif + d'évaluations à l'arrêt peut être légèrement différent de la limite à cause + d'exigences de déroulement interne de l'algorithme. Exemple : ``{"MaximumNumberOfFunctionEvaluations":50}`` StateVariationTolerance - Cette clé indique la variation relative maximale de l'état lors pour l'arrêt - par convergence sur l'état. Le défaut est de 1.e-4, et il est recommandé - de l'adapter aux besoins pour des problèmes réels. + Cette clé indique la variation relative maximale de l'état lors pour l'arrêt + par convergence sur l'état. Le défaut est de 1.e-4, et il est recommandé + de l'adapter aux besoins pour des problèmes réels. Exemple : ``{"StateVariationTolerance":1.e-4}`` CostDecrementTolerance - Cette clé indique une valeur limite, conduisant à arrêter le processus - itératif d'optimisation lorsque la fonction coût décroît moins que cette - tolérance au dernier pas. Le défaut est de 1.e-7, et il est recommandé - de l'adapter aux besoins pour des problèmes réels. + Cette clé indique une valeur limite, conduisant à arrêter le processus + itératif d'optimisation lorsque la fonction coût décroît moins que cette + tolérance au dernier pas. Le défaut est de 1.e-7, et il est recommandé + de l'adapter aux besoins pour des problèmes réels. Exemple : ``{"CostDecrementTolerance":1.e-7}`` QualityCriterion - Cette clé indique le critère de qualité, qui est minimisé pour trouver - l'estimation optimale de l'état. Le défaut est le critère usuel de - l'assimilation de données nommé "DA", qui est le critère de moindres carrés - pondérés augmentés. Les critères possibles sont dans la liste suivante, dans - laquelle les noms équivalents sont indiqués par un signe "=" : + Cette clé indique le critère de qualité, qui est minimisé pour trouver + l'estimation optimale de l'état. Le défaut est le critère usuel de + l'assimilation de données nommé "DA", qui est le critère de moindres carrés + pondérés augmentés. Les critères possibles sont dans la liste suivante, dans + laquelle les noms équivalents sont indiqués par un signe "=" : ["AugmentedWeightedLeastSquares"="AWLS"="DA", "WeightedLeastSquares"="WLS", "LeastSquares"="LS"="L2", "AbsoluteValue"="L1", "MaximumError"="ME"]. Exemple : ``{"QualityCriterion":"DA"}`` StoreSupplementaryCalculations - Cette liste indique les noms des variables supplémentaires qui peuvent être - disponibles à la fin de l'algorithme. Cela implique potentiellement des - calculs ou du stockage coûteux. La valeur par défaut est une liste vide, - aucune de ces variables n'étant calculée et stockée par défaut. Les noms + Cette liste indique les noms des variables supplémentaires qui peuvent être + disponibles à la fin de l'algorithme. Cela implique potentiellement des + calculs ou du stockage coûteux. La valeur par défaut est une liste vide, + aucune de ces variables n'étant calculée et stockée par défaut. Les noms possibles sont dans la liste suivante : ["CurrentState", "CostFunctionJ", "CostFunctionJb", "CostFunctionJo", "CostFunctionJAtCurrentOptimum", "CurrentOptimum", "IndexOfOptimum", "InnovationAtCurrentState", "BMA", @@ -196,77 +196,77 @@ Les options de l'algorithme sont les suivantes: Exemple : ``{"StoreSupplementaryCalculations":["BMA", "Innovation"]}`` -Informations et variables disponibles à la fin de l'algorithme +Informations et variables disponibles à la fin de l'algorithme ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -En sortie, après exécution de l'algorithme, on dispose d'informations et de +En sortie, après exécution de l'algorithme, on dispose d'informations et de variables issues du calcul. La description des -:ref:`section_ref_output_variables` indique la manière de les obtenir par la -méthode nommée ``get`` de la variable "*ADD*" du post-processing. Les variables -d'entrée, mises à disposition de l'utilisateur en sortie pour faciliter -l'écriture des procédures de post-processing, sont décrites dans +:ref:`section_ref_output_variables` indique la manière de les obtenir par la +méthode nommée ``get`` de la variable "*ADD*" du post-processing. Les variables +d'entrée, mises à disposition de l'utilisateur en sortie pour faciliter +l'écriture des procédures de post-processing, sont décrites dans l':ref:`subsection_r_o_v_Inventaire`. Les sorties non conditionnelles de l'algorithme sont les suivantes: Analysis - *Liste de vecteurs*. Chaque élément est un état optimal :math:`\mathbf{x}*` + *Liste de vecteurs*. Chaque élément est un état optimal :math:`\mathbf{x}*` en optimisation ou une analyse :math:`\mathbf{x}^a` en assimilation de - données. + données. Exemple : ``Xa = ADD.get("Analysis")[-1]`` CostFunctionJ - *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart + *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart :math:`J`. Exemple : ``J = ADD.get("CostFunctionJ")[:]`` CostFunctionJb - *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart - :math:`J^b`, c'est-à-dire de la partie écart à l'ébauche. + *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart + :math:`J^b`, c'est-à-dire de la partie écart à l'ébauche. Exemple : ``Jb = ADD.get("CostFunctionJb")[:]`` CostFunctionJo - *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart - :math:`J^o`, c'est-à-dire de la partie écart à l'observation. + *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart + :math:`J^o`, c'est-à-dire de la partie écart à l'observation. Exemple : ``Jo = ADD.get("CostFunctionJo")[:]`` CurrentState - *Liste de vecteurs*. Chaque élément est un vecteur d'état courant utilisé - au cours du déroulement de l'algorithme d'optimisation. + *Liste de vecteurs*. Chaque élément est un vecteur d'état courant utilisé + au cours du déroulement de l'algorithme d'optimisation. Exemple : ``Xs = ADD.get("CurrentState")[:]`` Les sorties conditionnelles de l'algorithme sont les suivantes: SimulatedObservationAtBackground - *Liste de vecteurs*. Chaque élément est un vecteur d'observation simulé à - partir de l'ébauche :math:`\mathbf{x}^b`. + *Liste de vecteurs*. Chaque élément est un vecteur d'observation simulé à + partir de l'ébauche :math:`\mathbf{x}^b`. Exemple : ``hxb = ADD.get("SimulatedObservationAtBackground")[-1]`` SimulatedObservationAtCurrentState - *Liste de vecteurs*. Chaque élément est un vecteur observé à l'état courant, - c'est-à-dire dans l'espace des observations. + *Liste de vecteurs*. Chaque élément est un vecteur observé à l'état courant, + c'est-à-dire dans l'espace des observations. Exemple : ``Ys = ADD.get("SimulatedObservationAtCurrentState")[-1]`` SimulatedObservationAtOptimum - *Liste de vecteurs*. Chaque élément est un vecteur d'observation simulé à - partir de l'analyse ou de l'état optimal :math:`\mathbf{x}^a`. + *Liste de vecteurs*. Chaque élément est un vecteur d'observation simulé à + partir de l'analyse ou de l'état optimal :math:`\mathbf{x}^a`. Exemple : ``hxa = ADD.get("SimulatedObservationAtOptimum")[-1]`` Voir aussi ++++++++++ -Références vers d'autres sections : +Références vers d'autres sections : - :ref:`section_ref_algorithm_ParticleSwarmOptimization` -Références bibliographiques : +Références bibliographiques : - [Johnson08]_ - [Nelder65]_ - [Powell64]_ diff --git a/doc/fr/ref_algorithm_EnsembleBlue.rst b/doc/fr/ref_algorithm_EnsembleBlue.rst index 32d23ef..b76e6d3 100644 --- a/doc/fr/ref_algorithm_EnsembleBlue.rst +++ b/doc/fr/ref_algorithm_EnsembleBlue.rst @@ -30,14 +30,14 @@ Algorithme de calcul "*EnsembleBlue*" Description +++++++++++ -Cet algorithme réalise une estimation de type BLUE (Best Linear Unbiased -Estimator, qui est ici un estimateur d'Aitken) de l'état d'un système par -méthode d'ensemble. Pour fonctionner, il faut fournir un ensemble d'ébauches, -dont le nombre déterminera la taille de l'ensemble pour l'estimation. - -Il est théoriquement réservé aux cas d'opérateurs d'observation linéaires, mais -doit fonctionner aussi dans les cas "faiblement" non-linéaire. On peut vérifier -la linéarité de l'opérateur d'observation à l'aide de +Cet algorithme réalise une estimation de type BLUE (Best Linear Unbiased +Estimator, qui est ici un estimateur d'Aitken) de l'état d'un système par +méthode d'ensemble. Pour fonctionner, il faut fournir un ensemble d'ébauches, +dont le nombre déterminera la taille de l'ensemble pour l'estimation. + +Il est théoriquement réservé aux cas d'opérateurs d'observation linéaires, mais +doit fonctionner aussi dans les cas "faiblement" non-linéaire. On peut vérifier +la linéarité de l'opérateur d'observation à l'aide de l':ref:`section_ref_algorithm_LinearityTest`. Commandes requises et optionnelles @@ -51,57 +51,57 @@ Commandes requises et optionnelles .. index:: single: ObservationOperator .. index:: single: SetSeed -Les commandes requises générales, disponibles dans l'interface en édition, sont +Les commandes requises générales, disponibles dans l'interface en édition, sont les suivantes: Background - *Commande obligatoire*. Elle définit le vecteur d'ébauche ou - d'initialisation, noté précédemment :math:`\mathbf{x}^b`. Sa valeur est - définie comme un objet de type "*Vector*" ou de type "*VectorSerie*". + *Commande obligatoire*. Elle définit le vecteur d'ébauche ou + d'initialisation, noté précédemment :math:`\mathbf{x}^b`. Sa valeur est + définie comme un objet de type "*Vector*" ou de type "*VectorSerie*". BackgroundError - *Commande obligatoire*. Elle définit la matrice de covariance des erreurs - d'ébauche, notée précédemment :math:`\mathbf{B}`. Sa valeur est définie + *Commande obligatoire*. Elle définit la matrice de covariance des erreurs + d'ébauche, notée précédemment :math:`\mathbf{B}`. Sa valeur est définie comme un objet de type "*Matrix*", de type "*ScalarSparseMatrix*", ou de type "*DiagonalSparseMatrix*". Observation - *Commande obligatoire*. Elle définit le vecteur d'observation utilisé en - assimilation de données ou en optimisation, et noté précédemment - :math:`\mathbf{y}^o`. Sa valeur est définie comme un objet de type "*Vector*" + *Commande obligatoire*. Elle définit le vecteur d'observation utilisé en + assimilation de données ou en optimisation, et noté précédemment + :math:`\mathbf{y}^o`. Sa valeur est définie comme un objet de type "*Vector*" ou de type "*VectorSerie*". ObservationError - *Commande obligatoire*. Elle définit la matrice de covariance des erreurs - d'ébauche, notée précédemment :math:`\mathbf{R}`. Sa valeur est définie + *Commande obligatoire*. Elle définit la matrice de covariance des erreurs + d'ébauche, notée précédemment :math:`\mathbf{R}`. Sa valeur est définie comme un objet de type "*Matrix*", de type "*ScalarSparseMatrix*", ou de type "*DiagonalSparseMatrix*". ObservationOperator - *Commande obligatoire*. Elle indique l'opérateur d'observation, noté - précédemment :math:`H`, qui transforme les paramètres d'entrée - :math:`\mathbf{x}` en résultats :math:`\mathbf{y}` qui sont à comparer aux - observations :math:`\mathbf{y}^o`. Sa valeur est définie comme un objet de + *Commande obligatoire*. Elle indique l'opérateur d'observation, noté + précédemment :math:`H`, qui transforme les paramètres d'entrée + :math:`\mathbf{x}` en résultats :math:`\mathbf{y}` qui sont à comparer aux + observations :math:`\mathbf{y}^o`. Sa valeur est définie comme un objet de type "*Function*" ou de type "*Matrix*". Dans le cas du type "*Function*", - différentes formes fonctionnelles peuvent être utilisées, comme décrit dans - la section :ref:`section_ref_operator_requirements`. Si un contrôle - :math:`U` est inclus dans le modèle d'observation, l'opérateur doit être - appliqué à une paire :math:`(X,U)`. - -Les commandes optionnelles générales, disponibles dans l'interface en édition, -sont indiquées dans la :ref:`section_ref_assimilation_keywords`. De plus, les -paramètres de la commande "*AlgorithmParameters*" permettent d'indiquer les -options particulières, décrites ci-après, de l'algorithme. On se reportera à la + différentes formes fonctionnelles peuvent être utilisées, comme décrit dans + la section :ref:`section_ref_operator_requirements`. Si un contrôle + :math:`U` est inclus dans le modèle d'observation, l'opérateur doit être + appliqué à une paire :math:`(X,U)`. + +Les commandes optionnelles générales, disponibles dans l'interface en édition, +sont indiquées dans la :ref:`section_ref_assimilation_keywords`. De plus, les +paramètres de la commande "*AlgorithmParameters*" permettent d'indiquer les +options particulières, décrites ci-après, de l'algorithme. On se reportera à la :ref:`section_ref_options_Algorithm_Parameters` pour le bon usage de cette commande. Les options de l'algorithme sont les suivantes: StoreSupplementaryCalculations - Cette liste indique les noms des variables supplémentaires qui peuvent être - disponibles à la fin de l'algorithme. Cela implique potentiellement des - calculs ou du stockage coûteux. La valeur par défaut est une liste vide, - aucune de ces variables n'étant calculée et stockée par défaut. Les noms + Cette liste indique les noms des variables supplémentaires qui peuvent être + disponibles à la fin de l'algorithme. Cela implique potentiellement des + calculs ou du stockage coûteux. La valeur par défaut est une liste vide, + aucune de ces variables n'étant calculée et stockée par défaut. Les noms possibles sont dans la liste suivante : ["CurrentState", "Innovation", "SimulatedObservationAtBackground", "SimulatedObservationAtCurrentState", "SimulatedObservationAtOptimum"]. @@ -109,48 +109,48 @@ Les options de l'algorithme sont les suivantes: Exemple : ``{"StoreSupplementaryCalculations":["CurrentState", "Innovation"]}`` SetSeed - Cette clé permet de donner un nombre entier pour fixer la graine du - générateur aléatoire utilisé pour générer l'ensemble. Un valeur pratique est - par exemple 1000. Par défaut, la graine est laissée non initialisée, et elle - utilise ainsi l'initialisation par défaut de l'ordinateur. + Cette clé permet de donner un nombre entier pour fixer la graine du + générateur aléatoire utilisé pour générer l'ensemble. Un valeur pratique est + par exemple 1000. Par défaut, la graine est laissée non initialisée, et elle + utilise ainsi l'initialisation par défaut de l'ordinateur. Exemple : ``{"SetSeed":1000}`` -Informations et variables disponibles à la fin de l'algorithme +Informations et variables disponibles à la fin de l'algorithme ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -En sortie, après exécution de l'algorithme, on dispose d'informations et de +En sortie, après exécution de l'algorithme, on dispose d'informations et de variables issues du calcul. La description des -:ref:`section_ref_output_variables` indique la manière de les obtenir par la -méthode nommée ``get`` de la variable "*ADD*" du post-processing. Les variables -d'entrée, mises à disposition de l'utilisateur en sortie pour faciliter -l'écriture des procédures de post-processing, sont décrites dans +:ref:`section_ref_output_variables` indique la manière de les obtenir par la +méthode nommée ``get`` de la variable "*ADD*" du post-processing. Les variables +d'entrée, mises à disposition de l'utilisateur en sortie pour faciliter +l'écriture des procédures de post-processing, sont décrites dans l':ref:`subsection_r_o_v_Inventaire`. Les sorties non conditionnelles de l'algorithme sont les suivantes: Analysis - *Liste de vecteurs*. Chaque élément est un état optimal :math:`\mathbf{x}*` + *Liste de vecteurs*. Chaque élément est un état optimal :math:`\mathbf{x}*` en optimisation ou une analyse :math:`\mathbf{x}^a` en assimilation de - données. + données. Exemple : ``Xa = ADD.get("Analysis")[-1]`` CurrentState - *Liste de vecteurs*. Chaque élément est un vecteur d'état courant utilisé - au cours du déroulement de l'algorithme d'optimisation. + *Liste de vecteurs*. Chaque élément est un vecteur d'état courant utilisé + au cours du déroulement de l'algorithme d'optimisation. Exemple : ``Xs = ADD.get("CurrentState")[:]`` Innovation - *Liste de vecteurs*. Chaque élément est un vecteur d'innovation, qui est - en statique l'écart de l'optimum à l'ébauche, et en dynamique l'incrément - d'évolution. + *Liste de vecteurs*. Chaque élément est un vecteur d'innovation, qui est + en statique l'écart de l'optimum à l'ébauche, et en dynamique l'incrément + d'évolution. Exemple : ``d = ADD.get("Innovation")[-1]`` Voir aussi ++++++++++ -Références vers d'autres sections : +Références vers d'autres sections : - :ref:`section_ref_algorithm_Blue` diff --git a/doc/fr/ref_algorithm_ExtendedBlue.rst b/doc/fr/ref_algorithm_ExtendedBlue.rst index 64432d8..6004fdb 100644 --- a/doc/fr/ref_algorithm_ExtendedBlue.rst +++ b/doc/fr/ref_algorithm_ExtendedBlue.rst @@ -30,16 +30,16 @@ Algorithme de calcul "*ExtendedBlue*" Description +++++++++++ -Cet algorithme réalise une estimation de type BLUE étendu (Best Linear Unbiased -Estimator, étendu) de l'état d'un système. +Cet algorithme réalise une estimation de type BLUE étendu (Best Linear Unbiased +Estimator, étendu) de l'état d'un système. -Cet algorithme est une généralisation partiellement non-linéaire de -l':ref:`section_ref_algorithm_Blue`. Il lui est équivalent pour un opérateur -d'observation linéaire. On peut vérifier la linéarité de l'opérateur -d'observation à l'aide de l':ref:`section_ref_algorithm_LinearityTest`. +Cet algorithme est une généralisation partiellement non-linéaire de +l':ref:`section_ref_algorithm_Blue`. Il lui est équivalent pour un opérateur +d'observation linéaire. On peut vérifier la linéarité de l'opérateur +d'observation à l'aide de l':ref:`section_ref_algorithm_LinearityTest`. -En non-linéaire, il se rapproche de l':ref:`section_ref_algorithm_3DVAR`, sans -lui être entièrement équivalent. +En non-linéaire, il se rapproche de l':ref:`section_ref_algorithm_3DVAR`, sans +lui être entièrement équivalent. Commandes requises et optionnelles ++++++++++++++++++++++++++++++++++ @@ -56,57 +56,57 @@ Commandes requises et optionnelles .. index:: single: NumberOfSamplesForQuantiles .. index:: single: SimulationForQuantiles -Les commandes requises générales, disponibles dans l'interface en édition, sont +Les commandes requises générales, disponibles dans l'interface en édition, sont les suivantes: Background - *Commande obligatoire*. Elle définit le vecteur d'ébauche ou - d'initialisation, noté précédemment :math:`\mathbf{x}^b`. Sa valeur est - définie comme un objet de type "*Vector*" ou de type "*VectorSerie*". + *Commande obligatoire*. Elle définit le vecteur d'ébauche ou + d'initialisation, noté précédemment :math:`\mathbf{x}^b`. Sa valeur est + définie comme un objet de type "*Vector*" ou de type "*VectorSerie*". BackgroundError - *Commande obligatoire*. Elle définit la matrice de covariance des erreurs - d'ébauche, notée précédemment :math:`\mathbf{B}`. Sa valeur est définie + *Commande obligatoire*. Elle définit la matrice de covariance des erreurs + d'ébauche, notée précédemment :math:`\mathbf{B}`. Sa valeur est définie comme un objet de type "*Matrix*", de type "*ScalarSparseMatrix*", ou de type "*DiagonalSparseMatrix*". Observation - *Commande obligatoire*. Elle définit le vecteur d'observation utilisé en - assimilation de données ou en optimisation, et noté précédemment - :math:`\mathbf{y}^o`. Sa valeur est définie comme un objet de type "*Vector*" + *Commande obligatoire*. Elle définit le vecteur d'observation utilisé en + assimilation de données ou en optimisation, et noté précédemment + :math:`\mathbf{y}^o`. Sa valeur est définie comme un objet de type "*Vector*" ou de type "*VectorSerie*". ObservationError - *Commande obligatoire*. Elle définit la matrice de covariance des erreurs - d'ébauche, notée précédemment :math:`\mathbf{R}`. Sa valeur est définie + *Commande obligatoire*. Elle définit la matrice de covariance des erreurs + d'ébauche, notée précédemment :math:`\mathbf{R}`. Sa valeur est définie comme un objet de type "*Matrix*", de type "*ScalarSparseMatrix*", ou de type "*DiagonalSparseMatrix*". ObservationOperator - *Commande obligatoire*. Elle indique l'opérateur d'observation, noté - précédemment :math:`H`, qui transforme les paramètres d'entrée - :math:`\mathbf{x}` en résultats :math:`\mathbf{y}` qui sont à comparer aux - observations :math:`\mathbf{y}^o`. Sa valeur est définie comme un objet de + *Commande obligatoire*. Elle indique l'opérateur d'observation, noté + précédemment :math:`H`, qui transforme les paramètres d'entrée + :math:`\mathbf{x}` en résultats :math:`\mathbf{y}` qui sont à comparer aux + observations :math:`\mathbf{y}^o`. Sa valeur est définie comme un objet de type "*Function*" ou de type "*Matrix*". Dans le cas du type "*Function*", - différentes formes fonctionnelles peuvent être utilisées, comme décrit dans - la section :ref:`section_ref_operator_requirements`. Si un contrôle - :math:`U` est inclus dans le modèle d'observation, l'opérateur doit être - appliqué à une paire :math:`(X,U)`. - -Les commandes optionnelles générales, disponibles dans l'interface en édition, -sont indiquées dans la :ref:`section_ref_assimilation_keywords`. De plus, les -paramètres de la commande "*AlgorithmParameters*" permettent d'indiquer les -options particulières, décrites ci-après, de l'algorithme. On se reportera à la + différentes formes fonctionnelles peuvent être utilisées, comme décrit dans + la section :ref:`section_ref_operator_requirements`. Si un contrôle + :math:`U` est inclus dans le modèle d'observation, l'opérateur doit être + appliqué à une paire :math:`(X,U)`. + +Les commandes optionnelles générales, disponibles dans l'interface en édition, +sont indiquées dans la :ref:`section_ref_assimilation_keywords`. De plus, les +paramètres de la commande "*AlgorithmParameters*" permettent d'indiquer les +options particulières, décrites ci-après, de l'algorithme. On se reportera à la :ref:`section_ref_options_Algorithm_Parameters` pour le bon usage de cette commande. Les options de l'algorithme sont les suivantes: StoreSupplementaryCalculations - Cette liste indique les noms des variables supplémentaires qui peuvent être - disponibles à la fin de l'algorithme. Cela implique potentiellement des - calculs ou du stockage coûteux. La valeur par défaut est une liste vide, - aucune de ces variables n'étant calculée et stockée par défaut. Les noms + Cette liste indique les noms des variables supplémentaires qui peuvent être + disponibles à la fin de l'algorithme. Cela implique potentiellement des + calculs ou du stockage coûteux. La valeur par défaut est une liste vide, + aucune de ces variables n'étant calculée et stockée par défaut. Les noms possibles sont dans la liste suivante : ["APosterioriCorrelations", "APosterioriCovariance", "APosterioriStandardDeviations", "APosterioriVariances", "BMA", "OMA", "OMB", "CurrentState", @@ -118,165 +118,165 @@ Les options de l'algorithme sont les suivantes: Exemple : ``{"StoreSupplementaryCalculations":["CurrentState", "Innovation"]}`` Quantiles - Cette liste indique les valeurs de quantile, entre 0 et 1, à estimer par - simulation autour de l'état optimal. L'échantillonnage utilise des tirages - aléatoires gaussiens multivariés, dirigés par la matrice de covariance a - posteriori. Cette option n'est utile que si le calcul supplémentaire - "SimulationQuantiles" a été choisi. La valeur par défaut est une liste vide. + Cette liste indique les valeurs de quantile, entre 0 et 1, à estimer par + simulation autour de l'état optimal. L'échantillonnage utilise des tirages + aléatoires gaussiens multivariés, dirigés par la matrice de covariance a + posteriori. Cette option n'est utile que si le calcul supplémentaire + "SimulationQuantiles" a été choisi. La valeur par défaut est une liste vide. Exemple : ``{"Quantiles":[0.1,0.9]}`` SetSeed - Cette clé permet de donner un nombre entier pour fixer la graine du - générateur aléatoire utilisé pour générer l'ensemble. Un valeur pratique est - par exemple 1000. Par défaut, la graine est laissée non initialisée, et elle - utilise ainsi l'initialisation par défaut de l'ordinateur. + Cette clé permet de donner un nombre entier pour fixer la graine du + générateur aléatoire utilisé pour générer l'ensemble. Un valeur pratique est + par exemple 1000. Par défaut, la graine est laissée non initialisée, et elle + utilise ainsi l'initialisation par défaut de l'ordinateur. Exemple : ``{"SetSeed":1000}`` NumberOfSamplesForQuantiles - Cette clé indique le nombre de simulations effectuées pour estimer les - quantiles. Cette option n'est utile que si le calcul supplémentaire - "SimulationQuantiles" a été choisi. Le défaut est 100, ce qui suffit souvent - pour une estimation correcte de quantiles courants à 5%, 10%, 90% ou 95%. + Cette clé indique le nombre de simulations effectuées pour estimer les + quantiles. Cette option n'est utile que si le calcul supplémentaire + "SimulationQuantiles" a été choisi. Le défaut est 100, ce qui suffit souvent + pour une estimation correcte de quantiles courants à 5%, 10%, 90% ou 95%. Exemple : ``{"NumberOfSamplesForQuantiles":100}`` SimulationForQuantiles - Cette clé indique le type de simulation, linéaire (avec l'opérateur - d'observation tangent appliqué sur des incréments de perturbations autour de - l'état optimal) ou non-linéaire (avec l'opérateur d'observation standard - appliqué aux états perturbés), que l'on veut faire pour chaque perturbation. - Cela change essentiellement le temps de chaque simulation élémentaire, - usuellement plus long en non-linéaire qu'en linéaire. Cette option n'est - utile que si le calcul supplémentaire "SimulationQuantiles" a été choisi. La - valeur par défaut est "Linear", et les choix possibles sont "Linear" et + Cette clé indique le type de simulation, linéaire (avec l'opérateur + d'observation tangent appliqué sur des incréments de perturbations autour de + l'état optimal) ou non-linéaire (avec l'opérateur d'observation standard + appliqué aux états perturbés), que l'on veut faire pour chaque perturbation. + Cela change essentiellement le temps de chaque simulation élémentaire, + usuellement plus long en non-linéaire qu'en linéaire. Cette option n'est + utile que si le calcul supplémentaire "SimulationQuantiles" a été choisi. La + valeur par défaut est "Linear", et les choix possibles sont "Linear" et "NonLinear". Exemple : ``{"SimulationForQuantiles":"Linear"}`` -Informations et variables disponibles à la fin de l'algorithme +Informations et variables disponibles à la fin de l'algorithme ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -En sortie, après exécution de l'algorithme, on dispose d'informations et de +En sortie, après exécution de l'algorithme, on dispose d'informations et de variables issues du calcul. La description des -:ref:`section_ref_output_variables` indique la manière de les obtenir par la -méthode nommée ``get`` de la variable "*ADD*" du post-processing. Les variables -d'entrée, mises à disposition de l'utilisateur en sortie pour faciliter -l'écriture des procédures de post-processing, sont décrites dans +:ref:`section_ref_output_variables` indique la manière de les obtenir par la +méthode nommée ``get`` de la variable "*ADD*" du post-processing. Les variables +d'entrée, mises à disposition de l'utilisateur en sortie pour faciliter +l'écriture des procédures de post-processing, sont décrites dans l':ref:`subsection_r_o_v_Inventaire`. Les sorties non conditionnelles de l'algorithme sont les suivantes: Analysis - *Liste de vecteurs*. Chaque élément est un état optimal :math:`\mathbf{x}*` + *Liste de vecteurs*. Chaque élément est un état optimal :math:`\mathbf{x}*` en optimisation ou une analyse :math:`\mathbf{x}^a` en assimilation de - données. + données. Exemple : ``Xa = ADD.get("Analysis")[-1]`` Les sorties conditionnelles de l'algorithme sont les suivantes: APosterioriCorrelations - *Liste de matrices*. Chaque élément est une matrice de corrélation des - erreurs *a posteriori* de l'état optimal. + *Liste de matrices*. Chaque élément est une matrice de corrélation des + erreurs *a posteriori* de l'état optimal. Exemple : ``C = ADD.get("APosterioriCorrelations")[-1]`` APosterioriCovariance - *Liste de matrices*. Chaque élément est une matrice :math:`\mathbf{A}*` de - covariances des erreurs *a posteriori* de l'état optimal. + *Liste de matrices*. Chaque élément est une matrice :math:`\mathbf{A}*` de + covariances des erreurs *a posteriori* de l'état optimal. Exemple : ``A = ADD.get("APosterioriCovariance")[-1]`` APosterioriStandardDeviations - *Liste de matrices*. Chaque élément est une matrice d'écart-types des - erreurs *a posteriori* de l'état optimal. + *Liste de matrices*. Chaque élément est une matrice d'écart-types des + erreurs *a posteriori* de l'état optimal. Exemple : ``E = ADD.get("APosterioriStandardDeviations")[-1]`` APosterioriVariances - *Liste de matrices*. Chaque élément est une matrice de variances des erreurs - *a posteriori* de l'état optimal. + *Liste de matrices*. Chaque élément est une matrice de variances des erreurs + *a posteriori* de l'état optimal. Exemple : ``V = ADD.get("APosterioriVariances")[-1]`` BMA - *Liste de vecteurs*. Chaque élément est un vecteur d'écart entre - l'ébauche et l'état optimal. + *Liste de vecteurs*. Chaque élément est un vecteur d'écart entre + l'ébauche et l'état optimal. Exemple : ``bma = ADD.get("BMA")[-1]`` CostFunctionJ - *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart + *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart :math:`J`. Exemple : ``J = ADD.get("CostFunctionJ")[:]`` CostFunctionJb - *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart - :math:`J^b`, c'est-à-dire de la partie écart à l'ébauche. + *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart + :math:`J^b`, c'est-à-dire de la partie écart à l'ébauche. Exemple : ``Jb = ADD.get("CostFunctionJb")[:]`` CostFunctionJo - *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart - :math:`J^o`, c'est-à-dire de la partie écart à l'observation. + *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart + :math:`J^o`, c'est-à-dire de la partie écart à l'observation. Exemple : ``Jo = ADD.get("CostFunctionJo")[:]`` Innovation - *Liste de vecteurs*. Chaque élément est un vecteur d'innovation, qui est - en statique l'écart de l'optimum à l'ébauche, et en dynamique l'incrément - d'évolution. + *Liste de vecteurs*. Chaque élément est un vecteur d'innovation, qui est + en statique l'écart de l'optimum à l'ébauche, et en dynamique l'incrément + d'évolution. Exemple : ``d = ADD.get("Innovation")[-1]`` MahalanobisConsistency - *Liste de valeurs*. Chaque élément est une valeur de l'indicateur de - qualité de Mahalanobis. + *Liste de valeurs*. Chaque élément est une valeur de l'indicateur de + qualité de Mahalanobis. Exemple : ``m = ADD.get("MahalanobisConsistency")[-1]`` OMA - *Liste de vecteurs*. Chaque élément est un vecteur d'écart entre - l'observation et l'état optimal dans l'espace des observations. + *Liste de vecteurs*. Chaque élément est un vecteur d'écart entre + l'observation et l'état optimal dans l'espace des observations. Exemple : ``oma = ADD.get("OMA")[-1]`` OMB - *Liste de vecteurs*. Chaque élément est un vecteur d'écart entre - l'observation et l'état d'ébauche dans l'espace des observations. + *Liste de vecteurs*. Chaque élément est un vecteur d'écart entre + l'observation et l'état d'ébauche dans l'espace des observations. Exemple : ``omb = ADD.get("OMB")[-1]`` SigmaBck2 - *Liste de valeurs*. Chaque élément est une valeur de l'indicateur de - qualité :math:`(\sigma^b)^2` de la partie ébauche. + *Liste de valeurs*. Chaque élément est une valeur de l'indicateur de + qualité :math:`(\sigma^b)^2` de la partie ébauche. Exemple : ``sb2 = ADD.get("SigmaBck")[-1]`` SigmaObs2 - *Liste de valeurs*. Chaque élément est une valeur de l'indicateur de - qualité :math:`(\sigma^o)^2` de la partie observation. + *Liste de valeurs*. Chaque élément est une valeur de l'indicateur de + qualité :math:`(\sigma^o)^2` de la partie observation. Exemple : ``so2 = ADD.get("SigmaObs")[-1]`` SimulatedObservationAtBackground - *Liste de vecteurs*. Chaque élément est un vecteur d'observation simulé à - partir de l'ébauche :math:`\mathbf{x}^b`. + *Liste de vecteurs*. Chaque élément est un vecteur d'observation simulé à + partir de l'ébauche :math:`\mathbf{x}^b`. Exemple : ``hxb = ADD.get("SimulatedObservationAtBackground")[-1]`` SimulatedObservationAtOptimum - *Liste de vecteurs*. Chaque élément est un vecteur d'observation simulé à - partir de l'analyse ou de l'état optimal :math:`\mathbf{x}^a`. + *Liste de vecteurs*. Chaque élément est un vecteur d'observation simulé à + partir de l'analyse ou de l'état optimal :math:`\mathbf{x}^a`. Exemple : ``hxa = ADD.get("SimulatedObservationAtOptimum")[-1]`` SimulationQuantiles - *Liste de vecteurs*. Chaque élément est un vecteur correspondant à l'état - observé qui réalise le quantile demandé, dans le même ordre que les + *Liste de vecteurs*. Chaque élément est un vecteur correspondant à l'état + observé qui réalise le quantile demandé, dans le même ordre que les quantiles requis par l'utilisateur. Exemple : ``sQuantiles = ADD.get("SimulationQuantiles")[:]`` @@ -284,7 +284,7 @@ Les sorties conditionnelles de l'algorithme sont les suivantes: Voir aussi ++++++++++ -Références vers d'autres sections : +Références vers d'autres sections : - :ref:`section_ref_algorithm_Blue` - :ref:`section_ref_algorithm_3DVAR` - :ref:`section_ref_algorithm_LinearityTest` diff --git a/doc/fr/ref_algorithm_ExtendedKalmanFilter.rst b/doc/fr/ref_algorithm_ExtendedKalmanFilter.rst index 71e9afd..2906abc 100644 --- a/doc/fr/ref_algorithm_ExtendedKalmanFilter.rst +++ b/doc/fr/ref_algorithm_ExtendedKalmanFilter.rst @@ -30,9 +30,9 @@ Algorithme de calcul "*ExtendedKalmanFilter*" Description +++++++++++ -Cet algorithme réalise une estimation de l'état d'un système dynamique par un -filtre de Kalman étendu, utilisant un calcul non linéaire de l'état et de -l'évolution incrémentale (processus). +Cet algorithme réalise une estimation de l'état d'un système dynamique par un +filtre de Kalman étendu, utilisant un calcul non linéaire de l'état et de +l'évolution incrémentale (processus). Commandes requises et optionnelles ++++++++++++++++++++++++++++++++++ @@ -48,80 +48,80 @@ Commandes requises et optionnelles .. index:: single: EstimationOf .. index:: single: StoreSupplementaryCalculations -Les commandes requises générales, disponibles dans l'interface en édition, sont +Les commandes requises générales, disponibles dans l'interface en édition, sont les suivantes: Background - *Commande obligatoire*. Elle définit le vecteur d'ébauche ou - d'initialisation, noté précédemment :math:`\mathbf{x}^b`. Sa valeur est - définie comme un objet de type "*Vector*" ou de type "*VectorSerie*". + *Commande obligatoire*. Elle définit le vecteur d'ébauche ou + d'initialisation, noté précédemment :math:`\mathbf{x}^b`. Sa valeur est + définie comme un objet de type "*Vector*" ou de type "*VectorSerie*". BackgroundError - *Commande obligatoire*. Elle définit la matrice de covariance des erreurs - d'ébauche, notée précédemment :math:`\mathbf{B}`. Sa valeur est définie + *Commande obligatoire*. Elle définit la matrice de covariance des erreurs + d'ébauche, notée précédemment :math:`\mathbf{B}`. Sa valeur est définie comme un objet de type "*Matrix*", de type "*ScalarSparseMatrix*", ou de type "*DiagonalSparseMatrix*". Observation - *Commande obligatoire*. Elle définit le vecteur d'observation utilisé en - assimilation de données ou en optimisation, et noté précédemment - :math:`\mathbf{y}^o`. Sa valeur est définie comme un objet de type "*Vector*" + *Commande obligatoire*. Elle définit le vecteur d'observation utilisé en + assimilation de données ou en optimisation, et noté précédemment + :math:`\mathbf{y}^o`. Sa valeur est définie comme un objet de type "*Vector*" ou de type "*VectorSerie*". ObservationError - *Commande obligatoire*. Elle définit la matrice de covariance des erreurs - d'ébauche, notée précédemment :math:`\mathbf{R}`. Sa valeur est définie + *Commande obligatoire*. Elle définit la matrice de covariance des erreurs + d'ébauche, notée précédemment :math:`\mathbf{R}`. Sa valeur est définie comme un objet de type "*Matrix*", de type "*ScalarSparseMatrix*", ou de type "*DiagonalSparseMatrix*". ObservationOperator - *Commande obligatoire*. Elle indique l'opérateur d'observation, noté - précédemment :math:`H`, qui transforme les paramètres d'entrée - :math:`\mathbf{x}` en résultats :math:`\mathbf{y}` qui sont à comparer aux - observations :math:`\mathbf{y}^o`. Sa valeur est définie comme un objet de + *Commande obligatoire*. Elle indique l'opérateur d'observation, noté + précédemment :math:`H`, qui transforme les paramètres d'entrée + :math:`\mathbf{x}` en résultats :math:`\mathbf{y}` qui sont à comparer aux + observations :math:`\mathbf{y}^o`. Sa valeur est définie comme un objet de type "*Function*" ou de type "*Matrix*". Dans le cas du type "*Function*", - différentes formes fonctionnelles peuvent être utilisées, comme décrit dans - la section :ref:`section_ref_operator_requirements`. Si un contrôle - :math:`U` est inclus dans le modèle d'observation, l'opérateur doit être - appliqué à une paire :math:`(X,U)`. - -Les commandes optionnelles générales, disponibles dans l'interface en édition, -sont indiquées dans la :ref:`section_ref_assimilation_keywords`. De plus, les -paramètres de la commande "*AlgorithmParameters*" permettent d'indiquer les -options particulières, décrites ci-après, de l'algorithme. On se reportera à la + différentes formes fonctionnelles peuvent être utilisées, comme décrit dans + la section :ref:`section_ref_operator_requirements`. Si un contrôle + :math:`U` est inclus dans le modèle d'observation, l'opérateur doit être + appliqué à une paire :math:`(X,U)`. + +Les commandes optionnelles générales, disponibles dans l'interface en édition, +sont indiquées dans la :ref:`section_ref_assimilation_keywords`. De plus, les +paramètres de la commande "*AlgorithmParameters*" permettent d'indiquer les +options particulières, décrites ci-après, de l'algorithme. On se reportera à la :ref:`section_ref_options_Algorithm_Parameters` pour le bon usage de cette commande. Les options de l'algorithme sont les suivantes: Bounds - Cette clé permet de définir des bornes supérieure et inférieure pour chaque - variable d'état optimisée. Les bornes doivent être données par une liste de - liste de paires de bornes inférieure/supérieure pour chaque variable, avec - une valeur extrême chaque fois qu'il n'y a pas de borne (``None`` n'est pas - une valeur autorisée lorsqu'il n'y a pas de borne). + Cette clé permet de définir des bornes supérieure et inférieure pour chaque + variable d'état optimisée. Les bornes doivent être données par une liste de + liste de paires de bornes inférieure/supérieure pour chaque variable, avec + une valeur extrême chaque fois qu'il n'y a pas de borne (``None`` n'est pas + une valeur autorisée lorsqu'il n'y a pas de borne). Exemple : ``{"Bounds":[[2.,5.],[1.e-2,10.],[-30.,1.e99],[-1.e99,1.e99]]}`` ConstrainedBy - Cette clé permet d'indiquer la méthode de prise en compte des contraintes de + Cette clé permet d'indiquer la méthode de prise en compte des contraintes de bornes. La seule disponible est "EstimateProjection", qui projette - l'estimation de l'état courant sur les contraintes de bornes. + l'estimation de l'état courant sur les contraintes de bornes. Exemple : ``{"ConstrainedBy":"EstimateProjection"}`` EstimationOf - Cette clé permet de choisir le type d'estimation à réaliser. Cela peut être - soit une estimation de l'état, avec la valeur "State", ou une estimation de - paramètres, avec la valeur "Parameters". Le choix par défaut est "State". + Cette clé permet de choisir le type d'estimation à réaliser. Cela peut être + soit une estimation de l'état, avec la valeur "State", ou une estimation de + paramètres, avec la valeur "Parameters". Le choix par défaut est "State". Exemple : ``{"EstimationOf":"Parameters"}`` StoreSupplementaryCalculations - Cette liste indique les noms des variables supplémentaires qui peuvent être - disponibles à la fin de l'algorithme. Cela implique potentiellement des - calculs ou du stockage coûteux. La valeur par défaut est une liste vide, - aucune de ces variables n'étant calculée et stockée par défaut. Les noms + Cette liste indique les noms des variables supplémentaires qui peuvent être + disponibles à la fin de l'algorithme. Cela implique potentiellement des + calculs ou du stockage coûteux. La valeur par défaut est une liste vide, + aucune de ces variables n'étant calculée et stockée par défaut. Les noms possibles sont dans la liste suivante : ["APosterioriCorrelations", "APosterioriCovariance", "APosterioriStandardDeviations", "APosterioriVariances", "BMA", "CostFunctionJ", "CostFunctionJb", @@ -129,92 +129,92 @@ Les options de l'algorithme sont les suivantes: Exemple : ``{"StoreSupplementaryCalculations":["BMA", "Innovation"]}`` -Informations et variables disponibles à la fin de l'algorithme +Informations et variables disponibles à la fin de l'algorithme ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -En sortie, après exécution de l'algorithme, on dispose d'informations et de +En sortie, après exécution de l'algorithme, on dispose d'informations et de variables issues du calcul. La description des -:ref:`section_ref_output_variables` indique la manière de les obtenir par la -méthode nommée ``get`` de la variable "*ADD*" du post-processing. Les variables -d'entrée, mises à disposition de l'utilisateur en sortie pour faciliter -l'écriture des procédures de post-processing, sont décrites dans +:ref:`section_ref_output_variables` indique la manière de les obtenir par la +méthode nommée ``get`` de la variable "*ADD*" du post-processing. Les variables +d'entrée, mises à disposition de l'utilisateur en sortie pour faciliter +l'écriture des procédures de post-processing, sont décrites dans l':ref:`subsection_r_o_v_Inventaire`. Les sorties non conditionnelles de l'algorithme sont les suivantes: Analysis - *Liste de vecteurs*. Chaque élément est un état optimal :math:`\mathbf{x}*` + *Liste de vecteurs*. Chaque élément est un état optimal :math:`\mathbf{x}*` en optimisation ou une analyse :math:`\mathbf{x}^a` en assimilation de - données. + données. Exemple : ``Xa = ADD.get("Analysis")[-1]`` Les sorties conditionnelles de l'algorithme sont les suivantes: APosterioriCorrelations - *Liste de matrices*. Chaque élément est une matrice de corrélation des - erreurs *a posteriori* de l'état optimal. + *Liste de matrices*. Chaque élément est une matrice de corrélation des + erreurs *a posteriori* de l'état optimal. Exemple : ``C = ADD.get("APosterioriCorrelations")[-1]`` APosterioriCovariance - *Liste de matrices*. Chaque élément est une matrice :math:`\mathbf{A}*` de - covariances des erreurs *a posteriori* de l'état optimal. + *Liste de matrices*. Chaque élément est une matrice :math:`\mathbf{A}*` de + covariances des erreurs *a posteriori* de l'état optimal. Exemple : ``A = ADD.get("APosterioriCovariance")[-1]`` APosterioriStandardDeviations - *Liste de matrices*. Chaque élément est une matrice d'écart-types des - erreurs *a posteriori* de l'état optimal. + *Liste de matrices*. Chaque élément est une matrice d'écart-types des + erreurs *a posteriori* de l'état optimal. Exemple : ``E = ADD.get("APosterioriStandardDeviations")[-1]`` APosterioriVariances - *Liste de matrices*. Chaque élément est une matrice de variances des erreurs - *a posteriori* de l'état optimal. + *Liste de matrices*. Chaque élément est une matrice de variances des erreurs + *a posteriori* de l'état optimal. Exemple : ``V = ADD.get("APosterioriVariances")[-1]`` BMA - *Liste de vecteurs*. Chaque élément est un vecteur d'écart entre - l'ébauche et l'état optimal. + *Liste de vecteurs*. Chaque élément est un vecteur d'écart entre + l'ébauche et l'état optimal. Exemple : ``bma = ADD.get("BMA")[-1]`` CostFunctionJ - *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart + *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart :math:`J`. Exemple : ``J = ADD.get("CostFunctionJ")[:]`` CostFunctionJb - *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart - :math:`J^b`, c'est-à-dire de la partie écart à l'ébauche. + *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart + :math:`J^b`, c'est-à-dire de la partie écart à l'ébauche. Exemple : ``Jb = ADD.get("CostFunctionJb")[:]`` CostFunctionJo - *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart - :math:`J^o`, c'est-à-dire de la partie écart à l'observation. + *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart + :math:`J^o`, c'est-à-dire de la partie écart à l'observation. Exemple : ``Jo = ADD.get("CostFunctionJo")[:]`` CurrentState - *Liste de vecteurs*. Chaque élément est un vecteur d'état courant utilisé - au cours du déroulement de l'algorithme d'optimisation. + *Liste de vecteurs*. Chaque élément est un vecteur d'état courant utilisé + au cours du déroulement de l'algorithme d'optimisation. Exemple : ``Xs = ADD.get("CurrentState")[:]`` Innovation - *Liste de vecteurs*. Chaque élément est un vecteur d'innovation, qui est - en statique l'écart de l'optimum à l'ébauche, et en dynamique l'incrément - d'évolution. + *Liste de vecteurs*. Chaque élément est un vecteur d'innovation, qui est + en statique l'écart de l'optimum à l'ébauche, et en dynamique l'incrément + d'évolution. Exemple : ``d = ADD.get("Innovation")[-1]`` Voir aussi ++++++++++ -Références vers d'autres sections : +Références vers d'autres sections : - :ref:`section_ref_algorithm_KalmanFilter` - :ref:`section_ref_algorithm_UnscentedKalmanFilter` diff --git a/doc/fr/ref_algorithm_FunctionTest.rst b/doc/fr/ref_algorithm_FunctionTest.rst index e7ff33d..31b6675 100644 --- a/doc/fr/ref_algorithm_FunctionTest.rst +++ b/doc/fr/ref_algorithm_FunctionTest.rst @@ -24,23 +24,23 @@ .. index:: single: FunctionTest .. _section_ref_algorithm_FunctionTest: -Algorithme de vérification "*FunctionTest*" +Algorithme de vérification "*FunctionTest*" ------------------------------------------- Description +++++++++++ -Cet algorithme permet de vérifier que l'opérateur d'observation fonctionne -correctement et que son appel se déroule de manière compatible avec son usage -dans les algorithmes d'ADAO. De manière pratique, il permet d'appeler une ou -plusieurs fois l'opérateur, en activant ou non le mode "debug" lors de -l'exécution. +Cet algorithme permet de vérifier que l'opérateur d'observation fonctionne +correctement et que son appel se déroule de manière compatible avec son usage +dans les algorithmes d'ADAO. De manière pratique, il permet d'appeler une ou +plusieurs fois l'opérateur, en activant ou non le mode "debug" lors de +l'exécution. -Une statistique sur les vecteurs en entrée et en sortie de chaque exécution de -l'opérateur est indiquée, et une autre globale est fournie de manière -récapitulative à la fin de l'algorithme de vérification. La précision -d'affichage est contrôlable pour permettre l'automatisation des tests -d'opérateur. +Une statistique sur les vecteurs en entrée et en sortie de chaque exécution de +l'opérateur est indiquée, et une autre globale est fournie de manière +récapitulative à la fin de l'algorithme de vérification. La précision +d'affichage est contrôlable pour permettre l'automatisation des tests +d'opérateur. Commandes requises et optionnelles ++++++++++++++++++++++++++++++++++ @@ -53,91 +53,91 @@ Commandes requises et optionnelles .. index:: single: SetDebug .. index:: single: StoreSupplementaryCalculations -Les commandes requises générales, disponibles dans l'interface en édition, sont +Les commandes requises générales, disponibles dans l'interface en édition, sont les suivantes: CheckingPoint - *Commande obligatoire*. Elle définit le vecteur utilisé comme l'état autour - duquel réaliser le test requis, noté :math:`\mathbf{x}` et similaire à - l'ébauche :math:`\mathbf{x}^b`. Sa valeur est définie comme un objet de type + *Commande obligatoire*. Elle définit le vecteur utilisé comme l'état autour + duquel réaliser le test requis, noté :math:`\mathbf{x}` et similaire à + l'ébauche :math:`\mathbf{x}^b`. Sa valeur est définie comme un objet de type "*Vector*". ObservationOperator - *Commande obligatoire*. Elle indique l'opérateur d'observation, notée - précédemment :math:`H`, qui transforme les paramètres d'entrée - :math:`\mathbf{x}` en résultats :math:`\mathbf{y}` qui sont à comparer aux - observations :math:`\mathbf{y}^o`. Sa valeur est définie comme un objet de - type "*Function*". Différentes formes fonctionnelles peuvent être - utilisées, comme décrit dans la section - :ref:`section_ref_operator_requirements`. Si un contrôle :math:`U` est - inclus dans le modèle d'observation, l'opérateur doit être appliqué à une + *Commande obligatoire*. Elle indique l'opérateur d'observation, notée + précédemment :math:`H`, qui transforme les paramètres d'entrée + :math:`\mathbf{x}` en résultats :math:`\mathbf{y}` qui sont à comparer aux + observations :math:`\mathbf{y}^o`. Sa valeur est définie comme un objet de + type "*Function*". Différentes formes fonctionnelles peuvent être + utilisées, comme décrit dans la section + :ref:`section_ref_operator_requirements`. Si un contrôle :math:`U` est + inclus dans le modèle d'observation, l'opérateur doit être appliqué à une paire :math:`(X,U)`. -Les commandes optionnelles générales, disponibles dans l'interface en édition, -sont indiquées dans la :ref:`section_ref_checking_keywords`. De plus, les -paramètres de la commande "*AlgorithmParameters*" permettent d'indiquer les -options particulières, décrites ci-après, de l'algorithme. On se reportera à la +Les commandes optionnelles générales, disponibles dans l'interface en édition, +sont indiquées dans la :ref:`section_ref_checking_keywords`. De plus, les +paramètres de la commande "*AlgorithmParameters*" permettent d'indiquer les +options particulières, décrites ci-après, de l'algorithme. On se reportera à la :ref:`section_ref_options_Algorithm_Parameters` pour le bon usage de cette commande. Les options de l'algorithme sont les suivantes: NumberOfPrintedDigits - Cette clé indique le nombre de décimales de précision pour les affichages de - valeurs réelles. La valeur par défaut est 5, avec un minimum de 0. + Cette clé indique le nombre de décimales de précision pour les affichages de + valeurs réelles. La valeur par défaut est 5, avec un minimum de 0. Exemple : ``{"NumberOfPrintedDigits":5}`` NumberOfRepetition - Cette clé indique le nombre de fois où répéter l'évaluation de la fonction. - La valeur par défaut est 1. + Cette clé indique le nombre de fois où répéter l'évaluation de la fonction. + La valeur par défaut est 1. Exemple : ``{"NumberOfRepetition":3}`` SetDebug - Cette clé requiert l'activation, ou pas, du mode de débogage durant - l'évaluation de la fonction. La valeur par défaut est "False", les choix + Cette clé requiert l'activation, ou pas, du mode de débogage durant + l'évaluation de la fonction. La valeur par défaut est "False", les choix sont "True" ou "False". Exemple : ``{"SetDebug":False}`` StoreSupplementaryCalculations - Cette liste indique les noms des variables supplémentaires qui peuvent être - disponibles à la fin de l'algorithme. Cela implique potentiellement des - calculs ou du stockage coûteux. La valeur par défaut est une liste vide, - aucune de ces variables n'étant calculée et stockée par défaut. Les noms + Cette liste indique les noms des variables supplémentaires qui peuvent être + disponibles à la fin de l'algorithme. Cela implique potentiellement des + calculs ou du stockage coûteux. La valeur par défaut est une liste vide, + aucune de ces variables n'étant calculée et stockée par défaut. Les noms possibles sont dans la liste suivante : ["CurrentState", "SimulatedObservationAtCurrentState"]. Exemple : ``{"StoreSupplementaryCalculations":["CurrentState"]}`` -Informations et variables disponibles à la fin de l'algorithme +Informations et variables disponibles à la fin de l'algorithme ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -En sortie, après exécution de l'algorithme, on dispose d'informations et de +En sortie, après exécution de l'algorithme, on dispose d'informations et de variables issues du calcul. La description des -:ref:`section_ref_output_variables` indique la manière de les obtenir par la -méthode nommée ``get`` de la variable "*ADD*" du post-processing. Les variables -d'entrée, mises à disposition de l'utilisateur en sortie pour faciliter -l'écriture des procédures de post-processing, sont décrites dans +:ref:`section_ref_output_variables` indique la manière de les obtenir par la +méthode nommée ``get`` de la variable "*ADD*" du post-processing. Les variables +d'entrée, mises à disposition de l'utilisateur en sortie pour faciliter +l'écriture des procédures de post-processing, sont décrites dans l':ref:`subsection_r_o_v_Inventaire`. Les sorties conditionnelles de l'algorithme sont les suivantes: CurrentState - *Liste de vecteurs*. Chaque élément est un vecteur d'état courant utilisé - au cours du déroulement de l'algorithme d'optimisation. + *Liste de vecteurs*. Chaque élément est un vecteur d'état courant utilisé + au cours du déroulement de l'algorithme d'optimisation. Exemple : ``Xs = ADD.get("CurrentState")[:]`` SimulatedObservationAtCurrentState - *Liste de vecteurs*. Chaque élément est un vecteur d'observation simulé à - partir de l'état courant, c'est-à-dire dans l'espace des observations. + *Liste de vecteurs*. Chaque élément est un vecteur d'observation simulé à + partir de l'état courant, c'est-à-dire dans l'espace des observations. Exemple : ``hxs = ADD.get("SimulatedObservationAtCurrentState")[-1]`` Voir aussi ++++++++++ -Références vers d'autres sections : +Références vers d'autres sections : - :ref:`section_ref_algorithm_LinearityTest` diff --git a/doc/fr/ref_algorithm_GradientTest.rst b/doc/fr/ref_algorithm_GradientTest.rst index 113808d..866f7ce 100644 --- a/doc/fr/ref_algorithm_GradientTest.rst +++ b/doc/fr/ref_algorithm_GradientTest.rst @@ -24,66 +24,66 @@ .. index:: single: GradientTest .. _section_ref_algorithm_GradientTest: -Algorithme de vérification "*GradientTest*" +Algorithme de vérification "*GradientTest*" ------------------------------------------- Description +++++++++++ -Cet algorithme permet de vérifier la qualité du gradient de l'opérateur, en -calculant un résidu dont les propriétés théoriques sont connues. Plusieurs -formules de résidu sont disponibles. +Cet algorithme permet de vérifier la qualité du gradient de l'opérateur, en +calculant un résidu dont les propriétés théoriques sont connues. Plusieurs +formules de résidu sont disponibles. Dans tous les cas, on prend :math:`\mathbf{dx}_0=Normal(0,\mathbf{x})` et :math:`\mathbf{dx}=\alpha*\mathbf{dx}_0`. :math:`F` est le code de calcul. -Résidu "Taylor" +Résidu "Taylor" *************** -On observe le résidu issu du développement de Taylor de la fonction :math:`F`, -normalisé par la valeur au point nominal : +On observe le résidu issu du développement de Taylor de la fonction :math:`F`, +normalisé par la valeur au point nominal : .. math:: R(\alpha) = \frac{|| F(\mathbf{x}+\alpha*\mathbf{dx}) - F(\mathbf{x}) - \alpha * \nabla_xF(\mathbf{dx}) ||}{|| F(\mathbf{x}) ||} -Si le résidu décroît et que la décroissance se fait en :math:`\alpha^2` selon -:math:`\alpha`, cela signifie que le gradient est bien calculé jusqu'à la -précision d'arrêt de la décroissance quadratique, et que :math:`F` n'est pas -linéaire. +Si le résidu décroît et que la décroissance se fait en :math:`\alpha^2` selon +:math:`\alpha`, cela signifie que le gradient est bien calculé jusqu'à la +précision d'arrêt de la décroissance quadratique, et que :math:`F` n'est pas +linéaire. -Si le résidu décroît et que la décroissance se fait en :math:`\alpha` selon -:math:`\alpha`, jusqu'à un certain seuil après lequel le résidu est faible et -constant, cela signifie que :math:`F` est linéaire et que le résidu décroît à +Si le résidu décroît et que la décroissance se fait en :math:`\alpha` selon +:math:`\alpha`, jusqu'à un certain seuil après lequel le résidu est faible et +constant, cela signifie que :math:`F` est linéaire et que le résidu décroît à partir de l'erreur faite dans le calcul du terme :math:`\nabla_xF`. -Résidu "TaylorOnNorm" +Résidu "TaylorOnNorm" ********************* -On observe le résidu issu du développement de Taylor de la fonction :math:`F`, -rapporté au paramètre :math:`\alpha` au carré : +On observe le résidu issu du développement de Taylor de la fonction :math:`F`, +rapporté au paramètre :math:`\alpha` au carré : .. math:: R(\alpha) = \frac{|| F(\mathbf{x}+\alpha*\mathbf{dx}) - F(\mathbf{x}) - \alpha * \nabla_xF(\mathbf{dx}) ||}{\alpha^2} -C'est un résidu essentiellement similaire au critère classique de Taylor décrit -précédemment, mais son comportement peut différer selon les propriétés -numériques des calculs de ses différents termes. +C'est un résidu essentiellement similaire au critère classique de Taylor décrit +précédemment, mais son comportement peut différer selon les propriétés +numériques des calculs de ses différents termes. -Si le résidu est constant jusqu'à un certain seuil et croissant ensuite, cela -signifie que le gradient est bien calculé jusqu'à cette précision d'arrêt, et -que :math:`F` n'est pas linéaire. +Si le résidu est constant jusqu'à un certain seuil et croissant ensuite, cela +signifie que le gradient est bien calculé jusqu'à cette précision d'arrêt, et +que :math:`F` n'est pas linéaire. -Si le résidu est systématiquement croissant en partant d'une valeur faible par -rapport à :math:`||F(\mathbf{x})||`, cela signifie que :math:`F` est -(quasi-)linéaire et que le calcul du gradient est correct jusqu'au moment où le -résidu est de l'ordre de grandeur de :math:`||F(\mathbf{x})||`. +Si le résidu est systématiquement croissant en partant d'une valeur faible par +rapport à :math:`||F(\mathbf{x})||`, cela signifie que :math:`F` est +(quasi-)linéaire et que le calcul du gradient est correct jusqu'au moment où le +résidu est de l'ordre de grandeur de :math:`||F(\mathbf{x})||`. -Résidu "Norm" +Résidu "Norm" ************* -On observe le résidu, qui est basé sur une approximation du gradient : +On observe le résidu, qui est basé sur une approximation du gradient : .. math:: R(\alpha) = \frac{|| F(\mathbf{x}+\alpha*\mathbf{dx}) - F(\mathbf{x}) ||}{\alpha} -qui doit rester constant jusqu'à ce que l'on atteigne la précision du calcul. +qui doit rester constant jusqu'à ce que l'on atteigne la précision du calcul. Commandes requises et optionnelles ++++++++++++++++++++++++++++++++++ @@ -98,129 +98,129 @@ Commandes requises et optionnelles .. index:: single: SetSeed .. index:: single: StoreSupplementaryCalculations -Les commandes requises générales, disponibles dans l'interface en édition, sont +Les commandes requises générales, disponibles dans l'interface en édition, sont les suivantes: CheckingPoint - *Commande obligatoire*. Elle définit le vecteur utilisé comme l'état autour - duquel réaliser le test requis, noté :math:`\mathbf{x}` et similaire à - l'ébauche :math:`\mathbf{x}^b`. Sa valeur est définie comme un objet de type + *Commande obligatoire*. Elle définit le vecteur utilisé comme l'état autour + duquel réaliser le test requis, noté :math:`\mathbf{x}` et similaire à + l'ébauche :math:`\mathbf{x}^b`. Sa valeur est définie comme un objet de type "*Vector*". ObservationOperator - *Commande obligatoire*. Elle indique l'opérateur d'observation, notée - précédemment :math:`H`, qui transforme les paramètres d'entrée - :math:`\mathbf{x}` en résultats :math:`\mathbf{y}` qui sont à comparer aux - observations :math:`\mathbf{y}^o`. Sa valeur est définie comme un objet de - type "*Function*". Différentes formes fonctionnelles peuvent être - utilisées, comme décrit dans la section - :ref:`section_ref_operator_requirements`. Si un contrôle :math:`U` est - inclus dans le modèle d'observation, l'opérateur doit être appliqué à une + *Commande obligatoire*. Elle indique l'opérateur d'observation, notée + précédemment :math:`H`, qui transforme les paramètres d'entrée + :math:`\mathbf{x}` en résultats :math:`\mathbf{y}` qui sont à comparer aux + observations :math:`\mathbf{y}^o`. Sa valeur est définie comme un objet de + type "*Function*". Différentes formes fonctionnelles peuvent être + utilisées, comme décrit dans la section + :ref:`section_ref_operator_requirements`. Si un contrôle :math:`U` est + inclus dans le modèle d'observation, l'opérateur doit être appliqué à une paire :math:`(X,U)`. -Les commandes optionnelles générales, disponibles dans l'interface en édition, -sont indiquées dans la :ref:`section_ref_checking_keywords`. De plus, les -paramètres de la commande "*AlgorithmParameters*" permettent d'indiquer les -options particulières, décrites ci-après, de l'algorithme. On se reportera à la +Les commandes optionnelles générales, disponibles dans l'interface en édition, +sont indiquées dans la :ref:`section_ref_checking_keywords`. De plus, les +paramètres de la commande "*AlgorithmParameters*" permettent d'indiquer les +options particulières, décrites ci-après, de l'algorithme. On se reportera à la :ref:`section_ref_options_Algorithm_Parameters` pour le bon usage de cette commande. Les options de l'algorithme sont les suivantes: AmplitudeOfInitialDirection - Cette clé indique la mise à l'échelle de la perturbation initiale construite - comme un vecteur utilisé pour la dérivée directionnelle autour du point - nominal de vérification. La valeur par défaut est de 1, ce qui signifie pas - de mise à l'échelle. + Cette clé indique la mise à l'échelle de la perturbation initiale construite + comme un vecteur utilisé pour la dérivée directionnelle autour du point + nominal de vérification. La valeur par défaut est de 1, ce qui signifie pas + de mise à l'échelle. Exemple : ``{"AmplitudeOfInitialDirection":0.5}`` EpsilonMinimumExponent - Cette clé indique la valeur de l'exposant minimal du coefficient en - puissance de 10 qui doit être utilisé pour faire décroître le multiplicateur - de l'incrément. La valeur par défaut est de -8, et elle doit être entre 0 et - -20. Par exemple, la valeur par défaut conduit à calculer le résidu de la - formule avec un incrément fixe multiplié par 1.e0 jusqu'à 1.e-8. + Cette clé indique la valeur de l'exposant minimal du coefficient en + puissance de 10 qui doit être utilisé pour faire décroître le multiplicateur + de l'incrément. La valeur par défaut est de -8, et elle doit être entre 0 et + -20. Par exemple, la valeur par défaut conduit à calculer le résidu de la + formule avec un incrément fixe multiplié par 1.e0 jusqu'à 1.e-8. Exemple : ``{"EpsilonMinimumExponent":-12}`` InitialDirection - Cette clé indique la direction vectorielle utilisée pour la dérivée - directionnelle autour du point nominal de vérification. Cela doit être un - vecteur. Si elle n'est pas spécifiée, la direction par défaut est une - perturbation par défaut autour de zéro de la même taille vectorielle que le - point de vérification. + Cette clé indique la direction vectorielle utilisée pour la dérivée + directionnelle autour du point nominal de vérification. Cela doit être un + vecteur. Si elle n'est pas spécifiée, la direction par défaut est une + perturbation par défaut autour de zéro de la même taille vectorielle que le + point de vérification. Exemple : ``{"InitialDirection":[0.1,0.1,100.,3}`` ResiduFormula - Cette clé indique la formule de résidu qui doit être utilisée pour le test. - Le choix par défaut est "Taylor", et les choix possibles sont "Taylor" - (résidu du développement de Taylor normalisé de l'opérateur, qui doit - décroître comme le carré de la perturbation), "TaylorOnNorm" (résidu du - développement de Taylor rapporté à la perturbation de l'opérateur, qui doit - rester constant) et "Norm" (résidu obtenu en prenant la norme du - développement de Taylor à l'ordre 0, qui approxime le gradient, et qui doit + Cette clé indique la formule de résidu qui doit être utilisée pour le test. + Le choix par défaut est "Taylor", et les choix possibles sont "Taylor" + (résidu du développement de Taylor normalisé de l'opérateur, qui doit + décroître comme le carré de la perturbation), "TaylorOnNorm" (résidu du + développement de Taylor rapporté à la perturbation de l'opérateur, qui doit + rester constant) et "Norm" (résidu obtenu en prenant la norme du + développement de Taylor à l'ordre 0, qui approxime le gradient, et qui doit rester constant). Exemple : ``{"ResiduFormula":"Taylor"}`` SetSeed - Cette clé permet de donner un nombre entier pour fixer la graine du - générateur aléatoire utilisé pour générer l'ensemble. Un valeur pratique est - par exemple 1000. Par défaut, la graine est laissée non initialisée, et elle - utilise ainsi l'initialisation par défaut de l'ordinateur. + Cette clé permet de donner un nombre entier pour fixer la graine du + générateur aléatoire utilisé pour générer l'ensemble. Un valeur pratique est + par exemple 1000. Par défaut, la graine est laissée non initialisée, et elle + utilise ainsi l'initialisation par défaut de l'ordinateur. Exemple : ``{"SetSeed":1000}`` StoreSupplementaryCalculations - Cette liste indique les noms des variables supplémentaires qui peuvent être - disponibles à la fin de l'algorithme. Cela implique potentiellement des - calculs ou du stockage coûteux. La valeur par défaut est une liste vide, - aucune de ces variables n'étant calculée et stockée par défaut. Les noms + Cette liste indique les noms des variables supplémentaires qui peuvent être + disponibles à la fin de l'algorithme. Cela implique potentiellement des + calculs ou du stockage coûteux. La valeur par défaut est une liste vide, + aucune de ces variables n'étant calculée et stockée par défaut. Les noms possibles sont dans la liste suivante : ["CurrentState", "Residu", "SimulatedObservationAtCurrentState"]. Exemple : ``{"StoreSupplementaryCalculations":["CurrentState"]}`` -Informations et variables disponibles à la fin de l'algorithme +Informations et variables disponibles à la fin de l'algorithme ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -En sortie, après exécution de l'algorithme, on dispose d'informations et de +En sortie, après exécution de l'algorithme, on dispose d'informations et de variables issues du calcul. La description des -:ref:`section_ref_output_variables` indique la manière de les obtenir par la -méthode nommée ``get`` de la variable "*ADD*" du post-processing. Les variables -d'entrée, mises à disposition de l'utilisateur en sortie pour faciliter -l'écriture des procédures de post-processing, sont décrites dans +:ref:`section_ref_output_variables` indique la manière de les obtenir par la +méthode nommée ``get`` de la variable "*ADD*" du post-processing. Les variables +d'entrée, mises à disposition de l'utilisateur en sortie pour faciliter +l'écriture des procédures de post-processing, sont décrites dans l':ref:`subsection_r_o_v_Inventaire`. Les sorties non conditionnelles de l'algorithme sont les suivantes: Residu - *Liste de valeurs*. Chaque élément est la valeur du résidu particulier - vérifié lors d'un algorithme de vérification, selon l'ordre des tests - effectués. + *Liste de valeurs*. Chaque élément est la valeur du résidu particulier + vérifié lors d'un algorithme de vérification, selon l'ordre des tests + effectués. Exemple : ``r = ADD.get("Residu")[:]`` Les sorties conditionnelles de l'algorithme sont les suivantes: CurrentState - *Liste de vecteurs*. Chaque élément est un vecteur d'état courant utilisé - au cours du déroulement de l'algorithme d'optimisation. + *Liste de vecteurs*. Chaque élément est un vecteur d'état courant utilisé + au cours du déroulement de l'algorithme d'optimisation. Exemple : ``Xs = ADD.get("CurrentState")[:]`` SimulatedObservationAtCurrentState - *Liste de vecteurs*. Chaque élément est un vecteur d'observation simulé à - partir de l'état courant, c'est-à-dire dans l'espace des observations. + *Liste de vecteurs*. Chaque élément est un vecteur d'observation simulé à + partir de l'état courant, c'est-à-dire dans l'espace des observations. Exemple : ``hxs = ADD.get("SimulatedObservationAtCurrentState")[-1]`` Voir aussi ++++++++++ -Références vers d'autres sections : +Références vers d'autres sections : - :ref:`section_ref_algorithm_FunctionTest` - :ref:`section_ref_algorithm_LinearityTest` - :ref:`section_ref_algorithm_TangentTest` diff --git a/doc/fr/ref_algorithm_KalmanFilter.rst b/doc/fr/ref_algorithm_KalmanFilter.rst index 57a7048..55aadb5 100644 --- a/doc/fr/ref_algorithm_KalmanFilter.rst +++ b/doc/fr/ref_algorithm_KalmanFilter.rst @@ -30,15 +30,15 @@ Algorithme de calcul "*KalmanFilter*" Description +++++++++++ -Cet algorithme réalise une estimation de l'état d'un système dynamique par un +Cet algorithme réalise une estimation de l'état d'un système dynamique par un filtre de Kalman. -Il est théoriquement réservé aux cas d'opérateurs d'observation et d'évolution -incrémentale (processus) linéaires, même s'il fonctionne parfois dans les cas -"faiblement" non-linéaire. On peut vérifier la linéarité de l'opérateur -d'observation à l'aide de l':ref:`section_ref_algorithm_LinearityTest`. +Il est théoriquement réservé aux cas d'opérateurs d'observation et d'évolution +incrémentale (processus) linéaires, même s'il fonctionne parfois dans les cas +"faiblement" non-linéaire. On peut vérifier la linéarité de l'opérateur +d'observation à l'aide de l':ref:`section_ref_algorithm_LinearityTest`. -En cas de non-linéarité, même peu marquée, on lui préférera +En cas de non-linéarité, même peu marquée, on lui préférera l':ref:`section_ref_algorithm_ExtendedKalmanFilter` ou l':ref:`section_ref_algorithm_UnscentedKalmanFilter`. @@ -54,64 +54,64 @@ Commandes requises et optionnelles .. index:: single: EstimationOf .. index:: single: StoreSupplementaryCalculations -Les commandes requises générales, disponibles dans l'interface en édition, sont +Les commandes requises générales, disponibles dans l'interface en édition, sont les suivantes: Background - *Commande obligatoire*. Elle définit le vecteur d'ébauche ou - d'initialisation, noté précédemment :math:`\mathbf{x}^b`. Sa valeur est - définie comme un objet de type "*Vector*" ou de type "*VectorSerie*". + *Commande obligatoire*. Elle définit le vecteur d'ébauche ou + d'initialisation, noté précédemment :math:`\mathbf{x}^b`. Sa valeur est + définie comme un objet de type "*Vector*" ou de type "*VectorSerie*". BackgroundError - *Commande obligatoire*. Elle définit la matrice de covariance des erreurs - d'ébauche, notée précédemment :math:`\mathbf{B}`. Sa valeur est définie + *Commande obligatoire*. Elle définit la matrice de covariance des erreurs + d'ébauche, notée précédemment :math:`\mathbf{B}`. Sa valeur est définie comme un objet de type "*Matrix*", de type "*ScalarSparseMatrix*", ou de type "*DiagonalSparseMatrix*". Observation - *Commande obligatoire*. Elle définit le vecteur d'observation utilisé en - assimilation de données ou en optimisation, et noté précédemment - :math:`\mathbf{y}^o`. Sa valeur est définie comme un objet de type "*Vector*" + *Commande obligatoire*. Elle définit le vecteur d'observation utilisé en + assimilation de données ou en optimisation, et noté précédemment + :math:`\mathbf{y}^o`. Sa valeur est définie comme un objet de type "*Vector*" ou de type "*VectorSerie*". ObservationError - *Commande obligatoire*. Elle définit la matrice de covariance des erreurs - d'ébauche, notée précédemment :math:`\mathbf{R}`. Sa valeur est définie + *Commande obligatoire*. Elle définit la matrice de covariance des erreurs + d'ébauche, notée précédemment :math:`\mathbf{R}`. Sa valeur est définie comme un objet de type "*Matrix*", de type "*ScalarSparseMatrix*", ou de type "*DiagonalSparseMatrix*". ObservationOperator - *Commande obligatoire*. Elle indique l'opérateur d'observation, noté - précédemment :math:`H`, qui transforme les paramètres d'entrée - :math:`\mathbf{x}` en résultats :math:`\mathbf{y}` qui sont à comparer aux - observations :math:`\mathbf{y}^o`. Sa valeur est définie comme un objet de + *Commande obligatoire*. Elle indique l'opérateur d'observation, noté + précédemment :math:`H`, qui transforme les paramètres d'entrée + :math:`\mathbf{x}` en résultats :math:`\mathbf{y}` qui sont à comparer aux + observations :math:`\mathbf{y}^o`. Sa valeur est définie comme un objet de type "*Function*" ou de type "*Matrix*". Dans le cas du type "*Function*", - différentes formes fonctionnelles peuvent être utilisées, comme décrit dans - la section :ref:`section_ref_operator_requirements`. Si un contrôle - :math:`U` est inclus dans le modèle d'observation, l'opérateur doit être - appliqué à une paire :math:`(X,U)`. - -Les commandes optionnelles générales, disponibles dans l'interface en édition, -sont indiquées dans la :ref:`section_ref_assimilation_keywords`. De plus, les -paramètres de la commande "*AlgorithmParameters*" permettent d'indiquer les -options particulières, décrites ci-après, de l'algorithme. On se reportera à la + différentes formes fonctionnelles peuvent être utilisées, comme décrit dans + la section :ref:`section_ref_operator_requirements`. Si un contrôle + :math:`U` est inclus dans le modèle d'observation, l'opérateur doit être + appliqué à une paire :math:`(X,U)`. + +Les commandes optionnelles générales, disponibles dans l'interface en édition, +sont indiquées dans la :ref:`section_ref_assimilation_keywords`. De plus, les +paramètres de la commande "*AlgorithmParameters*" permettent d'indiquer les +options particulières, décrites ci-après, de l'algorithme. On se reportera à la :ref:`section_ref_options_Algorithm_Parameters` pour le bon usage de cette commande. Les options de l'algorithme sont les suivantes: EstimationOf - Cette clé permet de choisir le type d'estimation à réaliser. Cela peut être - soit une estimation de l'état, avec la valeur "State", ou une estimation de - paramètres, avec la valeur "Parameters". Le choix par défaut est "State". + Cette clé permet de choisir le type d'estimation à réaliser. Cela peut être + soit une estimation de l'état, avec la valeur "State", ou une estimation de + paramètres, avec la valeur "Parameters". Le choix par défaut est "State". Exemple : ``{"EstimationOf":"Parameters"}`` StoreSupplementaryCalculations - Cette liste indique les noms des variables supplémentaires qui peuvent être - disponibles à la fin de l'algorithme. Cela implique potentiellement des - calculs ou du stockage coûteux. La valeur par défaut est une liste vide, - aucune de ces variables n'étant calculée et stockée par défaut. Les noms + Cette liste indique les noms des variables supplémentaires qui peuvent être + disponibles à la fin de l'algorithme. Cela implique potentiellement des + calculs ou du stockage coûteux. La valeur par défaut est une liste vide, + aucune de ces variables n'étant calculée et stockée par défaut. Les noms possibles sont dans la liste suivante : ["APosterioriCorrelations", "APosterioriCovariance", "APosterioriStandardDeviations", "APosterioriVariances", "BMA", "CostFunctionJ", "CostFunctionJb", @@ -119,92 +119,92 @@ Les options de l'algorithme sont les suivantes: Exemple : ``{"StoreSupplementaryCalculations":["BMA", "Innovation"]}`` -Informations et variables disponibles à la fin de l'algorithme +Informations et variables disponibles à la fin de l'algorithme ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -En sortie, après exécution de l'algorithme, on dispose d'informations et de +En sortie, après exécution de l'algorithme, on dispose d'informations et de variables issues du calcul. La description des -:ref:`section_ref_output_variables` indique la manière de les obtenir par la -méthode nommée ``get`` de la variable "*ADD*" du post-processing. Les variables -d'entrée, mises à disposition de l'utilisateur en sortie pour faciliter -l'écriture des procédures de post-processing, sont décrites dans +:ref:`section_ref_output_variables` indique la manière de les obtenir par la +méthode nommée ``get`` de la variable "*ADD*" du post-processing. Les variables +d'entrée, mises à disposition de l'utilisateur en sortie pour faciliter +l'écriture des procédures de post-processing, sont décrites dans l':ref:`subsection_r_o_v_Inventaire`. Les sorties non conditionnelles de l'algorithme sont les suivantes: Analysis - *Liste de vecteurs*. Chaque élément est un état optimal :math:`\mathbf{x}*` + *Liste de vecteurs*. Chaque élément est un état optimal :math:`\mathbf{x}*` en optimisation ou une analyse :math:`\mathbf{x}^a` en assimilation de - données. + données. Exemple : ``Xa = ADD.get("Analysis")[-1]`` Les sorties conditionnelles de l'algorithme sont les suivantes: APosterioriCorrelations - *Liste de matrices*. Chaque élément est une matrice de corrélation des - erreurs *a posteriori* de l'état optimal. + *Liste de matrices*. Chaque élément est une matrice de corrélation des + erreurs *a posteriori* de l'état optimal. Exemple : ``C = ADD.get("APosterioriCorrelations")[-1]`` APosterioriCovariance - *Liste de matrices*. Chaque élément est une matrice :math:`\mathbf{A}*` de - covariances des erreurs *a posteriori* de l'état optimal. + *Liste de matrices*. Chaque élément est une matrice :math:`\mathbf{A}*` de + covariances des erreurs *a posteriori* de l'état optimal. Exemple : ``A = ADD.get("APosterioriCovariance")[-1]`` APosterioriStandardDeviations - *Liste de matrices*. Chaque élément est une matrice d'écart-types des - erreurs *a posteriori* de l'état optimal. + *Liste de matrices*. Chaque élément est une matrice d'écart-types des + erreurs *a posteriori* de l'état optimal. Exemple : ``E = ADD.get("APosterioriStandardDeviations")[-1]`` APosterioriVariances - *Liste de matrices*. Chaque élément est une matrice de variances des erreurs - *a posteriori* de l'état optimal. + *Liste de matrices*. Chaque élément est une matrice de variances des erreurs + *a posteriori* de l'état optimal. Exemple : ``V = ADD.get("APosterioriVariances")[-1]`` BMA - *Liste de vecteurs*. Chaque élément est un vecteur d'écart entre - l'ébauche et l'état optimal. + *Liste de vecteurs*. Chaque élément est un vecteur d'écart entre + l'ébauche et l'état optimal. Exemple : ``bma = ADD.get("BMA")[-1]`` CostFunctionJ - *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart + *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart :math:`J`. Exemple : ``J = ADD.get("CostFunctionJ")[:]`` CostFunctionJb - *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart - :math:`J^b`, c'est-à-dire de la partie écart à l'ébauche. + *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart + :math:`J^b`, c'est-à-dire de la partie écart à l'ébauche. Exemple : ``Jb = ADD.get("CostFunctionJb")[:]`` CostFunctionJo - *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart - :math:`J^o`, c'est-à-dire de la partie écart à l'observation. + *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart + :math:`J^o`, c'est-à-dire de la partie écart à l'observation. Exemple : ``Jo = ADD.get("CostFunctionJo")[:]`` CurrentState - *Liste de vecteurs*. Chaque élément est un vecteur d'état courant utilisé - au cours du déroulement de l'algorithme d'optimisation. + *Liste de vecteurs*. Chaque élément est un vecteur d'état courant utilisé + au cours du déroulement de l'algorithme d'optimisation. Exemple : ``Xs = ADD.get("CurrentState")[:]`` Innovation - *Liste de vecteurs*. Chaque élément est un vecteur d'innovation, qui est - en statique l'écart de l'optimum à l'ébauche, et en dynamique l'incrément - d'évolution. + *Liste de vecteurs*. Chaque élément est un vecteur d'innovation, qui est + en statique l'écart de l'optimum à l'ébauche, et en dynamique l'incrément + d'évolution. Exemple : ``d = ADD.get("Innovation")[-1]`` Voir aussi ++++++++++ -Références vers d'autres sections : +Références vers d'autres sections : - :ref:`section_ref_algorithm_ExtendedKalmanFilter` - :ref:`section_ref_algorithm_UnscentedKalmanFilter` diff --git a/doc/fr/ref_algorithm_LinearLeastSquares.rst b/doc/fr/ref_algorithm_LinearLeastSquares.rst index d9f6733..795148e 100644 --- a/doc/fr/ref_algorithm_LinearLeastSquares.rst +++ b/doc/fr/ref_algorithm_LinearLeastSquares.rst @@ -30,17 +30,17 @@ Algorithme de calcul "*LinearLeastSquares*" Description +++++++++++ -Cet algorithme réalise une estimation linéaire de type "Moindres Carrés" -pondérés. Il est similaire à l':ref:`section_ref_algorithm_Blue` -amputé de sa partie ébauche. +Cet algorithme réalise une estimation linéaire de type "Moindres Carrés" +pondérés. Il est similaire à l':ref:`section_ref_algorithm_Blue` +amputé de sa partie ébauche. Cet algorithme est toujours le plus rapide de l'ensemble des algorithmes -d'optimisation d'ADAO. Il est théoriquement réservé aux cas d'opérateurs -d'observation linéaires, même s'il fonctionne parfois dans les cas "faiblement" -non-linéaire. On peut vérifier la linéarité de l'opérateur d'observation à +d'optimisation d'ADAO. Il est théoriquement réservé aux cas d'opérateurs +d'observation linéaires, même s'il fonctionne parfois dans les cas "faiblement" +non-linéaire. On peut vérifier la linéarité de l'opérateur d'observation à l'aide de l':ref:`section_ref_algorithm_LinearityTest`. -Dans tous les cas, il est recommandé de lui préférer au minimum +Dans tous les cas, il est recommandé de lui préférer au minimum l':ref:`section_ref_algorithm_Blue`, voire l':ref:`section_ref_algorithm_ExtendedBlue` ou l':ref:`section_ref_algorithm_3DVAR`. @@ -54,46 +54,46 @@ Commandes requises et optionnelles .. index:: single: ObservationOperator .. index:: single: StoreSupplementaryCalculations -Les commandes requises générales, disponibles dans l'interface en édition, sont +Les commandes requises générales, disponibles dans l'interface en édition, sont les suivantes: Observation - *Commande obligatoire*. Elle définit le vecteur d'observation utilisé en - assimilation de données ou en optimisation, et noté précédemment - :math:`\mathbf{y}^o`. Sa valeur est définie comme un objet de type "*Vector*" + *Commande obligatoire*. Elle définit le vecteur d'observation utilisé en + assimilation de données ou en optimisation, et noté précédemment + :math:`\mathbf{y}^o`. Sa valeur est définie comme un objet de type "*Vector*" ou de type "*VectorSerie*". ObservationError - *Commande obligatoire*. Elle définit la matrice de covariance des erreurs - d'ébauche, notée précédemment :math:`\mathbf{R}`. Sa valeur est définie + *Commande obligatoire*. Elle définit la matrice de covariance des erreurs + d'ébauche, notée précédemment :math:`\mathbf{R}`. Sa valeur est définie comme un objet de type "*Matrix*", de type "*ScalarSparseMatrix*", ou de type "*DiagonalSparseMatrix*". ObservationOperator - *Commande obligatoire*. Elle indique l'opérateur d'observation, noté - précédemment :math:`H`, qui transforme les paramètres d'entrée - :math:`\mathbf{x}` en résultats :math:`\mathbf{y}` qui sont à comparer aux - observations :math:`\mathbf{y}^o`. Sa valeur est définie comme un objet de + *Commande obligatoire*. Elle indique l'opérateur d'observation, noté + précédemment :math:`H`, qui transforme les paramètres d'entrée + :math:`\mathbf{x}` en résultats :math:`\mathbf{y}` qui sont à comparer aux + observations :math:`\mathbf{y}^o`. Sa valeur est définie comme un objet de type "*Function*" ou de type "*Matrix*". Dans le cas du type "*Function*", - différentes formes fonctionnelles peuvent être utilisées, comme décrit dans - la section :ref:`section_ref_operator_requirements`. Si un contrôle - :math:`U` est inclus dans le modèle d'observation, l'opérateur doit être - appliqué à une paire :math:`(X,U)`. - -Les commandes optionnelles générales, disponibles dans l'interface en édition, -sont indiquées dans la :ref:`section_ref_assimilation_keywords`. De plus, les -paramètres de la commande "*AlgorithmParameters*" permettent d'indiquer les -options particulières, décrites ci-après, de l'algorithme. On se reportera à la + différentes formes fonctionnelles peuvent être utilisées, comme décrit dans + la section :ref:`section_ref_operator_requirements`. Si un contrôle + :math:`U` est inclus dans le modèle d'observation, l'opérateur doit être + appliqué à une paire :math:`(X,U)`. + +Les commandes optionnelles générales, disponibles dans l'interface en édition, +sont indiquées dans la :ref:`section_ref_assimilation_keywords`. De plus, les +paramètres de la commande "*AlgorithmParameters*" permettent d'indiquer les +options particulières, décrites ci-après, de l'algorithme. On se reportera à la :ref:`section_ref_options_Algorithm_Parameters` pour le bon usage de cette commande. Les options de l'algorithme sont les suivantes: StoreSupplementaryCalculations - Cette liste indique les noms des variables supplémentaires qui peuvent être - disponibles à la fin de l'algorithme. Cela implique potentiellement des - calculs ou du stockage coûteux. La valeur par défaut est une liste vide, - aucune de ces variables n'étant calculée et stockée par défaut. Les noms + Cette liste indique les noms des variables supplémentaires qui peuvent être + disponibles à la fin de l'algorithme. Cela implique potentiellement des + calculs ou du stockage coûteux. La valeur par défaut est une liste vide, + aucune de ces variables n'étant calculée et stockée par défaut. Les noms possibles sont dans la liste suivante : ["OMA", "CurrentState", "CostFunctionJ", "CostFunctionJb", "CostFunctionJo", "SimulatedObservationAtCurrentState", "SimulatedObservationAtOptimum"]. @@ -104,66 +104,66 @@ Les options de l'algorithme sont les suivantes: Comme les commandes *"Background"* et *"BackgroundError"* sont requises pour TOUS les algorithmes de calcul dans l'interface, vous devez fournir une - valeur, malgré le fait que ces commandes ne sont pas requises pour - cet algorithme, et ne seront pas utilisées. La manière la plus simple est + valeur, malgré le fait que ces commandes ne sont pas requises pour + cet algorithme, et ne seront pas utilisées. La manière la plus simple est de donner "1" comme un STRING pour les deux. -Informations et variables disponibles à la fin de l'algorithme +Informations et variables disponibles à la fin de l'algorithme ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -En sortie, après exécution de l'algorithme, on dispose d'informations et de +En sortie, après exécution de l'algorithme, on dispose d'informations et de variables issues du calcul. La description des -:ref:`section_ref_output_variables` indique la manière de les obtenir par la -méthode nommée ``get`` de la variable "*ADD*" du post-processing. Les variables -d'entrée, mises à disposition de l'utilisateur en sortie pour faciliter -l'écriture des procédures de post-processing, sont décrites dans +:ref:`section_ref_output_variables` indique la manière de les obtenir par la +méthode nommée ``get`` de la variable "*ADD*" du post-processing. Les variables +d'entrée, mises à disposition de l'utilisateur en sortie pour faciliter +l'écriture des procédures de post-processing, sont décrites dans l':ref:`subsection_r_o_v_Inventaire`. Les sorties non conditionnelles de l'algorithme sont les suivantes: Analysis - *Liste de vecteurs*. Chaque élément est un état optimal :math:`\mathbf{x}*` + *Liste de vecteurs*. Chaque élément est un état optimal :math:`\mathbf{x}*` en optimisation ou une analyse :math:`\mathbf{x}^a` en assimilation de - données. + données. Exemple : ``Xa = ADD.get("Analysis")[-1]`` CostFunctionJ - *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart + *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart :math:`J`. Exemple : ``J = ADD.get("CostFunctionJ")[:]`` CostFunctionJb - *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart - :math:`J^b`, c'est-à-dire de la partie écart à l'ébauche. + *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart + :math:`J^b`, c'est-à-dire de la partie écart à l'ébauche. Exemple : ``Jb = ADD.get("CostFunctionJb")[:]`` CostFunctionJo - *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart - :math:`J^o`, c'est-à-dire de la partie écart à l'observation. + *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart + :math:`J^o`, c'est-à-dire de la partie écart à l'observation. Exemple : ``Jo = ADD.get("CostFunctionJo")[:]`` Les sorties conditionnelles de l'algorithme sont les suivantes: OMA - *Liste de vecteurs*. Chaque élément est un vecteur d'écart entre - l'observation et l'état optimal dans l'espace des observations. + *Liste de vecteurs*. Chaque élément est un vecteur d'écart entre + l'observation et l'état optimal dans l'espace des observations. Exemple : ``oma = ADD.get("OMA")[-1]`` SimulatedObservationAtOptimum - *Liste de vecteurs*. Chaque élément est un vecteur d'observation simulé à - partir de l'analyse ou de l'état optimal :math:`\mathbf{x}^a`. + *Liste de vecteurs*. Chaque élément est un vecteur d'observation simulé à + partir de l'analyse ou de l'état optimal :math:`\mathbf{x}^a`. Exemple : ``hxa = ADD.get("SimulatedObservationAtOptimum")[-1]`` Voir aussi ++++++++++ -Références vers d'autres sections : +Références vers d'autres sections : - :ref:`section_ref_algorithm_Blue` - :ref:`section_ref_algorithm_ExtendedBlue` - :ref:`section_ref_algorithm_3DVAR` diff --git a/doc/fr/ref_algorithm_LinearityTest.rst b/doc/fr/ref_algorithm_LinearityTest.rst index 587c797..df03fa5 100644 --- a/doc/fr/ref_algorithm_LinearityTest.rst +++ b/doc/fr/ref_algorithm_LinearityTest.rst @@ -24,89 +24,89 @@ .. index:: single: LinearityTest .. _section_ref_algorithm_LinearityTest: -Algorithme de vérification "*LinearityTest*" +Algorithme de vérification "*LinearityTest*" -------------------------------------------- Description +++++++++++ -Cet algorithme permet de vérifier la qualité de linéarité de l'opérateur, en -calculant un résidu dont les propriétés théoriques sont connues. Plusieurs -formules de résidu sont utilisables. +Cet algorithme permet de vérifier la qualité de linéarité de l'opérateur, en +calculant un résidu dont les propriétés théoriques sont connues. Plusieurs +formules de résidu sont utilisables. Dans tous les cas, on prend :math:`\mathbf{dx}_0=Normal(0,\mathbf{x})` et :math:`\mathbf{dx}=\alpha*\mathbf{dx}_0`. :math:`F` est le code de calcul. -Résidu "CenteredDL" +Résidu "CenteredDL" ******************* -On observe le résidu suivant, provenant de la différence centrée des valeurs de -:math:`F` au point nominal et aux points perturbés, normalisée par la valeur au +On observe le résidu suivant, provenant de la différence centrée des valeurs de +:math:`F` au point nominal et aux points perturbés, normalisée par la valeur au point nominal : .. math:: R(\alpha) = \frac{|| F(\mathbf{x}+\alpha*\mathbf{dx}) + F(\mathbf{x}-\alpha*\mathbf{dx}) - 2*F(\mathbf{x}) ||}{|| F(\mathbf{x}) ||} -S'il reste constamment très faible par rapport à 1, l'hypothèse de linéarité -de :math:`F` est vérifiée. +S'il reste constamment très faible par rapport à 1, l'hypothèse de linéarité +de :math:`F` est vérifiée. -Si le résidu varie, ou qu'il est de l'ordre de 1 ou plus, et qu'il n'est -faible qu'à partir d'un certain ordre d'incrément, l'hypothèse de linéarité -de :math:`F` n'est pas vérifiée. +Si le résidu varie, ou qu'il est de l'ordre de 1 ou plus, et qu'il n'est +faible qu'à partir d'un certain ordre d'incrément, l'hypothèse de linéarité +de :math:`F` n'est pas vérifiée. -Si le résidu décroît et que la décroissance se fait en :math:`\alpha^2` selon -:math:`\alpha`, cela signifie que le gradient est bien calculé jusqu'au niveau -d'arrêt de la décroissance quadratique. +Si le résidu décroît et que la décroissance se fait en :math:`\alpha^2` selon +:math:`\alpha`, cela signifie que le gradient est bien calculé jusqu'au niveau +d'arrêt de la décroissance quadratique. -Résidu "Taylor" +Résidu "Taylor" *************** -On observe le résidu issu du développement de Taylor de la fonction :math:`F`, -normalisée par la valeur au point nominal : +On observe le résidu issu du développement de Taylor de la fonction :math:`F`, +normalisée par la valeur au point nominal : .. math:: R(\alpha) = \frac{|| F(\mathbf{x}+\alpha*\mathbf{dx}) - F(\mathbf{x}) - \alpha * \nabla_xF(\mathbf{dx}) ||}{|| F(\mathbf{x}) ||} -S'il reste constamment trés faible par rapport à 1, l'hypothèse de linéarité -de :math:`F` est vérifiée. +S'il reste constamment trés faible par rapport à 1, l'hypothèse de linéarité +de :math:`F` est vérifiée. -Si le résidu varie, ou qu'il est de l'ordre de 1 ou plus, et qu'il n'est -faible qu'à partir d'un certain ordre d'incrément, l'hypothèse de linéarité -de :math:`F` n'est pas vérifiée. +Si le résidu varie, ou qu'il est de l'ordre de 1 ou plus, et qu'il n'est +faible qu'à partir d'un certain ordre d'incrément, l'hypothèse de linéarité +de :math:`F` n'est pas vérifiée. -Si le résidu décroît et que la décroissance se fait en :math:`\alpha^2` selon -:math:`\alpha`, cela signifie que le gradient est bien calculé jusqu'au niveau -d'arrêt de la décroissance quadratique. +Si le résidu décroît et que la décroissance se fait en :math:`\alpha^2` selon +:math:`\alpha`, cela signifie que le gradient est bien calculé jusqu'au niveau +d'arrêt de la décroissance quadratique. -Résidu "NominalTaylor" +Résidu "NominalTaylor" ********************** -On observe le résidu obtenu à partir de deux approximations d'ordre 1 de -:math:`F(\mathbf{x})`, normalisées par la valeur au point nominal : +On observe le résidu obtenu à partir de deux approximations d'ordre 1 de +:math:`F(\mathbf{x})`, normalisées par la valeur au point nominal : .. math:: R(\alpha) = \max(|| F(\mathbf{x}+\alpha*\mathbf{dx}) - \alpha * F(\mathbf{dx}) || / || F(\mathbf{x}) ||,|| F(\mathbf{x}-\alpha*\mathbf{dx}) + \alpha * F(\mathbf{dx}) || / || F(\mathbf{x}) ||) -S'il reste constamment égal à 1 à moins de 2 ou 3 pourcents prés (c'est-à-dire -que :math:`|R-1|` reste égal à 2 ou 3 pourcents), c'est que l'hypothèse de -linéarité de :math:`F` est vérifiée. +S'il reste constamment égal à 1 à moins de 2 ou 3 pourcents prés (c'est-à-dire +que :math:`|R-1|` reste égal à 2 ou 3 pourcents), c'est que l'hypothèse de +linéarité de :math:`F` est vérifiée. -S'il est égal à 1 sur une partie seulement du domaine de variation de -l'incrément :math:`\alpha`, c'est sur sous-domaine que l'hypothèse de linéarité -de :math:`F` est vérifiée. +S'il est égal à 1 sur une partie seulement du domaine de variation de +l'incrément :math:`\alpha`, c'est sur sous-domaine que l'hypothèse de linéarité +de :math:`F` est vérifiée. -Résidu "NominalTaylorRMS" +Résidu "NominalTaylorRMS" ************************* -On observe le résidu obtenu à partir de deux approximations d'ordre 1 de -:math:`F(\mathbf{x})`, normalisées par la valeur au point nominal, dont on -calcule l'écart quadratique (RMS) avec la valeur au point nominal : +On observe le résidu obtenu à partir de deux approximations d'ordre 1 de +:math:`F(\mathbf{x})`, normalisées par la valeur au point nominal, dont on +calcule l'écart quadratique (RMS) avec la valeur au point nominal : .. math:: R(\alpha) = \max(RMS( F(\mathbf{x}), F(\mathbf{x}+\alpha*\mathbf{dx}) - \alpha * F(\mathbf{dx}) ) / || F(\mathbf{x}) ||,RMS( F(\mathbf{x}), F(\mathbf{x}-\alpha*\mathbf{dx}) + \alpha * F(\mathbf{dx}) ) / || F(\mathbf{x}) ||) -S'il reste constamment égal à 0 à moins de 1 ou 2 pourcents prés, c'est -que l'hypothèse de linéarité de F est vérifiée. +S'il reste constamment égal à 0 à moins de 1 ou 2 pourcents prés, c'est +que l'hypothèse de linéarité de F est vérifiée. -S'il est égal à 0 sur une partie seulement du domaine de variation de -l'incrément :math:`\alpha`, c'est sur cette partie que l'hypothèse de linéarité -de F est vérifiée. +S'il est égal à 0 sur une partie seulement du domaine de variation de +l'incrément :math:`\alpha`, c'est sur cette partie que l'hypothèse de linéarité +de F est vérifiée. Commandes requises et optionnelles ++++++++++++++++++++++++++++++++++ @@ -121,130 +121,130 @@ Commandes requises et optionnelles .. index:: single: SetSeed .. index:: single: StoreSupplementaryCalculations -Les commandes requises générales, disponibles dans l'interface en édition, sont +Les commandes requises générales, disponibles dans l'interface en édition, sont les suivantes: CheckingPoint - *Commande obligatoire*. Elle définit le vecteur utilisé comme l'état autour - duquel réaliser le test requis, noté :math:`\mathbf{x}` et similaire à - l'ébauche :math:`\mathbf{x}^b`. Sa valeur est définie comme un objet de type + *Commande obligatoire*. Elle définit le vecteur utilisé comme l'état autour + duquel réaliser le test requis, noté :math:`\mathbf{x}` et similaire à + l'ébauche :math:`\mathbf{x}^b`. Sa valeur est définie comme un objet de type "*Vector*". ObservationOperator - *Commande obligatoire*. Elle indique l'opérateur d'observation, notée - précédemment :math:`H`, qui transforme les paramètres d'entrée - :math:`\mathbf{x}` en résultats :math:`\mathbf{y}` qui sont à comparer aux - observations :math:`\mathbf{y}^o`. Sa valeur est définie comme un objet de - type "*Function*". Différentes formes fonctionnelles peuvent être - utilisées, comme décrit dans la section - :ref:`section_ref_operator_requirements`. Si un contrôle :math:`U` est - inclus dans le modèle d'observation, l'opérateur doit être appliqué à une + *Commande obligatoire*. Elle indique l'opérateur d'observation, notée + précédemment :math:`H`, qui transforme les paramètres d'entrée + :math:`\mathbf{x}` en résultats :math:`\mathbf{y}` qui sont à comparer aux + observations :math:`\mathbf{y}^o`. Sa valeur est définie comme un objet de + type "*Function*". Différentes formes fonctionnelles peuvent être + utilisées, comme décrit dans la section + :ref:`section_ref_operator_requirements`. Si un contrôle :math:`U` est + inclus dans le modèle d'observation, l'opérateur doit être appliqué à une paire :math:`(X,U)`. -Les commandes optionnelles générales, disponibles dans l'interface en édition, -sont indiquées dans la :ref:`section_ref_checking_keywords`. De plus, les -paramètres de la commande "*AlgorithmParameters*" permettent d'indiquer les -options particulières, décrites ci-après, de l'algorithme. On se reportera à la +Les commandes optionnelles générales, disponibles dans l'interface en édition, +sont indiquées dans la :ref:`section_ref_checking_keywords`. De plus, les +paramètres de la commande "*AlgorithmParameters*" permettent d'indiquer les +options particulières, décrites ci-après, de l'algorithme. On se reportera à la :ref:`section_ref_options_Algorithm_Parameters` pour le bon usage de cette commande. Les options de l'algorithme sont les suivantes: AmplitudeOfInitialDirection - Cette clé indique la mise à l'échelle de la perturbation initiale construite - comme un vecteur utilisé pour la dérivée directionnelle autour du point - nominal de vérification. La valeur par défaut est de 1, ce qui signifie pas - de mise à l'échelle. + Cette clé indique la mise à l'échelle de la perturbation initiale construite + comme un vecteur utilisé pour la dérivée directionnelle autour du point + nominal de vérification. La valeur par défaut est de 1, ce qui signifie pas + de mise à l'échelle. Exemple : ``{"AmplitudeOfInitialDirection":0.5}`` EpsilonMinimumExponent - Cette clé indique la valeur de l'exposant minimal du coefficient en - puissance de 10 qui doit être utilisé pour faire décroître le multiplicateur - de l'incrément. La valeur par défaut est de -8, et elle doit être entre 0 et - -20. Par exemple, la valeur par défaut conduit à calculer le résidu de la - formule avec un incrément fixe multiplié par 1.e0 jusqu'à 1.e-8. + Cette clé indique la valeur de l'exposant minimal du coefficient en + puissance de 10 qui doit être utilisé pour faire décroître le multiplicateur + de l'incrément. La valeur par défaut est de -8, et elle doit être entre 0 et + -20. Par exemple, la valeur par défaut conduit à calculer le résidu de la + formule avec un incrément fixe multiplié par 1.e0 jusqu'à 1.e-8. Exemple : ``{"EpsilonMinimumExponent":-12}`` InitialDirection - Cette clé indique la direction vectorielle utilisée pour la dérivée - directionnelle autour du point nominal de vérification. Cela doit être un - vecteur. Si elle n'est pas spécifiée, la direction par défaut est une - perturbation par défaut autour de zéro de la même taille vectorielle que le - point de vérification. + Cette clé indique la direction vectorielle utilisée pour la dérivée + directionnelle autour du point nominal de vérification. Cela doit être un + vecteur. Si elle n'est pas spécifiée, la direction par défaut est une + perturbation par défaut autour de zéro de la même taille vectorielle que le + point de vérification. Exemple : ``{"InitialDirection":[0.1,0.1,100.,3}`` ResiduFormula - Cette clé indique la formule de résidu qui doit être utilisée pour le test. - Le choix par défaut est "CenteredDL", et les choix possibles sont - "CenteredDL" (résidu de la différence entre la fonction au point nominal et - ses valeurs avec des incréments positif et négatif, qui doit rester très - faible), "Taylor" (résidu du développement de Taylor de l'opérateur - normalisé par sa valeur nominal, qui doit rester très faible), - "NominalTaylor" (résidu de l'approximation à l'ordre 1 de l'opérateur, - normalisé au point nominal, qui doit rester proche de 1), et - "NominalTaylorRMS" (résidu de l'approximation à l'ordre 1 de l'opérateur, - normalisé par l'écart quadratique moyen (RMS) au point nominal, qui doit + Cette clé indique la formule de résidu qui doit être utilisée pour le test. + Le choix par défaut est "CenteredDL", et les choix possibles sont + "CenteredDL" (résidu de la différence entre la fonction au point nominal et + ses valeurs avec des incréments positif et négatif, qui doit rester très + faible), "Taylor" (résidu du développement de Taylor de l'opérateur + normalisé par sa valeur nominal, qui doit rester très faible), + "NominalTaylor" (résidu de l'approximation à l'ordre 1 de l'opérateur, + normalisé au point nominal, qui doit rester proche de 1), et + "NominalTaylorRMS" (résidu de l'approximation à l'ordre 1 de l'opérateur, + normalisé par l'écart quadratique moyen (RMS) au point nominal, qui doit rester proche de 0). Exemple : ``{"ResiduFormula":"CenteredDL"}`` SetSeed - Cette clé permet de donner un nombre entier pour fixer la graine du - générateur aléatoire utilisé pour générer l'ensemble. Un valeur pratique est - par exemple 1000. Par défaut, la graine est laissée non initialisée, et elle - utilise ainsi l'initialisation par défaut de l'ordinateur. + Cette clé permet de donner un nombre entier pour fixer la graine du + générateur aléatoire utilisé pour générer l'ensemble. Un valeur pratique est + par exemple 1000. Par défaut, la graine est laissée non initialisée, et elle + utilise ainsi l'initialisation par défaut de l'ordinateur. Exemple : ``{"SetSeed":1000}`` StoreSupplementaryCalculations - Cette liste indique les noms des variables supplémentaires qui peuvent être - disponibles à la fin de l'algorithme. Cela implique potentiellement des - calculs ou du stockage coûteux. La valeur par défaut est une liste vide, - aucune de ces variables n'étant calculée et stockée par défaut. Les noms + Cette liste indique les noms des variables supplémentaires qui peuvent être + disponibles à la fin de l'algorithme. Cela implique potentiellement des + calculs ou du stockage coûteux. La valeur par défaut est une liste vide, + aucune de ces variables n'étant calculée et stockée par défaut. Les noms possibles sont dans la liste suivante : ["CurrentState", "Residu", "SimulatedObservationAtCurrentState"]. Exemple : ``{"StoreSupplementaryCalculations":["CurrentState"]}`` -Informations et variables disponibles à la fin de l'algorithme +Informations et variables disponibles à la fin de l'algorithme ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -En sortie, après exécution de l'algorithme, on dispose d'informations et de +En sortie, après exécution de l'algorithme, on dispose d'informations et de variables issues du calcul. La description des -:ref:`section_ref_output_variables` indique la manière de les obtenir par la -méthode nommée ``get`` de la variable "*ADD*" du post-processing. Les variables -d'entrée, mises à disposition de l'utilisateur en sortie pour faciliter -l'écriture des procédures de post-processing, sont décrites dans +:ref:`section_ref_output_variables` indique la manière de les obtenir par la +méthode nommée ``get`` de la variable "*ADD*" du post-processing. Les variables +d'entrée, mises à disposition de l'utilisateur en sortie pour faciliter +l'écriture des procédures de post-processing, sont décrites dans l':ref:`subsection_r_o_v_Inventaire`. Les sorties non conditionnelles de l'algorithme sont les suivantes: Residu - *Liste de valeurs*. Chaque élément est la valeur du résidu particulier - vérifié lors d'un algorithme de vérification, selon l'ordre des tests - effectués. + *Liste de valeurs*. Chaque élément est la valeur du résidu particulier + vérifié lors d'un algorithme de vérification, selon l'ordre des tests + effectués. Exemple : ``r = ADD.get("Residu")[:]`` Les sorties conditionnelles de l'algorithme sont les suivantes: CurrentState - *Liste de vecteurs*. Chaque élément est un vecteur d'état courant utilisé - au cours du déroulement de l'algorithme d'optimisation. + *Liste de vecteurs*. Chaque élément est un vecteur d'état courant utilisé + au cours du déroulement de l'algorithme d'optimisation. Exemple : ``Xs = ADD.get("CurrentState")[:]`` SimulatedObservationAtCurrentState - *Liste de vecteurs*. Chaque élément est un vecteur d'observation simulé à - partir de l'état courant, c'est-à-dire dans l'espace des observations. + *Liste de vecteurs*. Chaque élément est un vecteur d'observation simulé à + partir de l'état courant, c'est-à-dire dans l'espace des observations. Exemple : ``hxs = ADD.get("SimulatedObservationAtCurrentState")[-1]`` Voir aussi ++++++++++ -Références vers d'autres sections : +Références vers d'autres sections : - :ref:`section_ref_algorithm_FunctionTest` diff --git a/doc/fr/ref_algorithm_NonLinearLeastSquares.rst b/doc/fr/ref_algorithm_NonLinearLeastSquares.rst index b59ac57..72c7f93 100644 --- a/doc/fr/ref_algorithm_NonLinearLeastSquares.rst +++ b/doc/fr/ref_algorithm_NonLinearLeastSquares.rst @@ -30,17 +30,17 @@ Algorithme de calcul "*NonLinearLeastSquares*" Description +++++++++++ -Cet algorithme réalise une estimation d'état par minimisation variationnelle de -la fonctionnelle :math:`J` d'écart classique de "Moindres Carrés" pondérés: +Cet algorithme réalise une estimation d'état par minimisation variationnelle de +la fonctionnelle :math:`J` d'écart classique de "Moindres Carrés" pondérés: .. math:: J(\mathbf{x})=(\mathbf{y}^o-\mathbf{H}.\mathbf{x})^T.\mathbf{R}^{-1}.(\mathbf{y}^o-\mathbf{H}.\mathbf{x}) -Il est similaire à l':ref:`section_ref_algorithm_3DVAR` privé de sa partie -ébauche. L'ébauche, requise dans l'interface, ne sert que de point initial pour +Il est similaire à l':ref:`section_ref_algorithm_3DVAR` privé de sa partie +ébauche. L'ébauche, requise dans l'interface, ne sert que de point initial pour la minimisation variationnelle. -Dans tous les cas, il est recommandé de lui préférer -l':ref:`section_ref_algorithm_3DVAR` pour sa stabilité comme pour son +Dans tous les cas, il est recommandé de lui préférer +l':ref:`section_ref_algorithm_3DVAR` pour sa stabilité comme pour son comportement lors de l'optimisation. Commandes requises et optionnelles @@ -59,109 +59,109 @@ Commandes requises et optionnelles .. index:: single: GradientNormTolerance .. index:: single: StoreSupplementaryCalculations -Les commandes requises générales, disponibles dans l'interface en édition, sont +Les commandes requises générales, disponibles dans l'interface en édition, sont les suivantes: Background - *Commande obligatoire*. Elle définit le vecteur d'ébauche ou - d'initialisation, noté précédemment :math:`\mathbf{x}^b`. Sa valeur est - définie comme un objet de type "*Vector*" ou de type "*VectorSerie*". + *Commande obligatoire*. Elle définit le vecteur d'ébauche ou + d'initialisation, noté précédemment :math:`\mathbf{x}^b`. Sa valeur est + définie comme un objet de type "*Vector*" ou de type "*VectorSerie*". Observation - *Commande obligatoire*. Elle définit le vecteur d'observation utilisé en - assimilation de données ou en optimisation, et noté précédemment - :math:`\mathbf{y}^o`. Sa valeur est définie comme un objet de type "*Vector*" + *Commande obligatoire*. Elle définit le vecteur d'observation utilisé en + assimilation de données ou en optimisation, et noté précédemment + :math:`\mathbf{y}^o`. Sa valeur est définie comme un objet de type "*Vector*" ou de type "*VectorSerie*". ObservationError - *Commande obligatoire*. Elle définit la matrice de covariance des erreurs - d'ébauche, notée précédemment :math:`\mathbf{R}`. Sa valeur est définie + *Commande obligatoire*. Elle définit la matrice de covariance des erreurs + d'ébauche, notée précédemment :math:`\mathbf{R}`. Sa valeur est définie comme un objet de type "*Matrix*", de type "*ScalarSparseMatrix*", ou de type "*DiagonalSparseMatrix*". ObservationOperator - *Commande obligatoire*. Elle indique l'opérateur d'observation, noté - précédemment :math:`H`, qui transforme les paramètres d'entrée - :math:`\mathbf{x}` en résultats :math:`\mathbf{y}` qui sont à comparer aux - observations :math:`\mathbf{y}^o`. Sa valeur est définie comme un objet de + *Commande obligatoire*. Elle indique l'opérateur d'observation, noté + précédemment :math:`H`, qui transforme les paramètres d'entrée + :math:`\mathbf{x}` en résultats :math:`\mathbf{y}` qui sont à comparer aux + observations :math:`\mathbf{y}^o`. Sa valeur est définie comme un objet de type "*Function*" ou de type "*Matrix*". Dans le cas du type "*Function*", - différentes formes fonctionnelles peuvent être utilisées, comme décrit dans - la section :ref:`section_ref_operator_requirements`. Si un contrôle - :math:`U` est inclus dans le modèle d'observation, l'opérateur doit être - appliqué à une paire :math:`(X,U)`. - -Les commandes optionnelles générales, disponibles dans l'interface en édition, -sont indiquées dans la :ref:`section_ref_assimilation_keywords`. De plus, les -paramètres de la commande "*AlgorithmParameters*" permettent d'indiquer les -options particulières, décrites ci-après, de l'algorithme. On se reportera à la + différentes formes fonctionnelles peuvent être utilisées, comme décrit dans + la section :ref:`section_ref_operator_requirements`. Si un contrôle + :math:`U` est inclus dans le modèle d'observation, l'opérateur doit être + appliqué à une paire :math:`(X,U)`. + +Les commandes optionnelles générales, disponibles dans l'interface en édition, +sont indiquées dans la :ref:`section_ref_assimilation_keywords`. De plus, les +paramètres de la commande "*AlgorithmParameters*" permettent d'indiquer les +options particulières, décrites ci-après, de l'algorithme. On se reportera à la :ref:`section_ref_options_Algorithm_Parameters` pour le bon usage de cette commande. Les options de l'algorithme sont les suivantes: Minimizer - Cette clé permet de changer le minimiseur pour l'optimiseur. Le choix par - défaut est "LBFGSB", et les choix possibles sont "LBFGSB" (minimisation non - linéaire sous contraintes, voir [Byrd95]_, [Morales11]_ et [Zhu97]_), "TNC" - (minimisation non linéaire sous contraintes), "CG" (minimisation non - linéaire sans contraintes), "BFGS" (minimisation non linéaire sans - contraintes), "NCG" (minimisation de type gradient conjugué de Newton), "LM" - (minimisation non linéaire de type Levenberg-Marquard). Il est fortement - conseillé de conserver la valeur par défaut. + Cette clé permet de changer le minimiseur pour l'optimiseur. Le choix par + défaut est "LBFGSB", et les choix possibles sont "LBFGSB" (minimisation non + linéaire sous contraintes, voir [Byrd95]_, [Morales11]_ et [Zhu97]_), "TNC" + (minimisation non linéaire sous contraintes), "CG" (minimisation non + linéaire sans contraintes), "BFGS" (minimisation non linéaire sans + contraintes), "NCG" (minimisation de type gradient conjugué de Newton), "LM" + (minimisation non linéaire de type Levenberg-Marquard). Il est fortement + conseillé de conserver la valeur par défaut. Exemple : ``{"Minimizer":"LBFGSB"}`` Bounds - Cette clé permet de définir des bornes supérieure et inférieure pour - chaque variable d'état optimisée. Les bornes doivent être données par une - liste de liste de paires de bornes inférieure/supérieure pour chaque + Cette clé permet de définir des bornes supérieure et inférieure pour + chaque variable d'état optimisée. Les bornes doivent être données par une + liste de liste de paires de bornes inférieure/supérieure pour chaque variable, avec une valeur ``None`` chaque fois qu'il n'y a pas de borne. Les - bornes peuvent toujours être spécifiées, mais seuls les optimiseurs sous + bornes peuvent toujours être spécifiées, mais seuls les optimiseurs sous contraintes les prennent en compte. Exemple : ``{"Bounds":[[2.,5.],[1.e-2,10.],[-30.,None],[None,None]]}`` MaximumNumberOfSteps - Cette clé indique le nombre maximum d'itérations possibles en optimisation - itérative. Le défaut est 15000, qui est très similaire à une absence de - limite sur les itérations. Il est ainsi recommandé d'adapter ce paramètre - aux besoins pour des problèmes réels. Pour certains optimiseurs, le nombre - de pas effectif d'arrêt peut être légèrement différent de la limite à cause - d'exigences de contrôle interne de l'algorithme. + Cette clé indique le nombre maximum d'itérations possibles en optimisation + itérative. Le défaut est 15000, qui est très similaire à une absence de + limite sur les itérations. Il est ainsi recommandé d'adapter ce paramètre + aux besoins pour des problèmes réels. Pour certains optimiseurs, le nombre + de pas effectif d'arrêt peut être légèrement différent de la limite à cause + d'exigences de contrôle interne de l'algorithme. Exemple : ``{"MaximumNumberOfSteps":100}`` CostDecrementTolerance - Cette clé indique une valeur limite, conduisant à arrêter le processus - itératif d'optimisation lorsque la fonction coût décroît moins que cette - tolérance au dernier pas. Le défaut est de 1.e-7, et il est recommandé - de l'adapter aux besoins pour des problèmes réels. + Cette clé indique une valeur limite, conduisant à arrêter le processus + itératif d'optimisation lorsque la fonction coût décroît moins que cette + tolérance au dernier pas. Le défaut est de 1.e-7, et il est recommandé + de l'adapter aux besoins pour des problèmes réels. Exemple : ``{"CostDecrementTolerance":1.e-7}`` ProjectedGradientTolerance - Cette clé indique une valeur limite, conduisant à arrêter le processus - itératif d'optimisation lorsque toutes les composantes du gradient projeté - sont en-dessous de cette limite. C'est utilisé uniquement par les - optimiseurs sous contraintes. Le défaut est -1, qui désigne le défaut - interne de chaque optimiseur (usuellement 1.e-5), et il n'est pas recommandé + Cette clé indique une valeur limite, conduisant à arrêter le processus + itératif d'optimisation lorsque toutes les composantes du gradient projeté + sont en-dessous de cette limite. C'est utilisé uniquement par les + optimiseurs sous contraintes. Le défaut est -1, qui désigne le défaut + interne de chaque optimiseur (usuellement 1.e-5), et il n'est pas recommandé de le changer. Exemple : ``{"ProjectedGradientTolerance":-1}`` GradientNormTolerance - Cette clé indique une valeur limite, conduisant à arrêter le processus - itératif d'optimisation lorsque la norme du gradient est en dessous de cette - limite. C'est utilisé uniquement par les optimiseurs sans contraintes. Le - défaut est 1.e-5 et il n'est pas recommandé de le changer. + Cette clé indique une valeur limite, conduisant à arrêter le processus + itératif d'optimisation lorsque la norme du gradient est en dessous de cette + limite. C'est utilisé uniquement par les optimiseurs sans contraintes. Le + défaut est 1.e-5 et il n'est pas recommandé de le changer. Exemple : ``{"GradientNormTolerance":1.e-5}`` StoreSupplementaryCalculations - Cette liste indique les noms des variables supplémentaires qui peuvent être - disponibles à la fin de l'algorithme. Cela implique potentiellement des - calculs ou du stockage coûteux. La valeur par défaut est une liste vide, - aucune de ces variables n'étant calculée et stockée par défaut. Les noms + Cette liste indique les noms des variables supplémentaires qui peuvent être + disponibles à la fin de l'algorithme. Cela implique potentiellement des + calculs ou du stockage coûteux. La valeur par défaut est une liste vide, + aucune de ces variables n'étant calculée et stockée par défaut. Les noms possibles sont dans la liste suivante : ["BMA", "CostFunctionJ", "CostFunctionJb", "CostFunctionJo", "CurrentState", "OMA", "OMB", "Innovation", "SimulatedObservationAtCurrentState", @@ -172,100 +172,100 @@ Les options de l'algorithme sont les suivantes: *Astuce pour cet algorithme :* Comme la commande *"BackgroundError"* est requise pour TOUS les algorithmes - de calcul dans l'interface, vous devez fournir une valeur, malgré le fait + de calcul dans l'interface, vous devez fournir une valeur, malgré le fait que cette commande n'est pas requise pour cet algorithme, et ne sera pas - utilisée. La manière la plus simple est de donner "1" comme un STRING. + utilisée. La manière la plus simple est de donner "1" comme un STRING. -Informations et variables disponibles à la fin de l'algorithme +Informations et variables disponibles à la fin de l'algorithme ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -En sortie, après exécution de l'algorithme, on dispose d'informations et de +En sortie, après exécution de l'algorithme, on dispose d'informations et de variables issues du calcul. La description des -:ref:`section_ref_output_variables` indique la manière de les obtenir par la -méthode nommée ``get`` de la variable "*ADD*" du post-processing. Les variables -d'entrée, mises à disposition de l'utilisateur en sortie pour faciliter -l'écriture des procédures de post-processing, sont décrites dans +:ref:`section_ref_output_variables` indique la manière de les obtenir par la +méthode nommée ``get`` de la variable "*ADD*" du post-processing. Les variables +d'entrée, mises à disposition de l'utilisateur en sortie pour faciliter +l'écriture des procédures de post-processing, sont décrites dans l':ref:`subsection_r_o_v_Inventaire`. Les sorties non conditionnelles de l'algorithme sont les suivantes: Analysis - *Liste de vecteurs*. Chaque élément est un état optimal :math:`\mathbf{x}*` + *Liste de vecteurs*. Chaque élément est un état optimal :math:`\mathbf{x}*` en optimisation ou une analyse :math:`\mathbf{x}^a` en assimilation de - données. + données. Exemple : ``Xa = ADD.get("Analysis")[-1]`` CostFunctionJ - *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart + *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart :math:`J`. Exemple : ``J = ADD.get("CostFunctionJ")[:]`` CostFunctionJb - *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart - :math:`J^b`, c'est-à-dire de la partie écart à l'ébauche. + *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart + :math:`J^b`, c'est-à-dire de la partie écart à l'ébauche. Exemple : ``Jb = ADD.get("CostFunctionJb")[:]`` CostFunctionJo - *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart - :math:`J^o`, c'est-à-dire de la partie écart à l'observation. + *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart + :math:`J^o`, c'est-à-dire de la partie écart à l'observation. Exemple : ``Jo = ADD.get("CostFunctionJo")[:]`` Les sorties conditionnelles de l'algorithme sont les suivantes: BMA - *Liste de vecteurs*. Chaque élément est un vecteur d'écart entre - l'ébauche et l'état optimal. + *Liste de vecteurs*. Chaque élément est un vecteur d'écart entre + l'ébauche et l'état optimal. Exemple : ``bma = ADD.get("BMA")[-1]`` CurrentState - *Liste de vecteurs*. Chaque élément est un vecteur d'état courant utilisé - au cours du déroulement de l'algorithme d'optimisation. + *Liste de vecteurs*. Chaque élément est un vecteur d'état courant utilisé + au cours du déroulement de l'algorithme d'optimisation. Exemple : ``Xs = ADD.get("CurrentState")[:]`` Innovation - *Liste de vecteurs*. Chaque élément est un vecteur d'innovation, qui est - en statique l'écart de l'optimum à l'ébauche, et en dynamique l'incrément - d'évolution. + *Liste de vecteurs*. Chaque élément est un vecteur d'innovation, qui est + en statique l'écart de l'optimum à l'ébauche, et en dynamique l'incrément + d'évolution. Exemple : ``d = ADD.get("Innovation")[-1]`` OMA - *Liste de vecteurs*. Chaque élément est un vecteur d'écart entre - l'observation et l'état optimal dans l'espace des observations. + *Liste de vecteurs*. Chaque élément est un vecteur d'écart entre + l'observation et l'état optimal dans l'espace des observations. Exemple : ``oma = ADD.get("OMA")[-1]`` OMB - *Liste de vecteurs*. Chaque élément est un vecteur d'écart entre - l'observation et l'état d'ébauche dans l'espace des observations. + *Liste de vecteurs*. Chaque élément est un vecteur d'écart entre + l'observation et l'état d'ébauche dans l'espace des observations. Exemple : ``omb = ADD.get("OMB")[-1]`` SimulatedObservationAtCurrentState - *Liste de vecteurs*. Chaque élément est un vecteur observé à l'état courant, - c'est-à-dire dans l'espace des observations. + *Liste de vecteurs*. Chaque élément est un vecteur observé à l'état courant, + c'est-à-dire dans l'espace des observations. Exemple : ``Ys = ADD.get("SimulatedObservationAtCurrentState")[-1]`` SimulatedObservationAtOptimum - *Liste de vecteurs*. Chaque élément est un vecteur d'observation simulé à - partir de l'analyse ou de l'état optimal :math:`\mathbf{x}^a`. + *Liste de vecteurs*. Chaque élément est un vecteur d'observation simulé à + partir de l'analyse ou de l'état optimal :math:`\mathbf{x}^a`. Exemple : ``hxa = ADD.get("SimulatedObservationAtOptimum")[-1]`` Voir aussi ++++++++++ -Références vers d'autres sections : +Références vers d'autres sections : - :ref:`section_ref_algorithm_3DVAR` -Références bibliographiques : +Références bibliographiques : - [Byrd95]_ - [Morales11]_ - [Zhu97]_ diff --git a/doc/fr/ref_algorithm_ObserverTest.rst b/doc/fr/ref_algorithm_ObserverTest.rst index 5d23470..18f5cbc 100644 --- a/doc/fr/ref_algorithm_ObserverTest.rst +++ b/doc/fr/ref_algorithm_ObserverTest.rst @@ -24,16 +24,16 @@ .. index:: single: ObserverTest .. _section_ref_algorithm_ObserverTest: -Algorithme de vérification "*ObserverTest*" +Algorithme de vérification "*ObserverTest*" ------------------------------------------- Description +++++++++++ -Cet algorithme permet de vérifier une fonction externe et fournie par -l'utilisateur, utilisée comme un *observer*. Cette fonction externe peut être -appliquée à chacune des variables potentiellement observables. Elle n'est -activée que sur celles qui sont explicitement associées avec l'*observer* dans +Cet algorithme permet de vérifier une fonction externe et fournie par +l'utilisateur, utilisée comme un *observer*. Cette fonction externe peut être +appliquée à chacune des variables potentiellement observables. Elle n'est +activée que sur celles qui sont explicitement associées avec l'*observer* dans l'interface. Commandes requises et optionnelles @@ -44,26 +44,26 @@ Commandes requises et optionnelles .. index:: single: ObservationOperator .. index:: single: Observers -Les commandes requises générales, disponibles dans l'interface en édition, sont +Les commandes requises générales, disponibles dans l'interface en édition, sont les suivantes: Observers - *Commande obligatoire*. Elle permet de définir des observateurs internes, - qui sont des fonctions liées à une variable particulière, qui sont exécutées - chaque fois que cette variable est modifiée. C'est une manière pratique de - suivre des variables d'intérêt durant le processus d'assimilation de données - ou d'optimisation, en l'affichant ou en la traçant, etc. Des exemples + *Commande obligatoire*. Elle permet de définir des observateurs internes, + qui sont des fonctions liées à une variable particulière, qui sont exécutées + chaque fois que cette variable est modifiée. C'est une manière pratique de + suivre des variables d'intérêt durant le processus d'assimilation de données + ou d'optimisation, en l'affichant ou en la traçant, etc. Des exemples courants (squelettes) sont fournis pour aider l'utilisateur ou pour - faciliter l'élaboration d'un cas. + faciliter l'élaboration d'un cas. + +Les commandes optionnelles générales, disponibles dans l'interface en édition, +sont indiquées dans la :ref:`section_ref_checking_keywords`. -Les commandes optionnelles générales, disponibles dans l'interface en édition, -sont indiquées dans la :ref:`section_ref_checking_keywords`. - *Astuce pour cet algorithme :* Comme les commandes *"CheckingPoint"* et *"ObservationOperator"* sont - requises pour TOUS les algorithmes de vérification dans l'interface, vous - devez fournir une valeur, malgré le fait que ces commandes ne sont pas - requises pour *"ObserverTest"*, et ne seront pas utilisées. La manière la + requises pour TOUS les algorithmes de vérification dans l'interface, vous + devez fournir une valeur, malgré le fait que ces commandes ne sont pas + requises pour *"ObserverTest"*, et ne seront pas utilisées. La manière la plus simple est de donner "1" comme un STRING pour les deux, - l'*"ObservationOperator"* devant être de type *Matrix*. + l'*"ObservationOperator"* devant être de type *Matrix*. diff --git a/doc/fr/ref_algorithm_ParticleSwarmOptimization.rst b/doc/fr/ref_algorithm_ParticleSwarmOptimization.rst index 4b279d1..e9afb6a 100644 --- a/doc/fr/ref_algorithm_ParticleSwarmOptimization.rst +++ b/doc/fr/ref_algorithm_ParticleSwarmOptimization.rst @@ -30,17 +30,17 @@ Algorithme de calcul "*ParticleSwarmOptimization*" Description +++++++++++ -Cet algorithme réalise une estimation de l'état d'un système dynamique par -minimisation d'une fonctionnelle d'écart :math:`J` en utilisant un essaim -particulaire. C'est une méthode qui n'utilise pas les dérivées de la -fonctionnelle d'écart. Elle entre dans la même catégorie que +Cet algorithme réalise une estimation de l'état d'un système dynamique par +minimisation d'une fonctionnelle d'écart :math:`J` en utilisant un essaim +particulaire. C'est une méthode qui n'utilise pas les dérivées de la +fonctionnelle d'écart. Elle entre dans la même catégorie que l':ref:`section_ref_algorithm_DerivativeFreeOptimization`. -C'est une méthode d'optimisation permettant la recherche du minimum global d'une +C'est une méthode d'optimisation permettant la recherche du minimum global d'une fonctionnelle d'erreur :math:`J` quelconque de type :math:`L^1`, :math:`L^2` ou -:math:`L^{\infty}`, avec ou sans pondérations. La fonctionnelle d'erreur par -défaut est celle de moindres carrés pondérés augmentés, classiquement utilisée -en assimilation de données. +:math:`L^{\infty}`, avec ou sans pondérations. La fonctionnelle d'erreur par +défaut est celle de moindres carrés pondérés augmentés, classiquement utilisée +en assimilation de données. Commandes requises et optionnelles ++++++++++++++++++++++++++++++++++ @@ -61,123 +61,123 @@ Commandes requises et optionnelles .. index:: single: SetSeed .. index:: single: StoreSupplementaryCalculations -Les commandes requises générales, disponibles dans l'interface en édition, sont +Les commandes requises générales, disponibles dans l'interface en édition, sont les suivantes: Background - *Commande obligatoire*. Elle définit le vecteur d'ébauche ou - d'initialisation, noté précédemment :math:`\mathbf{x}^b`. Sa valeur est - définie comme un objet de type "*Vector*" ou de type "*VectorSerie*". + *Commande obligatoire*. Elle définit le vecteur d'ébauche ou + d'initialisation, noté précédemment :math:`\mathbf{x}^b`. Sa valeur est + définie comme un objet de type "*Vector*" ou de type "*VectorSerie*". BackgroundError - *Commande obligatoire*. Elle définit la matrice de covariance des erreurs - d'ébauche, notée précédemment :math:`\mathbf{B}`. Sa valeur est définie + *Commande obligatoire*. Elle définit la matrice de covariance des erreurs + d'ébauche, notée précédemment :math:`\mathbf{B}`. Sa valeur est définie comme un objet de type "*Matrix*", de type "*ScalarSparseMatrix*", ou de type "*DiagonalSparseMatrix*". Observation - *Commande obligatoire*. Elle définit le vecteur d'observation utilisé en - assimilation de données ou en optimisation, et noté précédemment - :math:`\mathbf{y}^o`. Sa valeur est définie comme un objet de type "*Vector*" + *Commande obligatoire*. Elle définit le vecteur d'observation utilisé en + assimilation de données ou en optimisation, et noté précédemment + :math:`\mathbf{y}^o`. Sa valeur est définie comme un objet de type "*Vector*" ou de type "*VectorSerie*". ObservationError - *Commande obligatoire*. Elle définit la matrice de covariance des erreurs - d'ébauche, notée précédemment :math:`\mathbf{R}`. Sa valeur est définie + *Commande obligatoire*. Elle définit la matrice de covariance des erreurs + d'ébauche, notée précédemment :math:`\mathbf{R}`. Sa valeur est définie comme un objet de type "*Matrix*", de type "*ScalarSparseMatrix*", ou de type "*DiagonalSparseMatrix*". ObservationOperator - *Commande obligatoire*. Elle indique l'opérateur d'observation, noté - précédemment :math:`H`, qui transforme les paramètres d'entrée - :math:`\mathbf{x}` en résultats :math:`\mathbf{y}` qui sont à comparer aux - observations :math:`\mathbf{y}^o`. Sa valeur est définie comme un objet de + *Commande obligatoire*. Elle indique l'opérateur d'observation, noté + précédemment :math:`H`, qui transforme les paramètres d'entrée + :math:`\mathbf{x}` en résultats :math:`\mathbf{y}` qui sont à comparer aux + observations :math:`\mathbf{y}^o`. Sa valeur est définie comme un objet de type "*Function*" ou de type "*Matrix*". Dans le cas du type "*Function*", - différentes formes fonctionnelles peuvent être utilisées, comme décrit dans - la section :ref:`section_ref_operator_requirements`. Si un contrôle - :math:`U` est inclus dans le modèle d'observation, l'opérateur doit être - appliqué à une paire :math:`(X,U)`. - -Les commandes optionnelles générales, disponibles dans l'interface en édition, -sont indiquées dans la :ref:`section_ref_assimilation_keywords`. De plus, les -paramètres de la commande "*AlgorithmParameters*" permettent d'indiquer les -options particulières, décrites ci-après, de l'algorithme. On se reportera à la + différentes formes fonctionnelles peuvent être utilisées, comme décrit dans + la section :ref:`section_ref_operator_requirements`. Si un contrôle + :math:`U` est inclus dans le modèle d'observation, l'opérateur doit être + appliqué à une paire :math:`(X,U)`. + +Les commandes optionnelles générales, disponibles dans l'interface en édition, +sont indiquées dans la :ref:`section_ref_assimilation_keywords`. De plus, les +paramètres de la commande "*AlgorithmParameters*" permettent d'indiquer les +options particulières, décrites ci-après, de l'algorithme. On se reportera à la :ref:`section_ref_options_Algorithm_Parameters` pour le bon usage de cette commande. Les options de l'algorithme sont les suivantes: MaximumNumberOfSteps - Cette clé indique le nombre maximum d'itérations possibles en optimisation - itérative. Le défaut est 50, qui est une limite arbitraire. Il est ainsi - recommandé d'adapter ce paramètre aux besoins pour des problèmes réels. + Cette clé indique le nombre maximum d'itérations possibles en optimisation + itérative. Le défaut est 50, qui est une limite arbitraire. Il est ainsi + recommandé d'adapter ce paramètre aux besoins pour des problèmes réels. Exemple : ``{"MaximumNumberOfSteps":100}`` MaximumNumberOfFunctionEvaluations - Cette clé indique le nombre maximum d'évaluations possibles de la - fonctionnelle à optimiser. Le défaut est de 15000, qui est une limite - arbitraire. Il est ainsi recommandé d'adapter ce paramètre aux besoins pour - des problèmes réels. Pour certains optimiseurs, le nombre effectif - d'évaluations à l'arrêt peut être légèrement différent de la limite à cause - d'exigences de déroulement interne de l'algorithme. + Cette clé indique le nombre maximum d'évaluations possibles de la + fonctionnelle à optimiser. Le défaut est de 15000, qui est une limite + arbitraire. Il est ainsi recommandé d'adapter ce paramètre aux besoins pour + des problèmes réels. Pour certains optimiseurs, le nombre effectif + d'évaluations à l'arrêt peut être légèrement différent de la limite à cause + d'exigences de déroulement interne de l'algorithme. Exemple : ``{"MaximumNumberOfFunctionEvaluations":50}`` NumberOfInsects - Cette clé indique le nombre d'insectes ou de particules dans l'essaim. La - valeur par défaut est 100, qui est une valeur par défaut usuelle pour cet + Cette clé indique le nombre d'insectes ou de particules dans l'essaim. La + valeur par défaut est 100, qui est une valeur par défaut usuelle pour cet algorithme. Exemple : ``{"NumberOfInsects":100}`` SwarmVelocity - Cette clé indique la part de la vitesse d'insecte qui est imposée par - l'essaim. C'est une valeur réelle positive. Le défaut est de 1. + Cette clé indique la part de la vitesse d'insecte qui est imposée par + l'essaim. C'est une valeur réelle positive. Le défaut est de 1. Exemple : ``{"SwarmVelocity":1.}`` GroupRecallRate - Cette clé indique le taux de rappel vers le meilleur insecte de l'essaim. - C'est une valeur réelle comprise entre 0 et 1. Le défaut est de 0.5. + Cette clé indique le taux de rappel vers le meilleur insecte de l'essaim. + C'est une valeur réelle comprise entre 0 et 1. Le défaut est de 0.5. Exemple : ``{"GroupRecallRate":0.5}`` QualityCriterion - Cette clé indique le critère de qualité, qui est minimisé pour trouver - l'estimation optimale de l'état. Le défaut est le critère usuel de - l'assimilation de données nommé "DA", qui est le critère de moindres carrés - pondérés augmentés. Les critères possibles sont dans la liste suivante, dans - laquelle les noms équivalents sont indiqués par un signe "=" : + Cette clé indique le critère de qualité, qui est minimisé pour trouver + l'estimation optimale de l'état. Le défaut est le critère usuel de + l'assimilation de données nommé "DA", qui est le critère de moindres carrés + pondérés augmentés. Les critères possibles sont dans la liste suivante, dans + laquelle les noms équivalents sont indiqués par un signe "=" : ["AugmentedWeightedLeastSquares"="AWLS"="DA", "WeightedLeastSquares"="WLS", "LeastSquares"="LS"="L2", "AbsoluteValue"="L1", "MaximumError"="ME"]. Exemple : ``{"QualityCriterion":"DA"}`` BoxBounds - Cette clé permet de définir des bornes supérieure et inférieure pour chaque - incrément de variable d'état optimisée (et non pas chaque variable d'état - elle-même). Les bornes doivent être données par une liste de liste de paires - de bornes inférieure/supérieure pour chaque incrément de variable, avec une - valeur extrême chaque fois qu'il n'y a pas de borne (``None`` n'est pas une - valeur autorisée lorsqu'il n'y a pas de borne). Cette clé est requise et il - n'y a pas de valeurs par défaut. + Cette clé permet de définir des bornes supérieure et inférieure pour chaque + incrément de variable d'état optimisée (et non pas chaque variable d'état + elle-même). Les bornes doivent être données par une liste de liste de paires + de bornes inférieure/supérieure pour chaque incrément de variable, avec une + valeur extrême chaque fois qu'il n'y a pas de borne (``None`` n'est pas une + valeur autorisée lorsqu'il n'y a pas de borne). Cette clé est requise et il + n'y a pas de valeurs par défaut. Exemple : ``{"BoxBounds":[[-0.5,0.5], [0.01,2.], [0.,1.e99], [-1.e99,1.e99]]}`` SetSeed - Cette clé permet de donner un nombre entier pour fixer la graine du - générateur aléatoire utilisé pour générer l'ensemble. Un valeur pratique est - par exemple 1000. Par défaut, la graine est laissée non initialisée, et elle - utilise ainsi l'initialisation par défaut de l'ordinateur. + Cette clé permet de donner un nombre entier pour fixer la graine du + générateur aléatoire utilisé pour générer l'ensemble. Un valeur pratique est + par exemple 1000. Par défaut, la graine est laissée non initialisée, et elle + utilise ainsi l'initialisation par défaut de l'ordinateur. Exemple : ``{"SetSeed":1000}`` StoreSupplementaryCalculations - Cette liste indique les noms des variables supplémentaires qui peuvent être - disponibles à la fin de l'algorithme. Cela implique potentiellement des - calculs ou du stockage coûteux. La valeur par défaut est une liste vide, - aucune de ces variables n'étant calculée et stockée par défaut. Les noms + Cette liste indique les noms des variables supplémentaires qui peuvent être + disponibles à la fin de l'algorithme. Cela implique potentiellement des + calculs ou du stockage coûteux. La valeur par défaut est une liste vide, + aucune de ces variables n'étant calculée et stockée par défaut. Les noms possibles sont dans la liste suivante : ["BMA", "CostFunctionJ", "CostFunctionJb", "CostFunctionJo", "CurrentState", "OMA", "OMB", "Innovation", "SimulatedObservationAtBackground", @@ -185,100 +185,100 @@ Les options de l'algorithme sont les suivantes: Exemple : ``{"StoreSupplementaryCalculations":["BMA", "Innovation"]}`` -Informations et variables disponibles à la fin de l'algorithme +Informations et variables disponibles à la fin de l'algorithme ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -En sortie, après exécution de l'algorithme, on dispose d'informations et de +En sortie, après exécution de l'algorithme, on dispose d'informations et de variables issues du calcul. La description des -:ref:`section_ref_output_variables` indique la manière de les obtenir par la -méthode nommée ``get`` de la variable "*ADD*" du post-processing. Les variables -d'entrée, mises à disposition de l'utilisateur en sortie pour faciliter -l'écriture des procédures de post-processing, sont décrites dans +:ref:`section_ref_output_variables` indique la manière de les obtenir par la +méthode nommée ``get`` de la variable "*ADD*" du post-processing. Les variables +d'entrée, mises à disposition de l'utilisateur en sortie pour faciliter +l'écriture des procédures de post-processing, sont décrites dans l':ref:`subsection_r_o_v_Inventaire`. Les sorties non conditionnelles de l'algorithme sont les suivantes: Analysis - *Liste de vecteurs*. Chaque élément est un état optimal :math:`\mathbf{x}*` + *Liste de vecteurs*. Chaque élément est un état optimal :math:`\mathbf{x}*` en optimisation ou une analyse :math:`\mathbf{x}^a` en assimilation de - données. + données. Exemple : ``Xa = ADD.get("Analysis")[-1]`` CostFunctionJ - *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart + *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart :math:`J`. Exemple : ``J = ADD.get("CostFunctionJ")[:]`` CostFunctionJb - *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart - :math:`J^b`, c'est-à-dire de la partie écart à l'ébauche. + *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart + :math:`J^b`, c'est-à-dire de la partie écart à l'ébauche. Exemple : ``Jb = ADD.get("CostFunctionJb")[:]`` CostFunctionJo - *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart - :math:`J^o`, c'est-à-dire de la partie écart à l'observation. + *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart + :math:`J^o`, c'est-à-dire de la partie écart à l'observation. Exemple : ``Jo = ADD.get("CostFunctionJo")[:]`` Les sorties conditionnelles de l'algorithme sont les suivantes: BMA - *Liste de vecteurs*. Chaque élément est un vecteur d'écart entre - l'ébauche et l'état optimal. + *Liste de vecteurs*. Chaque élément est un vecteur d'écart entre + l'ébauche et l'état optimal. Exemple : ``bma = ADD.get("BMA")[-1]`` CurrentState - *Liste de vecteurs*. Chaque élément est un vecteur d'état courant utilisé - au cours du déroulement de l'algorithme d'optimisation. + *Liste de vecteurs*. Chaque élément est un vecteur d'état courant utilisé + au cours du déroulement de l'algorithme d'optimisation. Exemple : ``Xs = ADD.get("CurrentState")[:]`` Innovation - *Liste de vecteurs*. Chaque élément est un vecteur d'innovation, qui est - en statique l'écart de l'optimum à l'ébauche, et en dynamique l'incrément - d'évolution. + *Liste de vecteurs*. Chaque élément est un vecteur d'innovation, qui est + en statique l'écart de l'optimum à l'ébauche, et en dynamique l'incrément + d'évolution. Exemple : ``d = ADD.get("Innovation")[-1]`` OMA - *Liste de vecteurs*. Chaque élément est un vecteur d'écart entre - l'observation et l'état optimal dans l'espace des observations. + *Liste de vecteurs*. Chaque élément est un vecteur d'écart entre + l'observation et l'état optimal dans l'espace des observations. Exemple : ``oma = ADD.get("OMA")[-1]`` OMB - *Liste de vecteurs*. Chaque élément est un vecteur d'écart entre - l'observation et l'état d'ébauche dans l'espace des observations. + *Liste de vecteurs*. Chaque élément est un vecteur d'écart entre + l'observation et l'état d'ébauche dans l'espace des observations. Exemple : ``omb = ADD.get("OMB")[-1]`` SimulatedObservationAtBackground - *Liste de vecteurs*. Chaque élément est un vecteur d'observation simulé à - partir de l'ébauche :math:`\mathbf{x}^b`. + *Liste de vecteurs*. Chaque élément est un vecteur d'observation simulé à + partir de l'ébauche :math:`\mathbf{x}^b`. Exemple : ``hxb = ADD.get("SimulatedObservationAtBackground")[-1]`` SimulatedObservationAtCurrentState - *Liste de vecteurs*. Chaque élément est un vecteur observé à l'état courant, - c'est-à-dire dans l'espace des observations. + *Liste de vecteurs*. Chaque élément est un vecteur observé à l'état courant, + c'est-à-dire dans l'espace des observations. Exemple : ``Ys = ADD.get("SimulatedObservationAtCurrentState")[-1]`` SimulatedObservationAtOptimum - *Liste de vecteurs*. Chaque élément est un vecteur d'observation simulé à - partir de l'analyse ou de l'état optimal :math:`\mathbf{x}^a`. + *Liste de vecteurs*. Chaque élément est un vecteur d'observation simulé à + partir de l'analyse ou de l'état optimal :math:`\mathbf{x}^a`. Exemple : ``hxa = ADD.get("SimulatedObservationAtOptimum")[-1]`` Voir aussi ++++++++++ -Références vers d'autres sections : +Références vers d'autres sections : - :ref:`section_ref_algorithm_DerivativeFreeOptimization` -Références bibliographiques : +Références bibliographiques : - [WikipediaPSO]_ diff --git a/doc/fr/ref_algorithm_QuantileRegression.rst b/doc/fr/ref_algorithm_QuantileRegression.rst index c62dd30..4663d80 100644 --- a/doc/fr/ref_algorithm_QuantileRegression.rst +++ b/doc/fr/ref_algorithm_QuantileRegression.rst @@ -31,9 +31,9 @@ Description +++++++++++ Cet algorithme permet d'estimer les quantiles conditionnels de la distribution -des paramètres d'état, exprimés à l'aide d'un modèle des variables observées. Ce -sont donc les quantiles sur les variables observées qui vont permettre de -déterminer les paramètres de modèles satisfaisant aux conditions de quantiles. +des paramètres d'état, exprimés à l'aide d'un modèle des variables observées. Ce +sont donc les quantiles sur les variables observées qui vont permettre de +déterminer les paramètres de modèles satisfaisant aux conditions de quantiles. Commandes requises et optionnelles ++++++++++++++++++++++++++++++++++ @@ -49,77 +49,77 @@ Commandes requises et optionnelles .. index:: single: Bounds .. index:: single: StoreSupplementaryCalculations -Les commandes requises générales, disponibles dans l'interface en édition, sont +Les commandes requises générales, disponibles dans l'interface en édition, sont les suivantes: Background - *Commande obligatoire*. Elle définit le vecteur d'ébauche ou - d'initialisation, noté précédemment :math:`\mathbf{x}^b`. Sa valeur est - définie comme un objet de type "*Vector*" ou de type "*VectorSerie*". + *Commande obligatoire*. Elle définit le vecteur d'ébauche ou + d'initialisation, noté précédemment :math:`\mathbf{x}^b`. Sa valeur est + définie comme un objet de type "*Vector*" ou de type "*VectorSerie*". Observation - *Commande obligatoire*. Elle définit le vecteur d'observation utilisé en - assimilation de données ou en optimisation, et noté précédemment - :math:`\mathbf{y}^o`. Sa valeur est définie comme un objet de type "*Vector*" + *Commande obligatoire*. Elle définit le vecteur d'observation utilisé en + assimilation de données ou en optimisation, et noté précédemment + :math:`\mathbf{y}^o`. Sa valeur est définie comme un objet de type "*Vector*" ou de type "*VectorSerie*". ObservationOperator - *Commande obligatoire*. Elle indique l'opérateur d'observation, noté - précédemment :math:`H`, qui transforme les paramètres d'entrée - :math:`\mathbf{x}` en résultats :math:`\mathbf{y}` qui sont à comparer aux - observations :math:`\mathbf{y}^o`. Sa valeur est définie comme un objet de + *Commande obligatoire*. Elle indique l'opérateur d'observation, noté + précédemment :math:`H`, qui transforme les paramètres d'entrée + :math:`\mathbf{x}` en résultats :math:`\mathbf{y}` qui sont à comparer aux + observations :math:`\mathbf{y}^o`. Sa valeur est définie comme un objet de type "*Function*" ou de type "*Matrix*". Dans le cas du type "*Function*", - différentes formes fonctionnelles peuvent être utilisées, comme décrit dans - la section :ref:`section_ref_operator_requirements`. Si un contrôle - :math:`U` est inclus dans le modèle d'observation, l'opérateur doit être - appliqué à une paire :math:`(X,U)`. - -Les commandes optionnelles générales, disponibles dans l'interface en édition, -sont indiquées dans la :ref:`section_ref_assimilation_keywords`. De plus, les -paramètres de la commande "*AlgorithmParameters*" permettent d'indiquer les -options particulières, décrites ci-après, de l'algorithme. On se reportera à la + différentes formes fonctionnelles peuvent être utilisées, comme décrit dans + la section :ref:`section_ref_operator_requirements`. Si un contrôle + :math:`U` est inclus dans le modèle d'observation, l'opérateur doit être + appliqué à une paire :math:`(X,U)`. + +Les commandes optionnelles générales, disponibles dans l'interface en édition, +sont indiquées dans la :ref:`section_ref_assimilation_keywords`. De plus, les +paramètres de la commande "*AlgorithmParameters*" permettent d'indiquer les +options particulières, décrites ci-après, de l'algorithme. On se reportera à la :ref:`section_ref_options_Algorithm_Parameters` pour le bon usage de cette commande. Les options de l'algorithme sont les suivantes: Quantile - Cette clé permet de définir la valeur réelle du quantile recherché, entre 0 - et 1. La valeur par défaut est 0.5, correspondant à la médiane. + Cette clé permet de définir la valeur réelle du quantile recherché, entre 0 + et 1. La valeur par défaut est 0.5, correspondant à la médiane. Exemple : ``{"Quantile":0.5}`` MaximumNumberOfSteps - Cette clé indique le nombre maximum d'itérations possibles en optimisation - itérative. Le défaut est 15000, qui est très similaire à une absence de - limite sur les itérations. Il est ainsi recommandé d'adapter ce paramètre - aux besoins pour des problèmes réels. + Cette clé indique le nombre maximum d'itérations possibles en optimisation + itérative. Le défaut est 15000, qui est très similaire à une absence de + limite sur les itérations. Il est ainsi recommandé d'adapter ce paramètre + aux besoins pour des problèmes réels. Exemple : ``{"MaximumNumberOfSteps":100}`` CostDecrementTolerance - Cette clé indique une valeur limite, conduisant à arrêter le processus - itératif d'optimisation lorsque la fonction coût décroît moins que cette - tolérance au dernier pas. Le défaut est de 1.e-6, et il est recommandé de - l'adapter aux besoins pour des problèmes réels. + Cette clé indique une valeur limite, conduisant à arrêter le processus + itératif d'optimisation lorsque la fonction coût décroît moins que cette + tolérance au dernier pas. Le défaut est de 1.e-6, et il est recommandé de + l'adapter aux besoins pour des problèmes réels. Exemple : ``{"CostDecrementTolerance":1.e-7}`` Bounds - Cette clé permet de définir des bornes supérieure et inférieure pour chaque - variable d'état optimisée. Les bornes doivent être données par une liste de - liste de paires de bornes inférieure/supérieure pour chaque variable, avec + Cette clé permet de définir des bornes supérieure et inférieure pour chaque + variable d'état optimisée. Les bornes doivent être données par une liste de + liste de paires de bornes inférieure/supérieure pour chaque variable, avec une valeur ``None`` chaque fois qu'il n'y a pas de borne. Les bornes peuvent - toujours être spécifiées, mais seuls les optimiseurs sous contraintes les + toujours être spécifiées, mais seuls les optimiseurs sous contraintes les prennent en compte. Exemple : ``{"Bounds":[[2.,5.],[1.e-2,10.],[-30.,None],[None,None]]}`` StoreSupplementaryCalculations - Cette liste indique les noms des variables supplémentaires qui peuvent être - disponibles à la fin de l'algorithme. Cela implique potentiellement des - calculs ou du stockage coûteux. La valeur par défaut est une liste vide, - aucune de ces variables n'étant calculée et stockée par défaut. Les noms + Cette liste indique les noms des variables supplémentaires qui peuvent être + disponibles à la fin de l'algorithme. Cela implique potentiellement des + calculs ou du stockage coûteux. La valeur par défaut est une liste vide, + aucune de ces variables n'étant calculée et stockée par défaut. Les noms possibles sont dans la liste suivante : ["BMA", "CostFunctionJ", "CostFunctionJb", "CostFunctionJo", "CurrentState", "OMA", "OMB", "Innovation", "SimulatedObservationAtBackground", @@ -131,103 +131,103 @@ Les options de l'algorithme sont les suivantes: Comme les commandes *"BackgroundError"* et *"ObservationError"* sont requises pour TOUS les algorithmes de calcul dans l'interface, vous devez - fournir une valeur, malgré le fait que ces commandes ne sont pas requises - pour cet algorithme, et ne seront pas utilisées. La manière la plus simple + fournir une valeur, malgré le fait que ces commandes ne sont pas requises + pour cet algorithme, et ne seront pas utilisées. La manière la plus simple est de donner "1" comme un STRING pour les deux. -Informations et variables disponibles à la fin de l'algorithme +Informations et variables disponibles à la fin de l'algorithme ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -En sortie, après exécution de l'algorithme, on dispose d'informations et de +En sortie, après exécution de l'algorithme, on dispose d'informations et de variables issues du calcul. La description des -:ref:`section_ref_output_variables` indique la manière de les obtenir par la -méthode nommée ``get`` de la variable "*ADD*" du post-processing. Les variables -d'entrée, mises à disposition de l'utilisateur en sortie pour faciliter -l'écriture des procédures de post-processing, sont décrites dans +:ref:`section_ref_output_variables` indique la manière de les obtenir par la +méthode nommée ``get`` de la variable "*ADD*" du post-processing. Les variables +d'entrée, mises à disposition de l'utilisateur en sortie pour faciliter +l'écriture des procédures de post-processing, sont décrites dans l':ref:`subsection_r_o_v_Inventaire`. Les sorties non conditionnelles de l'algorithme sont les suivantes: Analysis - *Liste de vecteurs*. Chaque élément est un état optimal :math:`\mathbf{x}*` + *Liste de vecteurs*. Chaque élément est un état optimal :math:`\mathbf{x}*` en optimisation ou une analyse :math:`\mathbf{x}^a` en assimilation de - données. + données. Exemple : ``Xa = ADD.get("Analysis")[-1]`` CostFunctionJ - *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart + *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart :math:`J`. Exemple : ``J = ADD.get("CostFunctionJ")[:]`` CostFunctionJb - *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart - :math:`J^b`, c'est-à-dire de la partie écart à l'ébauche. + *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart + :math:`J^b`, c'est-à-dire de la partie écart à l'ébauche. Exemple : ``Jb = ADD.get("CostFunctionJb")[:]`` CostFunctionJo - *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart - :math:`J^o`, c'est-à-dire de la partie écart à l'observation. + *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart + :math:`J^o`, c'est-à-dire de la partie écart à l'observation. Exemple : ``Jo = ADD.get("CostFunctionJo")[:]`` Les sorties conditionnelles de l'algorithme sont les suivantes: BMA - *Liste de vecteurs*. Chaque élément est un vecteur d'écart entre - l'ébauche et l'état optimal. + *Liste de vecteurs*. Chaque élément est un vecteur d'écart entre + l'ébauche et l'état optimal. Exemple : ``bma = ADD.get("BMA")[-1]`` CurrentState - *Liste de vecteurs*. Chaque élément est un vecteur d'état courant utilisé - au cours du déroulement de l'algorithme d'optimisation. + *Liste de vecteurs*. Chaque élément est un vecteur d'état courant utilisé + au cours du déroulement de l'algorithme d'optimisation. Exemple : ``Xs = ADD.get("CurrentState")[:]`` Innovation - *Liste de vecteurs*. Chaque élément est un vecteur d'innovation, qui est - en statique l'écart de l'optimum à l'ébauche, et en dynamique l'incrément - d'évolution. + *Liste de vecteurs*. Chaque élément est un vecteur d'innovation, qui est + en statique l'écart de l'optimum à l'ébauche, et en dynamique l'incrément + d'évolution. Exemple : ``d = ADD.get("Innovation")[-1]`` OMA - *Liste de vecteurs*. Chaque élément est un vecteur d'écart entre - l'observation et l'état optimal dans l'espace des observations. + *Liste de vecteurs*. Chaque élément est un vecteur d'écart entre + l'observation et l'état optimal dans l'espace des observations. Exemple : ``oma = ADD.get("OMA")[-1]`` OMB - *Liste de vecteurs*. Chaque élément est un vecteur d'écart entre - l'observation et l'état d'ébauche dans l'espace des observations. + *Liste de vecteurs*. Chaque élément est un vecteur d'écart entre + l'observation et l'état d'ébauche dans l'espace des observations. Exemple : ``omb = ADD.get("OMB")[-1]`` SimulatedObservationAtBackground - *Liste de vecteurs*. Chaque élément est un vecteur d'observation simulé à - partir de l'ébauche :math:`\mathbf{x}^b`. + *Liste de vecteurs*. Chaque élément est un vecteur d'observation simulé à + partir de l'ébauche :math:`\mathbf{x}^b`. Exemple : ``hxb = ADD.get("SimulatedObservationAtBackground")[-1]`` SimulatedObservationAtCurrentState - *Liste de vecteurs*. Chaque élément est un vecteur observé à l'état courant, - c'est-à-dire dans l'espace des observations. + *Liste de vecteurs*. Chaque élément est un vecteur observé à l'état courant, + c'est-à-dire dans l'espace des observations. Exemple : ``Ys = ADD.get("SimulatedObservationAtCurrentState")[-1]`` SimulatedObservationAtOptimum - *Liste de vecteurs*. Chaque élément est un vecteur d'observation simulé à - partir de l'analyse ou de l'état optimal :math:`\mathbf{x}^a`. + *Liste de vecteurs*. Chaque élément est un vecteur d'observation simulé à + partir de l'analyse ou de l'état optimal :math:`\mathbf{x}^a`. Exemple : ``hxa = ADD.get("SimulatedObservationAtOptimum")[-1]`` Voir aussi ++++++++++ -Références bibliographiques : +Références bibliographiques : - [Buchinsky98]_ - [Cade03]_ - [Koenker00]_ diff --git a/doc/fr/ref_algorithm_SamplingTest.rst b/doc/fr/ref_algorithm_SamplingTest.rst index bc9e319..f1694d9 100644 --- a/doc/fr/ref_algorithm_SamplingTest.rst +++ b/doc/fr/ref_algorithm_SamplingTest.rst @@ -24,34 +24,34 @@ .. index:: single: SamplingTest .. _section_ref_algorithm_SamplingTest: -Algorithme de vérification "*SamplingTest*" +Algorithme de vérification "*SamplingTest*" ------------------------------------------- Description +++++++++++ -Cet algorithme permet d'établir les valeurs, liées à un état :math:`\mathbf{x}`, +Cet algorithme permet d'établir les valeurs, liées à un état :math:`\mathbf{x}`, d'une fonctionnelle d'erreur :math:`J` quelconque de type :math:`L^1`, -:math:`L^2` ou :math:`L^{\infty}`, avec ou sans pondérations, et de l'opérateur -d'observation, pour un échantillon d'états donné a priori. La fonctionnelle -d'erreur par défaut est celle de moindres carrés pondérés augmentés, -classiquement utilisée en assimilation de données. - -Il est utile pour tester la sensibilité, de la fonctionnelle :math:`J`, en -particulier, aux variations de l'état :math:`\mathbf{x}`. Lorsque un état n'est -pas observable, une valeur *"NaN"* est retournée. - -L'échantillon des états :math:`\mathbf{x}` peut être fourni explicitement ou -sous la forme d'hyper-cubes, explicites ou échantillonnés selon des lois -courantes. Attention à la taille de l'hyper-cube (et donc au nombre de calculs) +:math:`L^2` ou :math:`L^{\infty}`, avec ou sans pondérations, et de l'opérateur +d'observation, pour un échantillon d'états donné a priori. La fonctionnelle +d'erreur par défaut est celle de moindres carrés pondérés augmentés, +classiquement utilisée en assimilation de données. + +Il est utile pour tester la sensibilité, de la fonctionnelle :math:`J`, en +particulier, aux variations de l'état :math:`\mathbf{x}`. Lorsque un état n'est +pas observable, une valeur *"NaN"* est retournée. + +L'échantillon des états :math:`\mathbf{x}` peut être fourni explicitement ou +sous la forme d'hyper-cubes, explicites ou échantillonnés selon des lois +courantes. Attention à la taille de l'hyper-cube (et donc au nombre de calculs) qu'il est possible d'atteindre, elle peut rapidement devenir importante. -Pour apparaître pour l'utilisateur, les résultats de l'échantillonnage doivent -être demandés explicitement. On utilise pour cela, sur la variable désirée, la -sauvegarde finale à l'aide du mot-clé "*UserPostAnalysis*" ou le traitement en -cours de calcul à l'aide des "*observer*" adaptés. +Pour apparaître pour l'utilisateur, les résultats de l'échantillonnage doivent +être demandés explicitement. On utilise pour cela, sur la variable désirée, la +sauvegarde finale à l'aide du mot-clé "*UserPostAnalysis*" ou le traitement en +cours de calcul à l'aide des "*observer*" adaptés. -Pour effectuer un échantillonnage distribué ou plus complexe, voir le module +Pour effectuer un échantillonnage distribué ou plus complexe, voir le module OPENTURNS disponible dans SALOME. Commandes requises et optionnelles @@ -72,181 +72,181 @@ Commandes requises et optionnelles .. index:: single: SetSeed .. index:: single: StoreSupplementaryCalculations -Les commandes requises générales, disponibles dans l'interface en édition, sont +Les commandes requises générales, disponibles dans l'interface en édition, sont les suivantes: CheckingPoint - *Commande obligatoire*. Elle définit le vecteur utilisé comme l'état autour - duquel réaliser le test requis, noté :math:`\mathbf{x}` et similaire à - l'ébauche :math:`\mathbf{x}^b`. Sa valeur est définie comme un objet de type + *Commande obligatoire*. Elle définit le vecteur utilisé comme l'état autour + duquel réaliser le test requis, noté :math:`\mathbf{x}` et similaire à + l'ébauche :math:`\mathbf{x}^b`. Sa valeur est définie comme un objet de type "*Vector*". BackgroundError - *Commande obligatoire*. Elle définit la matrice de covariance des erreurs - d'ébauche, notée précédemment :math:`\mathbf{B}`. Sa valeur est définie + *Commande obligatoire*. Elle définit la matrice de covariance des erreurs + d'ébauche, notée précédemment :math:`\mathbf{B}`. Sa valeur est définie comme un objet de type "*Matrix*", de type "*ScalarSparseMatrix*", ou de type "*DiagonalSparseMatrix*". Observation - *Commande obligatoire*. Elle définit le vecteur d'observation utilisé en - assimilation de données ou en optimisation, et noté précédemment - :math:`\mathbf{y}^o`. Sa valeur est définie comme un objet de type "*Vector*" + *Commande obligatoire*. Elle définit le vecteur d'observation utilisé en + assimilation de données ou en optimisation, et noté précédemment + :math:`\mathbf{y}^o`. Sa valeur est définie comme un objet de type "*Vector*" ou de type "*VectorSerie*". ObservationError - *Commande obligatoire*. Elle définit la matrice de covariance des erreurs - d'ébauche, notée précédemment :math:`\mathbf{R}`. Sa valeur est définie + *Commande obligatoire*. Elle définit la matrice de covariance des erreurs + d'ébauche, notée précédemment :math:`\mathbf{R}`. Sa valeur est définie comme un objet de type "*Matrix*", de type "*ScalarSparseMatrix*", ou de type "*DiagonalSparseMatrix*". ObservationOperator - *Commande obligatoire*. Elle indique l'opérateur d'observation, notée - précédemment :math:`H`, qui transforme les paramètres d'entrée - :math:`\mathbf{x}` en résultats :math:`\mathbf{y}` qui sont à comparer aux - observations :math:`\mathbf{y}^o`. Sa valeur est définie comme un objet de - type "*Function*". Différentes formes fonctionnelles peuvent être - utilisées, comme décrit dans la section - :ref:`section_ref_operator_requirements`. Si un contrôle :math:`U` est - inclus dans le modèle d'observation, l'opérateur doit être appliqué à une + *Commande obligatoire*. Elle indique l'opérateur d'observation, notée + précédemment :math:`H`, qui transforme les paramètres d'entrée + :math:`\mathbf{x}` en résultats :math:`\mathbf{y}` qui sont à comparer aux + observations :math:`\mathbf{y}^o`. Sa valeur est définie comme un objet de + type "*Function*". Différentes formes fonctionnelles peuvent être + utilisées, comme décrit dans la section + :ref:`section_ref_operator_requirements`. Si un contrôle :math:`U` est + inclus dans le modèle d'observation, l'opérateur doit être appliqué à une paire :math:`(X,U)`. -Les commandes optionnelles générales, disponibles dans l'interface en édition, -sont indiquées dans la :ref:`section_ref_checking_keywords`. De plus, les -paramètres de la commande "*AlgorithmParameters*" permettent d'indiquer les -options particulières, décrites ci-après, de l'algorithme. On se reportera à la +Les commandes optionnelles générales, disponibles dans l'interface en édition, +sont indiquées dans la :ref:`section_ref_checking_keywords`. De plus, les +paramètres de la commande "*AlgorithmParameters*" permettent d'indiquer les +options particulières, décrites ci-après, de l'algorithme. On se reportera à la :ref:`section_ref_options_Algorithm_Parameters` pour le bon usage de cette commande. Les options de l'algorithme sont les suivantes: SampleAsnUplet - Cette clé décrit les points de calcul sous la forme d'une liste de n-uplets, - chaque n-uplet étant un état. + Cette clé décrit les points de calcul sous la forme d'une liste de n-uplets, + chaque n-uplet étant un état. - Exemple : ``{"SampleAsnUplet":[[0,1,2,3],[4,3,2,1],[-2,3,-4,5]]}`` pour 3 points dans un espace d'état de dimension 4 + Exemple : ``{"SampleAsnUplet":[[0,1,2,3],[4,3,2,1],[-2,3,-4,5]]}`` pour 3 points dans un espace d'état de dimension 4 SampleAsExplicitHyperCube - Cette clé décrit les points de calcul sous la forme d'un hyper-cube, dont on - donne la liste des échantillonnages explicites de chaque variable comme une - liste. C'est donc une liste de listes, chacune étant de taille - potentiellement différente. + Cette clé décrit les points de calcul sous la forme d'un hyper-cube, dont on + donne la liste des échantillonnages explicites de chaque variable comme une + liste. C'est donc une liste de listes, chacune étant de taille + potentiellement différente. - Exemple : ``{"SampleAsExplicitHyperCube":[[0.,0.25,0.5,0.75,1.], [-2,2,1]]}`` pour un espace d'état de dimension 2 + Exemple : ``{"SampleAsExplicitHyperCube":[[0.,0.25,0.5,0.75,1.], [-2,2,1]]}`` pour un espace d'état de dimension 2 SampleAsMinMaxStepHyperCube - Cette clé décrit les points de calcul sous la forme d'un hyper-cube, dont on - donne la liste des échantillonnages implicites de chaque variable par un - triplet *[min,max,step]*. C'est donc une liste de la même taille que celle - de l'état. Les bornes sont incluses. + Cette clé décrit les points de calcul sous la forme d'un hyper-cube, dont on + donne la liste des échantillonnages implicites de chaque variable par un + triplet *[min,max,step]*. C'est donc une liste de la même taille que celle + de l'état. Les bornes sont incluses. - Exemple : ``{"SampleAsMinMaxStepHyperCube":[[0.,1.,0.25],[-1,3,1]]}`` pour un espace d'état de dimension 2 + Exemple : ``{"SampleAsMinMaxStepHyperCube":[[0.,1.,0.25],[-1,3,1]]}`` pour un espace d'état de dimension 2 SampleAsIndependantRandomVariables - Cette clé décrit les points de calcul sous la forme d'un hyper-cube, dont - les points sur chaque axe proviennent de l'échantillonnage aléatoire - indépendant de la variable d'axe, selon la spécification de la - distribution, de ses paramètres et du nombre de points de l'échantillon, + Cette clé décrit les points de calcul sous la forme d'un hyper-cube, dont + les points sur chaque axe proviennent de l'échantillonnage aléatoire + indépendant de la variable d'axe, selon la spécification de la + distribution, de ses paramètres et du nombre de points de l'échantillon, sous la forme d'une liste ``['distribution', [parametres], nombre]`` pour - chaque axe. Les distributions possibles sont 'normal' de paramètres - (mean,std), 'lognormal' de paramètres (mean,sigma), 'uniform' de paramètres - (low,high), ou 'weibull' de paramètre (shape). C'est donc une liste de la - même taille que celle de l'état. + chaque axe. Les distributions possibles sont 'normal' de paramètres + (mean,std), 'lognormal' de paramètres (mean,sigma), 'uniform' de paramètres + (low,high), ou 'weibull' de paramètre (shape). C'est donc une liste de la + même taille que celle de l'état. - Exemple : ``{"SampleAsIndependantRandomVariables":[ ['normal',[0.,1.],3], ['uniform',[-2,2],4]]`` pour un espace d'état de dimension 2 + Exemple : ``{"SampleAsIndependantRandomVariables":[ ['normal',[0.,1.],3], ['uniform',[-2,2],4]]`` pour un espace d'état de dimension 2 QualityCriterion - Cette clé indique le critère de qualité, qui est utilisé pour trouver - l'estimation de l'état. Le défaut est le critère usuel de l'assimilation de - données nommé "DA", qui est le critère de moindres carrés pondérés - augmentés. Les critères possibles sont dans la liste suivante, dans laquelle - les noms équivalents sont indiqués par un signe "=" : + Cette clé indique le critère de qualité, qui est utilisé pour trouver + l'estimation de l'état. Le défaut est le critère usuel de l'assimilation de + données nommé "DA", qui est le critère de moindres carrés pondérés + augmentés. Les critères possibles sont dans la liste suivante, dans laquelle + les noms équivalents sont indiqués par un signe "=" : ["AugmentedWeightedLeastSquares"="AWLS"="DA", "WeightedLeastSquares"="WLS", "LeastSquares"="LS"="L2", "AbsoluteValue"="L1", "MaximumError"="ME"]. Exemple : ``{"QualityCriterion":"DA"}`` SetDebug - Cette clé requiert l'activation, ou pas, du mode de débogage durant - l'évaluation de la fonction. La valeur par défaut est "True", les choix sont + Cette clé requiert l'activation, ou pas, du mode de débogage durant + l'évaluation de la fonction. La valeur par défaut est "True", les choix sont "True" ou "False". Exemple : ``{"SetDebug":False}`` SetSeed - Cette clé permet de donner un nombre entier pour fixer la graine du - générateur aléatoire utilisé pour générer l'ensemble. Un valeur pratique est - par exemple 1000. Par défaut, la graine est laissée non initialisée, et elle - utilise ainsi l'initialisation par défaut de l'ordinateur. + Cette clé permet de donner un nombre entier pour fixer la graine du + générateur aléatoire utilisé pour générer l'ensemble. Un valeur pratique est + par exemple 1000. Par défaut, la graine est laissée non initialisée, et elle + utilise ainsi l'initialisation par défaut de l'ordinateur. Exemple : ``{"SetSeed":1000}`` StoreSupplementaryCalculations - Cette liste indique les noms des variables supplémentaires qui peuvent être - disponibles à la fin de l'algorithme. Cela implique potentiellement des - calculs ou du stockage coûteux. La valeur par défaut est une liste vide, - aucune de ces variables n'étant calculée et stockée par défaut. Les noms + Cette liste indique les noms des variables supplémentaires qui peuvent être + disponibles à la fin de l'algorithme. Cela implique potentiellement des + calculs ou du stockage coûteux. La valeur par défaut est une liste vide, + aucune de ces variables n'étant calculée et stockée par défaut. Les noms possibles sont dans la liste suivante : ["CostFunctionJ", "CostFunctionJb", "CostFunctionJo", "CurrentState", "InnovationAtCurrentState", "SimulatedObservationAtCurrentState"]. Exemple : ``{"StoreSupplementaryCalculations":["CostFunctionJ", "SimulatedObservationAtCurrentState"]}`` -Informations et variables disponibles à la fin de l'algorithme +Informations et variables disponibles à la fin de l'algorithme ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -En sortie, après exécution de l'algorithme, on dispose d'informations et de +En sortie, après exécution de l'algorithme, on dispose d'informations et de variables issues du calcul. La description des -:ref:`section_ref_output_variables` indique la manière de les obtenir par la -méthode nommée ``get`` de la variable "*ADD*" du post-processing. Les variables -d'entrée, mises à disposition de l'utilisateur en sortie pour faciliter -l'écriture des procédures de post-processing, sont décrites dans +:ref:`section_ref_output_variables` indique la manière de les obtenir par la +méthode nommée ``get`` de la variable "*ADD*" du post-processing. Les variables +d'entrée, mises à disposition de l'utilisateur en sortie pour faciliter +l'écriture des procédures de post-processing, sont décrites dans l':ref:`subsection_r_o_v_Inventaire`. Les sorties non conditionnelles de l'algorithme sont les suivantes: CostFunctionJ - *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart + *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart :math:`J`. Exemple : ``J = ADD.get("CostFunctionJ")[:]`` CostFunctionJb - *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart - :math:`J^b`, c'est-à-dire de la partie écart à l'ébauche. + *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart + :math:`J^b`, c'est-à-dire de la partie écart à l'ébauche. Exemple : ``Jb = ADD.get("CostFunctionJb")[:]`` CostFunctionJo - *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart - :math:`J^o`, c'est-à-dire de la partie écart à l'observation. + *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart + :math:`J^o`, c'est-à-dire de la partie écart à l'observation. Exemple : ``Jo = ADD.get("CostFunctionJo")[:]`` Les sorties conditionnelles de l'algorithme sont les suivantes: CurrentState - *Liste de vecteurs*. Chaque élément est un vecteur d'état courant utilisé - au cours du déroulement de l'algorithme d'optimisation. + *Liste de vecteurs*. Chaque élément est un vecteur d'état courant utilisé + au cours du déroulement de l'algorithme d'optimisation. Exemple : ``Xs = ADD.get("CurrentState")[:]`` InnovationAtCurrentState - *Liste de vecteurs*. Chaque élément est un vecteur d'innovation à l'état + *Liste de vecteurs*. Chaque élément est un vecteur d'innovation à l'état courant. Exemple : ``ds = ADD.get("InnovationAtCurrentState")[-1]`` SimulatedObservationAtCurrentState - *Liste de vecteurs*. Chaque élément est un vecteur d'observation simulé à - partir de l'état courant, c'est-à-dire dans l'espace des observations. + *Liste de vecteurs*. Chaque élément est un vecteur d'observation simulé à + partir de l'état courant, c'est-à-dire dans l'espace des observations. Exemple : ``hxs = ADD.get("SimulatedObservationAtCurrentState")[-1]`` Voir aussi ++++++++++ -Références vers d'autres sections : +Références vers d'autres sections : - :ref:`section_ref_algorithm_FunctionTest` -Références vers d'autres modules SALOME : +Références vers d'autres modules SALOME : - OPENTURNS, voir le *Guide utilisateur du module OPENTURNS* dans le menu principal *Aide* de l'environnement SALOME diff --git a/doc/fr/ref_algorithm_TangentTest.rst b/doc/fr/ref_algorithm_TangentTest.rst index 67aecfa..a2e529c 100644 --- a/doc/fr/ref_algorithm_TangentTest.rst +++ b/doc/fr/ref_algorithm_TangentTest.rst @@ -24,31 +24,31 @@ .. index:: single: TangentTest .. _section_ref_algorithm_TangentTest: -Algorithme de vérification "*TangentTest*" +Algorithme de vérification "*TangentTest*" ------------------------------------------ Description +++++++++++ -Cet algorithme permet de vérifier la qualité de l'opérateur tangent, en -calculant un résidu dont les propriétés théoriques sont connues. +Cet algorithme permet de vérifier la qualité de l'opérateur tangent, en +calculant un résidu dont les propriétés théoriques sont connues. -On observe le résidu suivant, provenant du rapport d'incréments utilisant -l'opérateur linéaire tangent : +On observe le résidu suivant, provenant du rapport d'incréments utilisant +l'opérateur linéaire tangent : .. math:: R(\alpha) = \frac{|| F(\mathbf{x}+\alpha*\mathbf{dx}) - F(\mathbf{x}) ||}{|| \alpha * TangentF_x * \mathbf{dx} ||} -qui doit rester stable en :math:`1+O(\alpha)` jusqu'à ce que l'on atteigne la -précision du calcul. +qui doit rester stable en :math:`1+O(\alpha)` jusqu'à ce que l'on atteigne la +précision du calcul. -Lorsque :math:`|R-1|/\alpha` est inférieur ou égal à une valeur stable lorsque -:math:`\alpha` varie, le tangent est valide, jusqu'à ce que l'on atteigne la -précision du calcul. +Lorsque :math:`|R-1|/\alpha` est inférieur ou égal à une valeur stable lorsque +:math:`\alpha` varie, le tangent est valide, jusqu'à ce que l'on atteigne la +précision du calcul. -Si :math:`|R-1|/\alpha` est très faible, le code de calcul :math:`F` est -vraisemblablement linéaire ou quasi-linéaire (ce que l'on peut vérifier par -l':ref:`section_ref_algorithm_LinearityTest`), et le tangent est valide jusqu'à -ce que l'on atteigne la précision du calcul. +Si :math:`|R-1|/\alpha` est très faible, le code de calcul :math:`F` est +vraisemblablement linéaire ou quasi-linéaire (ce que l'on peut vérifier par +l':ref:`section_ref_algorithm_LinearityTest`), et le tangent est valide jusqu'à +ce que l'on atteigne la précision du calcul. On prend :math:`\mathbf{dx}_0=Normal(0,\mathbf{x})` et :math:`\mathbf{dx}=\alpha*\mathbf{dx}_0`. :math:`F` est le code de calcul. @@ -65,117 +65,117 @@ Commandes requises et optionnelles .. index:: single: SetSeed .. index:: single: StoreSupplementaryCalculations -Les commandes requises générales, disponibles dans l'interface en édition, sont +Les commandes requises générales, disponibles dans l'interface en édition, sont les suivantes: CheckingPoint - *Commande obligatoire*. Elle définit le vecteur utilisé comme l'état autour - duquel réaliser le test requis, noté :math:`\mathbf{x}` et similaire à - l'ébauche :math:`\mathbf{x}^b`. Sa valeur est définie comme un objet de type + *Commande obligatoire*. Elle définit le vecteur utilisé comme l'état autour + duquel réaliser le test requis, noté :math:`\mathbf{x}` et similaire à + l'ébauche :math:`\mathbf{x}^b`. Sa valeur est définie comme un objet de type "*Vector*". ObservationOperator - *Commande obligatoire*. Elle indique l'opérateur d'observation, notée - précédemment :math:`H`, qui transforme les paramètres d'entrée - :math:`\mathbf{x}` en résultats :math:`\mathbf{y}` qui sont à comparer aux - observations :math:`\mathbf{y}^o`. Sa valeur est définie comme un objet de - type "*Function*". Différentes formes fonctionnelles peuvent être - utilisées, comme décrit dans la section - :ref:`section_ref_operator_requirements`. Si un contrôle :math:`U` est - inclus dans le modèle d'observation, l'opérateur doit être appliqué à une + *Commande obligatoire*. Elle indique l'opérateur d'observation, notée + précédemment :math:`H`, qui transforme les paramètres d'entrée + :math:`\mathbf{x}` en résultats :math:`\mathbf{y}` qui sont à comparer aux + observations :math:`\mathbf{y}^o`. Sa valeur est définie comme un objet de + type "*Function*". Différentes formes fonctionnelles peuvent être + utilisées, comme décrit dans la section + :ref:`section_ref_operator_requirements`. Si un contrôle :math:`U` est + inclus dans le modèle d'observation, l'opérateur doit être appliqué à une paire :math:`(X,U)`. -Les commandes optionnelles générales, disponibles dans l'interface en édition, -sont indiquées dans la :ref:`section_ref_checking_keywords`. De plus, les -paramètres de la commande "*AlgorithmParameters*" permettent d'indiquer les -options particulières, décrites ci-après, de l'algorithme. On se reportera à la +Les commandes optionnelles générales, disponibles dans l'interface en édition, +sont indiquées dans la :ref:`section_ref_checking_keywords`. De plus, les +paramètres de la commande "*AlgorithmParameters*" permettent d'indiquer les +options particulières, décrites ci-après, de l'algorithme. On se reportera à la :ref:`section_ref_options_Algorithm_Parameters` pour le bon usage de cette commande. Les options de l'algorithme sont les suivantes: AmplitudeOfInitialDirection - Cette clé indique la mise à l'échelle de la perturbation initiale construite - comme un vecteur utilisé pour la dérivée directionnelle autour du point - nominal de vérification. La valeur par défaut est de 1, ce qui signifie pas - de mise à l'échelle. + Cette clé indique la mise à l'échelle de la perturbation initiale construite + comme un vecteur utilisé pour la dérivée directionnelle autour du point + nominal de vérification. La valeur par défaut est de 1, ce qui signifie pas + de mise à l'échelle. Exemple : ``{"AmplitudeOfInitialDirection":0.5}`` EpsilonMinimumExponent - Cette clé indique la valeur de l'exposant minimal du coefficient en - puissance de 10 qui doit être utilisé pour faire décroître le multiplicateur - de l'incrément. La valeur par défaut est de -8, et elle doit être entre 0 et - -20. Par exemple, la valeur par défaut conduit à calculer le résidu de la - formule avec un incrément fixe multiplié par 1.e0 jusqu'à 1.e-8. + Cette clé indique la valeur de l'exposant minimal du coefficient en + puissance de 10 qui doit être utilisé pour faire décroître le multiplicateur + de l'incrément. La valeur par défaut est de -8, et elle doit être entre 0 et + -20. Par exemple, la valeur par défaut conduit à calculer le résidu de la + formule avec un incrément fixe multiplié par 1.e0 jusqu'à 1.e-8. Exemple : ``{"EpsilonMinimumExponent":-12}`` InitialDirection - Cette clé indique la direction vectorielle utilisée pour la dérivée - directionnelle autour du point nominal de vérification. Cela doit être un - vecteur. Si elle n'est pas spécifiée, la direction par défaut est une - perturbation par défaut autour de zéro de la même taille vectorielle que le - point de vérification. + Cette clé indique la direction vectorielle utilisée pour la dérivée + directionnelle autour du point nominal de vérification. Cela doit être un + vecteur. Si elle n'est pas spécifiée, la direction par défaut est une + perturbation par défaut autour de zéro de la même taille vectorielle que le + point de vérification. Exemple : ``{"InitialDirection":[0.1,0.1,100.,3}`` SetSeed - Cette clé permet de donner un nombre entier pour fixer la graine du - générateur aléatoire utilisé pour générer l'ensemble. Un valeur pratique est - par exemple 1000. Par défaut, la graine est laissée non initialisée, et elle - utilise ainsi l'initialisation par défaut de l'ordinateur. + Cette clé permet de donner un nombre entier pour fixer la graine du + générateur aléatoire utilisé pour générer l'ensemble. Un valeur pratique est + par exemple 1000. Par défaut, la graine est laissée non initialisée, et elle + utilise ainsi l'initialisation par défaut de l'ordinateur. Exemple : ``{"SetSeed":1000}`` StoreSupplementaryCalculations - Cette liste indique les noms des variables supplémentaires qui peuvent être - disponibles à la fin de l'algorithme. Cela implique potentiellement des - calculs ou du stockage coûteux. La valeur par défaut est une liste vide, - aucune de ces variables n'étant calculée et stockée par défaut. Les noms + Cette liste indique les noms des variables supplémentaires qui peuvent être + disponibles à la fin de l'algorithme. Cela implique potentiellement des + calculs ou du stockage coûteux. La valeur par défaut est une liste vide, + aucune de ces variables n'étant calculée et stockée par défaut. Les noms possibles sont dans la liste suivante : ["CurrentState", "Residu", "SimulatedObservationAtCurrentState"]. Exemple : ``{"StoreSupplementaryCalculations":["CurrentState"]}`` -Informations et variables disponibles à la fin de l'algorithme +Informations et variables disponibles à la fin de l'algorithme ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -En sortie, après exécution de l'algorithme, on dispose d'informations et de +En sortie, après exécution de l'algorithme, on dispose d'informations et de variables issues du calcul. La description des -:ref:`section_ref_output_variables` indique la manière de les obtenir par la -méthode nommée ``get`` de la variable "*ADD*" du post-processing. Les variables -d'entrée, mises à disposition de l'utilisateur en sortie pour faciliter -l'écriture des procédures de post-processing, sont décrites dans +:ref:`section_ref_output_variables` indique la manière de les obtenir par la +méthode nommée ``get`` de la variable "*ADD*" du post-processing. Les variables +d'entrée, mises à disposition de l'utilisateur en sortie pour faciliter +l'écriture des procédures de post-processing, sont décrites dans l':ref:`subsection_r_o_v_Inventaire`. Les sorties non conditionnelles de l'algorithme sont les suivantes: Residu - *Liste de valeurs*. Chaque élément est la valeur du résidu particulier - vérifié lors d'un algorithme de vérification, selon l'ordre des tests - effectués. + *Liste de valeurs*. Chaque élément est la valeur du résidu particulier + vérifié lors d'un algorithme de vérification, selon l'ordre des tests + effectués. Exemple : ``r = ADD.get("Residu")[:]`` Les sorties conditionnelles de l'algorithme sont les suivantes: CurrentState - *Liste de vecteurs*. Chaque élément est un vecteur d'état courant utilisé - au cours du déroulement de l'algorithme d'optimisation. + *Liste de vecteurs*. Chaque élément est un vecteur d'état courant utilisé + au cours du déroulement de l'algorithme d'optimisation. Exemple : ``Xs = ADD.get("CurrentState")[:]`` SimulatedObservationAtCurrentState - *Liste de vecteurs*. Chaque élément est un vecteur d'observation simulé à - partir de l'état courant, c'est-à-dire dans l'espace des observations. + *Liste de vecteurs*. Chaque élément est un vecteur d'observation simulé à + partir de l'état courant, c'est-à-dire dans l'espace des observations. Exemple : ``hxs = ADD.get("SimulatedObservationAtCurrentState")[-1]`` Voir aussi ++++++++++ -Références vers d'autres sections : +Références vers d'autres sections : - :ref:`section_ref_algorithm_FunctionTest` - :ref:`section_ref_algorithm_LinearityTest` - :ref:`section_ref_algorithm_AdjointTest` diff --git a/doc/fr/ref_algorithm_UnscentedKalmanFilter.rst b/doc/fr/ref_algorithm_UnscentedKalmanFilter.rst index e0e82cd..ece43de 100644 --- a/doc/fr/ref_algorithm_UnscentedKalmanFilter.rst +++ b/doc/fr/ref_algorithm_UnscentedKalmanFilter.rst @@ -30,10 +30,10 @@ Algorithme de calcul "*UnscentedKalmanFilter*" Description +++++++++++ -Cet algorithme réalise une estimation de l'état d'un système dynamique par un -filtre de Kalman "unscented", permettant d'éviter de devoir calculer les -opérateurs tangent ou adjoint pour les opérateurs d'observation ou d'évolution, -comme dans les filtres de Kalman simple ou étendu. +Cet algorithme réalise une estimation de l'état d'un système dynamique par un +filtre de Kalman "unscented", permettant d'éviter de devoir calculer les +opérateurs tangent ou adjoint pour les opérateurs d'observation ou d'évolution, +comme dans les filtres de Kalman simple ou étendu. Commandes requises et optionnelles ++++++++++++++++++++++++++++++++++ @@ -53,90 +53,90 @@ Commandes requises et optionnelles .. index:: single: Reconditioner .. index:: single: StoreSupplementaryCalculations -Les commandes requises générales, disponibles dans l'interface en édition, sont +Les commandes requises générales, disponibles dans l'interface en édition, sont les suivantes: Background - *Commande obligatoire*. Elle définit le vecteur d'ébauche ou - d'initialisation, noté précédemment :math:`\mathbf{x}^b`. Sa valeur est - définie comme un objet de type "*Vector*" ou de type "*VectorSerie*". + *Commande obligatoire*. Elle définit le vecteur d'ébauche ou + d'initialisation, noté précédemment :math:`\mathbf{x}^b`. Sa valeur est + définie comme un objet de type "*Vector*" ou de type "*VectorSerie*". BackgroundError - *Commande obligatoire*. Elle définit la matrice de covariance des erreurs - d'ébauche, notée précédemment :math:`\mathbf{B}`. Sa valeur est définie + *Commande obligatoire*. Elle définit la matrice de covariance des erreurs + d'ébauche, notée précédemment :math:`\mathbf{B}`. Sa valeur est définie comme un objet de type "*Matrix*", de type "*ScalarSparseMatrix*", ou de type "*DiagonalSparseMatrix*". Observation - *Commande obligatoire*. Elle définit le vecteur d'observation utilisé en - assimilation de données ou en optimisation, et noté précédemment - :math:`\mathbf{y}^o`. Sa valeur est définie comme un objet de type "*Vector*" + *Commande obligatoire*. Elle définit le vecteur d'observation utilisé en + assimilation de données ou en optimisation, et noté précédemment + :math:`\mathbf{y}^o`. Sa valeur est définie comme un objet de type "*Vector*" ou de type "*VectorSerie*". ObservationError - *Commande obligatoire*. Elle définit la matrice de covariance des erreurs - d'ébauche, notée précédemment :math:`\mathbf{R}`. Sa valeur est définie + *Commande obligatoire*. Elle définit la matrice de covariance des erreurs + d'ébauche, notée précédemment :math:`\mathbf{R}`. Sa valeur est définie comme un objet de type "*Matrix*", de type "*ScalarSparseMatrix*", ou de type "*DiagonalSparseMatrix*". ObservationOperator - *Commande obligatoire*. Elle indique l'opérateur d'observation, noté - précédemment :math:`H`, qui transforme les paramètres d'entrée - :math:`\mathbf{x}` en résultats :math:`\mathbf{y}` qui sont à comparer aux - observations :math:`\mathbf{y}^o`. Sa valeur est définie comme un objet de + *Commande obligatoire*. Elle indique l'opérateur d'observation, noté + précédemment :math:`H`, qui transforme les paramètres d'entrée + :math:`\mathbf{x}` en résultats :math:`\mathbf{y}` qui sont à comparer aux + observations :math:`\mathbf{y}^o`. Sa valeur est définie comme un objet de type "*Function*" ou de type "*Matrix*". Dans le cas du type "*Function*", - différentes formes fonctionnelles peuvent être utilisées, comme décrit dans - la section :ref:`section_ref_operator_requirements`. Si un contrôle - :math:`U` est inclus dans le modèle d'observation, l'opérateur doit être - appliqué à une paire :math:`(X,U)`. - -Les commandes optionnelles générales, disponibles dans l'interface en édition, -sont indiquées dans la :ref:`section_ref_assimilation_keywords`. De plus, les -paramètres de la commande "*AlgorithmParameters*" permettent d'indiquer les -options particulières, décrites ci-après, de l'algorithme. On se reportera à la + différentes formes fonctionnelles peuvent être utilisées, comme décrit dans + la section :ref:`section_ref_operator_requirements`. Si un contrôle + :math:`U` est inclus dans le modèle d'observation, l'opérateur doit être + appliqué à une paire :math:`(X,U)`. + +Les commandes optionnelles générales, disponibles dans l'interface en édition, +sont indiquées dans la :ref:`section_ref_assimilation_keywords`. De plus, les +paramètres de la commande "*AlgorithmParameters*" permettent d'indiquer les +options particulières, décrites ci-après, de l'algorithme. On se reportera à la :ref:`section_ref_options_Algorithm_Parameters` pour le bon usage de cette commande. Les options de l'algorithme sont les suivantes: Bounds - Cette clé permet de définir des bornes supérieure et inférieure pour chaque - variable d'état optimisée. Les bornes doivent être données par une liste de - liste de paires de bornes inférieure/supérieure pour chaque variable, avec - une valeur extrême chaque fois qu'il n'y a pas de borne (``None`` n'est pas - une valeur autorisée lorsqu'il n'y a pas de borne). + Cette clé permet de définir des bornes supérieure et inférieure pour chaque + variable d'état optimisée. Les bornes doivent être données par une liste de + liste de paires de bornes inférieure/supérieure pour chaque variable, avec + une valeur extrême chaque fois qu'il n'y a pas de borne (``None`` n'est pas + une valeur autorisée lorsqu'il n'y a pas de borne). Exemple : ``{"Bounds":[[2.,5.],[1.e-2,10.],[-30.,1.e99],[-1.e99,1.e99]]}`` ConstrainedBy - Cette clé permet d'indiquer la méthode de prise en compte des contraintes de + Cette clé permet d'indiquer la méthode de prise en compte des contraintes de bornes. La seule disponible est "EstimateProjection", qui projette - l'estimation de l'état courant sur les contraintes de bornes. + l'estimation de l'état courant sur les contraintes de bornes. Exemple : ``{"ConstrainedBy":"EstimateProjection"}`` EstimationOf - Cette clé permet de choisir le type d'estimation à réaliser. Cela peut être - soit une estimation de l'état, avec la valeur "State", ou une estimation de - paramètres, avec la valeur "Parameters". Le choix par défaut est "State". + Cette clé permet de choisir le type d'estimation à réaliser. Cela peut être + soit une estimation de l'état, avec la valeur "State", ou une estimation de + paramètres, avec la valeur "Parameters". Le choix par défaut est "State". Exemple : ``{"EstimationOf":"Parameters"}`` Alpha, Beta, Kappa, Reconditioner - Ces clés sont des paramètres de mise à l'échelle interne. "Alpha" requiert + Ces clés sont des paramètres de mise à l'échelle interne. "Alpha" requiert une valeur comprise entre 1.e-4 et 1. "Beta" a une valeur optimale de 2 pour - une distribution *a priori* gaussienne. "Kappa" requiert une valeur entière, - dont la bonne valeur par défaut est obtenue en la mettant à 0. - "Reconditioner" requiert une valeur comprise entre 1.e-3 et 10, son défaut - étant 1. + une distribution *a priori* gaussienne. "Kappa" requiert une valeur entière, + dont la bonne valeur par défaut est obtenue en la mettant à 0. + "Reconditioner" requiert une valeur comprise entre 1.e-3 et 10, son défaut + étant 1. Exemple : ``{"Alpha":1,"Beta":2,"Kappa":0,"Reconditioner":1}`` StoreSupplementaryCalculations - Cette liste indique les noms des variables supplémentaires qui peuvent être - disponibles à la fin de l'algorithme. Cela implique potentiellement des - calculs ou du stockage coûteux. La valeur par défaut est une liste vide, - aucune de ces variables n'étant calculée et stockée par défaut. Les noms + Cette liste indique les noms des variables supplémentaires qui peuvent être + disponibles à la fin de l'algorithme. Cela implique potentiellement des + calculs ou du stockage coûteux. La valeur par défaut est une liste vide, + aucune de ces variables n'étant calculée et stockée par défaut. Les noms possibles sont dans la liste suivante : ["APosterioriCorrelations", "APosterioriCovariance", "APosterioriStandardDeviations", "APosterioriVariances", "BMA", "CostFunctionJ", "CostFunctionJb", @@ -144,95 +144,95 @@ Les options de l'algorithme sont les suivantes: Exemple : ``{"StoreSupplementaryCalculations":["BMA", "Innovation"]}`` -Informations et variables disponibles à la fin de l'algorithme +Informations et variables disponibles à la fin de l'algorithme ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -En sortie, après exécution de l'algorithme, on dispose d'informations et de +En sortie, après exécution de l'algorithme, on dispose d'informations et de variables issues du calcul. La description des -:ref:`section_ref_output_variables` indique la manière de les obtenir par la -méthode nommée ``get`` de la variable "*ADD*" du post-processing. Les variables -d'entrée, mises à disposition de l'utilisateur en sortie pour faciliter -l'écriture des procédures de post-processing, sont décrites dans +:ref:`section_ref_output_variables` indique la manière de les obtenir par la +méthode nommée ``get`` de la variable "*ADD*" du post-processing. Les variables +d'entrée, mises à disposition de l'utilisateur en sortie pour faciliter +l'écriture des procédures de post-processing, sont décrites dans l':ref:`subsection_r_o_v_Inventaire`. Les sorties non conditionnelles de l'algorithme sont les suivantes: Analysis - *Liste de vecteurs*. Chaque élément est un état optimal :math:`\mathbf{x}*` + *Liste de vecteurs*. Chaque élément est un état optimal :math:`\mathbf{x}*` en optimisation ou une analyse :math:`\mathbf{x}^a` en assimilation de - données. + données. Exemple : ``Xa = ADD.get("Analysis")[-1]`` Les sorties conditionnelles de l'algorithme sont les suivantes: APosterioriCorrelations - *Liste de matrices*. Chaque élément est une matrice de corrélation des - erreurs *a posteriori* de l'état optimal. + *Liste de matrices*. Chaque élément est une matrice de corrélation des + erreurs *a posteriori* de l'état optimal. Exemple : ``C = ADD.get("APosterioriCorrelations")[-1]`` APosterioriCovariance - *Liste de matrices*. Chaque élément est une matrice :math:`\mathbf{A}*` de - covariances des erreurs *a posteriori* de l'état optimal. + *Liste de matrices*. Chaque élément est une matrice :math:`\mathbf{A}*` de + covariances des erreurs *a posteriori* de l'état optimal. Exemple : ``A = ADD.get("APosterioriCovariance")[-1]`` APosterioriStandardDeviations - *Liste de matrices*. Chaque élément est une matrice d'écart-types des - erreurs *a posteriori* de l'état optimal. + *Liste de matrices*. Chaque élément est une matrice d'écart-types des + erreurs *a posteriori* de l'état optimal. Exemple : ``E = ADD.get("APosterioriStandardDeviations")[-1]`` APosterioriVariances - *Liste de matrices*. Chaque élément est une matrice de variances des erreurs - *a posteriori* de l'état optimal. + *Liste de matrices*. Chaque élément est une matrice de variances des erreurs + *a posteriori* de l'état optimal. Exemple : ``V = ADD.get("APosterioriVariances")[-1]`` BMA - *Liste de vecteurs*. Chaque élément est un vecteur d'écart entre - l'ébauche et l'état optimal. + *Liste de vecteurs*. Chaque élément est un vecteur d'écart entre + l'ébauche et l'état optimal. Exemple : ``bma = ADD.get("BMA")[-1]`` CostFunctionJ - *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart + *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart :math:`J`. Exemple : ``J = ADD.get("CostFunctionJ")[:]`` CostFunctionJb - *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart - :math:`J^b`, c'est-à-dire de la partie écart à l'ébauche. + *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart + :math:`J^b`, c'est-à-dire de la partie écart à l'ébauche. Exemple : ``Jb = ADD.get("CostFunctionJb")[:]`` CostFunctionJo - *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart - :math:`J^o`, c'est-à-dire de la partie écart à l'observation. + *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart + :math:`J^o`, c'est-à-dire de la partie écart à l'observation. Exemple : ``Jo = ADD.get("CostFunctionJo")[:]`` CurrentState - *Liste de vecteurs*. Chaque élément est un vecteur d'état courant utilisé - au cours du déroulement de l'algorithme d'optimisation. + *Liste de vecteurs*. Chaque élément est un vecteur d'état courant utilisé + au cours du déroulement de l'algorithme d'optimisation. Exemple : ``Xs = ADD.get("CurrentState")[:]`` Innovation - *Liste de vecteurs*. Chaque élément est un vecteur d'innovation, qui est - en statique l'écart de l'optimum à l'ébauche, et en dynamique l'incrément - d'évolution. + *Liste de vecteurs*. Chaque élément est un vecteur d'innovation, qui est + en statique l'écart de l'optimum à l'ébauche, et en dynamique l'incrément + d'évolution. Exemple : ``d = ADD.get("Innovation")[-1]`` Voir aussi ++++++++++ -Références vers d'autres sections : +Références vers d'autres sections : - :ref:`section_ref_algorithm_KalmanFilter` - :ref:`section_ref_algorithm_ExtendedKalmanFilter` -Références bibliographiques : +Références bibliographiques : - [WikipediaUKF]_ diff --git a/doc/fr/ref_assimilation_keywords.rst b/doc/fr/ref_assimilation_keywords.rst index 78404c4..959466d 100644 --- a/doc/fr/ref_assimilation_keywords.rst +++ b/doc/fr/ref_assimilation_keywords.rst @@ -24,7 +24,7 @@ .. index:: single: ASSIMILATION_STUDY .. _section_ref_assimilation_keywords: -Liste des commandes et mots-clés pour un cas d'assimilation de données ou d'optimisation +Liste des commandes et mots-clés pour un cas d'assimilation de données ou d'optimisation ---------------------------------------------------------------------------------------- .. index:: single: Algorithm @@ -49,134 +49,134 @@ Liste des commandes et mots-cl .. index:: single: UserPostAnalysis .. index:: single: UserPostAnalysis Template -Ce jeu de commandes est lié à la description d'un cas de calcul, qui est une -procédure d'*Assimilation de Données* ou d'*Optimisation*. Les termes sont -classés par ordre alphabétique, sauf le premier, qui décrit le choix entre le -calcul ou la vérification. +Ce jeu de commandes est lié à la description d'un cas de calcul, qui est une +procédure d'*Assimilation de Données* ou d'*Optimisation*. Les termes sont +classés par ordre alphabétique, sauf le premier, qui décrit le choix entre le +calcul ou la vérification. -Les différentes commandes sont les suivantes: +Les différentes commandes sont les suivantes: **ASSIMILATION_STUDY** - *Commande obligatoire*. C'est la commande générale qui décrit le cas - d'assimilation de données ou d'optimisation. Elle contient hiérarchiquement + *Commande obligatoire*. C'est la commande générale qui décrit le cas + d'assimilation de données ou d'optimisation. Elle contient hiérarchiquement toutes les autres commandes. AlgorithmParameters - *Commande obligatoire*. Elle définit l'algorithme d'assimilation de données - ou d'optimisation choisi par le mot-clé "*Algorithm*", et ses éventuels - paramètres optionnels. Les choix d'algorithmes sont disponibles à travers + *Commande obligatoire*. Elle définit l'algorithme d'assimilation de données + ou d'optimisation choisi par le mot-clé "*Algorithm*", et ses éventuels + paramètres optionnels. Les choix d'algorithmes sont disponibles à travers l'interface graphique. Il existe par exemple le "3DVAR", le "Blue"... Chaque - algorithme est défini, plus loin, par une sous-section spécifique. De - manière facultative, la commande permet aussi d'ajouter des paramètres pour - contrôler l'algorithme. Leurs valeurs sont définies explicitement ou dans un - objet de type "*Dict*". On se reportera à la - :ref:`section_ref_options_Algorithm_Parameters` pour l'usage détaillé de + algorithme est défini, plus loin, par une sous-section spécifique. De + manière facultative, la commande permet aussi d'ajouter des paramètres pour + contrôler l'algorithme. Leurs valeurs sont définies explicitement ou dans un + objet de type "*Dict*". On se reportera à la + :ref:`section_ref_options_Algorithm_Parameters` pour l'usage détaillé de cette partie de la commande. Background - *Commande obligatoire*. Elle définit le vecteur d'ébauche ou - d'initialisation, noté précédemment :math:`\mathbf{x}^b`. Sa valeur est - définie comme un objet de type "*Vector*". + *Commande obligatoire*. Elle définit le vecteur d'ébauche ou + d'initialisation, noté précédemment :math:`\mathbf{x}^b`. Sa valeur est + définie comme un objet de type "*Vector*". BackgroundError - *Commande obligatoire*. Elle définit la matrice de covariance des erreurs - d'ébauche, notée précédemment :math:`\mathbf{B}`. Sa valeur est définie + *Commande obligatoire*. Elle définit la matrice de covariance des erreurs + d'ébauche, notée précédemment :math:`\mathbf{B}`. Sa valeur est définie comme un objet de type "*Matrix*", de type "*ScalarSparseMatrix*", ou de type "*DiagonalSparseMatrix*". ControlInput - *Commande optionnelle*. Elle indique le vecteur de contrôle utilisé pour - forcer le modèle d'évolution à chaque pas, usuellement noté - :math:`\mathbf{U}`. Sa valeur est définie comme un objet de type "*Vector*" - ou de type "*VectorSerie*". Lorsqu'il n'y a pas de contrôle, sa valeur doit - être une chaîne vide ''. + *Commande optionnelle*. Elle indique le vecteur de contrôle utilisé pour + forcer le modèle d'évolution à chaque pas, usuellement noté + :math:`\mathbf{U}`. Sa valeur est définie comme un objet de type "*Vector*" + ou de type "*VectorSerie*". Lorsqu'il n'y a pas de contrôle, sa valeur doit + être une chaîne vide ''. Debug - *Commande optionnelle*. Elle définit le niveau de sorties et d'informations - intermédiaires de débogage. Les choix sont limités entre 0 (pour False) et + *Commande optionnelle*. Elle définit le niveau de sorties et d'informations + intermédiaires de débogage. Les choix sont limités entre 0 (pour False) et 1 (pour True). EvolutionError - *Commande optionnelle*. Elle définit la matrice de covariance des erreurs - d'évolution, usuellement notée :math:`\mathbf{Q}`. Sa valeur est définie + *Commande optionnelle*. Elle définit la matrice de covariance des erreurs + d'évolution, usuellement notée :math:`\mathbf{Q}`. Sa valeur est définie comme un objet de type "*Matrix*", de type "*ScalarSparseMatrix*", ou de type "*DiagonalSparseMatrix*". EvolutionModel - *Commande optionnelle*. Elle indique l'opérateur d'évolution du modèle, - usuellement noté :math:`M`, qui décrit un pas élémentaire d'évolution. Sa - valeur est définie comme un objet de type "*Function*" ou de type - "*Matrix*". Dans le cas du type "*Function*", différentes formes - fonctionnelles peuvent être utilisées, comme décrit dans la section - :ref:`section_ref_operator_requirements`. Si un contrôle :math:`U` est - inclus dans le modèle d'évolution, l'opérateur doit être appliqué à une + *Commande optionnelle*. Elle indique l'opérateur d'évolution du modèle, + usuellement noté :math:`M`, qui décrit un pas élémentaire d'évolution. Sa + valeur est définie comme un objet de type "*Function*" ou de type + "*Matrix*". Dans le cas du type "*Function*", différentes formes + fonctionnelles peuvent être utilisées, comme décrit dans la section + :ref:`section_ref_operator_requirements`. Si un contrôle :math:`U` est + inclus dans le modèle d'évolution, l'opérateur doit être appliqué à une paire :math:`(X,U)`. InputVariables *Commande optionnelle*. Elle permet d'indiquer le nom et la taille des - variables physiques qui sont rassemblées dans le vecteur d'état. Cette - information est destinée à être utilisée dans le traitement algorithmique - interne des données. + variables physiques qui sont rassemblées dans le vecteur d'état. Cette + information est destinée à être utilisée dans le traitement algorithmique + interne des données. Observation - *Commande obligatoire*. Elle définit le vecteur d'observation utilisé en - assimilation de données ou en optimisation, et noté précédemment - :math:`\mathbf{y}^o`. Sa valeur est définie comme un objet de type "*Vector*" + *Commande obligatoire*. Elle définit le vecteur d'observation utilisé en + assimilation de données ou en optimisation, et noté précédemment + :math:`\mathbf{y}^o`. Sa valeur est définie comme un objet de type "*Vector*" ou de type "*VectorSerie*". ObservationError - *Commande obligatoire*. Elle définit la matrice de covariance des erreurs - d'ébauche, notée précédemment :math:`\mathbf{R}`. Sa valeur est définie + *Commande obligatoire*. Elle définit la matrice de covariance des erreurs + d'ébauche, notée précédemment :math:`\mathbf{R}`. Sa valeur est définie comme un objet de type "*Matrix*", de type "*ScalarSparseMatrix*", ou de type "*DiagonalSparseMatrix*". ObservationOperator - *Commande obligatoire*. Elle indique l'opérateur d'observation, noté - précédemment :math:`H`, qui transforme les paramètres d'entrée - :math:`\mathbf{x}` en résultats :math:`\mathbf{y}` qui sont à comparer aux - observations :math:`\mathbf{y}^o`. Sa valeur est définie comme un objet de + *Commande obligatoire*. Elle indique l'opérateur d'observation, noté + précédemment :math:`H`, qui transforme les paramètres d'entrée + :math:`\mathbf{x}` en résultats :math:`\mathbf{y}` qui sont à comparer aux + observations :math:`\mathbf{y}^o`. Sa valeur est définie comme un objet de type "*Function*" ou de type "*Matrix*". Dans le cas du type "*Function*", - différentes formes fonctionnelles peuvent être utilisées, comme décrit dans - la section :ref:`section_ref_operator_requirements`. Si un contrôle - :math:`U` est inclus dans le modèle d'observation, l'opérateur doit être - appliqué à une paire :math:`(X,U)`. + différentes formes fonctionnelles peuvent être utilisées, comme décrit dans + la section :ref:`section_ref_operator_requirements`. Si un contrôle + :math:`U` est inclus dans le modèle d'observation, l'opérateur doit être + appliqué à une paire :math:`(X,U)`. Observers - *Commande optionnelle*. Elle permet de définir des observateurs internes, - qui sont des fonctions liées à une variable particulière, qui sont exécutées - chaque fois que cette variable est modifiée. C'est une manière pratique de - suivre des variables d'intérêt durant le processus d'assimilation de données - ou d'optimisation, en l'affichant ou en la traçant, etc. Des exemples + *Commande optionnelle*. Elle permet de définir des observateurs internes, + qui sont des fonctions liées à une variable particulière, qui sont exécutées + chaque fois que cette variable est modifiée. C'est une manière pratique de + suivre des variables d'intérêt durant le processus d'assimilation de données + ou d'optimisation, en l'affichant ou en la traçant, etc. Des exemples courants (squelettes) sont fournis pour aider l'utilisateur ou pour - faciliter l'élaboration d'un cas. + faciliter l'élaboration d'un cas. OutputVariables - *Commande optionnelle*. Elle permet d'indiquer le nom et la taille des - variables physiques qui sont rassemblées dans le vecteur d'observation. - Cette information est destinée à être utilisée dans le traitement - algorithmique interne des données. + *Commande optionnelle*. Elle permet d'indiquer le nom et la taille des + variables physiques qui sont rassemblées dans le vecteur d'observation. + Cette information est destinée à être utilisée dans le traitement + algorithmique interne des données. StudyName - *Commande obligatoire*. C'est une chaîne de caractères quelconque pour - décrire l'étude ADAO par un nom ou une déclaration. + *Commande obligatoire*. C'est une chaîne de caractères quelconque pour + décrire l'étude ADAO par un nom ou une déclaration. StudyRepertory - *Commande optionnelle*. S'il existe, ce répertoire est utilisé comme base - pour les calculs, et il est utilisé pour trouver les fichiers de script, - donnés par nom sans répertoire, qui peuvent être utilisés pour définir + *Commande optionnelle*. S'il existe, ce répertoire est utilisé comme base + pour les calculs, et il est utilisé pour trouver les fichiers de script, + donnés par nom sans répertoire, qui peuvent être utilisés pour définir certaines variables. UserDataInit - *Commande optionnelle*. Elle permet d'initialiser certains paramètres ou - certaines données automatiquement avant le traitement de données d'entrée - pour l'assimilation de données ou l'optimisation. Pour cela, elle indique un - nom de fichier de script à exécuter avant d'entrer dans l'initialisation des + *Commande optionnelle*. Elle permet d'initialiser certains paramètres ou + certaines données automatiquement avant le traitement de données d'entrée + pour l'assimilation de données ou l'optimisation. Pour cela, elle indique un + nom de fichier de script à exécuter avant d'entrer dans l'initialisation des variables choisies. UserPostAnalysis - *Commande optionnelle*. Elle permet de traiter des paramètres ou des - résultats après le déroulement de l'algorithme d'assimilation de données ou - d'optimisation. Sa valeur est définie comme un fichier script ou une chaîne - de caractères, permettant de produire directement du code de post-processing + *Commande optionnelle*. Elle permet de traiter des paramètres ou des + résultats après le déroulement de l'algorithme d'assimilation de données ou + d'optimisation. Sa valeur est définie comme un fichier script ou une chaîne + de caractères, permettant de produire directement du code de post-processing dans un cas ADAO. Des exemples courants (squelettes) sont fournis pour aider - l'utilisateur ou pour faciliter l'élaboration d'un cas. + l'utilisateur ou pour faciliter l'élaboration d'un cas. diff --git a/doc/fr/ref_checking_keywords.rst b/doc/fr/ref_checking_keywords.rst index 74b5cc4..d618fab 100644 --- a/doc/fr/ref_checking_keywords.rst +++ b/doc/fr/ref_checking_keywords.rst @@ -24,7 +24,7 @@ .. index:: single: CHECKING_STUDY .. _section_ref_checking_keywords: -Liste des commandes et mots-clés pour un cas de vérification +Liste des commandes et mots-clés pour un cas de vérification ------------------------------------------------------------ .. index:: single: Algorithm @@ -42,91 +42,91 @@ Liste des commandes et mots-cl .. index:: single: StudyRepertory .. index:: single: UserDataInit -Ce jeu de commandes est lié à la description d'un cas de vérification, qui est -une procédure pour vérifier les propriétés d'une information requise, utilisée -ailleurs par un cas de calcul. Les termes sont classés par ordre alphabétique, -sauf le premier, qui décrit le choix entre le calcul ou la vérification. +Ce jeu de commandes est lié à la description d'un cas de vérification, qui est +une procédure pour vérifier les propriétés d'une information requise, utilisée +ailleurs par un cas de calcul. Les termes sont classés par ordre alphabétique, +sauf le premier, qui décrit le choix entre le calcul ou la vérification. -Les différentes commandes sont les suivantes: +Les différentes commandes sont les suivantes: **CHECKING_STUDY** - *Commande obligatoire*. C'est la commande générale qui décrit le cas de - vérification. Elle contient hiérarchiquement toutes les autres commandes. + *Commande obligatoire*. C'est la commande générale qui décrit le cas de + vérification. Elle contient hiérarchiquement toutes les autres commandes. AlgorithmParameters - *Commande obligatoire*. Elle définit l'algorithme de test choisi par le - mot-clé "*Algorithm*", et ses éventuels paramètres optionnels. Les choix - d'algorithmes sont disponibles à travers l'interface graphique. Il existe + *Commande obligatoire*. Elle définit l'algorithme de test choisi par le + mot-clé "*Algorithm*", et ses éventuels paramètres optionnels. Les choix + d'algorithmes sont disponibles à travers l'interface graphique. Il existe par exemple le "FunctionTest", le "GradientTest"... Chaque algorithme est - défini, plus loin, par une sous-section spécifique. De manière facultative, - la commande permet aussi d'ajouter des paramètres pour contrôler - l'algorithme. Leurs valeurs sont définies explicitement ou dans un objet de - type "*Dict*". On se reportera à la - :ref:`section_ref_options_Algorithm_Parameters` pour l'usage détaillé de + défini, plus loin, par une sous-section spécifique. De manière facultative, + la commande permet aussi d'ajouter des paramètres pour contrôler + l'algorithme. Leurs valeurs sont définies explicitement ou dans un objet de + type "*Dict*". On se reportera à la + :ref:`section_ref_options_Algorithm_Parameters` pour l'usage détaillé de cette partie de la commande. CheckingPoint - *Commande obligatoire*. Elle définit le vecteur utilisé comme l'état autour - duquel réaliser le test requis, noté :math:`\mathbf{x}` et similaire à - l'ébauche :math:`\mathbf{x}^b`. Sa valeur est définie comme un objet de type + *Commande obligatoire*. Elle définit le vecteur utilisé comme l'état autour + duquel réaliser le test requis, noté :math:`\mathbf{x}` et similaire à + l'ébauche :math:`\mathbf{x}^b`. Sa valeur est définie comme un objet de type "*Vector*". BackgroundError - *Commande obligatoire*. Elle définit la matrice de covariance des erreurs - d'ébauche, notée précédemment :math:`\mathbf{B}`. Sa valeur est définie + *Commande obligatoire*. Elle définit la matrice de covariance des erreurs + d'ébauche, notée précédemment :math:`\mathbf{B}`. Sa valeur est définie comme un objet de type "*Matrix*", de type "*ScalarSparseMatrix*", ou de type "*DiagonalSparseMatrix*". Debug - *Commande optionnelle*. Elle définit le niveau de sorties et d'informations - intermédiaires de débogage. Les choix sont limités entre 0 (pour False) et + *Commande optionnelle*. Elle définit le niveau de sorties et d'informations + intermédiaires de débogage. Les choix sont limités entre 0 (pour False) et 1 (pour True). Observation - *Commande obligatoire*. Elle définit le vecteur d'observation utilisé en - assimilation de données ou en optimisation, et noté précédemment - :math:`\mathbf{y}^o`. Sa valeur est définie comme un objet de type "*Vector*" + *Commande obligatoire*. Elle définit le vecteur d'observation utilisé en + assimilation de données ou en optimisation, et noté précédemment + :math:`\mathbf{y}^o`. Sa valeur est définie comme un objet de type "*Vector*" ou de type "*VectorSerie*". ObservationError - *Commande obligatoire*. Elle définit la matrice de covariance des erreurs - d'ébauche, notée précédemment :math:`\mathbf{R}`. Sa valeur est définie + *Commande obligatoire*. Elle définit la matrice de covariance des erreurs + d'ébauche, notée précédemment :math:`\mathbf{R}`. Sa valeur est définie comme un objet de type "*Matrix*", de type "*ScalarSparseMatrix*", ou de type "*DiagonalSparseMatrix*". ObservationOperator - *Commande obligatoire*. Elle indique l'opérateur d'observation, noté - précédemment :math:`H`, qui transforme les paramètres d'entrée - :math:`\mathbf{x}` en résultats :math:`\mathbf{y}` qui sont à comparer aux - observations :math:`\mathbf{y}^o`. Sa valeur est définie comme un objet de + *Commande obligatoire*. Elle indique l'opérateur d'observation, noté + précédemment :math:`H`, qui transforme les paramètres d'entrée + :math:`\mathbf{x}` en résultats :math:`\mathbf{y}` qui sont à comparer aux + observations :math:`\mathbf{y}^o`. Sa valeur est définie comme un objet de type "*Function*" ou de type "*Matrix*". Dans le cas du type "*Function*", - différentes formes fonctionnelles peuvent être utilisées, comme décrit dans - la section :ref:`section_ref_operator_requirements`. Si un contrôle - :math:`U` est inclus dans le modèle d'observation, l'opérateur doit être - appliqué à une paire :math:`(X,U)`. + différentes formes fonctionnelles peuvent être utilisées, comme décrit dans + la section :ref:`section_ref_operator_requirements`. Si un contrôle + :math:`U` est inclus dans le modèle d'observation, l'opérateur doit être + appliqué à une paire :math:`(X,U)`. Observers - *Commande optionnelle*. Elle permet de définir des observateurs internes, - qui sont des fonctions liées à une variable particulière, qui sont exécutées - chaque fois que cette variable est modifiée. C'est une manière pratique de - suivre des variables d'intérêt durant le processus d'assimilation de données - ou d'optimisation, en l'affichant ou en la traçant, etc. Des exemples + *Commande optionnelle*. Elle permet de définir des observateurs internes, + qui sont des fonctions liées à une variable particulière, qui sont exécutées + chaque fois que cette variable est modifiée. C'est une manière pratique de + suivre des variables d'intérêt durant le processus d'assimilation de données + ou d'optimisation, en l'affichant ou en la traçant, etc. Des exemples courants (squelettes) sont fournis pour aider l'utilisateur ou pour - faciliter l'élaboration d'un cas. + faciliter l'élaboration d'un cas. StudyName - *Commande obligatoire*. C'est une chaîne de caractères quelconque pour - décrire l'étude ADAO par un nom ou une déclaration. + *Commande obligatoire*. C'est une chaîne de caractères quelconque pour + décrire l'étude ADAO par un nom ou une déclaration. StudyRepertory - *Commande optionnelle*. S'il existe, ce répertoire est utilisé comme base - pour les calculs, et il est utilisé pour trouver les fichiers de script, - donnés par nom sans répertoire, qui peuvent être utilisés pour définir + *Commande optionnelle*. S'il existe, ce répertoire est utilisé comme base + pour les calculs, et il est utilisé pour trouver les fichiers de script, + donnés par nom sans répertoire, qui peuvent être utilisés pour définir certaines variables. UserDataInit - *Commande optionnelle*. Elle permet d'initialiser certains paramètres ou - certaines données automatiquement avant le traitement de données d'entrée - pour l'assimilation de données ou l'optimisation. Pour cela, elle indique un - nom de fichier de script à exécuter avant d'entrer dans l'initialisation des + *Commande optionnelle*. Elle permet d'initialiser certains paramètres ou + certaines données automatiquement avant le traitement de données d'entrée + pour l'assimilation de données ou l'optimisation. Pour cela, elle indique un + nom de fichier de script à exécuter avant d'entrer dans l'initialisation des variables choisies. diff --git a/doc/fr/ref_covariance_requirements.rst b/doc/fr/ref_covariance_requirements.rst index 2235ee8..e5841ac 100644 --- a/doc/fr/ref_covariance_requirements.rst +++ b/doc/fr/ref_covariance_requirements.rst @@ -23,42 +23,42 @@ .. _section_ref_covariance_requirements: -Exigences pour décrire les matrices de covariance +Exigences pour décrire les matrices de covariance ------------------------------------------------- .. index:: single: matrice de covariance -.. index:: single: covariances d'erreurs d'ébauche +.. index:: single: covariances d'erreurs d'ébauche .. index:: single: covariances d'erreurs d'observation .. index:: single: covariances -De manière générale, une matrice de covariance (ou une matrice de -variance-covariance) doit être carrée, symétrique, semi-définie positive. Chacun -de ses termes décrit la covariance des deux variables aléatoires correspondantes -à sa position dans la matrice. La forme normalisée de la covariance est la -corrélation linéaire. On peut écrire la relation suivante, entre une matrice de -covariance :math:`\mathbf{M}` et ses matrices correspondantes de corrélation -:math:`\mathbf{C}` (matrice pleine) et d'écart-type :math:`\mathbf{\Sigma}` +De manière générale, une matrice de covariance (ou une matrice de +variance-covariance) doit être carrée, symétrique, semi-définie positive. Chacun +de ses termes décrit la covariance des deux variables aléatoires correspondantes +à sa position dans la matrice. La forme normalisée de la covariance est la +corrélation linéaire. On peut écrire la relation suivante, entre une matrice de +covariance :math:`\mathbf{M}` et ses matrices correspondantes de corrélation +:math:`\mathbf{C}` (matrice pleine) et d'écart-type :math:`\mathbf{\Sigma}` (matrice diagonale): .. math:: \mathbf{M} = \mathbf{\Sigma} * \mathbf{C} * \mathbf{\Sigma} -Diverses matrices de covariance sont nécessaires pour mettre en oeuvre des -procédures d'assimilation de données ou d'optimisation. Les principales sont la -matrice de covariance des erreurs d'ébauche, notée :math:`\mathbf{B}`, et la -matrice de covariance des erreurs d'observation, notée :math:`\mathbf{R}`. +Diverses matrices de covariance sont nécessaires pour mettre en oeuvre des +procédures d'assimilation de données ou d'optimisation. Les principales sont la +matrice de covariance des erreurs d'ébauche, notée :math:`\mathbf{B}`, et la +matrice de covariance des erreurs d'observation, notée :math:`\mathbf{R}`. -Il y a 3 méthodes pratiques pour l'utilisateur pour fournir une matrice de -covariance. La méthode est choisie à l'aide du mot-clé "*INPUT_TYPE*" de chaque -matrice de covariance, comme montré dans la figure qui suit : +Il y a 3 méthodes pratiques pour l'utilisateur pour fournir une matrice de +covariance. La méthode est choisie à l'aide du mot-clé "*INPUT_TYPE*" de chaque +matrice de covariance, comme montré dans la figure qui suit : .. eficas_covariance_matrix: .. image:: images/eficas_covariance_matrix.png :align: center :width: 100% .. centered:: - **Choisir la représentation d'une matrice de covariance** + **Choisir la représentation d'une matrice de covariance** -Première forme matricielle : utiliser la représentation "*Matrix*" +Première forme matricielle : utiliser la représentation "*Matrix*" ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .. index:: single: Matrix @@ -66,10 +66,10 @@ Premi .. index:: single: EvolutionError .. index:: single: ObservationError -La première forme est le défaut, et c'est la plus générale. La matrice de -covariance :math:`\mathbf{M}` doit être entièrement spécifiée. Même si la -matrice est symétrique par nature, la totalité de la matrice :math:`\mathbf{M}` -doit être donnée. +La première forme est le défaut, et c'est la plus générale. La matrice de +covariance :math:`\mathbf{M}` doit être entièrement spécifiée. Même si la +matrice est symétrique par nature, la totalité de la matrice :math:`\mathbf{M}` +doit être donnée. .. math:: \mathbf{M} = \begin{pmatrix} m_{11} & m_{12} & \cdots & m_{1n} \\ @@ -78,10 +78,10 @@ doit m_{n1} & \cdots & m_{nn-1} & m_{nn} \end{pmatrix} -Cela peut être réalisé soit par un vecteur ou une matrice Numpy, soit par une -liste de listes de valeurs (c'est-à-dire une liste de lignes). Par exemple, une -matrice simple diagonale unitaire de covariances des erreurs d'ébauche -:math:`\mathbf{B}` peut être décrite dans un fichier de script Python par:: +Cela peut être réalisé soit par un vecteur ou une matrice Numpy, soit par une +liste de listes de valeurs (c'est-à-dire une liste de lignes). Par exemple, une +matrice simple diagonale unitaire de covariances des erreurs d'ébauche +:math:`\mathbf{B}` peut être décrite dans un fichier de script Python par:: BackgroundError = [[1, 0 ... 0], [0, 1 ... 0] ... [0, 0 ... 1]] @@ -89,7 +89,7 @@ ou:: BackgroundError = numpy.eye(...) -Seconde forme matricielle : utiliser la représentation "*ScalarSparseMatrix*" +Seconde forme matricielle : utiliser la représentation "*ScalarSparseMatrix*" +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .. index:: single: ScalarSparseMatrix @@ -97,10 +97,10 @@ Seconde forme matricielle : utiliser la repr .. index:: single: EvolutionError .. index:: single: ObservationError -Au contraire, la seconde forme matricielle est une méthode très simplifiée pour -définir une matrice. La matrice de covariance :math:`\mathbf{M}` est ici -supposée être un multiple positif de la matrice identité. Cette matrice peut -alors être spécifiée de manière unique par le multiplicateur :math:`m`: +Au contraire, la seconde forme matricielle est une méthode très simplifiée pour +définir une matrice. La matrice de covariance :math:`\mathbf{M}` est ici +supposée être un multiple positif de la matrice identité. Cette matrice peut +alors être spécifiée de manière unique par le multiplicateur :math:`m`: .. math:: \mathbf{M} = m \times \begin{pmatrix} 1 & 0 & \cdots & 0 \\ @@ -109,17 +109,17 @@ alors 0 & \cdots & 0 & 1 \end{pmatrix} -Le multiplicateur :math:`m` doit être un nombre réel ou entier positif (s'il -est négatif, ce qui est impossible car une matrice de covariance est positive, +Le multiplicateur :math:`m` doit être un nombre réel ou entier positif (s'il +est négatif, ce qui est impossible car une matrice de covariance est positive, il est convertit en nombre positif). Par exemple, une simple matrice diagonale -unitaire de covariances des erreurs d'ébauche :math:`\mathbf{B}` peut être -décrite dans un fichier de script Python par:: +unitaire de covariances des erreurs d'ébauche :math:`\mathbf{B}` peut être +décrite dans un fichier de script Python par:: BackgroundError = 1. ou, mieux, par un "*String*" directement dans le cas ADAO. -Troisième forme matricielle : utiliser la représentation "*DiagonalSparseMatrix*" +Troisième forme matricielle : utiliser la représentation "*DiagonalSparseMatrix*" +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .. index:: single: DiagonalSparseMatrix @@ -127,11 +127,11 @@ Troisi .. index:: single: EvolutionError .. index:: single: ObservationError -La troisième forme est aussi une méthode simplifiée pour fournir la matrice, +La troisième forme est aussi une méthode simplifiée pour fournir la matrice, mais un peu plus puissante que la seconde. La matrice de covariance -:math:`\mathbf{M}` est ici toujours considérée comme diagonale, mais -l'utilisateur doit spécifier toutes les valeurs positives situées sur la -diagonale. La matrice peut alors être définie uniquement par un vecteur +:math:`\mathbf{M}` est ici toujours considérée comme diagonale, mais +l'utilisateur doit spécifier toutes les valeurs positives situées sur la +diagonale. La matrice peut alors être définie uniquement par un vecteur :math:`\mathbf{V}` qui se retrouve ensuite sur la diagonale: .. math:: \mathbf{M} = \begin{pmatrix} @@ -141,11 +141,11 @@ diagonale. La matrice peut alors 0 & \cdots & 0 & v_{n} \end{pmatrix} -Cela peut être réalisé soit par vecteur ou une matrice Numpy, soit par +Cela peut être réalisé soit par vecteur ou une matrice Numpy, soit par une liste, soit par une liste de listes de valeurs positives (dans tous les cas, -si certaines valeurs sont négatives, elles sont converties en valeurs +si certaines valeurs sont négatives, elles sont converties en valeurs positives). Par exemple, un matrice simple diagonale unitaire des covariances -des erreurs d'ébauche :math:`\mathbf{B}` peut être décrite dans un fichier de +des erreurs d'ébauche :math:`\mathbf{B}` peut être décrite dans un fichier de script Python par:: BackgroundError = [1, 1 ... 1] diff --git a/doc/fr/ref_entry_types.rst b/doc/fr/ref_entry_types.rst index a8d4d90..a3f38b5 100644 --- a/doc/fr/ref_entry_types.rst +++ b/doc/fr/ref_entry_types.rst @@ -23,86 +23,86 @@ .. _section_ref_entry_types: -Liste des types d'entrées possibles +Liste des types d'entrées possibles ----------------------------------- -Chaque variable ADAO présente un pseudo-type qui aide à la remplir et à la -valider. Ces pseudo-types représentent explicitement des formes informatiques ou -mathématiques simples. Deux pseudo-types, purement informatiques, permettent de -désigner la manière dont on fournit les variables en entrée: +Chaque variable ADAO présente un pseudo-type qui aide à la remplir et à la +valider. Ces pseudo-types représentent explicitement des formes informatiques ou +mathématiques simples. Deux pseudo-types, purement informatiques, permettent de +désigner la manière dont on fournit les variables en entrée: .. index:: single: Script **Script** - Cela indique un script donné comme un fichier externe. Il peut être désigné + Cela indique un script donné comme un fichier externe. Il peut être désigné par un nom de fichier avec chemin complet ou seulement par un nom de fichier - sans le chemin. Si le fichier est donné uniquement par un nom sans chemin, - et si un répertoire d'étude est aussi indiqué, le fichier est recherché dans - le répertoire d'étude donné. + sans le chemin. Si le fichier est donné uniquement par un nom sans chemin, + et si un répertoire d'étude est aussi indiqué, le fichier est recherché dans + le répertoire d'étude donné. .. index:: single: String **String** - Cela indique une chaîne de caractères fournissant une représentation - littérale d'une matrice, d'un vecteur ou d'une collection de vecteurs, comme - par exemple "1 2 ; 3 4" ou "[[1,2],[3,4]]" pour une matrice carrée de taille + Cela indique une chaîne de caractères fournissant une représentation + littérale d'une matrice, d'un vecteur ou d'une collection de vecteurs, comme + par exemple "1 2 ; 3 4" ou "[[1,2],[3,4]]" pour une matrice carrée de taille 2x2. -Les différents autres pseudo-types sont les suivants. Les variables auxquelles -ils s'appliquent peuvent elles-mêmes être données soit par une chaîne de -caractères (un "*String*"), soit par un fichier script (un "*Script*"): +Les différents autres pseudo-types sont les suivants. Les variables auxquelles +ils s'appliquent peuvent elles-mêmes être données soit par une chaîne de +caractères (un "*String*"), soit par un fichier script (un "*Script*"): .. index:: single: Dict **Dict** - Cela indique une variable qui doit être remplie avec un dictionnaire Python - ``{"clé":"valeur"...}``. + Cela indique une variable qui doit être remplie avec un dictionnaire Python + ``{"clé":"valeur"...}``. .. index:: single: Function **Function** - Cela indique une variable qui doit être donnée comme une fonction Python. - Les fonctions sont des entrées spéciales décrites par des + Cela indique une variable qui doit être donnée comme une fonction Python. + Les fonctions sont des entrées spéciales décrites par des :ref:`section_ref_operator_requirements`. .. index:: single: Matrix **Matrix** - Cela indique une variable qui doit être donnée comme une matrice. + Cela indique une variable qui doit être donnée comme une matrice. .. index:: single: ScalarSparseMatrix **ScalarSparseMatrix** - Cela indique une variable qui doit être donnée comme un nombre unique (qui - sera ensuite utilisé pour multiplier une matrice identité). + Cela indique une variable qui doit être donnée comme un nombre unique (qui + sera ensuite utilisé pour multiplier une matrice identité). .. index:: single: DiagonalSparseMatrix **DiagonalSparseMatrix** - Cela indique une variable qui doit doit être donnée comme un vecteur, (qui - sera ensuite utilisé comme la diagonale d'une matrice carrée). + Cela indique une variable qui doit doit être donnée comme un vecteur, (qui + sera ensuite utilisé comme la diagonale d'une matrice carrée). .. index:: single: Vector **Vector** - Cela indique une variable qui doit être remplie comme un vecteur. + Cela indique une variable qui doit être remplie comme un vecteur. .. index:: single: VectorSerie **VectorSerie** - Cela indique une variable qui doit être remplie comme une liste de vecteurs. + Cela indique une variable qui doit être remplie comme une liste de vecteurs. -Lorsqu'une commande ou un mot-clé peut être rempli par un nom de fichier script -désigné par le pseudo-type "*Script*", ce script doit présenter une variable ou -une méthode que porte le même nom que la variable à remplir. En d'autres termes, -lorsque l'on importe le script dans un noeud Python de YACS, il doit créer une +Lorsqu'une commande ou un mot-clé peut être rempli par un nom de fichier script +désigné par le pseudo-type "*Script*", ce script doit présenter une variable ou +une méthode que porte le même nom que la variable à remplir. En d'autres termes, +lorsque l'on importe le script dans un noeud Python de YACS, il doit créer une variable du bon nom dans l'espace de nommage courant du noeud. Par exemple, un -script Python rendant disponible la variable d'ébauche, nommée "*Background*", -doit présenter la forme suivante:: +script Python rendant disponible la variable d'ébauche, nommée "*Background*", +doit présenter la forme suivante:: ... Background =... ... -Son importation permet ainsi de créer la variable "*Background*". Les points -"..." symbolisent du code quelconque autour de ce début particulier de ligne. +Son importation permet ainsi de créer la variable "*Background*". Les points +"..." symbolisent du code quelconque autour de ce début particulier de ligne. diff --git a/doc/fr/ref_observers_requirements.rst b/doc/fr/ref_observers_requirements.rst index 7e6c43c..9f6ec35 100644 --- a/doc/fr/ref_observers_requirements.rst +++ b/doc/fr/ref_observers_requirements.rst @@ -23,71 +23,71 @@ .. _ref_observers_requirements: -Exigences pour les fonctions décrivant un "*observer*" +Exigences pour les fonctions décrivant un "*observer*" ------------------------------------------------------ .. index:: single: Observer .. index:: single: Observer Template -Certaines variables spéciales, internes à l'optimisation, utilisées au cours des -calculs, peuvent être surveillées durant un calcul ADAO. Ces variables peuvent -être affichées, tracées, enregistrées, etc. C'est réalisable en utilisant des -"*observer*", parfois aussi appelés des "callback". Ce sont des scripts Python, -qui sont chacun associés à une variable donnée. Ils sont activés à chaque +Certaines variables spéciales, internes à l'optimisation, utilisées au cours des +calculs, peuvent être surveillées durant un calcul ADAO. Ces variables peuvent +être affichées, tracées, enregistrées, etc. C'est réalisable en utilisant des +"*observer*", parfois aussi appelés des "callback". Ce sont des scripts Python, +qui sont chacun associés à une variable donnée. Ils sont activés à chaque modification de la variable. -Il y a 3 méthodes pratiques pour intégrer un "*observer*" dans un cas ADAO. La -méthode est choisie à l'aide du mot-clé "*NodeType*" de chaque entrée de type -"*observer*", comme montré dans la figure qui suit : +Il y a 3 méthodes pratiques pour intégrer un "*observer*" dans un cas ADAO. La +méthode est choisie à l'aide du mot-clé "*NodeType*" de chaque entrée de type +"*observer*", comme montré dans la figure qui suit : .. eficas_observer_nodetype: .. image:: images/eficas_observer_nodetype.png :align: center :width: 100% .. centered:: - **Choisir pour un "*observer*" son type d'entrée** - -L'"*observer*" peut être fourni sous la forme d'un script explicite (entrée de -type "*String*"), d'un script contenu dans un fichier externe (entrée de type -"*Script*"), ou en utilisant un modèle (entrée de type "*Template*") fourni par -défaut dans ADAO lors de l'usage de l'éditeur graphique. Ces derniers sont des -scripts simples qui peuvent être adaptés par l'utilisateur, soit dans l'étape -d'édition intégrée du cas, soit dans l'étape d'édition du schéma avant -l'exécution, pour améliorer la performance du calcul ADAO dans le superviseur -d'exécution de SALOME. - -Forme générale d'un script permettant de définir un *observer* + **Choisir pour un "*observer*" son type d'entrée** + +L'"*observer*" peut être fourni sous la forme d'un script explicite (entrée de +type "*String*"), d'un script contenu dans un fichier externe (entrée de type +"*Script*"), ou en utilisant un modèle (entrée de type "*Template*") fourni par +défaut dans ADAO lors de l'usage de l'éditeur graphique. Ces derniers sont des +scripts simples qui peuvent être adaptés par l'utilisateur, soit dans l'étape +d'édition intégrée du cas, soit dans l'étape d'édition du schéma avant +l'exécution, pour améliorer la performance du calcul ADAO dans le superviseur +d'exécution de SALOME. + +Forme générale d'un script permettant de définir un *observer* ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -Pour pouvoir utiliser cette capacité, l'utilisateur doit disposer ou construire -des scripts utilisant en entrée standard (i.e. disponible dans l'espace de -nommage) les variables ``var`` et ``info``. La variable ``var`` est à utiliser -comme un objet de type liste/tuple, contenant la variable d'intérêt indicée par -l'étape de mise à jour. +Pour pouvoir utiliser cette capacité, l'utilisateur doit disposer ou construire +des scripts utilisant en entrée standard (i.e. disponible dans l'espace de +nommage) les variables ``var`` et ``info``. La variable ``var`` est à utiliser +comme un objet de type liste/tuple, contenant la variable d'intérêt indicée par +l'étape de mise à jour. -A titre d'exemple, voici un script très simple (similaire au modèle +A titre d'exemple, voici un script très simple (similaire au modèle "*ValuePrinter*"), utilisable pour afficher la valeur d'une variable -surveillée:: +surveillée:: print " --->",info," Value =",var[-1] -Stockées comme un fichier Python ou une chaîne de caractères explicite, ces -lignes de script peuvent être associées à chaque variable présente dans le -mot-clé "*SELECTION*" de la commande "*Observers*" du cas ADAO : "*Analysis*", +Stockées comme un fichier Python ou une chaîne de caractères explicite, ces +lignes de script peuvent être associées à chaque variable présente dans le +mot-clé "*SELECTION*" de la commande "*Observers*" du cas ADAO : "*Analysis*", "*CurrentState*", "*CostFunction*"... La valeur courante de la variable sera -affichée à chaque étape de l'algorithme d'optimisation ou d'assimilation. Les -"*observer*" peuvent inclure des capacités d'affichage graphique, de stockage, +affichée à chaque étape de l'algorithme d'optimisation ou d'assimilation. Les +"*observer*" peuvent inclure des capacités d'affichage graphique, de stockage, de traitement complexe, d'analyse statistique, etc. -On donne ci-après l'identifiant et le contenu de chaque modèle disponible. +On donne ci-après l'identifiant et le contenu de chaque modèle disponible. -Inventaire des modèles d'*observer* disponibles ("*Template*") +Inventaire des modèles d'*observer* disponibles ("*Template*") ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .. index:: single: ValuePrinter (Observer) -Modèle **ValuePrinter** : -......................... +Modèle **ValuePrinter** : +.......................... Imprime sur la sortie standard la valeur courante de la variable. @@ -97,8 +97,8 @@ Imprime sur la sortie standard la valeur courante de la variable. .. index:: single: ValueAndIndexPrinter (Observer) -Modèle **ValueAndIndexPrinter** : -................................. +Modèle **ValueAndIndexPrinter** : +.................................. Imprime sur la sortie standard la valeur courante de la variable, en ajoutant son index. @@ -108,10 +108,10 @@ Imprime sur la sortie standard la valeur courante de la variable, en ajoutant so .. index:: single: ValueSeriePrinter (Observer) -Modèle **ValueSeriePrinter** : -.............................. +Modèle **ValueSeriePrinter** : +............................... -Imprime sur la sortie standard la série des valeurs de la variable. +Imprime sur la sortie standard la série des valeurs de la variable. :: @@ -119,10 +119,10 @@ Imprime sur la sortie standard la s .. index:: single: ValueSaver (Observer) -Modèle **ValueSaver** : -....................... +Modèle **ValueSaver** : +........................ -Enregistre la valeur courante de la variable dans un fichier du répertoire '/tmp' nommé 'value...txt' selon le nom de la variable et l'étape d'enregistrement. +Enregistre la valeur courante de la variable dans un fichier du répertoire '/tmp' nommé 'value...txt' selon le nom de la variable et l'étape d'enregistrement. :: @@ -140,10 +140,10 @@ Enregistre la valeur courante de la variable dans un fichier du r .. index:: single: ValueSerieSaver (Observer) -Modèle **ValueSerieSaver** : -............................ +Modèle **ValueSerieSaver** : +............................. -Enregistre la série des valeurs de la variable dans un fichier du répertoire '/tmp' nommé 'value...txt' selon le nom de la variable et l'étape. +Enregistre la série des valeurs de la variable dans un fichier du répertoire '/tmp' nommé 'value...txt' selon le nom de la variable et l'étape. :: @@ -161,10 +161,10 @@ Enregistre la s .. index:: single: ValuePrinterAndSaver (Observer) -Modèle **ValuePrinterAndSaver** : -................................. +Modèle **ValuePrinterAndSaver** : +.................................. -Imprime sur la sortie standard et, en même temps enregistre dans un fichier, la valeur courante de la variable. +Imprime sur la sortie standard et, en même temps enregistre dans un fichier, la valeur courante de la variable. :: @@ -183,10 +183,10 @@ Imprime sur la sortie standard et, en m .. index:: single: ValueIndexPrinterAndSaver (Observer) -Modèle **ValueIndexPrinterAndSaver** : -...................................... +Modèle **ValueIndexPrinterAndSaver** : +....................................... -Imprime sur la sortie standard et, en même temps enregistre dans un fichier, la valeur courante de la variable, en ajoutant son index. +Imprime sur la sortie standard et, en même temps enregistre dans un fichier, la valeur courante de la variable, en ajoutant son index. :: @@ -205,10 +205,10 @@ Imprime sur la sortie standard et, en m .. index:: single: ValueSeriePrinterAndSaver (Observer) -Modèle **ValueSeriePrinterAndSaver** : -...................................... +Modèle **ValueSeriePrinterAndSaver** : +....................................... -Imprime sur la sortie standard et, en même temps, enregistre dans un fichier la série des valeurs de la variable. +Imprime sur la sortie standard et, en même temps, enregistre dans un fichier la série des valeurs de la variable. :: @@ -227,8 +227,8 @@ Imprime sur la sortie standard et, en m .. index:: single: ValueGnuPlotter (Observer) -Modèle **ValueGnuPlotter** : -............................ +Modèle **ValueGnuPlotter** : +............................. Affiche graphiquement avec Gnuplot la valeur courante de la variable. @@ -249,10 +249,10 @@ Affiche graphiquement avec Gnuplot la valeur courante de la variable. .. index:: single: ValueSerieGnuPlotter (Observer) -Modèle **ValueSerieGnuPlotter** : -................................. +Modèle **ValueSerieGnuPlotter** : +.................................. -Affiche graphiquement avec Gnuplot la série des valeurs de la variable. +Affiche graphiquement avec Gnuplot la série des valeurs de la variable. :: @@ -271,10 +271,10 @@ Affiche graphiquement avec Gnuplot la s .. index:: single: ValuePrinterAndGnuPlotter (Observer) -Modèle **ValuePrinterAndGnuPlotter** : -...................................... +Modèle **ValuePrinterAndGnuPlotter** : +....................................... -Imprime sur la sortie standard et, en même temps, affiche graphiquement avec Gnuplot la valeur courante de la variable. +Imprime sur la sortie standard et, en même temps, affiche graphiquement avec Gnuplot la valeur courante de la variable. :: @@ -294,10 +294,10 @@ Imprime sur la sortie standard et, en m .. index:: single: ValueSeriePrinterAndGnuPlotter (Observer) -Modèle **ValueSeriePrinterAndGnuPlotter** : -........................................... +Modèle **ValueSeriePrinterAndGnuPlotter** : +............................................ -Imprime sur la sortie standard et, en même temps, affiche graphiquement avec Gnuplot la série des valeurs de la variable. +Imprime sur la sortie standard et, en même temps, affiche graphiquement avec Gnuplot la série des valeurs de la variable. :: @@ -317,10 +317,10 @@ Imprime sur la sortie standard et, en m .. index:: single: ValuePrinterSaverAndGnuPlotter (Observer) -Modèle **ValuePrinterSaverAndGnuPlotter** : -........................................... +Modèle **ValuePrinterSaverAndGnuPlotter** : +............................................ -Imprime sur la sortie standard et, en même temps, enregistre dans un fichier et affiche graphiquement la valeur courante de la variable . +Imprime sur la sortie standard et, en même temps, enregistre dans un fichier et affiche graphiquement la valeur courante de la variable . :: @@ -350,10 +350,10 @@ Imprime sur la sortie standard et, en m .. index:: single: ValueSeriePrinterSaverAndGnuPlotter (Observer) -Modèle **ValueSeriePrinterSaverAndGnuPlotter** : -................................................ +Modèle **ValueSeriePrinterSaverAndGnuPlotter** : +................................................. -Imprime sur la sortie standard et, en même temps, enregistre dans un fichier et affiche graphiquement la série des valeurs de la variable. +Imprime sur la sortie standard et, en même temps, enregistre dans un fichier et affiche graphiquement la série des valeurs de la variable. :: @@ -383,8 +383,8 @@ Imprime sur la sortie standard et, en m .. index:: single: ValueMean (Observer) -Modèle **ValueMean** : -...................... +Modèle **ValueMean** : +....................... Imprime sur la sortie standard la moyenne de la valeur courante de la variable. @@ -395,10 +395,10 @@ Imprime sur la sortie standard la moyenne de la valeur courante de la variable. .. index:: single: ValueStandardError (Observer) -Modèle **ValueStandardError** : -............................... +Modèle **ValueStandardError** : +................................ -Imprime sur la sortie standard l'écart-type de la valeur courante de la variable. +Imprime sur la sortie standard l'écart-type de la valeur courante de la variable. :: @@ -407,8 +407,8 @@ Imprime sur la sortie standard l' .. index:: single: ValueVariance (Observer) -Modèle **ValueVariance** : -.......................... +Modèle **ValueVariance** : +........................... Imprime sur la sortie standard la variance de la valeur courante de la variable. @@ -419,8 +419,8 @@ Imprime sur la sortie standard la variance de la valeur courante de la variable. .. index:: single: ValueL2Norm (Observer) -Modèle **ValueL2Norm** : -........................ +Modèle **ValueL2Norm** : +......................... Imprime sur la sortie standard la norme L2 de la valeur courante de la variable. @@ -432,10 +432,10 @@ Imprime sur la sortie standard la norme L2 de la valeur courante de la variable. .. index:: single: ValueRMS (Observer) -Modèle **ValueRMS** : -..................... +Modèle **ValueRMS** : +...................... -Imprime sur la sortie standard la racine de la moyenne des carrés (RMS), ou moyenne quadratique, de la valeur courante de la variable. +Imprime sur la sortie standard la racine de la moyenne des carrés (RMS), ou moyenne quadratique, de la valeur courante de la variable. :: diff --git a/doc/fr/ref_operator_requirements.rst b/doc/fr/ref_operator_requirements.rst index 4ea2faa..1ee19ed 100644 --- a/doc/fr/ref_operator_requirements.rst +++ b/doc/fr/ref_operator_requirements.rst @@ -23,50 +23,50 @@ .. _section_ref_operator_requirements: -Exigences pour les fonctions décrivant un opérateur +Exigences pour les fonctions décrivant un opérateur --------------------------------------------------- -Les opérateurs d'observation et d'évolution sont nécessaires pour mettre en -oeuvre les procédures d'assimilation de données ou d'optimisation. Ils -comprennent la simulation physique par des calculs numériques, mais aussi le -filtrage et de restriction pour comparer la simulation à l'observation. -L'opérateur d'évolution est ici considéré dans sa forme incrémentale, qui -représente la transition entre deux états successifs, et il est alors similaire -à l'opérateur d'observation. +Les opérateurs d'observation et d'évolution sont nécessaires pour mettre en +oeuvre les procédures d'assimilation de données ou d'optimisation. Ils +comprennent la simulation physique par des calculs numériques, mais aussi le +filtrage et de restriction pour comparer la simulation à l'observation. +L'opérateur d'évolution est ici considéré dans sa forme incrémentale, qui +représente la transition entre deux états successifs, et il est alors similaire +à l'opérateur d'observation. -Schématiquement, un opérateur doit donner une solution étant donné les -paramètres d'entrée. Une partie des paramètres d'entrée peut être modifiée au -cours de la procédure d'optimisation. Ainsi, la représentation mathématique d'un -tel processus est une fonction. Il a été brièvement décrit dans la section -:ref:`section_theory` et il est généralisée ici par la relation: +Schématiquement, un opérateur doit donner une solution étant donné les +paramètres d'entrée. Une partie des paramètres d'entrée peut être modifiée au +cours de la procédure d'optimisation. Ainsi, la représentation mathématique d'un +tel processus est une fonction. Il a été brièvement décrit dans la section +:ref:`section_theory` et il est généralisée ici par la relation: .. math:: \mathbf{y} = O( \mathbf{x} ) -entre les pseudo-observations :math:`\mathbf{y}` et les paramètres -:math:`\mathbf{x}` en utilisant l'opérateur d'observation ou d'évolution -:math:`O`. La même représentation fonctionnelle peut être utilisée pour le -modèle linéaire tangent :math:`\mathbf{O}` de :math:`O` et son adjoint +entre les pseudo-observations :math:`\mathbf{y}` et les paramètres +:math:`\mathbf{x}` en utilisant l'opérateur d'observation ou d'évolution +:math:`O`. La même représentation fonctionnelle peut être utilisée pour le +modèle linéaire tangent :math:`\mathbf{O}` de :math:`O` et son adjoint :math:`\mathbf{O}^*`, qui sont aussi requis par certains algorithmes -d'assimilation de données ou d'optimisation. +d'assimilation de données ou d'optimisation. -En entrée et en sortie de ces opérateurs, les variables :math:`\mathbf{x}` et -:math:`\mathbf{y}` ou leurs incréments sont mathématiquement des vecteurs, et -ils sont donc passés comme des vecteurs non-orientés (de type liste ou vecteur -Numpy) ou orientés (de type matrice Numpy). +En entrée et en sortie de ces opérateurs, les variables :math:`\mathbf{x}` et +:math:`\mathbf{y}` ou leurs incréments sont mathématiquement des vecteurs, et +ils sont donc passés comme des vecteurs non-orientés (de type liste ou vecteur +Numpy) ou orientés (de type matrice Numpy). -Ensuite, **pour décrire complètement un opérateur, l'utilisateur n'a qu'à -fournir une fonction qui réalise uniquement l'opération fonctionnelle de manière -complète**. +Ensuite, **pour décrire complètement un opérateur, l'utilisateur n'a qu'à +fournir une fonction qui réalise uniquement l'opération fonctionnelle de manière +complète**. -Cette fonction est généralement donnée comme un script qui peut être exécuté -dans un noeud YACS. Ce script peut aussi, sans différences, lancer des codes -externes ou utiliser des appels et des méthodes internes SALOME. Si l'algorithme -nécessite les 3 aspects de l'opérateur (forme directe, forme tangente et forme +Cette fonction est généralement donnée comme un script qui peut être exécuté +dans un noeud YACS. Ce script peut aussi, sans différences, lancer des codes +externes ou utiliser des appels et des méthodes internes SALOME. Si l'algorithme +nécessite les 3 aspects de l'opérateur (forme directe, forme tangente et forme adjointe), l'utilisateur doit donner les 3 fonctions ou les approximer. -Il existe 3 méthodes effectives pour l'utilisateur de fournir une représentation -fonctionnelle de l'opérateur. Ces méthodes sont choisies dans le champ "*FROM*" -de chaque opérateur ayant une valeur "*Function*" comme "*INPUT_TYPE*", comme le +Il existe 3 méthodes effectives pour l'utilisateur de fournir une représentation +fonctionnelle de l'opérateur. Ces méthodes sont choisies dans le champ "*FROM*" +de chaque opérateur ayant une valeur "*Function*" comme "*INPUT_TYPE*", comme le montre la figure suivante: .. eficas_operator_function: @@ -74,9 +74,9 @@ montre la figure suivante: :align: center :width: 100% .. centered:: - **Choisir une représentation fonctionnelle de l'opérateur** + **Choisir une représentation fonctionnelle de l'opérateur** -Première forme fonctionnelle : utiliser "*ScriptWithOneFunction*" +Première forme fonctionnelle : utiliser "*ScriptWithOneFunction*" +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .. index:: single: ScriptWithOneFunction @@ -84,43 +84,43 @@ Premi .. index:: single: DifferentialIncrement .. index:: single: CenteredFiniteDifference -La première consiste à ne fournir qu'une seule fonction potentiellement non -linéaire, et d'approximer les opérateurs tangent et adjoint. Ceci est fait en -utilisant le mot-clé "*ScriptWithOneFunction*" pour la description de -l'opérateur choisi dans l'interface graphique ADAO. L'utilisateur doit fournir +La première consiste à ne fournir qu'une seule fonction potentiellement non +linéaire, et d'approximer les opérateurs tangent et adjoint. Ceci est fait en +utilisant le mot-clé "*ScriptWithOneFunction*" pour la description de +l'opérateur choisi dans l'interface graphique ADAO. L'utilisateur doit fournir la fonction dans un script, avec un nom obligatoire "*DirectOperator*". Par -exemple, le script peut suivre le modèle suivant:: +exemple, le script peut suivre le modèle suivant:: def DirectOperator( X ): - """ Opérateur direct de simulation non-linéaire """ + """ Opérateur direct de simulation non-linéaire """ ... ... ... return Y=O(X) -Dans ce cas, l'utilisateur doit aussi fournir une valeur pour l'incrément -différentiel (ou conserver la valeur par défaut), en utilisant dans l'interface -graphique (GUI) le mot-clé "*DifferentialIncrement*", qui a une valeur par -défaut de 1%. Ce coefficient est utilisé dans l'approximation différences finies -pour construire les opérateurs tangent et adjoint. L'ordre de l'approximation -différences finies peut aussi être choisi à travers l'interface, en utilisant le -mot-clé "*CenteredFiniteDifference*", avec 0 pour un schéma non centré du -premier ordre (qui est la valeur par défaut), et avec 1 pour un schéma centré du -second ordre (qui coûte numériquement deux fois plus cher que le premier ordre). -Si nécessaire et si possible, on peut :ref:`subsection_ref_parallel_df`. Dans -tous les cas, un mécanisme de cache interne permet de limiter le nombre -d'évaluations de l'opérateur au minimum possible du point de vue de l'exécution -séquentielle ou parallèle des approximations numériques des opérateurs tangent -et adjoint, pour éviter des calculs redondants. - -Cette première forme de définition de l'opérateur permet aisément de tester la -forme fonctionnelle avant son usage dans un cas ADAO, réduisant notablement la -complexité de l'implémentation de l'opérateur. On peut ainsi utiliser -l'algorithme ADAO de vérification "*FunctionTest*" (voir la section sur +Dans ce cas, l'utilisateur doit aussi fournir une valeur pour l'incrément +différentiel (ou conserver la valeur par défaut), en utilisant dans l'interface +graphique (GUI) le mot-clé "*DifferentialIncrement*", qui a une valeur par +défaut de 1%. Ce coefficient est utilisé dans l'approximation différences finies +pour construire les opérateurs tangent et adjoint. L'ordre de l'approximation +différences finies peut aussi être choisi à travers l'interface, en utilisant le +mot-clé "*CenteredFiniteDifference*", avec 0 pour un schéma non centré du +premier ordre (qui est la valeur par défaut), et avec 1 pour un schéma centré du +second ordre (qui coûte numériquement deux fois plus cher que le premier ordre). +Si nécessaire et si possible, on peut :ref:`subsection_ref_parallel_df`. Dans +tous les cas, un mécanisme de cache interne permet de limiter le nombre +d'évaluations de l'opérateur au minimum possible du point de vue de l'exécution +séquentielle ou parallèle des approximations numériques des opérateurs tangent +et adjoint, pour éviter des calculs redondants. + +Cette première forme de définition de l'opérateur permet aisément de tester la +forme fonctionnelle avant son usage dans un cas ADAO, réduisant notablement la +complexité de l'implémentation de l'opérateur. On peut ainsi utiliser +l'algorithme ADAO de vérification "*FunctionTest*" (voir la section sur l':ref:`section_ref_algorithm_FunctionTest`) pour ce test. **Avertissement important :** le nom "*DirectOperator*" est obligatoire, et le -type de l'argument ``X`` peut être une liste, un vecteur ou une matrice Numpy. +type de l'argument ``X`` peut être une liste, un vecteur ou une matrice Numpy. La fonction utilisateur doit accepter et traiter tous ces cas. Seconde forme fonctionnelle : utiliser "*ScriptWithFunctions*" @@ -131,55 +131,55 @@ Seconde forme fonctionnelle : utiliser "*ScriptWithFunctions*" .. index:: single: TangentOperator .. index:: single: AdjointOperator -**En général, il est recommandé d'utiliser la première forme fonctionnelle -plutôt que la seconde. Un petit accroissement de performances n'est pas une -bonne raison pour utiliser l'implémentation détaillée de cette seconde forme +**En général, il est recommandé d'utiliser la première forme fonctionnelle +plutôt que la seconde. Un petit accroissement de performances n'est pas une +bonne raison pour utiliser l'implémentation détaillée de cette seconde forme fonctionnelle.** -La seconde consiste à fournir directement les trois opérateurs liés :math:`O`, -:math:`\mathbf{O}` et :math:`\mathbf{O}^*`. C'est effectué en utilisant le -mot-clé "*ScriptWithFunctions*" pour la description de l'opérateur choisi dans +La seconde consiste à fournir directement les trois opérateurs liés :math:`O`, +:math:`\mathbf{O}` et :math:`\mathbf{O}^*`. C'est effectué en utilisant le +mot-clé "*ScriptWithFunctions*" pour la description de l'opérateur choisi dans l'interface graphique (GUI) d'ADAO. L'utilisateur doit fournir trois fonctions dans un script, avec trois noms obligatoires "*DirectOperator*", "*TangentOperator*" et "*AdjointOperator*". Par exemple, le script peut suivre le squelette suivant:: def DirectOperator( X ): - """ Opérateur direct de simulation non-linéaire """ + """ Opérateur direct de simulation non-linéaire """ ... ... ... return quelque chose comme Y def TangentOperator( (X, dX) ): - """ Opérateur linéaire tangent, autour de X, appliqué à dX """ + """ Opérateur linéaire tangent, autour de X, appliqué à dX """ ... ... ... return quelque chose comme Y def AdjointOperator( (X, Y) ): - """ Opérateur adjoint, autour de X, appliqué à Y """ + """ Opérateur adjoint, autour de X, appliqué à Y """ ... ... ... return quelque chose comme X -Un nouvelle fois, cette seconde définition d'opérateur permet aisément de tester -les formes fonctionnelles avant de les utiliser dans le cas ADAO, réduisant la -complexité de l'implémentation de l'opérateur. +Un nouvelle fois, cette seconde définition d'opérateur permet aisément de tester +les formes fonctionnelles avant de les utiliser dans le cas ADAO, réduisant la +complexité de l'implémentation de l'opérateur. Pour certains algorithmes, il faut que les fonctions tangente et adjointe puisse -renvoyer les matrices équivalentes à l'opérateur linéaire. Dans ce cas, lorsque, +renvoyer les matrices équivalentes à l'opérateur linéaire. Dans ce cas, lorsque, respectivement, les arguments ``dX`` ou ``Y`` valent ``None``, l'utilisateur -doit renvoyer la matrice associée. +doit renvoyer la matrice associée. **Avertissement important :** les noms "*DirectOperator*", "*TangentOperator*" et "*AdjointOperator*" sont obligatoires, et le type des arguments ``X``, -``Y``, ``dX`` peut être une liste, un vecteur ou une matrice Numpy. +``Y``, ``dX`` peut être une liste, un vecteur ou une matrice Numpy. La fonction utilisateur doit accepter et traiter tous ces cas. -Troisième forme fonctionnelle : utiliser "*ScriptWithSwitch*" +Troisième forme fonctionnelle : utiliser "*ScriptWithSwitch*" +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .. index:: single: ScriptWithSwitch @@ -187,28 +187,28 @@ Troisi .. index:: single: TangentOperator .. index:: single: AdjointOperator -**Il est recommandé de ne pas utiliser cette troisième forme fonctionnelle sans -une solide raison numérique ou physique. Un accroissement de performances n'est -pas une bonne raison pour utiliser la complexité de cette troisième forme -fonctionnelle. Seule une impossibilité à utiliser les première ou seconde formes -justifie l'usage de la troisième.** +**Il est recommandé de ne pas utiliser cette troisième forme fonctionnelle sans +une solide raison numérique ou physique. Un accroissement de performances n'est +pas une bonne raison pour utiliser la complexité de cette troisième forme +fonctionnelle. Seule une impossibilité à utiliser les première ou seconde formes +justifie l'usage de la troisième.** -La troisième forme donne de plus grandes possibilités de contrôle de l'exécution -des trois fonctions représentant l'opérateur, permettant un usage et un contrôle -avancés sur chaque exécution du code de simulation. C'est réalisable en -utilisant le mot-clé "*ScriptWithSwitch*" pour la description de l'opérateur à +La troisième forme donne de plus grandes possibilités de contrôle de l'exécution +des trois fonctions représentant l'opérateur, permettant un usage et un contrôle +avancés sur chaque exécution du code de simulation. C'est réalisable en +utilisant le mot-clé "*ScriptWithSwitch*" pour la description de l'opérateur à travers l'interface graphique (GUI) d'ADAO. L'utilisateur doit fournir un script -unique aiguillant, selon un contrôle, l'exécution des formes directe, tangente +unique aiguillant, selon un contrôle, l'exécution des formes directe, tangente et adjointe du code de simulation. L'utilisateur peut alors, par exemple, utiliser des approximations pour les codes tangent et adjoint, ou introduire une -plus grande complexité du traitement des arguments des fonctions. Mais cette -démarche sera plus difficile à implémenter et à déboguer. +plus grande complexité du traitement des arguments des fonctions. Mais cette +démarche sera plus difficile à implémenter et à déboguer. -Toutefois, si vous souhaitez utiliser cette troisième forme, on recommande de se -baser sur le modèle suivant pour le script d'aiguillage. Il nécessite un fichier -script ou un code externe nommé ici "*Physical_simulation_functions.py*", -contenant trois fonctions nommées "*DirectOperator*", "*TangentOperator*" et -"*AdjointOperator*" comme précédemment. Voici le squelette d'aiguillage:: +Toutefois, si vous souhaitez utiliser cette troisième forme, on recommande de se +baser sur le modèle suivant pour le script d'aiguillage. Il nécessite un fichier +script ou un code externe nommé ici "*Physical_simulation_functions.py*", +contenant trois fonctions nommées "*DirectOperator*", "*TangentOperator*" et +"*AdjointOperator*" comme précédemment. Voici le squelette d'aiguillage:: import Physical_simulation_functions import numpy, logging @@ -255,67 +255,67 @@ contenant trois fonctions nomm result["returnCode"] = 0 result["errorMessage"] = "" -Toutes les modifications envisageables peuvent être faites à partir de cette -hypothèse de squelette. +Toutes les modifications envisageables peuvent être faites à partir de cette +hypothèse de squelette. .. _section_ref_operator_control: -Cas spécial d'un opérateur d'évolution avec contrôle +Cas spécial d'un opérateur d'évolution avec contrôle ++++++++++++++++++++++++++++++++++++++++++++++++++++ -Dans certains cas, l'opérateur d'évolution ou d'observation doit être contrôlé -par un contrôle d'entrée externe, qui est donné *a priori*. Dans ce cas, la -forme générique du modèle incrémental est légèrement modifié comme suit: +Dans certains cas, l'opérateur d'évolution ou d'observation doit être contrôlé +par un contrôle d'entrée externe, qui est donné *a priori*. Dans ce cas, la +forme générique du modèle incrémental est légèrement modifié comme suit: .. math:: \mathbf{y} = O( \mathbf{x}, \mathbf{u}) -où :math:`\mathbf{u}` est le contrôle sur l'incrément d'état. En effet, -l'opérateur direct doit être appliqué à une paire de variables :math:`(X,U)`. -Schématiquement, l'opérateur doit être construit comme suit:: +où :math:`\mathbf{u}` est le contrôle sur l'incrément d'état. En effet, +l'opérateur direct doit être appliqué à une paire de variables :math:`(X,U)`. +Schématiquement, l'opérateur doit être construit comme suit:: def DirectOperator( (X, U) ): - """ Opérateur direct de simulation non-linéaire """ + """ Opérateur direct de simulation non-linéaire """ ... ... ... - return quelque chose comme X(n+1) (évolution) ou Y(n+1) (observation) + return quelque chose comme X(n+1) (évolution) ou Y(n+1) (observation) -Les opérateurs tangent et adjoint ont la même signature que précédemment, en -notant que les dérivées doivent être faites seulement partiellement par rapport -à :math:`\mathbf{x}`. Dans un tel cas de contrôle explicite, seule la deuxième -forme fonctionnelle (en utilisant "*ScriptWithFunctions*") et la troisième forme -fonctionnelle (en utilisant "*ScriptWithSwitch*") peuvent être utilisées. +Les opérateurs tangent et adjoint ont la même signature que précédemment, en +notant que les dérivées doivent être faites seulement partiellement par rapport +à :math:`\mathbf{x}`. Dans un tel cas de contrôle explicite, seule la deuxième +forme fonctionnelle (en utilisant "*ScriptWithFunctions*") et la troisième forme +fonctionnelle (en utilisant "*ScriptWithSwitch*") peuvent être utilisées. -Remarques complémentaires sur l'adimensionnement des opérateurs +Remarques complémentaires sur l'adimensionnement des opérateurs +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .. index:: single: Adimensionnement .. index:: single: Sans dimension -Il est fréquent que les grandeurs physiques, en entrée ou en sortie des -opérateurs, présentent des différences notables d'ordre de grandeur ou de taux -de variation. Une manière d'éviter des difficultés numériques est d'utiliser, ou -d'établir, un adimensionnement des calculs menés dans les opérateurs -[WikipediaND]_. Par principe, dans la mesure où la simulation de la physique -devrait être la plus adimensionnée possible, il est en premier lieu recommandé -d'utiliser les capacités existantes d'adimensionnement du code de calcul. - -Néanmoins, dans le cas courant où l'on ne peut en disposer, il est souvent utile -d'environner le calcul pour l'adimensionner en entrée ou en sortie. Une manière -simple de faire cela en entrée consiste à transformer les paramètres +Il est fréquent que les grandeurs physiques, en entrée ou en sortie des +opérateurs, présentent des différences notables d'ordre de grandeur ou de taux +de variation. Une manière d'éviter des difficultés numériques est d'utiliser, ou +d'établir, un adimensionnement des calculs menés dans les opérateurs +[WikipediaND]_. Par principe, dans la mesure où la simulation de la physique +devrait être la plus adimensionnée possible, il est en premier lieu recommandé +d'utiliser les capacités existantes d'adimensionnement du code de calcul. + +Néanmoins, dans le cas courant où l'on ne peut en disposer, il est souvent utile +d'environner le calcul pour l'adimensionner en entrée ou en sortie. Une manière +simple de faire cela en entrée consiste à transformer les paramètres :math:`\mathbf{x}` en argument d'une fonction comme "*DirectOperator*". On -utilise le plus souvent les valeurs par défaut :math:`\mathbf{x}^b` (ébauche, ou +utilise le plus souvent les valeurs par défaut :math:`\mathbf{x}^b` (ébauche, ou valeur nominale). Pourvu que chaque composante de :math:`\mathbf{x}^b` soit non nulle, on peut en effet poser: .. math:: \mathbf{x} = \mathbf{\alpha}\mathbf{x}^b -et optimiser ensuite le paramètre multiplicatif :math:`\mathbf{\alpha}`. Ce -paramètre a pour valeur par défaut (ou pour ébauche) un vecteur de 1. Attention, -l'application d'une démarche d'adimensionnement nécessite aussi la modification -des covariances d'erreurs associées dans la formulation ADAO du problème +et optimiser ensuite le paramètre multiplicatif :math:`\mathbf{\alpha}`. Ce +paramètre a pour valeur par défaut (ou pour ébauche) un vecteur de 1. Attention, +l'application d'une démarche d'adimensionnement nécessite aussi la modification +des covariances d'erreurs associées dans la formulation ADAO du problème d'optimisation. -Une telle démarche suffit rarement à éviter tous les problèmes numériques, mais -permet souvent d'améliorer beaucoup le conditionnement numérique de +Une telle démarche suffit rarement à éviter tous les problèmes numériques, mais +permet souvent d'améliorer beaucoup le conditionnement numérique de l'optimisation. diff --git a/doc/fr/ref_options_AlgorithmParameters.rst b/doc/fr/ref_options_AlgorithmParameters.rst index 40896ee..757a5db 100644 --- a/doc/fr/ref_options_AlgorithmParameters.rst +++ b/doc/fr/ref_options_AlgorithmParameters.rst @@ -29,97 +29,97 @@ Description des options d'un algorithme dans "*AlgorithmParameters*" -------------------------------------------------------------------- -Chaque algorithme peut être contrôlé en utilisant des options ou des paramètres -particuliers. Ils sont donnés à travers la commande optionnelle "*Parameters*" +Chaque algorithme peut être contrôlé en utilisant des options ou des paramètres +particuliers. Ils sont donnés à travers la commande optionnelle "*Parameters*" incluse dans la commande obligatoire "*AlgorithmParameters*". -Il y a 3 méthodes pratiques pour l'utilisateur pour fournir ces options. La -méthode est déterminée de la manière suivante dans l'interface graphique -d'édition : +Il y a 3 méthodes pratiques pour l'utilisateur pour fournir ces options. La +méthode est déterminée de la manière suivante dans l'interface graphique +d'édition : -#. premièrement à l'aide du mot-clé "*Parameters*" dans la commande "*AlgorithmParameters*", qui permet de choisir entre "*Defaults*" (utilisation de mots-clés explicites pré-remplis par les valeurs par défaut des paramètres) et "*Dict*" (utilisation d'un dictionnaire pour renseigner les mots-clés nécessaires), -#. puis deuxièmement, uniquement dans le cas "*Dict*" de "*Parameters*", par le mot-clé "*FROM*" inclus qui permet de choisir entre une entrée par chaîne de caractères ou une entrée par fichier de script Python. +#. premièrement à l'aide du mot-clé "*Parameters*" dans la commande "*AlgorithmParameters*", qui permet de choisir entre "*Defaults*" (utilisation de mots-clés explicites pré-remplis par les valeurs par défaut des paramètres) et "*Dict*" (utilisation d'un dictionnaire pour renseigner les mots-clés nécessaires), +#. puis deuxièmement, uniquement dans le cas "*Dict*" de "*Parameters*", par le mot-clé "*FROM*" inclus qui permet de choisir entre une entrée par chaîne de caractères ou une entrée par fichier de script Python. -Si une option ou un paramètre est spécifié par l'utilisateur pour un algorithme -qui ne la supporte pas, cette option est simplement laissée inutilisée et ne +Si une option ou un paramètre est spécifié par l'utilisateur pour un algorithme +qui ne la supporte pas, cette option est simplement laissée inutilisée et ne bloque pas le traitement. La signification des acronymes ou des noms -particuliers peut être trouvée dans l':ref:`genindex` ou dans le +particuliers peut être trouvée dans l':ref:`genindex` ou dans le :ref:`section_glossary`. -Première méthode : utiliser les mots-clés explicites pré-remplis +Première méthode : utiliser les mots-clés explicites pré-remplis ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -Pour donner les valeurs des paramètres par les mots-clés explicites pré-remplis, -directement dans l'interface graphique, l'utilisateur sélectionne le type -"*Defaults*" dans le mot-clé "*Parameters*", puis les mots-clés dans la liste -prévue "*Parameters[Algo]*" qui apparaît, associée à l'algorithme choisi, comme -montré dans la figure qui suit : +Pour donner les valeurs des paramètres par les mots-clés explicites pré-remplis, +directement dans l'interface graphique, l'utilisateur sélectionne le type +"*Defaults*" dans le mot-clé "*Parameters*", puis les mots-clés dans la liste +prévue "*Parameters[Algo]*" qui apparaît, associée à l'algorithme choisi, comme +montré dans la figure qui suit : .. adao_algopar_defaults: .. image:: images/adao_algopar_defaults.png :align: center :width: 100% .. centered:: - **Utiliser les mots-clés explicites pré-remplis pour les paramètres algorithmiques** + **Utiliser les mots-clés explicites pré-remplis pour les paramètres algorithmiques** -Chaque paramètre est optionnel, et il présente sa valeur par défaut lorsqu'il -est sélectionné par l'utilisateur. On peut alors modifier sa valeur, ou la +Chaque paramètre est optionnel, et il présente sa valeur par défaut lorsqu'il +est sélectionné par l'utilisateur. On peut alors modifier sa valeur, ou la renseigner dans le cas de listes par exemple. -C'est la manière recommandée pour modifier uniquement une partie des paramètres -algorithmiques de manière sûre. Cette méthode ne permet de définir que les -paramètres autorisés pour un algorithme donné, et les valeurs définies ne sont -pas conservées si l'utilisateur change d'algorithme. +C'est la manière recommandée pour modifier uniquement une partie des paramètres +algorithmiques de manière sûre. Cette méthode ne permet de définir que les +paramètres autorisés pour un algorithme donné, et les valeurs définies ne sont +pas conservées si l'utilisateur change d'algorithme. -Seconde méthode : utiliser une chaîne de caractères dans l'interface graphique +Seconde méthode : utiliser une chaîne de caractères dans l'interface graphique ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -Pour donner les valeurs des paramètres par une chaîne de caractères, directement -dans l'interface graphique, l'utilisateur sélectionne le type "*Dict*" dans le -mot-clé "*Parameters*", puis le type "*String*" dans le mot-clé "*FROM*" de la -commande "*Dict*" qui apparaît, comme montré dans la figure qui suit : +Pour donner les valeurs des paramètres par une chaîne de caractères, directement +dans l'interface graphique, l'utilisateur sélectionne le type "*Dict*" dans le +mot-clé "*Parameters*", puis le type "*String*" dans le mot-clé "*FROM*" de la +commande "*Dict*" qui apparaît, comme montré dans la figure qui suit : .. adao_algopar_string: .. image:: images/adao_algopar_string.png :align: center :width: 100% .. centered:: - **Utiliser une chaîne de caractères pour les paramètres algorithmiques** + **Utiliser une chaîne de caractères pour les paramètres algorithmiques** Dans le champs de saisie, il faut utiliser des guillemets simples pour une -définition standard de dictionnaire, comme par exemple:: +définition standard de dictionnaire, comme par exemple:: '{"MaximumNumberOfSteps":25,"SetSeed":1000}' -C'est la manière recommandée pour définir des paramètres algorithmiques. Cette -méthode permet en particulier de conserver des options ou des paramètres pour -d'autres algorithmes que celui que l'on utilise au moment présent. Cela facilite -le changement d'algorithme ou la conservation de valeurs par défaut différentes -des défauts standards. +C'est la manière recommandée pour définir des paramètres algorithmiques. Cette +méthode permet en particulier de conserver des options ou des paramètres pour +d'autres algorithmes que celui que l'on utilise au moment présent. Cela facilite +le changement d'algorithme ou la conservation de valeurs par défaut différentes +des défauts standards. -Troisième méthode : utiliser un fichier de script Python externe +Troisième méthode : utiliser un fichier de script Python externe ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -Pour donner les valeurs des paramètres par un fichier de script Python externe, -l'utilisateur sélectionne dans l'interface graphique le type "*Dict*" dans le -mot-clé "*Parameters*", puis le type "*Script*" dans le mot-clé "*FROM*" de la -commande "*Dict*" qui apparaît, comme montré dans la figure qui suit : +Pour donner les valeurs des paramètres par un fichier de script Python externe, +l'utilisateur sélectionne dans l'interface graphique le type "*Dict*" dans le +mot-clé "*Parameters*", puis le type "*Script*" dans le mot-clé "*FROM*" de la +commande "*Dict*" qui apparaît, comme montré dans la figure qui suit : .. :adao_algopar_script .. image:: images/adao_algopar_script.png :align: center :width: 100% .. centered:: - **Utiliser un fichier externe pour les paramètres algorithmiques** + **Utiliser un fichier externe pour les paramètres algorithmiques** -Ce fichier script Python externe doit définir alors une variable au nom imposé -"*AlgorithmParameters*", à la manière de l'exemple qui suit:: +Ce fichier script Python externe doit définir alors une variable au nom imposé +"*AlgorithmParameters*", à la manière de l'exemple qui suit:: AlgorithmParameters = { "MaximumNumberOfSteps" : 25, "StoreSupplementaryCalculations" : ["APosterioriCovariance","OMA"], } -Le fichier peut aussi contenir d'autres commandes Python. Cette méthode permet -aussi, comme la précédente, de conserver des options ou des paramètres pour +Le fichier peut aussi contenir d'autres commandes Python. Cette méthode permet +aussi, comme la précédente, de conserver des options ou des paramètres pour d'autres algorithmes que celui que l'on utilise. diff --git a/doc/fr/ref_output_variables.rst b/doc/fr/ref_output_variables.rst index 77917a1..cae240d 100644 --- a/doc/fr/ref_output_variables.rst +++ b/doc/fr/ref_output_variables.rst @@ -35,36 +35,36 @@ Comment obtenir les informations disponibles en sortie .. index:: single: get .. index:: single: ADD -En sortie, après exécution d'une assimilation de données, d'une optimisation -ou d'une vérification, on dispose de variables et d'informations issues du -calcul. L'obtention de ces informations se fait ensuite de manière standardisée -à l'aide de l'étape de post-processing du calcul. - -L'étape est aisément identifiée par l'utilisateur dans son cas ADAO de -définition (par le mot-clé "*UserPostAnalysis*") ou dans son schéma YACS -d'exécution (par des noeuds ou blocs situés après le bloc de calcul, et reliés +En sortie, après exécution d'une assimilation de données, d'une optimisation +ou d'une vérification, on dispose de variables et d'informations issues du +calcul. L'obtention de ces informations se fait ensuite de manière standardisée +à l'aide de l'étape de post-processing du calcul. + +L'étape est aisément identifiée par l'utilisateur dans son cas ADAO de +définition (par le mot-clé "*UserPostAnalysis*") ou dans son schéma YACS +d'exécution (par des noeuds ou blocs situés après le bloc de calcul, et reliés graphiquement au port de sortie "*algoResults*" du bloc de calcul): -#. Dans le cas où l'utilisateur définit le post-processing dans son cas ADAO, il utilise un fichier script externe ou des commandes dans le champ de type "*String*" ou "*Template*". Le script qu'il fournit dispose d'une variable fixe "*ADD*" dans l'espace de noms. -#. Dans le cas où l'utilisateur définit le post-processing dans son schéma YACS par un noeud Python situé après le bloc de calcul, il doit ajouter un port d'entrée de type "*pyobj*" nommé par exemple "*Study*", relié graphiquement au port de sortie "*algoResults*" du bloc de calcul. Le noeud Python de post-processing doit ensuite débuter par ``ADD = Study.getResults()``. +#. Dans le cas où l'utilisateur définit le post-processing dans son cas ADAO, il utilise un fichier script externe ou des commandes dans le champ de type "*String*" ou "*Template*". Le script qu'il fournit dispose d'une variable fixe "*ADD*" dans l'espace de noms. +#. Dans le cas où l'utilisateur définit le post-processing dans son schéma YACS par un noeud Python situé après le bloc de calcul, il doit ajouter un port d'entrée de type "*pyobj*" nommé par exemple "*Study*", relié graphiquement au port de sortie "*algoResults*" du bloc de calcul. Le noeud Python de post-processing doit ensuite débuter par ``ADD = Study.getResults()``. -Des patrons (ou "templates") sont donnés ci-après en +Des patrons (ou "templates") sont donnés ci-après en :ref:`subsection_r_o_v_Template`. Dans tous les cas, le post-processing de l'utilisateur dispose dans l'espace de noms d'une variable dont le nom est -"*ADD*", et dont l'unique méthode utilisable est nommée ``get``. Les arguments -de cette méthode sont un nom d'information de sortie, comme décrit dans +"*ADD*", et dont l'unique méthode utilisable est nommée ``get``. Les arguments +de cette méthode sont un nom d'information de sortie, comme décrit dans l':ref:`subsection_r_o_v_Inventaire`. -Par exemple, pour avoir l'état optimal après un calcul d'assimilation de données +Par exemple, pour avoir l'état optimal après un calcul d'assimilation de données ou d'optimisation, on utilise l'appel suivant:: ADD.get("Analysis") -Cet appel renvoie une liste de valeurs de la notion demandée (ou, dans le cas -de variables d'entrées qui ne sont par nature qu'en un unique exemplaire, la -valeur elle-même). On peut alors demander un élément particulier de la liste par +Cet appel renvoie une liste de valeurs de la notion demandée (ou, dans le cas +de variables d'entrées qui ne sont par nature qu'en un unique exemplaire, la +valeur elle-même). On peut alors demander un élément particulier de la liste par les commandes standards de liste (en particulier ``[-1]`` pour le dernier, et -``[:]`` pour tous les éléments). +``[:]`` pour tous les éléments). .. _subsection_r_o_v_Template: @@ -76,22 +76,22 @@ Exemples de scripts Python pour obtenir ou traiter les sorties .. index:: single: AnalysisSaver .. index:: single: AnalysisPrinterAndSaver -Ces exemples présentent des commandes ou scripts Python qui permettent d'obtenir -ou de traiter les sorties d'une exécution d'algorithme. Pour aider -l'utilisateur, ils sont directement disponibles dans l'interface, à la -construction du cas ADAO dans l'éditeur intégré de cas, dans les champs de type -"*Template*". De manière équivalente, ces commandes peuvent être contenues dans -un script utilisateur externe (et insérées dans le cas ADAO par l'entrée de type -"*Script*") ou contenues dans une chaîne de caractères, y compris les retour à -la ligne (et insérées dans le cas ADAO par l'entrée de type "*String*"). De -nombreuses variantes peuvent être imaginées à partir de ces exemples simples, -l'objectif étant surtout d'aider l'utilisateur à effectuer le traitement exact +Ces exemples présentent des commandes ou scripts Python qui permettent d'obtenir +ou de traiter les sorties d'une exécution d'algorithme. Pour aider +l'utilisateur, ils sont directement disponibles dans l'interface, à la +construction du cas ADAO dans l'éditeur intégré de cas, dans les champs de type +"*Template*". De manière équivalente, ces commandes peuvent être contenues dans +un script utilisateur externe (et insérées dans le cas ADAO par l'entrée de type +"*Script*") ou contenues dans une chaîne de caractères, y compris les retour à +la ligne (et insérées dans le cas ADAO par l'entrée de type "*String*"). De +nombreuses variantes peuvent être imaginées à partir de ces exemples simples, +l'objectif étant surtout d'aider l'utilisateur à effectuer le traitement exact dont il a besoin en sortie. -Le premier exemple (appelé "*AnalysisPrinter*" dans les entrées de type -"*Template*") consiste à afficher, dans la sortie standard d'exécution, la -valeur de l'analyse ou de l'état optimal, noté :math:`\mathbf{x}^a` dans la -partie :ref:`section_theory`. Cela se réalise par les commandes:: +Le premier exemple (appelé "*AnalysisPrinter*" dans les entrées de type +"*Template*") consiste à afficher, dans la sortie standard d'exécution, la +valeur de l'analyse ou de l'état optimal, noté :math:`\mathbf{x}^a` dans la +partie :ref:`section_theory`. Cela se réalise par les commandes:: import numpy xa=numpy.ravel(ADD.get('Analysis')[-1]) @@ -99,11 +99,11 @@ partie :ref:`section_theory`. Cela se r La fonction ``numpy.ravel`` assure simplement que la variable ``xa`` contienne un vrai vecteur unidimensionnel, quels que soient les choix informatiques -précédents. +précédents. -Un second exemple (appelé "*AnalysisSaver*" dans les entrées de type -"*Template*") consiste à enregistrer sur fichier la valeur de l'analyse ou de -l'état optimal :math:`\mathbf{x}^a`. Cela se réalise par les commandes:: +Un second exemple (appelé "*AnalysisSaver*" dans les entrées de type +"*Template*") consiste à enregistrer sur fichier la valeur de l'analyse ou de +l'état optimal :math:`\mathbf{x}^a`. Cela se réalise par les commandes:: import numpy xa=numpy.ravel(ADD.get('Analysis')[-1]) @@ -113,10 +113,10 @@ l' Le fichier d'enregistrement choisi est un fichier texte ``/tmp/analysis.txt``. -Il est aisé de combiner ces deux exemples pour en construire un troisième -(appelé "*AnalysisPrinterAndSaver*" dans les entrées de type "*Template*"). Il -consiste à simultanément afficher dans la sortie standard d'exécution et à -enregistrer sur fichier la valeur de :math:`\mathbf{x}^a`. Cela se réalise par +Il est aisé de combiner ces deux exemples pour en construire un troisième +(appelé "*AnalysisPrinterAndSaver*" dans les entrées de type "*Template*"). Il +consiste à simultanément afficher dans la sortie standard d'exécution et à +enregistrer sur fichier la valeur de :math:`\mathbf{x}^a`. Cela se réalise par les commandes:: import numpy @@ -127,37 +127,37 @@ les commandes:: numpy.savetxt(f,xa) Pour faciliter l'extension de ces exemples selon les besoins utilisateurs, on -rappelle que l'ensemble des fonctions de SALOME sont disponibles au même niveau -que ces commandes. L'utilisateur peut en particulier requérir des actions de -représentation graphique avec le module PARAVIS [#]_ ou d'autres modules, des -actions de calcul pilotés par YACS [#]_ ou un autre module, etc. +rappelle que l'ensemble des fonctions de SALOME sont disponibles au même niveau +que ces commandes. L'utilisateur peut en particulier requérir des actions de +représentation graphique avec le module PARAVIS [#]_ ou d'autres modules, des +actions de calcul pilotés par YACS [#]_ ou un autre module, etc. -D'autres exemples d'utilisation sont aussi donnés en :ref:`section_u_step4` de +D'autres exemples d'utilisation sont aussi donnés en :ref:`section_u_step4` de la partie :ref:`section_using`, ou en partie :ref:`section_examples`. -Conditionnalité des informations disponibles en sortie +Conditionnalité des informations disponibles en sortie ++++++++++++++++++++++++++++++++++++++++++++++++++++++ .. index:: single: AlgorithmParameters .. index:: single: Stored -La disponibilité des informations après le calcul est conditionnée par le fait -qu'elles aient été calculées ou demandées. +La disponibilité des informations après le calcul est conditionnée par le fait +qu'elles aient été calculées ou demandées. -Chaque algorithme ne fournit pas obligatoirement les mêmes informations, et -n'utilise par exemple pas nécessairement les mêmes quantités intermédiaires. Il -y a donc des informations toujours présentes comme l'état optimal résultant du -calcul. Les autres informations ne sont présentes que pour certains algorithmes -et/ou que si elles ont été réclamées avant l'exécution du calcul. +Chaque algorithme ne fournit pas obligatoirement les mêmes informations, et +n'utilise par exemple pas nécessairement les mêmes quantités intermédiaires. Il +y a donc des informations toujours présentes comme l'état optimal résultant du +calcul. Les autres informations ne sont présentes que pour certains algorithmes +et/ou que si elles ont été réclamées avant l'exécution du calcul. -On rappelle que l'utilisateur peut réclamer des informations supplémentaires -lors de l'établissement de son cas ADAO, en utilisant la commande optionnelle -"*AlgorithmParameters*" du cas ADAO. On se reportera à la +On rappelle que l'utilisateur peut réclamer des informations supplémentaires +lors de l'établissement de son cas ADAO, en utilisant la commande optionnelle +"*AlgorithmParameters*" du cas ADAO. On se reportera à la :ref:`section_ref_options_Algorithm_Parameters` pour le bon usage de cette -commande, et à la description de chaque algorithme pour les informations -disponibles par algorithme. On peut aussi demander à conserver certaines -informations en entrée en changeant le booléen "*Stored*" qui lui est associé -dans l'édition du cas ADAO. +commande, et à la description de chaque algorithme pour les informations +disponibles par algorithme. On peut aussi demander à conserver certaines +informations en entrée en changeant le booléen "*Stored*" qui lui est associé +dans l'édition du cas ADAO. .. _subsection_r_o_v_Inventaire: @@ -167,239 +167,239 @@ Inventaire des informations potentiellement disponibles en sortie .. index:: single: Dry .. index:: single: Forecast -L'ensemble des informations potentiellement disponibles en sortie est indiqué -ici indépendamment des algorithmes, pour inventaire. +L'ensemble des informations potentiellement disponibles en sortie est indiqué +ici indépendamment des algorithmes, pour inventaire. -L'état optimal est une information qui est toujours naturellement disponible -après un calcul d'assimilation de données ou d'optimisation. Il désigné par le -mot-clé suivant: +L'état optimal est une information qui est toujours naturellement disponible +après un calcul d'assimilation de données ou d'optimisation. Il désigné par le +mot-clé suivant: Analysis - *Liste de vecteurs*. Chaque élément est un état optimal :math:`\mathbf{x}*` + *Liste de vecteurs*. Chaque élément est un état optimal :math:`\mathbf{x}*` en optimisation ou une analyse :math:`\mathbf{x}^a` en assimilation de - données. + données. Exemple : ``Xa = ADD.get("Analysis")[-1]`` -Les variables suivantes sont des variables d'entrée. Elles sont mises à -disposition de l'utilisateur en sortie pour faciliter l'écriture des procédures -de post-processing, et sont conditionnées par une demande utilisateur à l'aide -d'un booléen "*Stored*" en entrée. +Les variables suivantes sont des variables d'entrée. Elles sont mises à +disposition de l'utilisateur en sortie pour faciliter l'écriture des procédures +de post-processing, et sont conditionnées par une demande utilisateur à l'aide +d'un booléen "*Stored*" en entrée. Background - *Vecteur*, dont la disponibilité est conditionnée par "*Stored*" en entrée. - C'est le vecteur d'ébauche :math:`\mathbf{x}^b`. + *Vecteur*, dont la disponibilité est conditionnée par "*Stored*" en entrée. + C'est le vecteur d'ébauche :math:`\mathbf{x}^b`. Exemple : ``Xb = ADD.get("Background")`` BackgroundError - *Matrice*, dont la disponibilité est conditionnée par "*Stored*" en entrée. + *Matrice*, dont la disponibilité est conditionnée par "*Stored*" en entrée. C'est la matrice :math:`\mathbf{B}` de covariances des erreurs *a priori* - de l'ébauche. + de l'ébauche. Exemple : ``B = ADD.get("BackgroundError")`` EvolutionError - *Matrice*, dont la disponibilité est conditionnée par "*Stored*" en entrée. + *Matrice*, dont la disponibilité est conditionnée par "*Stored*" en entrée. C'est la matrice :math:`\mathbf{M}` de covariances des erreurs *a priori* - de l'évolution. + de l'évolution. Exemple : ``M = ADD.get("EvolutionError")`` Observation - *Vecteur*, dont la disponibilité est conditionnée par "*Stored*" en entrée. + *Vecteur*, dont la disponibilité est conditionnée par "*Stored*" en entrée. C'est le vecteur d'observation :math:`\mathbf{y}^o`. Exemple : ``Yo = ADD.get("Observation")`` ObservationError - *Matrice*, dont la disponibilité est conditionnée par "*Stored*" en entrée. + *Matrice*, dont la disponibilité est conditionnée par "*Stored*" en entrée. C'est la matrice :math:`\mathbf{R}` de covariances des erreurs *a priori* de l'observation. Exemple : ``R = ADD.get("ObservationError")`` -Toutes les autres informations sont conditionnées par l'algorithme et/ou par la -demande utilisateur de disponibilité. Ce sont les suivantes, par ordre -alphabétique: +Toutes les autres informations sont conditionnées par l'algorithme et/ou par la +demande utilisateur de disponibilité. Ce sont les suivantes, par ordre +alphabétique: APosterioriCorrelations - *Liste de matrices*. Chaque élément est une matrice de corrélations des - erreurs *a posteriori* de l'état optimal, issue de la matrice + *Liste de matrices*. Chaque élément est une matrice de corrélations des + erreurs *a posteriori* de l'état optimal, issue de la matrice :math:`\mathbf{A}*` des covariances. Exemple : ``C = ADD.get("APosterioriCorrelations")[-1]`` APosterioriCovariance - *Liste de matrices*. Chaque élément est une matrice :math:`\mathbf{A}*` de - covariances des erreurs *a posteriori* de l'état optimal. + *Liste de matrices*. Chaque élément est une matrice :math:`\mathbf{A}*` de + covariances des erreurs *a posteriori* de l'état optimal. Exemple : ``A = ADD.get("APosterioriCovariance")[-1]`` APosterioriStandardDeviations - *Liste de matrices*. Chaque élément est une matrice diagonale d'écarts-types - des erreurs *a posteriori* de l'état optimal, issue de la matrice + *Liste de matrices*. Chaque élément est une matrice diagonale d'écarts-types + des erreurs *a posteriori* de l'état optimal, issue de la matrice :math:`\mathbf{A}*` des covariances. Exemple : ``S = ADD.get("APosterioriStandardDeviations")[-1]`` APosterioriVariances - *Liste de matrices*. Chaque élément est une matrice diagonale de variances - des erreurs *a posteriori* de l'état optimal, issue de la matrice + *Liste de matrices*. Chaque élément est une matrice diagonale de variances + des erreurs *a posteriori* de l'état optimal, issue de la matrice :math:`\mathbf{A}*` des covariances. Exemple : ``V = ADD.get("APosterioriVariances")[-1]`` BMA - *Liste de vecteurs*. Chaque élément est un vecteur d'écart entre - l'ébauche et l'état optimal. + *Liste de vecteurs*. Chaque élément est un vecteur d'écart entre + l'ébauche et l'état optimal. Exemple : ``bma = ADD.get("BMA")[-1]`` CostFunctionJ - *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart + *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart :math:`J`. Exemple : ``J = ADD.get("CostFunctionJ")[:]`` CostFunctionJb - *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart - :math:`J^b`, c'est-à-dire de la partie écart à l'ébauche. + *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart + :math:`J^b`, c'est-à-dire de la partie écart à l'ébauche. Exemple : ``Jb = ADD.get("CostFunctionJb")[:]`` CostFunctionJo - *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart - :math:`J^o`, c'est-à-dire de la partie écart à l'observation. + *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart + :math:`J^o`, c'est-à-dire de la partie écart à l'observation. Exemple : ``Jo = ADD.get("CostFunctionJo")[:]`` CostFunctionJAtCurrentOptimum - *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart - :math:`J`. A chaque pas, la valeur correspond à l'état optimal trouvé depuis - le début. + *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart + :math:`J`. A chaque pas, la valeur correspond à l'état optimal trouvé depuis + le début. Exemple : ``JACO = ADD.get("CostFunctionJAtCurrentOptimum")[:]`` CostFunctionJbAtCurrentOptimum - *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart - :math:`J^b`, c'est-à-dire de la partie écart à l'ébauche. A chaque pas, la - valeur correspond à l'état optimal trouvé depuis le début. + *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart + :math:`J^b`, c'est-à-dire de la partie écart à l'ébauche. A chaque pas, la + valeur correspond à l'état optimal trouvé depuis le début. Exemple : ``JbACO = ADD.get("CostFunctionJbAtCurrentOptimum")[:]`` CostFunctionJoAtCurrentOptimum - *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart - :math:`J^o`, c'est-à-dire de la partie écart à l'observation. A chaque pas, - la valeur correspond à l'état optimal trouvé depuis le début. + *Liste de valeurs*. Chaque élément est une valeur de fonctionnelle d'écart + :math:`J^o`, c'est-à-dire de la partie écart à l'observation. A chaque pas, + la valeur correspond à l'état optimal trouvé depuis le début. Exemple : ``JoACO = ADD.get("CostFunctionJoAtCurrentOptimum")[:]`` CurrentOptimum - *Liste de vecteurs*. Chaque élément est le vecteur d'état optimal au pas de - temps courant au cours du déroulement de l'algorithme d'optimisation. Ce - n'est pas nécessairement le dernier état. + *Liste de vecteurs*. Chaque élément est le vecteur d'état optimal au pas de + temps courant au cours du déroulement de l'algorithme d'optimisation. Ce + n'est pas nécessairement le dernier état. Exemple : ``Xo = ADD.get("CurrentOptimum")[:]`` CurrentState - *Liste de vecteurs*. Chaque élément est un vecteur d'état courant utilisé - au cours du déroulement de l'algorithme d'optimisation. + *Liste de vecteurs*. Chaque élément est un vecteur d'état courant utilisé + au cours du déroulement de l'algorithme d'optimisation. Exemple : ``Xs = ADD.get("CurrentState")[:]`` IndexOfOptimum - *Liste d'entiers*. Chaque élément est l'index d'itération de l'optimum - obtenu au cours du déroulement de l'algorithme d'optimisation. Ce n'est pas - nécessairement le numéro de la dernière itération. + *Liste d'entiers*. Chaque élément est l'index d'itération de l'optimum + obtenu au cours du déroulement de l'algorithme d'optimisation. Ce n'est pas + nécessairement le numéro de la dernière itération. Exemple : ``i = ADD.get("IndexOfOptimum")[-1]`` Innovation - *Liste de vecteurs*. Chaque élément est un vecteur d'innovation, qui est - en statique l'écart de l'optimum à l'ébauche, et en dynamique l'incrément - d'évolution. + *Liste de vecteurs*. Chaque élément est un vecteur d'innovation, qui est + en statique l'écart de l'optimum à l'ébauche, et en dynamique l'incrément + d'évolution. Exemple : ``d = ADD.get("Innovation")[-1]`` InnovationAtCurrentState - *Liste de vecteurs*. Chaque élément est un vecteur d'innovation à l'état + *Liste de vecteurs*. Chaque élément est un vecteur d'innovation à l'état courant. Exemple : ``ds = ADD.get("InnovationAtCurrentState")[-1]`` MahalanobisConsistency - *Liste de valeurs*. Chaque élément est une valeur de l'indicateur de - qualité de Mahalanobis. + *Liste de valeurs*. Chaque élément est une valeur de l'indicateur de + qualité de Mahalanobis. Exemple : ``m = ADD.get("MahalanobisConsistency")[-1]`` OMA - *Liste de vecteurs*. Chaque élément est un vecteur d'écart entre - l'observation et l'état optimal dans l'espace des observations. + *Liste de vecteurs*. Chaque élément est un vecteur d'écart entre + l'observation et l'état optimal dans l'espace des observations. Exemple : ``oma = ADD.get("OMA")[-1]`` OMB - *Liste de vecteurs*. Chaque élément est un vecteur d'écart entre - l'observation et l'état d'ébauche dans l'espace des observations. + *Liste de vecteurs*. Chaque élément est un vecteur d'écart entre + l'observation et l'état d'ébauche dans l'espace des observations. Exemple : ``omb = ADD.get("OMB")[-1]`` Residu - *Liste de valeurs*. Chaque élément est la valeur du résidu particulier - vérifié lors d'un algorithme de vérification, selon l'ordre des tests - effectués. + *Liste de valeurs*. Chaque élément est la valeur du résidu particulier + vérifié lors d'un algorithme de vérification, selon l'ordre des tests + effectués. Exemple : ``r = ADD.get("Residu")[:]`` SigmaBck2 - *Liste de valeurs*. Chaque élément est une valeur de l'indicateur de - qualité :math:`(\sigma^b)^2` de la partie ébauche. + *Liste de valeurs*. Chaque élément est une valeur de l'indicateur de + qualité :math:`(\sigma^b)^2` de la partie ébauche. Exemple : ``sb2 = ADD.get("SigmaBck")[-1]`` SigmaObs2 - *Liste de valeurs*. Chaque élément est une valeur de l'indicateur de - qualité :math:`(\sigma^o)^2` de la partie observation. + *Liste de valeurs*. Chaque élément est une valeur de l'indicateur de + qualité :math:`(\sigma^o)^2` de la partie observation. Exemple : ``so2 = ADD.get("SigmaObs")[-1]`` SimulatedObservationAtBackground - *Liste de vecteurs*. Chaque élément est un vecteur d'observation simulé à - partir de l'ébauche :math:`\mathbf{x}^b`. C'est la prévision à partir de - l'ébauche, et elle est parfois appellée "*Dry*". + *Liste de vecteurs*. Chaque élément est un vecteur d'observation simulé à + partir de l'ébauche :math:`\mathbf{x}^b`. C'est la prévision à partir de + l'ébauche, et elle est parfois appellée "*Dry*". Exemple : ``hxb = ADD.get("SimulatedObservationAtBackground")[-1]`` SimulatedObservationAtCurrentOptimum - *Liste de vecteurs*. Chaque élément est un vecteur d'observation simulé à - partir de l'état optimal au pas de temps courant au cours du déroulement de - l'algorithme d'optimisation, c'est-à-dire dans l'espace des observations. + *Liste de vecteurs*. Chaque élément est un vecteur d'observation simulé à + partir de l'état optimal au pas de temps courant au cours du déroulement de + l'algorithme d'optimisation, c'est-à-dire dans l'espace des observations. Exemple : ``hxo = ADD.get("SimulatedObservationAtCurrentOptimum")[-1]`` SimulatedObservationAtCurrentState - *Liste de vecteurs*. Chaque élément est un vecteur d'observation simulé à - partir de l'état courant, c'est-à-dire dans l'espace des observations. + *Liste de vecteurs*. Chaque élément est un vecteur d'observation simulé à + partir de l'état courant, c'est-à-dire dans l'espace des observations. Exemple : ``hxs = ADD.get("SimulatedObservationAtCurrentState")[-1]`` SimulatedObservationAtOptimum - *Liste de vecteurs*. Chaque élément est un vecteur d'observation simulé à - partir de l'analyse ou de l'état optimal :math:`\mathbf{x}^a`. C'est la - prévision à partir de l'analyse ou de l'état optimal, et elle est parfois - appellée "*Forecast*". + *Liste de vecteurs*. Chaque élément est un vecteur d'observation simulé à + partir de l'analyse ou de l'état optimal :math:`\mathbf{x}^a`. C'est la + prévision à partir de l'analyse ou de l'état optimal, et elle est parfois + appellée "*Forecast*". Exemple : ``hxa = ADD.get("SimulatedObservationAtOptimum")[-1]`` SimulationQuantiles - *Liste de vecteurs*. Chaque élément est un vecteur correspondant à l'état - observé qui réalise le quantile demandé, dans le même ordre que les + *Liste de vecteurs*. Chaque élément est un vecteur correspondant à l'état + observé qui réalise le quantile demandé, dans le même ordre que les quantiles requis par l'utilisateur. Exemple : ``sQuantiles = ADD.get("SimulationQuantiles")[:]`` -.. [#] Pour de plus amples informations sur PARAVIS, voir le *module PARAVIS* et son aide intégrée disponible dans le menu principal *Aide* de l'environnement SALOME. +.. [#] Pour de plus amples informations sur PARAVIS, voir le *module PARAVIS* et son aide intégrée disponible dans le menu principal *Aide* de l'environnement SALOME. -.. [#] 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. +.. [#] 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. diff --git a/doc/fr/reference.rst b/doc/fr/reference.rst index 89962c2..4c4f685 100644 --- a/doc/fr/reference.rst +++ b/doc/fr/reference.rst @@ -24,38 +24,38 @@ .. _section_reference: ================================================================================ -**[DocR]** Description de référence des commandes et mots-clés ADAO +**[DocR]** Description de référence des commandes et mots-clés ADAO ================================================================================ -Les sections suivantes présentent la description de référence des commandes et -mots-clés ADAO disponibles à travers l'interface graphique (GUI) ou à travers -des scripts. Les deux premières sections communes présentent les +Les sections suivantes présentent la description de référence des commandes et +mots-clés ADAO disponibles à travers l'interface graphique (GUI) ou à travers +des scripts. Les deux premières sections communes présentent les :ref:`section_reference_entry` et les :ref:`section_reference_special_entry`. -Ensuite, on décrit successivement les :ref:`section_reference_assimilation` et +Ensuite, on décrit successivement les :ref:`section_reference_assimilation` et les :ref:`section_reference_checking`. -Chaque commande ou mot-clé à définir par l'interface graphique (GUI) a des -propriétés particulières. La première propriété est d'être *requise*, -*optionnelle* ou simplement utile, décrivant un type d'entrée. La seconde -propriété est d'être une variable "ouverte" avec un type fixé mais avec -n'importe quelle valeur autorisée par le type, ou une variable "fermée", limitée -à des valeurs spécifiées. L'éditeur graphique intégré disposant de capacités -intrinsèques de validation, les propriétés des commandes ou mots-clés données à +Chaque commande ou mot-clé à définir par l'interface graphique (GUI) a des +propriétés particulières. La première propriété est d'être *requise*, +*optionnelle* ou simplement utile, décrivant un type d'entrée. La seconde +propriété est d'être une variable "ouverte" avec un type fixé mais avec +n'importe quelle valeur autorisée par le type, ou une variable "fermée", limitée +à des valeurs spécifiées. L'éditeur graphique intégré disposant de capacités +intrinsèques de validation, les propriétés des commandes ou mots-clés données à l'aide de l'interface graphique sont automatiquement correctes. .. _section_reference_entry: ======================================================================================== -**[DocR]** Entrées et sorties générales +**[DocR]** Entrées et sorties générales ======================================================================================== -Cette section décrit de manière générale les différentes possibilités de types -d'entrées et de variables de sortie que l'on peut utiliser. Les notations -mathématiques utilisées sont expliquées dans la section :ref:`section_theory`. +Cette section décrit de manière générale les différentes possibilités de types +d'entrées et de variables de sortie que l'on peut utiliser. Les notations +mathématiques utilisées sont expliquées dans la section :ref:`section_theory`. .. toctree:: :maxdepth: 1 - + ref_entry_types ref_options_AlgorithmParameters ref_output_variables @@ -63,16 +63,16 @@ math .. _section_reference_special_entry: ======================================================================================== -**[DocR]** Entrées spéciales : fonctions, matrices, "*observer*" +**[DocR]** Entrées spéciales : fonctions, matrices, "*observer*" ======================================================================================== -Cette section décrit les entrées spéciales, comme les formes fonctionnelles ou -matricielles, que l'on peut utiliser. Les notations mathématiques utilisées -sont expliquées dans la section :ref:`section_theory`. +Cette section décrit les entrées spéciales, comme les formes fonctionnelles ou +matricielles, que l'on peut utiliser. Les notations mathématiques utilisées +sont expliquées dans la section :ref:`section_theory`. .. toctree:: :maxdepth: 1 - + ref_operator_requirements ref_covariance_requirements ref_observers_requirements @@ -80,21 +80,21 @@ sont expliqu .. _section_reference_assimilation: ============================================================================================ -**[DocR]** Cas d'assimilation de données ou d'optimisation +**[DocR]** Cas d'assimilation de données ou d'optimisation ============================================================================================ -Cette section décrit les algorithmes d'assimilation de données ou d'optimisation -disponibles dans ADAO, détaillant leurs caractéristiques d'utilisation et leurs +Cette section décrit les algorithmes d'assimilation de données ou d'optimisation +disponibles dans ADAO, détaillant leurs caractéristiques d'utilisation et leurs options. Des exemples sur l'usage de ces commandes sont disponibles dans la section -:ref:`section_examples` et dans les fichiers d'exemple installés avec le module -ADAO. Les notations mathématiques utilisées sont expliquées dans la section +:ref:`section_examples` et dans les fichiers d'exemple installés avec le module +ADAO. Les notations mathématiques utilisées sont expliquées dans la section :ref:`section_theory`. .. toctree:: :maxdepth: 1 - + ref_assimilation_keywords ref_algorithm_3DVAR ref_algorithm_4DVAR @@ -113,20 +113,20 @@ ADAO. Les notations math .. _section_reference_checking: ================================================================================ -**[DocR]** Cas de vérification +**[DocR]** Cas de vérification ================================================================================ -Cette section décrit les algorithmes de vérification disponibles dans ADAO, -détaillant leurs caractéristiques d'utilisation et leurs options. +Cette section décrit les algorithmes de vérification disponibles dans ADAO, +détaillant leurs caractéristiques d'utilisation et leurs options. Des exemples sur l'usage de ces commandes sont disponibles dans la section -:ref:`section_examples` et dans les fichiers d'exemple installés avec le module -ADAO. Les notations mathématiques utilisées sont expliquées dans la section +:ref:`section_examples` et dans les fichiers d'exemple installés avec le module +ADAO. Les notations mathématiques utilisées sont expliquées dans la section :ref:`section_theory`. .. toctree:: :maxdepth: 1 - + ref_checking_keywords ref_algorithm_AdjointTest ref_algorithm_FunctionTest diff --git a/doc/fr/theory.rst b/doc/fr/theory.rst index ebe3bbc..1ba5d50 100644 --- a/doc/fr/theory.rst +++ b/doc/fr/theory.rst @@ -24,220 +24,220 @@ .. _section_theory: ================================================================================= -**[DocT]** Une brève introduction à l'Assimilation de Données et à l'Optimisation +**[DocT]** Une brève introduction à l'Assimilation de Données et à l'Optimisation ================================================================================= .. index:: single: Data Assimilation -.. index:: single: assimilation de données -.. index:: single: état vrai +.. index:: single: assimilation de données +.. index:: single: état vrai .. index:: single: observation .. index:: single: a priori -L'**assimilation de données** est un cadre général pour le calcul de -l'estimation optimale de l'état réel d'un système, au cours du temps si -nécessaire. Il utilise les valeurs obtenues en combinant des observations et des -modèles *a priori*, incluant de plus des informations sur leurs erreurs. - -En d'autres termes, l'assimilation de données rassemble les données mesurées -d'un système, qui sont les observations, avec une connaissance physique et -mathématique *a priori* du système, intégrée dans les modèles numériques, afin -d'obtenir la meilleure estimation possible de l'état réel du système et de ses -propriétés stochastiques. On note que cet état réel (ou "*état vrai*") ne peut -être atteint, mais peut seulement être estimé. De plus, malgré le fait que les -informations utilisées sont stochastiques par nature, l'assimilation de données -fournit des techniques déterministes afin de réaliser l'estimation de manière -très efficace. - -L'assimilation de données cherchant l'estimation la **meilleure possible**, la -démarche technique sous-jacente intègre toujours de l'optimisation afin de -trouver cette estimation : des méthodes d'optimisation choisies sont toujours -intégrées dans les algorithmes d'assimilation de données. Par ailleurs, les -méthodes d'optimisation peuvent être vues dans ADAO comme un moyen d'étendre les -applications d'assimilation de données. Elles seront présentées de cette façon -dans la section pour `Approfondir l'estimation d'état par des méthodes -d'optimisation`_, mais elles sont beaucoup plus générale et peuvent être -utilisés sans les concepts d'assimilation de données. - -Deux types principaux d'applications existent en assimilation de données, qui -sont couverts par le même formalisme : l'**identification de paramètres** et la +L'**assimilation de données** est un cadre général pour le calcul de +l'estimation optimale de l'état réel d'un système, au cours du temps si +nécessaire. Il utilise les valeurs obtenues en combinant des observations et des +modèles *a priori*, incluant de plus des informations sur leurs erreurs. + +En d'autres termes, l'assimilation de données rassemble les données mesurées +d'un système, qui sont les observations, avec une connaissance physique et +mathématique *a priori* du système, intégrée dans les modèles numériques, afin +d'obtenir la meilleure estimation possible de l'état réel du système et de ses +propriétés stochastiques. On note que cet état réel (ou "*état vrai*") ne peut +être atteint, mais peut seulement être estimé. De plus, malgré le fait que les +informations utilisées sont stochastiques par nature, l'assimilation de données +fournit des techniques déterministes afin de réaliser l'estimation de manière +très efficace. + +L'assimilation de données cherchant l'estimation la **meilleure possible**, la +démarche technique sous-jacente intègre toujours de l'optimisation afin de +trouver cette estimation : des méthodes d'optimisation choisies sont toujours +intégrées dans les algorithmes d'assimilation de données. Par ailleurs, les +méthodes d'optimisation peuvent être vues dans ADAO comme un moyen d'étendre les +applications d'assimilation de données. Elles seront présentées de cette façon +dans la section pour `Approfondir l'estimation d'état par des méthodes +d'optimisation`_, mais elles sont beaucoup plus générale et peuvent être +utilisés sans les concepts d'assimilation de données. + +Deux types principaux d'applications existent en assimilation de données, qui +sont couverts par le même formalisme : l'**identification de paramètres** et la **reconstruction de champs**. Avant d'introduire la `Description simple du cadre -méthodologique de l'assimilation de données`_ dans une prochaine section, nous -décrivons brièvement ces deux types d'applications. A la fin de ce chapitre, -quelques références permettent d'`Approfondir le cadre méthodologique de -l'assimilation de données`_ et d'`Approfondir l'estimation d'état par des -méthodes d'optimisation`_. +méthodologique de l'assimilation de données`_ dans une prochaine section, nous +décrivons brièvement ces deux types d'applications. A la fin de ce chapitre, +quelques références permettent d'`Approfondir le cadre méthodologique de +l'assimilation de données`_ et d'`Approfondir l'estimation d'état par des +méthodes d'optimisation`_. -Reconstruction de champs ou interpolation de données +Reconstruction de champs ou interpolation de données ---------------------------------------------------- .. index:: single: reconstruction de champs -.. index:: single: interpolation de données +.. index:: single: interpolation de données .. index:: single: interpolation de champs -La **reconstruction (ou l'interpolation) de champs** consiste à trouver, à -partir d'un nombre restreint de mesures réelles, le champs physique qui est le -plus *cohérent* avec ces mesures. +La **reconstruction (ou l'interpolation) de champs** consiste à trouver, à +partir d'un nombre restreint de mesures réelles, le champs physique qui est le +plus *cohérent* avec ces mesures. -La *cohérence* est à comprendre en termes d'interpolation, c'est-à-dire que le -champ que l'on cherche à reconstruire, en utilisant de l'assimilation de données +La *cohérence* est à comprendre en termes d'interpolation, c'est-à-dire que le +champ que l'on cherche à reconstruire, en utilisant de l'assimilation de données sur les mesures, doit s'adapter au mieux aux mesures, tout en restant contraint -par la simulation globale du champ. Le champ calculé est donc une estimation *a -priori* du champ que l'on cherche à identifier. +par la simulation globale du champ. Le champ calculé est donc une estimation *a +priori* du champ que l'on cherche à identifier. -Si le système évolue dans le temps, la reconstruction doit être établie à chaque +Si le système évolue dans le temps, la reconstruction doit être établie à chaque pas de temps, du champ dans son ensemble. Le processus d'interpolation est dans -ce cas plus compliqué car il est temporel, et plus seulement en termes de -valeurs instantanées du champ. - -Un exemple simple de reconstruction de champs provient de la météorologie, dans -laquelle on recherche les valeurs de variables comme la température ou la -pression en tout point du domaine spatial. On dispose de mesures instantanées de -ces quantités en certains points, mais aussi d'un historique de ces mesures. De -plus, ces variables sont contraintes par les équations d'évolution de -l'atmosphère, qui indiquent par exemple que la pression en un point ne peut pas -prendre une valeur quelconque indépendamment de la valeur au même point à un -temps précédent. On doit donc faire la reconstruction d'un champ en tout point -de l'espace, de manière "cohérente" avec les équations d'évolution et avec les -mesures aux précédents pas de temps. - -Identification de paramètres, ajustement de modèles, calibration +ce cas plus compliqué car il est temporel, et plus seulement en termes de +valeurs instantanées du champ. + +Un exemple simple de reconstruction de champs provient de la météorologie, dans +laquelle on recherche les valeurs de variables comme la température ou la +pression en tout point du domaine spatial. On dispose de mesures instantanées de +ces quantités en certains points, mais aussi d'un historique de ces mesures. De +plus, ces variables sont contraintes par les équations d'évolution de +l'atmosphère, qui indiquent par exemple que la pression en un point ne peut pas +prendre une valeur quelconque indépendamment de la valeur au même point à un +temps précédent. On doit donc faire la reconstruction d'un champ en tout point +de l'espace, de manière "cohérente" avec les équations d'évolution et avec les +mesures aux précédents pas de temps. + +Identification de paramètres, ajustement de modèles, calibration ---------------------------------------------------------------- -.. index:: single: identification de paramètres -.. index:: single: ajustement de paramètres -.. index:: single: ajustement de modèles +.. index:: single: identification de paramètres +.. index:: single: ajustement de paramètres +.. index:: single: ajustement de modèles .. index:: single: calibration -.. index:: single: ébauche -.. index:: single: régularisation -.. index:: single: problèmes inverses - -L'**identification (ou l'ajustement) de paramètres** par assimilation de données -est une forme de calibration d'état qui utilise simultanément les mesures -physiques et une estimation *a priori* des paramètres (appelée l'"*ébauche*") -d'état que l'on cherche à identifier, ainsi qu'une caractérisation de leurs -erreurs. De ce point de vue, cette démarche utilise toutes les informations -disponibles sur le système physique, avec des hypothèses restrictives mais -réalistes sur les erreurs, pour trouver l'"*estimation optimale*" de l'état -vrai. On peut noter, en termes d'optimisation, que l'ébauche réalise la -"*régularisation*", au sens mathématique de Tikhonov [Tikhonov77]_ -[WikipediaTI]_, du problème principal d'identification de paramètres. On peut -aussi désigner cette démarche comme une résolution de type "*problème inverse*". - -En pratique, les deux écarts (ou incréments) observés "*calculs-mesures*" et -"*calculs-ébauche*" sont combinés pour construire la correction de calibration -des paramètres ou des conditions initiales. L'ajout de ces deux incréments -requiert une pondération relative, qui est choisie pour refléter la confiance -que l'on donne à chaque information utilisée. Cette confiance est représentée -par la covariance des erreurs sur l'ébauche et sur les observations. Ainsi +.. index:: single: ébauche +.. index:: single: régularisation +.. index:: single: problèmes inverses + +L'**identification (ou l'ajustement) de paramètres** par assimilation de données +est une forme de calibration d'état qui utilise simultanément les mesures +physiques et une estimation *a priori* des paramètres (appelée l'"*ébauche*") +d'état que l'on cherche à identifier, ainsi qu'une caractérisation de leurs +erreurs. De ce point de vue, cette démarche utilise toutes les informations +disponibles sur le système physique, avec des hypothèses restrictives mais +réalistes sur les erreurs, pour trouver l'"*estimation optimale*" de l'état +vrai. On peut noter, en termes d'optimisation, que l'ébauche réalise la +"*régularisation*", au sens mathématique de Tikhonov [Tikhonov77]_ +[WikipediaTI]_, du problème principal d'identification de paramètres. On peut +aussi désigner cette démarche comme une résolution de type "*problème inverse*". + +En pratique, les deux écarts (ou incréments) observés "*calculs-mesures*" et +"*calculs-ébauche*" sont combinés pour construire la correction de calibration +des paramètres ou des conditions initiales. L'ajout de ces deux incréments +requiert une pondération relative, qui est choisie pour refléter la confiance +que l'on donne à chaque information utilisée. Cette confiance est représentée +par la covariance des erreurs sur l'ébauche et sur les observations. Ainsi l'aspect stochastique des informations est essentiel pour construire une fonction d'erreur pour la calibration. -Un exemple simple d'identification de paramètres provient de tout type de -simulation physique impliquant un modèle paramétré. Par exemple, une simulation -de mécanique statique d'une poutre contrainte par des forces est décrite par les -paramètres de la poutre, comme un coefficient de Young, ou par l'intensité des -forces appliquées. Le problème d'estimation de paramètres consiste à chercher -par exemple la bonne valeur du coefficient de Young de telle manière à ce que la +Un exemple simple d'identification de paramètres provient de tout type de +simulation physique impliquant un modèle paramétré. Par exemple, une simulation +de mécanique statique d'une poutre contrainte par des forces est décrite par les +paramètres de la poutre, comme un coefficient de Young, ou par l'intensité des +forces appliquées. Le problème d'estimation de paramètres consiste à chercher +par exemple la bonne valeur du coefficient de Young de telle manière à ce que la simulation de la poutre corresponde aux mesures, en y incluant la connaissance des erreurs. -Description simple du cadre méthodologique de l'assimilation de données +Description simple du cadre méthodologique de l'assimilation de données ----------------------------------------------------------------------- -.. index:: single: ébauche -.. index:: single: covariances d'erreurs d'ébauche +.. index:: single: ébauche +.. index:: single: covariances d'erreurs d'ébauche .. index:: single: covariances d'erreurs d'observation .. index:: single: covariances .. index:: single: 3DVAR .. index:: single: Blue -On peut décrire ces démarches de manière simple. Par défaut, toutes les -variables sont des vecteurs, puisqu'il y a plusieurs paramètres à ajuster, ou un -champ discrétisé à reconstruire. +On peut décrire ces démarches de manière simple. Par défaut, toutes les +variables sont des vecteurs, puisqu'il y a plusieurs paramètres à ajuster, ou un +champ discrétisé à reconstruire. -Selon les notations standards en assimilation de données, on note -:math:`\mathbf{x}^a` les paramètres optimaux qui doivent être déterminés par +Selon les notations standards en assimilation de données, on note +:math:`\mathbf{x}^a` les paramètres optimaux qui doivent être déterminés par calibration, :math:`\mathbf{y}^o` les observations (ou les mesures -expérimentales) auxquelles on doit comparer les sorties de simulation, -:math:`\mathbf{x}^b` l'ébauche (valeurs *a priori*, ou valeurs de -régularisation) des paramètres cherchés, :math:`\mathbf{x}^t` les paramètres -inconnus idéaux qui donneraient exactement les observations (en supposant que -toutes les erreurs soient nulles et que le modèle soit exact) en sortie. - -Dans le cas le plus simple, qui est statique, les étapes de simulation et -d'observation peuvent être combinées en un unique opérateur d'observation noté -:math:`H` (linéaire ou non-linéaire). Il transforme formellement les paramètres -:math:`\mathbf{x}` en entrée en résultats :math:`\mathbf{y}`, qui peuvent être -directement comparés aux observations :math:`\mathbf{y}^o` : +expérimentales) auxquelles on doit comparer les sorties de simulation, +:math:`\mathbf{x}^b` l'ébauche (valeurs *a priori*, ou valeurs de +régularisation) des paramètres cherchés, :math:`\mathbf{x}^t` les paramètres +inconnus idéaux qui donneraient exactement les observations (en supposant que +toutes les erreurs soient nulles et que le modèle soit exact) en sortie. + +Dans le cas le plus simple, qui est statique, les étapes de simulation et +d'observation peuvent être combinées en un unique opérateur d'observation noté +:math:`H` (linéaire ou non-linéaire). Il transforme formellement les paramètres +:math:`\mathbf{x}` en entrée en résultats :math:`\mathbf{y}`, qui peuvent être +directement comparés aux observations :math:`\mathbf{y}^o` : .. math:: \mathbf{y} = H(\mathbf{x}) -De plus, on utilise l'opérateur linéarisé :math:`\mathbf{H}` pour représenter -l'effet de l'opérateur complet :math:`H` autour d'un point de linéarisation (et -on omettra ensuite de mentionner :math:`H` même si l'on peut le conserver). En -réalité, on a déjà indiqué que la nature stochastique des variables est -essentielle, provenant du fait que le modèle, l'ébauche et les observations sont +De plus, on utilise l'opérateur linéarisé :math:`\mathbf{H}` pour représenter +l'effet de l'opérateur complet :math:`H` autour d'un point de linéarisation (et +on omettra ensuite de mentionner :math:`H` même si l'on peut le conserver). En +réalité, on a déjà indiqué que la nature stochastique des variables est +essentielle, provenant du fait que le modèle, l'ébauche et les observations sont tous incorrects. On introduit donc des erreurs d'observations additives, sous la -forme d'un vecteur aléatoire :math:`\mathbf{\epsilon}^o` tel que : +forme d'un vecteur aléatoire :math:`\mathbf{\epsilon}^o` tel que : .. math:: \mathbf{y}^o = \mathbf{H} \mathbf{x}^t + \mathbf{\epsilon}^o -Les erreurs représentées ici ne sont pas uniquement celles des observations, ce -sont aussi celles de la simulation. On peut toujours considérer que ces erreurs -sont de moyenne nulle. En notant :math:`E[.]` l'espérance mathématique -classique, on peut alors définir une matrice :math:`\mathbf{R}` des covariances +Les erreurs représentées ici ne sont pas uniquement celles des observations, ce +sont aussi celles de la simulation. On peut toujours considérer que ces erreurs +sont de moyenne nulle. En notant :math:`E[.]` l'espérance mathématique +classique, on peut alors définir une matrice :math:`\mathbf{R}` des covariances d'erreurs d'observation par l'expression : .. math:: \mathbf{R} = E[\mathbf{\epsilon}^o.{\mathbf{\epsilon}^o}^T] -L'ébauche peut aussi être écrite formellement comme une fonction de la valeur +L'ébauche peut aussi être écrite formellement comme une fonction de la valeur vraie, en introduisant le vecteur d'erreurs :math:`\mathbf{\epsilon}^b` tel que : .. math:: \mathbf{x}^b = \mathbf{x}^t + \mathbf{\epsilon}^b -Les erreurs :math:`\mathbf{\epsilon}^b` sont aussi supposées de moyenne nulle, -de la même manière que pour les observations. On définit la matrice -:math:`\mathbf{B}` des covariances d'erreurs d'ébauche par : +Les erreurs :math:`\mathbf{\epsilon}^b` sont aussi supposées de moyenne nulle, +de la même manière que pour les observations. On définit la matrice +:math:`\mathbf{B}` des covariances d'erreurs d'ébauche par : .. math:: \mathbf{B} = E[\mathbf{\epsilon}^b.{\mathbf{\epsilon}^b}^T] -L'estimation optimale des paramètres vrais :math:`\mathbf{x}^t`, étant donné -l'ébauche :math:`\mathbf{x}^b` et les observations :math:`\mathbf{y}^o`, est +L'estimation optimale des paramètres vrais :math:`\mathbf{x}^t`, étant donné +l'ébauche :math:`\mathbf{x}^b` et les observations :math:`\mathbf{y}^o`, est ainsi "l'*analyse*" :math:`\mathbf{x}^a` et provient de la minimisation d'une fonction d'erreur, explicite en assimilation variationnelle, ou d'une correction de filtrage en assimilation par filtrage. En **assimilation variationnelle**, dans un cas statique, on cherche -classiquement à minimiser la fonction :math:`J` suivante : +classiquement à minimiser la fonction :math:`J` suivante : .. math:: J(\mathbf{x})=\frac{1}{2}(\mathbf{x}-\mathbf{x}^b)^T.\mathbf{B}^{-1}.(\mathbf{x}-\mathbf{x}^b)+\frac{1}{2}(\mathbf{y}^o-\mathbf{H}.\mathbf{x})^T.\mathbf{R}^{-1}.(\mathbf{y}^o-\mathbf{H}.\mathbf{x}) -:math:`J` est classiquement désignée comme la fonctionnelle "*3D-VAR*" en -assimilation de données (voir par exemple [Talagrand97]_) ou comme la -fonctionnelle de régularisation de Tikhonov généralisée en optimisation (voir +:math:`J` est classiquement désignée comme la fonctionnelle "*3D-VAR*" en +assimilation de données (voir par exemple [Talagrand97]_) ou comme la +fonctionnelle de régularisation de Tikhonov généralisée en optimisation (voir par exemple [WikipediaTI]_). Comme les matrices de covariance :math:`\mathbf{B}` et :math:`\mathbf{R}` sont proportionnelles aux variances d'erreurs, leur -présence dans les deux termes de la fonctionnelle :math:`J` permet effectivement -de pondérer les termes d'écarts par la confiance dans les erreurs d'ébauche ou -d'observations. Le vecteur :math:`\mathbf{x}` des paramètres réalisant le +présence dans les deux termes de la fonctionnelle :math:`J` permet effectivement +de pondérer les termes d'écarts par la confiance dans les erreurs d'ébauche ou +d'observations. Le vecteur :math:`\mathbf{x}` des paramètres réalisant le minimum de cette fonction constitue ainsi l'analyse :math:`\mathbf{x}^a`. C'est -à ce niveau que l'on doit utiliser toute la panoplie des méthodes de +à ce niveau que l'on doit utiliser toute la panoplie des méthodes de minimisation de fonctions connues par ailleurs en optimisation (voir aussi la -section `Approfondir l'estimation d'état par des méthodes d'optimisation`_). -Selon la taille du vecteur :math:`\mathbf{x}` des paramètres à identifier, et la -disponibilité du gradient ou de la hessienne de :math:`J`, il est judicieux -d'adapter la méthode d'optimisation choisie (gradient, Newton, quasi-Newton...). +section `Approfondir l'estimation d'état par des méthodes d'optimisation`_). +Selon la taille du vecteur :math:`\mathbf{x}` des paramètres à identifier, et la +disponibilité du gradient ou de la hessienne de :math:`J`, il est judicieux +d'adapter la méthode d'optimisation choisie (gradient, Newton, quasi-Newton...). -En **assimilation par filtrage**, dans ce cas simple usuellement dénommé +En **assimilation par filtrage**, dans ce cas simple usuellement dénommé "*BLUE*" (pour "*Best Linear Unbiased Estimator*"), l'analyse -:math:`\mathbf{x}^a` est donnée comme une correction de l'ébauche -:math:`\mathbf{x}^b` par un terme proportionnel à la différence entre les +:math:`\mathbf{x}^a` est donnée comme une correction de l'ébauche +:math:`\mathbf{x}^b` par un terme proportionnel à la différence entre les observations :math:`\mathbf{y}^o` et les calculs :math:`\mathbf{H}\mathbf{x}^b` : .. math:: \mathbf{x}^a = \mathbf{x}^b + \mathbf{K}(\mathbf{y}^o - \mathbf{H}\mathbf{x}^b) -où :math:`\mathbf{K}` est la matrice de gain de Kalman, qui s'exprime à l'aide +où :math:`\mathbf{K}` est la matrice de gain de Kalman, qui s'exprime à l'aide des matrices de covariance sous la forme suivante : .. math:: \mathbf{K} = \mathbf{B}\mathbf{H}^T(\mathbf{H}\mathbf{B}\mathbf{H}^T+\mathbf{R})^{-1} @@ -245,110 +245,110 @@ des matrices de covariance sous la forme suivante : L'avantage du filtrage est le calcul explicite du gain, pour produire ensuite la matrice *a posteriori* de covariance d'analyse. -Dans ce cas statique simple, on peut montrer, sous une hypothèse de -distributions gaussiennes d'erreurs (très peu restrictive en pratique), que les -deux approches *variationnelle* et *de filtrage* donnent la même solution. +Dans ce cas statique simple, on peut montrer, sous une hypothèse de +distributions gaussiennes d'erreurs (très peu restrictive en pratique), que les +deux approches *variationnelle* et *de filtrage* donnent la même solution. -On indique que ces méthodes de "*3D-VAR*" et de "*BLUE*" peuvent être étendues à -des problèmes dynamiques, sous les noms respectifs de "*4D-VAR*" et de "*filtre -de Kalman*". Elles peuvent prendre en compte l'opérateur d'évolution pour -établir aux bons pas de temps une analyse de l'écart entre les observations et -les simulations et pour avoir, à chaque instant, la propagation de l'ébauche à -travers le modèle d'évolution. Un grand nombre de variantes ont été développées -pour accroître la qualité numérique des méthodes ou pour prendre en compte des -contraintes informatiques comme la taille ou la durée des calculs. +On indique que ces méthodes de "*3D-VAR*" et de "*BLUE*" peuvent être étendues à +des problèmes dynamiques, sous les noms respectifs de "*4D-VAR*" et de "*filtre +de Kalman*". Elles peuvent prendre en compte l'opérateur d'évolution pour +établir aux bons pas de temps une analyse de l'écart entre les observations et +les simulations et pour avoir, à chaque instant, la propagation de l'ébauche à +travers le modèle d'évolution. Un grand nombre de variantes ont été développées +pour accroître la qualité numérique des méthodes ou pour prendre en compte des +contraintes informatiques comme la taille ou la durée des calculs. -Approfondir le cadre méthodologique de l'assimilation de données +Approfondir le cadre méthodologique de l'assimilation de données ---------------------------------------------------------------- -.. index:: single: estimation d'état -.. index:: single: estimation de paramètres -.. index:: single: problèmes inverses -.. index:: single: estimation bayésienne +.. index:: single: estimation d'état +.. index:: single: estimation de paramètres +.. index:: single: problèmes inverses +.. index:: single: estimation bayésienne .. index:: single: interpolation optimale -.. index:: single: régularisation mathématique -.. index:: single: méthodes de régularisation -.. index:: single: méthodes de lissage +.. index:: single: régularisation mathématique +.. index:: single: méthodes de régularisation +.. index:: single: méthodes de lissage Pour obtenir de plus amples informations sur les techniques d'assimilation de -données, le lecteur peut consulter les documents introductifs comme +données, le lecteur peut consulter les documents introductifs comme [Talagrand97]_ ou [Argaud09]_, des supports de formations ou de cours comme [Bouttier99]_ et [Bocquet04]_ (ainsi que d'autres documents issus des -applications des géosciences), ou des documents généraux comme [Talagrand97]_, +applications des géosciences), ou des documents généraux comme [Talagrand97]_, [Tarantola87]_, [Kalnay03]_, [Ide97]_, [Tikhonov77]_ et [WikipediaDA]_. -On note que l'assimilation de données n'est pas limitée à la météorologie ou aux -géo-sciences, mais est largement utilisée dans d'autres domaines scientifiques. +On note que l'assimilation de données n'est pas limitée à la météorologie ou aux +géo-sciences, mais est largement utilisée dans d'autres domaines scientifiques. Il y a de nombreux champs d'applications scientifiques et technologiques dans -lesquels l'utilisation efficace des données observées, mais incomplètes, est +lesquels l'utilisation efficace des données observées, mais incomplètes, est cruciale. -Certains aspects de l'assimilation de données sont aussi connus sous les noms -d'*estimation d'état*, d'*estimation de paramètres*, de *problèmes inverses*, -d'*estimation bayésienne*, d'*interpolation optimale*, de *régularisation -mathématique*, de *lissage de données*, etc. Ces termes peuvent être utilisés +Certains aspects de l'assimilation de données sont aussi connus sous les noms +d'*estimation d'état*, d'*estimation de paramètres*, de *problèmes inverses*, +d'*estimation bayésienne*, d'*interpolation optimale*, de *régularisation +mathématique*, de *lissage de données*, etc. Ces termes peuvent être utilisés dans les recherches bibliographiques. -Approfondir l'estimation d'état par des méthodes d'optimisation +Approfondir l'estimation d'état par des méthodes d'optimisation --------------------------------------------------------------- -.. index:: single: estimation d'état -.. index:: single: méthodes d'optimisation +.. index:: single: estimation d'état +.. index:: single: méthodes d'optimisation -Comme vu précédemment, dans un cas de simulation statique, l'assimilation -variationnelle de données nécessite de minimiser la fonction objectif :math:`J`: +Comme vu précédemment, dans un cas de simulation statique, l'assimilation +variationnelle de données nécessite de minimiser la fonction objectif :math:`J`: .. math:: J(\mathbf{x})=(\mathbf{x}-\mathbf{x}^b)^T.\mathbf{B}^{-1}.(\mathbf{x}-\mathbf{x}^b)+(\mathbf{y}^o-\mathbf{H}.\mathbf{x})^T.\mathbf{R}^{-1}.(\mathbf{y}^o-\mathbf{H}.\mathbf{x}) -qui est dénommée la fonctionnelle du "*3D-VAR*". Elle peut être vue comme la -forme étendue d'une *minimisation moindres carrés*, obtenue en ajoutant un terme -de régularisation utilisant :math:`\mathbf{x}-\mathbf{x}^b`, et en pondérant les -différences par les deux matrices de covariances :math:`\mathbf{B}` et -:math:`\mathbf{R}`. La minimisation de la fonctionnelle :math:`J` conduit à la -*meilleure* estimation de l'état :math:`\mathbf{x}`. Pour obtenir plus -d'informations sur ces notions, on se reportera aux ouvrages généraux de -référence comme [Tarantola87]_. - -Les possibilités d'extension de cette estimation d'état, en utilisant de manière -plus explicite des méthodes d'optimisation et leurs propriétés, peuvent être -imaginées de deux manières. - -En premier lieu, les méthodes classiques d'optimisation impliquent l'usage de -méthodes de minimisation variées basées sur un gradient. Elles sont extrêmement -efficaces pour rechercher un minimum local isolé. Mais elles nécessitent que la -fonctionnelle :math:`J` soit suffisamment régulière et différentiable, et elles -ne sont pas en mesure de saisir des propriétés globales du problème de +qui est dénommée la fonctionnelle du "*3D-VAR*". Elle peut être vue comme la +forme étendue d'une *minimisation moindres carrés*, obtenue en ajoutant un terme +de régularisation utilisant :math:`\mathbf{x}-\mathbf{x}^b`, et en pondérant les +différences par les deux matrices de covariances :math:`\mathbf{B}` et +:math:`\mathbf{R}`. La minimisation de la fonctionnelle :math:`J` conduit à la +*meilleure* estimation de l'état :math:`\mathbf{x}`. Pour obtenir plus +d'informations sur ces notions, on se reportera aux ouvrages généraux de +référence comme [Tarantola87]_. + +Les possibilités d'extension de cette estimation d'état, en utilisant de manière +plus explicite des méthodes d'optimisation et leurs propriétés, peuvent être +imaginées de deux manières. + +En premier lieu, les méthodes classiques d'optimisation impliquent l'usage de +méthodes de minimisation variées basées sur un gradient. Elles sont extrêmement +efficaces pour rechercher un minimum local isolé. Mais elles nécessitent que la +fonctionnelle :math:`J` soit suffisamment régulière et différentiable, et elles +ne sont pas en mesure de saisir des propriétés globales du problème de minimisation, comme par exemple : minimum global, ensemble de solutions -équivalentes dues à une sur-paramétrisation, multiples minima locaux, etc. **Une -méthode pour étendre les possibilités d'estimation consiste donc à utiliser -l'ensemble des méthodes d'optimisation existantes, permettant la minimisation -globale, diverses propriétés de robustesse de la recherche, etc**. Il existe de -nombreuses méthodes de minimisation, comme les méthodes stochastiques, -évolutionnaires, les heuristiques et méta-heuristiques pour les problèmes à -valeurs réelles, etc. Elles peuvent traiter des fonctionnelles :math:`J` en -partie irrégulières ou bruitées, peuvent caractériser des minima locaux, etc. Le -principal désavantage de ces méthodes est un coût numérique souvent bien -supérieur pour trouver les estimations d'états, et pas de garantie de -convergence en temps fini. Ici, on ne mentionne que des méthodes qui sont -disponibles dans le module ADAO : la *régression de quantile (Quantile +équivalentes dues à une sur-paramétrisation, multiples minima locaux, etc. **Une +méthode pour étendre les possibilités d'estimation consiste donc à utiliser +l'ensemble des méthodes d'optimisation existantes, permettant la minimisation +globale, diverses propriétés de robustesse de la recherche, etc**. Il existe de +nombreuses méthodes de minimisation, comme les méthodes stochastiques, +évolutionnaires, les heuristiques et méta-heuristiques pour les problèmes à +valeurs réelles, etc. Elles peuvent traiter des fonctionnelles :math:`J` en +partie irrégulières ou bruitées, peuvent caractériser des minima locaux, etc. Le +principal désavantage de ces méthodes est un coût numérique souvent bien +supérieur pour trouver les estimations d'états, et pas de garantie de +convergence en temps fini. Ici, on ne mentionne que des méthodes qui sont +disponibles dans le module ADAO : la *régression de quantile (Quantile Regression)* [WikipediaQR]_ et l'*optimisation par essaim de particules (Particle Swarm Optimization)* [WikipediaPSO]_. -En second lieu, les méthodes d'optimisation cherchent usuellement à minimiser -des mesures quadratiques d'erreurs, car les propriétés naturelles de ces -fonctions objectifs sont bien adaptées à l'optimisation classique par gradient. -Mais d'autres mesures d'erreurs peuvent être mieux adaptées aux problèmes de -simulation de la physique réelle. Ainsi, **une autre manière d'étendre les -possibilités d'estimation consiste à utiliser d'autres mesures d'erreurs à -réduire**. Par exemple, on peut citer l'**erreur absolue**, l'**erreur -maximale**, etc. Ces mesures d'erreurs ne sont pas différentiables, mais -certaines méthodes d'optimisation peuvent les traiter: heuristiques et -méta-heuristiques pour les problèmes à valeurs réelles, etc. Comme précédemment, -le principal désavantage de ces méthodes est un coût numérique souvent bien -supérieur pour trouver les estimations d'états, et pas de garantie de -convergence en temps fini. Ici encore, on ne mentionne que des méthodes qui sont +En second lieu, les méthodes d'optimisation cherchent usuellement à minimiser +des mesures quadratiques d'erreurs, car les propriétés naturelles de ces +fonctions objectifs sont bien adaptées à l'optimisation classique par gradient. +Mais d'autres mesures d'erreurs peuvent être mieux adaptées aux problèmes de +simulation de la physique réelle. Ainsi, **une autre manière d'étendre les +possibilités d'estimation consiste à utiliser d'autres mesures d'erreurs à +réduire**. Par exemple, on peut citer l'**erreur absolue**, l'**erreur +maximale**, etc. Ces mesures d'erreurs ne sont pas différentiables, mais +certaines méthodes d'optimisation peuvent les traiter: heuristiques et +méta-heuristiques pour les problèmes à valeurs réelles, etc. Comme précédemment, +le principal désavantage de ces méthodes est un coût numérique souvent bien +supérieur pour trouver les estimations d'états, et pas de garantie de +convergence en temps fini. Ici encore, on ne mentionne que des méthodes qui sont disponibles dans le module ADAO : l'*optimisation par essaim de particules (Particle Swarm Optimization)* [WikipediaPSO]_. -Le lecteur intéressé par le sujet de l'optimisation pourra utilement commencer -sa recherche grâce au point d'entrée [WikipediaMO]_. +Le lecteur intéressé par le sujet de l'optimisation pourra utilement commencer +sa recherche grâce au point d'entrée [WikipediaMO]_. diff --git a/doc/fr/tui.rst b/doc/fr/tui.rst index fae2554..0ed68a7 100644 --- a/doc/fr/tui.rst +++ b/doc/fr/tui.rst @@ -30,28 +30,28 @@ **[DocR]** Interface de programmation textuelle pour l'utilisateur (API/TUI) ================================================================================ -Cette section présente des méthodes avancées d'usage du module ADAO à l'aide de +Cette section présente des méthodes avancées d'usage du module ADAO à l'aide de son interface de programmation textuelle (API/TUI). Cette interface permet de -créer un objet de calcul de manière similaire à la construction d'un cas par -l'interface graphique (GUI). Dans le cas où l'on désire réaliser à la main le +créer un objet de calcul de manière similaire à la construction d'un cas par +l'interface graphique (GUI). Dans le cas où l'on désire réaliser à la main le cas de calcul TUI, on recommande de bien s'appuyer sur l'ensemble de la -documentation du module ADAO, et de se reporter si nécessaire à l'interface -graphique (GUI), pour disposer de l'ensemble des éléments permettant de -renseigner correctement les commandes. Les notions générales et termes utilisés -ici sont définis dans :ref:`section_theory`. +documentation du module ADAO, et de se reporter si nécessaire à l'interface +graphique (GUI), pour disposer de l'ensemble des éléments permettant de +renseigner correctement les commandes. Les notions générales et termes utilisés +ici sont définis dans :ref:`section_theory`. .. _subsection_tui_creating: -Création de cas de calcul TUI ADAO et exemples +Création de cas de calcul TUI ADAO et exemples ---------------------------------------------- .. _subsection_tui_example: -Un exemple simple de création d'un cas de calcul TUI ADAO +Un exemple simple de création d'un cas de calcul TUI ADAO +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Pour introduire l'interface TUI, on commence par un exemple simple mais complet -de cas de calcul ADAO. Toutes les données sont explicitement définies dans le +de cas de calcul ADAO. Toutes les données sont explicitement définies dans le corps du script pour faciliter la lecture. L'ensemble des commandes est le suivant:: @@ -67,41 +67,41 @@ suivant:: case.set( 'Observer', Variable="Analysis", Template="ValuePrinter" ) case.execute() -Le résultat de l'exécution de ces commandes dans SALOME (que ce soit par la +Le résultat de l'exécution de ces commandes dans SALOME (que ce soit par la commande "*shell*" de SALOME, dans la console Python de l'interface, ou par le -menu d'exécution d'un script) est le suivant:: +menu d'exécution d'un script) est le suivant:: Analysis [ 0.25000264 0.79999797 0.94999939] -Création détaillée d'un cas de calcul TUI ADAO +Création détaillée d'un cas de calcul TUI ADAO ++++++++++++++++++++++++++++++++++++++++++++++ -On décrit ici plus en détail les différentes étapes de création d'un cas de -calcul TUI ADAO. Les commandes elles-mêmes sont détaillées juste après dans +On décrit ici plus en détail les différentes étapes de création d'un cas de +calcul TUI ADAO. Les commandes elles-mêmes sont détaillées juste après dans l':ref:`subsection_tui_commands`. -La création et l'initialisation d'une étude se font par les commandes suivantes, -le nom ``case`` de l'objet du cas de calcul TUI ADAO étant quelconque, au choix +La création et l'initialisation d'une étude se font par les commandes suivantes, +le nom ``case`` de l'objet du cas de calcul TUI ADAO étant quelconque, au choix de l'utilisateur:: from numpy import array import adaoBuilder case = adaoBuilder.New() -Il est recommandé d'importer par principe le module ``numpy`` ou ses +Il est recommandé d'importer par principe le module ``numpy`` ou ses constructeurs particuliers comme celui d'``array``, pour faciliter ensuite son -usage dans les commandes elle-mêmes. - -Ensuite, le cas doit être construit par une préparation et un enregistrement des -données définissant l'étude. L'ordre de ces commande n'a pas d'importance, il -suffit que les concepts requis par l'algorithme utilisé soient présentes. On se -reportera à :ref:`section_reference` et à ses sous-parties pour avoir le détail -des commandes par algorithme. Ici, on définit successivement l'algorithme -d'assimilation de données ou d'optimisation choisi et ses paramètres, puis -l'ébauche :math:`\mathbf{x}^b` (nommée ``Background``) et sa covariance -d'erreurs :math:`\mathbf{B}` (nommée ``BackgroundError``), et enfin -l'observation :math:`\mathbf{y}^o` (nommée ``Observation``) et sa covariance -d'erreurs :math:`\mathbf{R}` (nommée ``ObservationError``):: +usage dans les commandes elle-mêmes. + +Ensuite, le cas doit être construit par une préparation et un enregistrement des +données définissant l'étude. L'ordre de ces commande n'a pas d'importance, il +suffit que les concepts requis par l'algorithme utilisé soient présentes. On se +reportera à :ref:`section_reference` et à ses sous-parties pour avoir le détail +des commandes par algorithme. Ici, on définit successivement l'algorithme +d'assimilation de données ou d'optimisation choisi et ses paramètres, puis +l'ébauche :math:`\mathbf{x}^b` (nommée ``Background``) et sa covariance +d'erreurs :math:`\mathbf{B}` (nommée ``BackgroundError``), et enfin +l'observation :math:`\mathbf{y}^o` (nommée ``Observation``) et sa covariance +d'erreurs :math:`\mathbf{R}` (nommée ``ObservationError``):: case.set( 'AlgorithmParameters', Algorithm='3DVAR' ) # @@ -111,29 +111,29 @@ d'erreurs :math:`\mathbf{R}` (nomm case.set( 'Observation', Vector=array([0.5, 1.5, 2.5]) ) case.set( 'ObservationError', DiagonalSparseMatrix='1 1 1' ) -On remarque que l'on peut donner, en entrée des quantités vectorielles ou +On remarque que l'on peut donner, en entrée des quantités vectorielles ou matricielles, des objets de type ``str``, ``list`` ou ``tuple`` de Python, ou de type ``array`` ou ``matrix`` de Numpy. Dans ces deux derniers cas, il faut simplement importer le module Numpy avant. -On doit ensuite définir les opérateurs :math:`H` d'observation et éventuellement -:math:`M` d'évolution. Dans tous les cas, linéaire ou non-linéaire, on peut les -définir comme des fonctions. Dans le cas simple d'un opérateur linéaire, on peut -aussi le définir à l'aide de la matrice qui correspond à l'opérateur linéaire. -Dans le cas présent le plus simple d'opérateur linéaire, on utilise la syntaxe -suivante pour un opérateur de :math:`\mathbf{R}^3` sur lui-même:: +On doit ensuite définir les opérateurs :math:`H` d'observation et éventuellement +:math:`M` d'évolution. Dans tous les cas, linéaire ou non-linéaire, on peut les +définir comme des fonctions. Dans le cas simple d'un opérateur linéaire, on peut +aussi le définir à l'aide de la matrice qui correspond à l'opérateur linéaire. +Dans le cas présent le plus simple d'opérateur linéaire, on utilise la syntaxe +suivante pour un opérateur de :math:`\mathbf{R}^3` sur lui-même:: case.ObservationOperator(Matrix = "1 0 0;0 2 0;0 0 3") -Dans le cas beaucoup plus courant d'un opérateur non-linéaire de -:math:`\mathbf{R}^n` dans :math:`\mathbf{R}^p`, il doit être préalablement +Dans le cas beaucoup plus courant d'un opérateur non-linéaire de +:math:`\mathbf{R}^n` dans :math:`\mathbf{R}^p`, il doit être préalablement disponible sous la forme d'une fonction Python, connue dans l'espace de nommage -courant, qui prend en entrée un vecteur ``numpy`` (ou une liste ordonnée) de +courant, qui prend en entrée un vecteur ``numpy`` (ou une liste ordonnée) de taille :math:`n` et qui restitue en sortie un vecteur ``numpy`` de taille -:math:`p`. Lorsque seul l'opérateur non-linéaire est défini par l'argument -"*OneFunction*", son adjoint est directement établi de manière numérique et il -est paramétrable par l'argument "*Parameters*". L'exemple suivant montre une -fonction ``simulation`` (qui réalise ici le même opérateur linéaire que +:math:`p`. Lorsque seul l'opérateur non-linéaire est défini par l'argument +"*OneFunction*", son adjoint est directement établi de manière numérique et il +est paramétrable par l'argument "*Parameters*". L'exemple suivant montre une +fonction ``simulation`` (qui réalise ici le même opérateur linéaire que ci-dessus) et l'enregistre dans le cas ADAO:: import numpy @@ -148,82 +148,82 @@ ci-dessus) et l'enregistre dans le cas ADAO:: Parameters = {"DifferentialIncrement":0.01}, ) -Pour connaître les résultats intermédiaire ou finaux du calcul du cas, on peut -ajouter des "*observer*", qui permettent d'associer l'exécution d'un script à -une variable intermédiaire ou finale du calcul. On se reportera à la description -de la manière d':ref:`section_advanced_observer`, et à la :ref:`section_reference` -pour savoir quelles sont les quantités observables. Cette association -d'"*observer*" avec une quantité existante se fait de manière similaire à la -définition des données du calcul:: +Pour connaître les résultats intermédiaire ou finaux du calcul du cas, on peut +ajouter des "*observer*", qui permettent d'associer l'exécution d'un script à +une variable intermédiaire ou finale du calcul. On se reportera à la description +de la manière d':ref:`section_advanced_observer`, et à la :ref:`section_reference` +pour savoir quelles sont les quantités observables. Cette association +d'"*observer*" avec une quantité existante se fait de manière similaire à la +définition des données du calcul:: case.set( 'Observer', Variable="Analysis", Template="ValuePrinter" ) Enfin, lorsque toutes les informations requises sont disponibles dans le cas -``case`` de calcul ADAO, on peut en demander l'exécution de manière très -simple dans l'environnement de l'interpréteur Python:: +``case`` de calcul ADAO, on peut en demander l'exécution de manière très +simple dans l'environnement de l'interpréteur Python:: case.execute() -Au final, on obtient le script très compact proposé précédemment dans +Au final, on obtient le script très compact proposé précédemment dans :ref:`subsection_tui_example`. -Fournir des données ou informations de calcul plus complexes +Fournir des données ou informations de calcul plus complexes ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -Une telle interface s'écrivant en Python, il est possible d'utiliser toute la -puissance du langage pour entrer des données plus complexes qu'une déclaration +Une telle interface s'écrivant en Python, il est possible d'utiliser toute la +puissance du langage pour entrer des données plus complexes qu'une déclaration explicite. -L'enregistrement des données d'entrées supporte différents types de variables, -mais surtout, ces entrées peuvent recevoir des variables courantes disponibles -dans l'espace de nommage du script. Il est donc aisé d'utiliser des variables -calculées préalablement ou obtenues par l'import de scripts "utilisateur". Si +L'enregistrement des données d'entrées supporte différents types de variables, +mais surtout, ces entrées peuvent recevoir des variables courantes disponibles +dans l'espace de nommage du script. Il est donc aisé d'utiliser des variables +calculées préalablement ou obtenues par l'import de scripts "utilisateur". Si par exemple les observations sont disponibles sous la forme d'une liste dans un -fichier Python externe nommé ``observations.py`` sous le nom ``table``, il -suffit de réaliser les opérations suivantes pour enregistrer les observations +fichier Python externe nommé ``observations.py`` sous le nom ``table``, il +suffit de réaliser les opérations suivantes pour enregistrer les observations dans le cas de calcul TUI ADAO:: from observations import table case.set( 'Observation', Vector=table ) -La première ligne importe la variable ``table`` depuis le fichier externe, et la -seconde enregistre directement cette table comme la donnée "*Observation*". +La première ligne importe la variable ``table`` depuis le fichier externe, et la +seconde enregistre directement cette table comme la donnée "*Observation*". -La simplicité de cet enregistrement montre bien la facilité d'obtenir les -données de calcul depuis des sources externes, fichiers ou flux informatiques -atteignables en Python. Comme d'habitude, il est recommandé à l'utilisateur de -vérifier ses données avant de les enregistrer dans le cas de calcul TUI ADAO -pour éviter les erreurs compliquées à corriger. +La simplicité de cet enregistrement montre bien la facilité d'obtenir les +données de calcul depuis des sources externes, fichiers ou flux informatiques +atteignables en Python. Comme d'habitude, il est recommandé à l'utilisateur de +vérifier ses données avant de les enregistrer dans le cas de calcul TUI ADAO +pour éviter les erreurs compliquées à corriger. -Obtenir et utiliser les résultats de calcul de manière plus riche +Obtenir et utiliser les résultats de calcul de manière plus riche +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -De la même manière, il est possible d'obtenir et traiter les résultats de calcul -de manière plus riche, pour enchaîner sur des post-traitements après le calcul +De la même manière, il est possible d'obtenir et traiter les résultats de calcul +de manière plus riche, pour enchaîner sur des post-traitements après le calcul en TUI. -Les variables de résultats de calcul, ou les variables internes issues de -l'optimisation ou de l'assimilation de données, sont disponibles à travers la -méthode ``get`` du cas de calcul TUI ADAO, qui renvoie un objet de type liste de -la variable demandée. On se reportera aux :ref:`section_ref_output_variables` -pour une description détaillée sur ce sujet. +Les variables de résultats de calcul, ou les variables internes issues de +l'optimisation ou de l'assimilation de données, sont disponibles à travers la +méthode ``get`` du cas de calcul TUI ADAO, qui renvoie un objet de type liste de +la variable demandée. On se reportera aux :ref:`section_ref_output_variables` +pour une description détaillée sur ce sujet. A titre d'exemple, on donne quelques lignes de script qui permettent d'obtenir -le nombre d'itérations de l'optimisation et la valeur optimale ainsi que sa +le nombre d'itérations de l'optimisation et la valeur optimale ainsi que sa taille:: - print - print " Nombre d'iterations :", len(case.get("CostFunctionJ")) + print("") + print(" Nombre d'iterations : %i"%len(case.get("CostFunctionJ"))) Xa = case.get("Analysis") - print " Analyse optimale :", Xa[-1] - print " Taille de l'analyse :", len(Xa[-1]) - print + print(" Analyse optimale : %s"%(Xa[-1],)) + print(" Taille de l'analyse : %i"%len(Xa[-1])) + print("") -Ces lignes peuvent être très simplement additionnées à l'exemple initial de cas -de calcul TUI ADAO proposé dans :ref:`subsection_tui_example`. +Ces lignes peuvent être très simplement additionnées à l'exemple initial de cas +de calcul TUI ADAO proposé dans :ref:`subsection_tui_example`. -De même que pour l'entrée des données, la simplicité de récupération des -résultats permet d'envisager aisément des post-traitements enchaînés dans +De même que pour l'entrée des données, la simplicité de récupération des +résultats permet d'envisager aisément des post-traitements enchaînés dans SALOME, pour utiliser par exemple de la visualisation avec MatPlotLib ou PARAVIS [PARAVIS]_, de l'adaptation de maillage avec HOMARD [HOMARD]_, ou pour d'autres calculs. @@ -235,35 +235,35 @@ Ensemble des commandes disponibles en interface textuelle TUI Dans l'interface TUI du module ADAO, on suit les conventions et recommandations courantes en Python pour la distinction entre ce qui est public, et ce qui est -privé ou réservé car relevant des détails d'implémentation. De manière pratique, -tout nom d'objet ou de fonction commençant par au moins un signe "_" est privé -au sens courant de programmation ("*private*"). Néanmoins, l'absence d'un tel -signe au début d'un nom ne le désigne pas comme public. De manière générale, en -Python, et contrairement à d'autres langages, on peut accéder aux objets ou aux -fonction privés. Cela peut parfois être utile, mais un tel usage dans vos codes -conduira à des plantages sans avertissement lors de futures versions. Il est -donc fortement recommandé de ne pas le faire. +privé ou réservé car relevant des détails d'implémentation. De manière pratique, +tout nom d'objet ou de fonction commençant par au moins un signe "_" est privé +au sens courant de programmation ("*private*"). Néanmoins, l'absence d'un tel +signe au début d'un nom ne le désigne pas comme public. De manière générale, en +Python, et contrairement à d'autres langages, on peut accéder aux objets ou aux +fonction privés. Cela peut parfois être utile, mais un tel usage dans vos codes +conduira à des plantages sans avertissement lors de futures versions. Il est +donc fortement recommandé de ne pas le faire. Pour clarifier et faciliter l'utilisation du module pour du script, **cette -section définit donc l'interface de programmation (API) textuelle publique pour -l'utilisateur (TUI) de manière complète et limitative**. L'usage en script -d'objets ou fonctions ADAO autres que ceux qui sont définis ici est fortement -déconseillé, car cela conduira vraisemblablement à des plantages sans +section définit donc l'interface de programmation (API) textuelle publique pour +l'utilisateur (TUI) de manière complète et limitative**. L'usage en script +d'objets ou fonctions ADAO autres que ceux qui sont définis ici est fortement +déconseillé, car cela conduira vraisemblablement à des plantages sans avertissement lors de futures versions. -Syntaxes d'appel équivalentes pour les commandes TUI +Syntaxes d'appel équivalentes pour les commandes TUI ++++++++++++++++++++++++++++++++++++++++++++++++++++ -La définition des données lors de la création de cas de calcul TUI ADAO supporte -**deux syntaxes entièrement équivalentes**. On peut : +La définition des données lors de la création de cas de calcul TUI ADAO supporte +**deux syntaxes entièrement équivalentes**. On peut : - soit utiliser la commande ``set`` et comme premier argument le concept ``XXXXX`` sur lequel appliquer la commande dont les arguments suivent, - soit utiliser la commande ``setXXXXX`` contenant les arguments de la commande - à appliquer. + à appliquer. -Pour illustrer cette équivalence, on prend l'exemple des deux commandes -suivantes qui conduisent au même résultat:: +Pour illustrer cette équivalence, on prend l'exemple des deux commandes +suivantes qui conduisent au même résultat:: case.set( 'Background', Vector=[0, 1, 2] ) @@ -271,41 +271,41 @@ et:: case.setBackground( Vector=[0, 1, 2] ) -Le choix de l'une ou l'autre des syntaxes est librement laissé à l'utilisateur, -selon son contexte d'usage. Dans la suite, par souci de clarté, on définit les +Le choix de l'une ou l'autre des syntaxes est librement laissé à l'utilisateur, +selon son contexte d'usage. Dans la suite, par souci de clarté, on définit les commandes selon la seconde syntaxe. -Création d'un cas de calcul en interface textuelle TUI +Création d'un cas de calcul en interface textuelle TUI ++++++++++++++++++++++++++++++++++++++++++++++++++++++ -La création et l'initialisation d'un cas de calcul en interface textuelle TUI se +La création et l'initialisation d'un cas de calcul en interface textuelle TUI se font en important le module d'interface "*adaoBuilder*" et en invoquant sa -méthode "*New()*" comme illustré dans les quelques lignes suivantes (le nom -``case`` de l'objet étant quelconque, au choix de l'utilisateur):: +méthode "*New()*" comme illustré dans les quelques lignes suivantes (le nom +``case`` de l'objet étant quelconque, au choix de l'utilisateur):: from numpy import array import adaoBuilder case = adaoBuilder.New() -Il est recommandé par principe de toujours importer le module ``numpy`` (ou ses +Il est recommandé par principe de toujours importer le module ``numpy`` (ou ses constructeurs particuliers, comme celui d'``array``) pour faciliter ensuite son -usage dans les commandes elle-mêmes. +usage dans les commandes elle-mêmes. -Définir les données de calcul +Définir les données de calcul +++++++++++++++++++++++++++++ -Les commandes qui suivent permettent de définir les données d'un cas de calcul +Les commandes qui suivent permettent de définir les données d'un cas de calcul TUI ADAO. Le pseudo-type des arguments est similaire et compatible avec ceux des -entrées en interface GUI, décrits dans la section des +entrées en interface GUI, décrits dans la section des :ref:`section_reference_entry` et en particulier par la -:ref:`section_ref_entry_types`. La vérification de l'adéquation des grandeurs se -fait soit lors de leur définition, soit lors de l'exécution. - -Dans chaque commande, le mot-clé booléen "*Stored*" permet d'indiquer si l'on -veut éventuellement la stocker la grandeur définie, pour en disposer en cours de -calcul ou en sortie. Le choix par défaut est de ne pas stocker, et il est -recommandé de conserver cette valeur par défaut. En effet, pour un cas de calcul -TUI, on dispose déjà souvent des grandeurs données en entrées qui sont présentes +:ref:`section_ref_entry_types`. La vérification de l'adéquation des grandeurs se +fait soit lors de leur définition, soit lors de l'exécution. + +Dans chaque commande, le mot-clé booléen "*Stored*" permet d'indiquer si l'on +veut éventuellement la stocker la grandeur définie, pour en disposer en cours de +calcul ou en sortie. Le choix par défaut est de ne pas stocker, et il est +recommandé de conserver cette valeur par défaut. En effet, pour un cas de calcul +TUI, on dispose déjà souvent des grandeurs données en entrées qui sont présentes dans l'espace de nommage courant du cas. Les commandes disponibles sont les suivantes : @@ -313,221 +313,222 @@ Les commandes disponibles sont les suivantes : .. index:: single: setBackground **setBackground** (*Vector, VectorSerie, Script, Stored*) - Cette commande permet de définir l'ébauche :math:`\mathbf{x}^b`. Selon les - algorithmes, on peut la définir comme un vecteur simple par "*Vector*", ou - comme une liste de vecteurs par "*VectorSerie*". Si on la définit par un - script dans "*Script*", le vecteur est de type "*Vector*" (par défaut) ou - "*VectorSerie*" selon que l'une de ces variables est placée à "*True*". + Cette commande permet de définir l'ébauche :math:`\mathbf{x}^b`. Selon les + algorithmes, on peut la définir comme un vecteur simple par "*Vector*", ou + comme une liste de vecteurs par "*VectorSerie*". Si on la définit par un + script dans "*Script*", le vecteur est de type "*Vector*" (par défaut) ou + "*VectorSerie*" selon que l'une de ces variables est placée à "*True*". .. index:: single: setBackgroundError **setBackgroundError** (*Matrix, ScalarSparseMatrix, DiagonalSparseMatrix, Script, Stored*) - Cette commande permet de définir la matrice :math:`\mathbf{B}` de - covariance des erreurs d'ébauche. La matrice peut être définie de manière - complète par le mot-clé "*Matrix*", ou de manière parcimonieuse, comme une + Cette commande permet de définir la matrice :math:`\mathbf{B}` de + covariance des erreurs d'ébauche. La matrice peut être définie de manière + complète par le mot-clé "*Matrix*", ou de manière parcimonieuse, comme une matrice diagonale dont on donne la variance unique sur la diagonale par "*ScalarSparseMatrix*", ou comme une matrice diagonale dont on donne le - vecteur des variances situé sur la diagonale par "*DiagonalSparseMatrix*". - Si on la définit par un script dans "*Script*", la matrice est de type - "*Matrix*" (par défaut), "*ScalarSparseMatrix*" ou "*DiagonalSparseMatrix*" - selon que l'une de ces variables est placée à "*True*". + vecteur des variances situé sur la diagonale par "*DiagonalSparseMatrix*". + Si on la définit par un script dans "*Script*", la matrice est de type + "*Matrix*" (par défaut), "*ScalarSparseMatrix*" ou "*DiagonalSparseMatrix*" + selon que l'une de ces variables est placée à "*True*". .. index:: single: setCheckingPoint **setCheckingPoint** (*Vector, VectorSerie, Script, Stored*) - Cette commande permet de définir un point courant :math:`\mathbf{x}` utilisé - pour un algorithme de vérification. Selon les algorithmes, on peut le - définir comme un vecteur simple par "*Vector*", ou comme une liste de - vecteurs par "*VectorSerie*". Si on le définit par un script dans - "*Script*", le vecteur est de type "*Vector*" (par défaut) ou - "*VectorSerie*" selon que l'une de ces variables est placée à "*True*". + Cette commande permet de définir un point courant :math:`\mathbf{x}` utilisé + pour un algorithme de vérification. Selon les algorithmes, on peut le + définir comme un vecteur simple par "*Vector*", ou comme une liste de + vecteurs par "*VectorSerie*". Si on le définit par un script dans + "*Script*", le vecteur est de type "*Vector*" (par défaut) ou + "*VectorSerie*" selon que l'une de ces variables est placée à "*True*". .. index:: single: setControlModel **setControlModel** (*Matrix, OneFunction, ThreeFunctions, Parameters, Script, Stored*) - Cette commande permet de définir l'opérateur de contrôle :math:`O`, qui - décrit un contrôle d'entrée linéaire externe de l'opérateur d'évolution ou + Cette commande permet de définir l'opérateur de contrôle :math:`O`, qui + décrit un contrôle d'entrée linéaire externe de l'opérateur d'évolution ou d'observation. On se reportera :ref:`section_ref_operator_control`. Sa - valeur est définie comme un objet de type fonction ou de type "*Matrix*". - Dans le cas d'une fonction, différentes formes fonctionnelles peuvent être - utilisées, comme décrit dans la section - :ref:`section_ref_operator_requirements`, et entrées par les mots-clés - "*OneFunction*" ou "*ThreeFunctions*". Dans le cas d'une définition par - "*Script*", l'opérateur est de type "*Matrix*", "*OneFunction*" ou - "*ThreeFunctions*" selon que l'une de ces variables est placée à "*True*". - Les paramètres de contrôle de l'approximation numérique de l'opérateur - adjoint, dans le cas "*OneFunction*", peuvent être renseignés par un - dictionnaire à travers le mot-clé "*Parameters*". Les entrées potentielles - de ce dictionnaire de paramètres sont "*DifferentialIncrement*", - "*CenteredFiniteDifference*" (similaires à celles de l'interface graphique). + valeur est définie comme un objet de type fonction ou de type "*Matrix*". + Dans le cas d'une fonction, différentes formes fonctionnelles peuvent être + utilisées, comme décrit dans la section + :ref:`section_ref_operator_requirements`, et entrées par les mots-clés + "*OneFunction*" ou "*ThreeFunctions*". Dans le cas d'une définition par + "*Script*", l'opérateur est de type "*Matrix*", "*OneFunction*" ou + "*ThreeFunctions*" selon que l'une de ces variables est placée à "*True*". + Les paramètres de contrôle de l'approximation numérique de l'opérateur + adjoint, dans le cas "*OneFunction*", peuvent être renseignés par un + dictionnaire à travers le mot-clé "*Parameters*". Les entrées potentielles + de ce dictionnaire de paramètres sont "*DifferentialIncrement*", + "*CenteredFiniteDifference*" (similaires à celles de l'interface graphique). .. index:: single: setControlInput **setControlInput** (*Vector, VectorSerie, Script, Stored*) - Cette commande permet de définir le vecteur de contrôle :math:`\mathbf{u}`. - Selon les algorithmes, on peut le définir comme un vecteur simple par + Cette commande permet de définir le vecteur de contrôle :math:`\mathbf{u}`. + Selon les algorithmes, on peut le définir comme un vecteur simple par "*Vector*", ou comme une liste de vecteurs par "*VectorSerie*". Si on le - définit par un script dans "*Script*", le vecteur est de type "*Vector*" - (par défaut) ou "*VectorSerie*" selon que l'une de ces variables est placée - à "*True*". + définit par un script dans "*Script*", le vecteur est de type "*Vector*" + (par défaut) ou "*VectorSerie*" selon que l'une de ces variables est placée + à "*True*". .. index:: single: setEvolutionError **setEvolutionError** (*Matrix, ScalarSparseMatrix, DiagonalSparseMatrix, Script, Stored*) - Cette commande permet de définir la matrice :math:`\mathbf{Q}` de - covariance des erreurs d'évolution. La matrice peut être définie de manière - complète par le mot-clé "*Matrix*", ou de manière parcimonieuse, comme une + Cette commande permet de définir la matrice :math:`\mathbf{Q}` de + covariance des erreurs d'évolution. La matrice peut être définie de manière + complète par le mot-clé "*Matrix*", ou de manière parcimonieuse, comme une matrice diagonale dont on donne la variance unique sur la diagonale par "*ScalarSparseMatrix*", ou comme une matrice diagonale dont on donne le - vecteur des variances situé sur la diagonale par "*DiagonalSparseMatrix*". - Si on la définit par un script dans "*Script*", la matrice est de type - "*Matrix*" (par défaut), "*ScalarSparseMatrix*" ou "*DiagonalSparseMatrix*" - selon que l'une de ces variables est placée à "*True*". + vecteur des variances situé sur la diagonale par "*DiagonalSparseMatrix*". + Si on la définit par un script dans "*Script*", la matrice est de type + "*Matrix*" (par défaut), "*ScalarSparseMatrix*" ou "*DiagonalSparseMatrix*" + selon que l'une de ces variables est placée à "*True*". .. index:: single: setEvolutionModel **setEvolutionModel** (*Matrix, OneFunction, ThreeFunctions, Parameters, Script, Stored*) - Cette commande permet de définir l'opérateur d'evolution :math:`M`, qui - décrit un pas élémentaire d'évolution. Sa valeur est définie comme un objet + Cette commande permet de définir l'opérateur d'evolution :math:`M`, qui + décrit un pas élémentaire d'évolution. Sa valeur est définie comme un objet de type fonction ou de type "*Matrix*". Dans le cas d'une fonction, - différentes formes fonctionnelles peuvent être utilisées, comme décrit dans - la section :ref:`section_ref_operator_requirements`, et entrées par les - mots-clés "*OneFunction*" ou "*ThreeFunctions*". Dans le cas d'une - définition par "*Script*", l'opérateur est de type "*Matrix*", + différentes formes fonctionnelles peuvent être utilisées, comme décrit dans + la section :ref:`section_ref_operator_requirements`, et entrées par les + mots-clés "*OneFunction*" ou "*ThreeFunctions*". Dans le cas d'une + définition par "*Script*", l'opérateur est de type "*Matrix*", "*OneFunction*" ou "*ThreeFunctions*" selon que l'une de ces variables est - placée à "*True*". Les paramètres de contrôle de l'approximation numérique - de l'opérateur adjoint, dans le cas "*OneFunction*", peuvent être renseignés - par un dictionnaire dans "*Parameters*". Les entrées potentielles de ce - dictionnaire de paramètres sont "*DifferentialIncrement*", + placée à "*True*". Les paramètres de contrôle de l'approximation numérique + de l'opérateur adjoint, dans le cas "*OneFunction*", peuvent être renseignés + par un dictionnaire dans "*Parameters*". Les entrées potentielles de ce + dictionnaire de paramètres sont "*DifferentialIncrement*", "*CenteredFiniteDifference*", "*EnableMultiProcessing*", - "*NumberOfProcesses*" (similaires à celles de l'interface graphique). + "*NumberOfProcesses*" (similaires à celles de l'interface graphique). .. index:: single: setObservation **setObservation** (*Vector, VectorSerie, Script, Stored*) - Cette commande permet de définir le vecteur d'observation - :math:`\mathbf{y}^o`. Selon les algorithmes, on peut le définir comme un + Cette commande permet de définir le vecteur d'observation + :math:`\mathbf{y}^o`. Selon les algorithmes, on peut le définir comme un vecteur simple par "*Vector*", ou comme une liste de vecteurs par - "*VectorSerie*". Si on le définit par un script dans "*Script*", le vecteur - est de type "*Vector*" (par défaut) ou "*VectorSerie*" selon que l'une de - ces variables est placée à "*True*". + "*VectorSerie*". Si on le définit par un script dans "*Script*", le vecteur + est de type "*Vector*" (par défaut) ou "*VectorSerie*" selon que l'une de + ces variables est placée à "*True*". .. index:: single: setObservationError **setObservationError** (*Matrix, ScalarSparseMatrix, DiagonalSparseMatrix, Script, Stored*) - Cette commande permet de définir la matrice :math:`\mathbf{R}` de - covariance des erreurs d'observation. La matrice peut être définie de - manière complète par le mot-clé "*Matrix*", ou de manière parcimonieuse, + Cette commande permet de définir la matrice :math:`\mathbf{R}` de + covariance des erreurs d'observation. La matrice peut être définie de + manière complète par le mot-clé "*Matrix*", ou de manière parcimonieuse, comme une matrice diagonale dont on donne la variance unique sur la diagonale par "*ScalarSparseMatrix*", ou comme une matrice diagonale dont on - donne le vecteur des variances situé sur la diagonale par - "*DiagonalSparseMatrix*". Si on la définit par un script dans "*Script*", la - matrice est de type "*Matrix*" (par défaut), "*ScalarSparseMatrix*" ou - "*DiagonalSparseMatrix*" selon que l'une de ces variables est placée à + donne le vecteur des variances situé sur la diagonale par + "*DiagonalSparseMatrix*". Si on la définit par un script dans "*Script*", la + matrice est de type "*Matrix*" (par défaut), "*ScalarSparseMatrix*" ou + "*DiagonalSparseMatrix*" selon que l'une de ces variables est placée à "*True*". .. index:: single: setObservationOperator **setObservationOperator** (*Matrix, OneFunction, ThreeFunctions, AppliedInXb, Parameters, Script, Stored*) - Cette commande permet de définir l'opérateur d'observation :math:`H`, qui - transforme les paramètres d'entrée :math:`\mathbf{x}` en résultats - :math:`\mathbf{y}` qui sont à comparer aux observations - :math:`\mathbf{y}^o`. Sa valeur est définie comme un objet de type fonction - ou de type "*Matrix*". Dans le cas d'une fonction, différentes formes - fonctionnelles peuvent être utilisées, comme décrit dans la section - :ref:`section_ref_operator_requirements`, et entrées par les mots-clés - "*OneFunction*" ou "*ThreeFunctions*". Dans le cas d'une définition par - "*Script*", l'opérateur est de type "*Matrix*", "*OneFunction*" ou - "*ThreeFunctions*" selon que l'une de ces variables est placée à "*True*". - Dans le cas où l'opérateur :math:`H` évalué en :math:`\mathbf{x}^b` est - disponible, il peut être donné en utilisant "*AppliedInXb*" et sera - considéré comme un vecteur. Les paramètres de contrôle de l'approximation - numérique de l'opérateur adjoint, dans le cas "*OneFunction*", peuvent être - renseignés par un dictionnaire dans "*Parameters*". Les entrées potentielles - de ce dictionnaire de paramètres sont "*DifferentialIncrement*", + Cette commande permet de définir l'opérateur d'observation :math:`H`, qui + transforme les paramètres d'entrée :math:`\mathbf{x}` en résultats + :math:`\mathbf{y}` qui sont à comparer aux observations + :math:`\mathbf{y}^o`. Sa valeur est définie comme un objet de type fonction + ou de type "*Matrix*". Dans le cas d'une fonction, différentes formes + fonctionnelles peuvent être utilisées, comme décrit dans la section + :ref:`section_ref_operator_requirements`, et entrées par les mots-clés + "*OneFunction*" ou "*ThreeFunctions*". Dans le cas d'une définition par + "*Script*", l'opérateur est de type "*Matrix*", "*OneFunction*" ou + "*ThreeFunctions*" selon que l'une de ces variables est placée à "*True*". + Dans le cas où l'opérateur :math:`H` évalué en :math:`\mathbf{x}^b` est + disponible, il peut être donné en utilisant "*AppliedInXb*" et sera + considéré comme un vecteur. Les paramètres de contrôle de l'approximation + numérique de l'opérateur adjoint, dans le cas "*OneFunction*", peuvent être + renseignés par un dictionnaire dans "*Parameters*". Les entrées potentielles + de ce dictionnaire de paramètres sont "*DifferentialIncrement*", "*CenteredFiniteDifference*", "*EnableMultiProcessing*", - "*NumberOfProcesses*" (similaires à celles de l'interface graphique). + "*NumberOfProcesses*" (similaires à celles de l'interface graphique). .. index:: single: set **set** (*Concept,...*) - Cette commande permet de disposer d'une syntaxe équivalente pour toutes les - commandes de ce paragraphe. Son premier argument est le nom du concept à - définir (par exemple "*Background*" ou "*ObservationOperator*"), sur lequel - s'applique ensuite les arguments qui suivent, qui sont les mêmes que dans - les commandes individuelles précédentes. Lors de l'usage de cette commande, + Cette commande permet de disposer d'une syntaxe équivalente pour toutes les + commandes de ce paragraphe. Son premier argument est le nom du concept à + définir (par exemple "*Background*" ou "*ObservationOperator*"), sur lequel + s'applique ensuite les arguments qui suivent, qui sont les mêmes que dans + les commandes individuelles précédentes. Lors de l'usage de cette commande, il est indispensable de nommer les arguments (par exemple "*Vector=...*"). -Paramétrer le calcul, les sorties, etc. +Paramétrer le calcul, les sorties, etc. +++++++++++++++++++++++++++++++++++++++ .. index:: single: setAlgorithmParameters **setAlgorithmParameters** (*Algorithm, Parameters, Script*) - Cette commande permet de choisir l'algorithme de calcul ou de vérification + Cette commande permet de choisir l'algorithme de calcul ou de vérification par l'argument "*Algorithm*" sous la forme d'un nom d'algorithme (on se reportera utilement aux listes des :ref:`section_reference_assimilation` et - des :ref:`section_reference_checking`), et de définir les paramètres de - calcul par l'argument "*Parameters*". Dans le cas d'une définition par - "*Script*", le fichier indiqué doit contenir les deux variables - "*Algorithm*" et "*Parameters*" (ou "*AlgorithmParameters*" de manière - équivalente). + des :ref:`section_reference_checking`), et de définir les paramètres de + calcul par l'argument "*Parameters*". Dans le cas d'une définition par + "*Script*", le fichier indiqué doit contenir les deux variables + "*Algorithm*" et "*Parameters*" (ou "*AlgorithmParameters*" de manière + équivalente). .. index:: single: setDebug **setDebug** () - Cette commande permet d'activer le mode d'information détaillé lors de - l'exécution. + Cette commande permet d'activer le mode d'information détaillé lors de + l'exécution. .. index:: single: setNoDebug **setNoDebug** () - Cette commande permet de désactiver le mode d'information détaillé lors de - l'exécution. + Cette commande permet de désactiver le mode d'information détaillé lors de + l'exécution. .. index:: single: setObserver **setObserver** (*Variable, Template, String, Script, Info*) - Cette commande permet de définir un *observer* sur une variable courante ou - finale du calcul. On se reportera à la description des - :ref:`ref_observers_requirements` pour avoir leur liste et leur format, et à - la :ref:`section_reference` pour savoir quelles sont les quantités - observables. On définit comme un "*String*" le corps de l'*observer*, en - utilisant une chaine de caractères incluant si nécessaire des sauts de + Cette commande permet de définir un *observer* sur une variable courante ou + finale du calcul. On se reportera à la description des + :ref:`ref_observers_requirements` pour avoir leur liste et leur format, et + à la :ref:`section_reference` pour savoir quelles sont les quantités + observables. On définit comme un "*String*" le corps de l'*observer*, en + utilisant une chaîne de caractères incluant si nécessaire des sauts de lignes. On recommande d'utiliser les patrons disponibles par l'argument - "*Template*". Dans le cas d'une définition par "*Script*", le fichier - indiqué doit contenir uniquement le corps de la fonction, comme décrit dans - les :ref:`ref_observers_requirements`. + "*Template*". Dans le cas d'une définition par "*Script*", le fichier + indiqué doit contenir uniquement le corps de la fonction, comme décrit dans + les :ref:`ref_observers_requirements`. La variable "*Info*" contient une + chaîne de caractère d'information ou une chaine vide. -Effectuer le calcul +Effectuer le calcul +++++++++++++++++++ .. index:: single: executePythonScheme **executePythonScheme** () Cette commande lance le calcul complet dans l'environnement de - l'interpréteur Python courant, sans interaction avec YACS [YACS]_. Les - sorties standard et d'erreur sont celles de l'interpréteur Python. On - dispose si nécessaire du parallélisme interne des algorithmes dans ADAO et - du parallélisme interne du ou des codes de simulation utilisé. + l'interpréteur Python courant, sans interaction avec YACS [YACS]_. Les + sorties standard et d'erreur sont celles de l'interpréteur Python. On + dispose si nécessaire du parallélisme interne des algorithmes dans ADAO et + du parallélisme interne du ou des codes de simulation utilisé. .. .. index:: single: generateYACSscheme -.. +.. .. **executeYACSScheme** (*File*) -.. Cete commande génère le schéma YACS [YACS]_ du cas de calcul dans le fichier -.. requis "*File*", et en lance l'exécution dans l'interpréteur YACS, comme on -.. peut le réaliser en utilisant l'éditeur standard de cas ADAO. Les sorties -.. standard et d'erreur sont celles de l'interpréteur YACS. On dispose si -.. nécessaire du parallélisme de noeuds et blocs dans YACS, du parallélisme -.. interne des algorithmes dans ADAO et du parallélisme interne du ou des codes -.. de simulation utilisé. +.. Cete commande génère le schéma YACS [YACS]_ du cas de calcul dans le fichier +.. requis "*File*", et en lance l'exécution dans l'interpréteur YACS, comme on +.. peut le réaliser en utilisant l'éditeur standard de cas ADAO. Les sorties +.. standard et d'erreur sont celles de l'interpréteur YACS. On dispose si +.. nécessaire du parallélisme de noeuds et blocs dans YACS, du parallélisme +.. interne des algorithmes dans ADAO et du parallélisme interne du ou des codes +.. de simulation utilisé. .. index:: single: execute **execute** () Cette commande est un raccourci utilisateur pour "*executePythonScheme*". -Obtenir séparément les résultats de calcul +Obtenir séparément les résultats de calcul ++++++++++++++++++++++++++++++++++++++++++ .. index:: single: get @@ -537,42 +538,42 @@ Obtenir s sortie du cas de calcul TUI ADAO pour les utiliser dans la suite du scripting, par exemple en visualisation. Elle a pour argument le nom d'un variable dans "*Concept*", et renvoie en retour la grandeur sous la forme - d'une liste (même s'il n'y en a qu'un exemplaire) de cette variable de - base. Pour connaître la liste des variables et les utiliser, on se - reportera à l':ref:`subsection_r_o_v_Inventaire`, et plus généralement à la + d'une liste (même s'il n'y en a qu'un exemplaire) de cette variable de + base. Pour connaître la liste des variables et les utiliser, on se + reportera à l':ref:`subsection_r_o_v_Inventaire`, et plus généralement à la fois aux :ref:`section_ref_output_variables` et aux documentations individuelles des algorithmes. .. _subsection_tui_advanced: -Exemples plus avancés de cas de calcul TUI ADAO +Exemples plus avancés de cas de calcul TUI ADAO ----------------------------------------------- On propose ici des exemples plus complets de cas de calcul TUI ADAO, en donnant -l'objectif de l'exemple et un jeu de commandes qui permet de parvenir à cet +l'objectif de l'exemple et un jeu de commandes qui permet de parvenir à cet objectif. -Exploitation indépendante des résultats d'un cas de calcul +Exploitation indépendante des résultats d'un cas de calcul ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -L'objectif est d'effectuer en TUI la mise en données d'un cas de calcul ADAO, -son exécution, puis la récupération des résultats pour ensuite enchaîner sur une -exploitation indépendante de ces résultats (cette dernière n'étant pas décrite -ici, puisque dépendante de l'utilisateur). +L'objectif est d'effectuer en TUI la mise en données d'un cas de calcul ADAO, +son exécution, puis la récupération des résultats pour ensuite enchaîner sur une +exploitation indépendante de ces résultats (cette dernière n'étant pas décrite +ici, puisque dépendante de l'utilisateur). -Les hypothèses du cas utilisateur sont les suivantes. On suppose : +Les hypothèses du cas utilisateur sont les suivantes. On suppose : -#. que l'on veut recaler 3 paramètres ``alpha``, ``beta`` et ``gamma`` dans un domaine borné, -#. que l'on dispose d'observations nommées ``observations``, -#. que l'utilisateur dispose en Python d'une fonction de simulation physique appelée ``simulation``, préalablement (bien) testée, qui transforme les 3 paramètres en résultats similaires aux observations, -#. que l'exploitation indépendante, que l'utilisateur veut faire, est représentée ici par l'affichage simple de l'état initial, de l'état optimal, de la simulation en ce point, des états intermédiaires et du nombre d'itérations d'optimisation. +#. que l'on veut recaler 3 paramètres ``alpha``, ``beta`` et ``gamma`` dans un domaine borné, +#. que l'on dispose d'observations nommées ``observations``, +#. que l'utilisateur dispose en Python d'une fonction de simulation physique appelée ``simulation``, préalablement (bien) testée, qui transforme les 3 paramètres en résultats similaires aux observations, +#. que l'exploitation indépendante, que l'utilisateur veut faire, est représentée ici par l'affichage simple de l'état initial, de l'état optimal, de la simulation en ce point, des états intermédiaires et du nombre d'itérations d'optimisation. -Pour effectuer de manière simple cet essai de cas de calcul TUI, on se donne par -exemple les entrées suivantes, parfaitement arbitraires, en construisant les -observations par simulation pour se placer dans un cas d'expériences jumelles:: +Pour effectuer de manière simple cet essai de cas de calcul TUI, on se donne par +exemple les entrées suivantes, parfaitement arbitraires, en construisant les +observations par simulation pour se placer dans un cas d'expériences jumelles:: # - # Construction artificielle d'un exemple de données utilisateur + # Construction artificielle d'un exemple de données utilisateur # ------------------------------------------------------------- alpha = 5. beta = 7 @@ -598,7 +599,7 @@ Le jeu de commandes que l'on peut utiliser est le suivant:: import numpy import adaoBuilder # - # Mise en forme des entrées + # Mise en forme des entrées # ------------------------- Xb = (alpha, beta, gamma) Bounds = ( @@ -634,20 +635,20 @@ Le jeu de commandes que l'on peut utiliser est le suivant:: case.set( 'Observer', Variable="CurrentState", Template="ValuePrinter" ) case.execute() # - # Exploitation indépendante + # Exploitation indépendante # ------------------------- Xbackground = case.get("Background") Xoptimum = case.get("Analysis")[-1] FX_at_optimum = case.get("SimulatedObservationAtOptimum")[-1] J_values = case.get("CostFunctionJ")[:] - print - print "Nombre d'itérations internes...: %i"%len(J_values) - print "Etat initial...................:",numpy.ravel(Xbackground) - print "Etat optimal...................:",numpy.ravel(Xoptimum) - print "Simulation à l'état optimal....:",numpy.ravel(FX_at_optimum) - print + print("") + print("Nombre d'itérations internes...: %i"%len(J_values)) + print("Etat initial...................: %s"%(numpy.ravel(Xbackground),)) + print("Etat optimal...................: %s"%(numpy.ravel(Xoptimum),)) + print("Simulation à l'état optimal....: %s"%(numpy.ravel(FX_at_optimum),)) + print("") -L'exécution de jeu de commandes donne le résultat suivant:: +L'exécution de jeu de commandes donne le résultat suivant:: CurrentState [ 5. 7. 9.] CurrentState [ 0. 3. 1.5] @@ -660,15 +661,15 @@ L'ex CurrentState [ 2.00000007 3. 4.00000011] CurrentState [ 2. 3. 4.] - Nombre d'itérations internes...: 10 + Nombre d'itérations internes...: 10 Etat initial...................: [ 5. 7. 9.] Etat optimal...................: [ 2. 3. 4.] - Simulation à l'état optimal....: [ 2. 6. 12. 20.] + Simulation à l'état optimal....: [ 2. 6. 12. 20.] -Comme il se doit en expériences jumelles, on constate que l'on retrouve bien les -paramètres qui ont servi à construire artificiellement les observations. +Comme il se doit en expériences jumelles, on constate que l'on retrouve bien les +paramètres qui ont servi à construire artificiellement les observations. -.. Réconciliation de courbes à l'aide de MedCoupling +.. Réconciliation de courbes à l'aide de MedCoupling .. +++++++++++++++++++++++++++++++++++++++++++++++++ .. Utilisation de fonctions de surveillance de type "observer" @@ -677,8 +678,8 @@ param .. Equivalences entre l'interface graphique (GUI) et l'interface textuelle (TUI) .. ----------------------------------------------------------------------------- -.. [HOMARD] Pour de plus amples informations sur HOMARD, voir le *module HOMARD* et son aide intégrée disponible dans le menu principal *Aide* de l'environnement SALOME. +.. [HOMARD] Pour de plus amples informations sur HOMARD, voir le *module HOMARD* et son aide intégrée disponible dans le menu principal *Aide* de l'environnement SALOME. -.. [PARAVIS] Pour de plus amples informations sur PARAVIS, voir le *module PARAVIS* et son aide intégrée disponible dans le menu principal *Aide* de l'environnement SALOME. +.. [PARAVIS] Pour de plus amples informations sur PARAVIS, voir le *module PARAVIS* et son aide intégrée disponible dans le menu principal *Aide* de l'environnement SALOME. -.. [YACS] Pour de plus amples informations sur YACS, voir le *module YACS* et son aide intégrée disponible dans le menu principal *Aide* de l'environnement SALOME. +.. [YACS] Pour de plus amples informations sur YACS, voir le *module YACS* et son aide intégrée disponible dans le menu principal *Aide* de l'environnement SALOME. diff --git a/doc/fr/using.rst b/doc/fr/using.rst index f6c1ee1..28598cf 100644 --- a/doc/fr/using.rst +++ b/doc/fr/using.rst @@ -43,28 +43,28 @@ :align: middle :scale: 50% -Cette section présente l'usage du module ADAO dans la plateforme SALOME. On -décrit ici le cheminement général pour établir un cas ADAO, les détails étant -fournis dans les chapitres suivants. Il est complété par la description -détaillée de l'ensemble des commandes et mots-clés dans la section -:ref:`section_reference`, par des procédures avancées d'usage dans la section +Cette section présente l'usage du module ADAO dans la plateforme SALOME. On +décrit ici le cheminement général pour établir un cas ADAO, les détails étant +fournis dans les chapitres suivants. Il est complété par la description +détaillée de l'ensemble des commandes et mots-clés dans la section +:ref:`section_reference`, par des procédures avancées d'usage dans la section :ref:`section_advanced`, et par des exemples dans la section :ref:`section_examples`. -Procédure logique pour construire un cas ADAO +Procédure logique pour construire un cas ADAO --------------------------------------------- -La construction d'un cas ADAO suit une démarche simple pour définir l'ensemble -des données d'entrée, et ensuite générer un diagramme complet d'exécution -utilisé dans YACS [#]_. De nombreuses variations existent pour la définition -des données d'entrée, mais la séquence logique reste inchangée. +La construction d'un cas ADAO suit une démarche simple pour définir l'ensemble +des données d'entrée, et ensuite générer un diagramme complet d'exécution +utilisé dans YACS [#]_. De nombreuses variations existent pour la définition +des données d'entrée, mais la séquence logique reste inchangée. -De manière générale, l'utilisateur doit connaître ses données d'entrées, -requises pour mettre au point une étude d'assimilation de données, en suivant la -:ref:`section_methodology`. Ces données peuvent déjà être disponibles dans +De manière générale, l'utilisateur doit connaître ses données d'entrées, +requises pour mettre au point une étude d'assimilation de données, en suivant la +:ref:`section_methodology`. Ces données peuvent déjà être disponibles dans SALOME ou non. -Fondamentalement, la procédure d'utilisation de ADAO comprend les étapes +Fondamentalement, la procédure d'utilisation de ADAO comprend les étapes suivantes: - :ref:`section_u_step1` @@ -73,21 +73,21 @@ suivantes: - :ref:`section_u_step4` - :ref:`section_u_step5` -Chaque étape est détaillée dans la section suivante. +Chaque étape est détaillée dans la section suivante. -Procédure détaillée pour construire un cas ADAO +Procédure détaillée pour construire un cas ADAO ----------------------------------------------- .. _section_u_step1: -ÉTAPE 1 : Activer le module ADAO et utiliser l'interface graphique d'édition (GUI) +ÉTAPE 1 : Activer le module ADAO et utiliser l'interface graphique d'édition (GUI) ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -Comme toujours pour un module, il doit être préalablement activé en -sélectionnant le bouton de module approprié (ou le menu) dans la barre d'outils -de SALOME. S'il n'existe aucune étude SALOME chargée, un menu contextuel -apparaît, permettant de choisir entre la création d'une nouvelle étude, ou -l'ouverture d'une étude déjà existante: +Comme toujours pour un module, il doit être préalablement activé en +sélectionnant le bouton de module approprié (ou le menu) dans la barre d'outils +de SALOME. S'il n'existe aucune étude SALOME chargée, un menu contextuel +apparaît, permettant de choisir entre la création d'une nouvelle étude, ou +l'ouverture d'une étude déjà existante: .. _adao_activate1: .. image:: images/adao_activate.png @@ -95,48 +95,48 @@ l'ouverture d'une .. centered:: **Activation du module ADAO dans SALOME** -En choisissant le bouton "*Nouveau*", un éditeur intégré de cas [#]_ sera -ouvert, en même temps que le "*navigateur d'objets*" standard. On peut alors -cliquer sur le bouton "*Nouveau*" (ou choisir l'entrée "*Nouveau*" dans le dans -le menu principal "*ADAO*") pour créer un nouveau cas ADAO, et on obtient : +En choisissant le bouton "*Nouveau*", un éditeur intégré de cas [#]_ sera +ouvert, en même temps que le "*navigateur d'objets*" standard. On peut alors +cliquer sur le bouton "*Nouveau*" (ou choisir l'entrée "*Nouveau*" dans le dans +le menu principal "*ADAO*") pour créer un nouveau cas ADAO, et on obtient : .. _adao_viewer: .. image:: images/adao_viewer.png :align: center :width: 100% .. centered:: - **L'éditeur intégré pour la définition des cas dans le module ADAO** + **L'éditeur intégré pour la définition des cas dans le module ADAO** .. _section_u_step2: -ÉTAPE 2 : Créer et modifier le cas ADAO, et l'enregistrer +ÉTAPE 2 : Créer et modifier le cas ADAO, et l'enregistrer +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -Pour construire un cas en utilisant l'éditeur intégré, on doit passer par une -série de sous-étapes, en choisissant, à chaque étape, un mot-clé puis en -remplissant ses valeurs. On note que c'est dans cette étape qu'il faut, entre -autres, définir l'**appel au code de simulation** utilisé dans les opérateurs -d'observation ou d'évolution décrivant le problème [#]_. +Pour construire un cas en utilisant l'éditeur intégré, on doit passer par une +série de sous-étapes, en choisissant, à chaque étape, un mot-clé puis en +remplissant ses valeurs. On note que c'est dans cette étape qu'il faut, entre +autres, définir l'**appel au code de simulation** utilisé dans les opérateurs +d'observation ou d'évolution décrivant le problème [#]_. -L'éditeur structuré indique des types hiérarchiques, des valeurs ou des -mots-clés autorisés. Les mots-clés incomplets ou incorrects sont identifiés par -un indicateur d'erreur visuel rouge. Les valeurs possibles sont indiquées pour -les mots-clés par la définition d'une liste limitée de valeurs, et les entrées -adaptées sont données pour les autres mots-clés. Des messages d'aide sont -fournis de manière contextuelle aux places réservées de l'éditeur. +L'éditeur structuré indique des types hiérarchiques, des valeurs ou des +mots-clés autorisés. Les mots-clés incomplets ou incorrects sont identifiés par +un indicateur d'erreur visuel rouge. Les valeurs possibles sont indiquées pour +les mots-clés par la définition d'une liste limitée de valeurs, et les entrées +adaptées sont données pour les autres mots-clés. Des messages d'aide sont +fournis de manière contextuelle aux places réservées de l'éditeur. Un nouveau cas est mis en place avec la liste minimale des commandes. Toutes les -commandes ou les mots-clés obligatoires sont déjà présents, aucun d'eux ne peut -être supprimé. Des mots-clés optionnels peuvent être ajoutés en les choisissant -dans une liste de suggestions de ceux autorisés pour la commande principale, par -exemple la commande "*ASSIMILATION_STUDY*". À titre d'exemple, on peut ajouter -des paramètres dans le mot-clé "*AlgorithmParameters*", comme décrit dans la -dernière partie de la section :ref:`section_examples`. - -A la fin de ces actions, lorsque tous les champs ou les mots-clés ont été -correctement définis, chaque ligne de l'arborescence des commandes doit -présenter un drapeau vert. Cela signifie que l'ensemble du cas est valide et -dûment rempli (et qu'il peut être sauvegardé). +commandes ou les mots-clés obligatoires sont déjà présents, aucun d'eux ne peut +être supprimé. Des mots-clés optionnels peuvent être ajoutés en les choisissant +dans une liste de suggestions de ceux autorisés pour la commande principale, par +exemple la commande "*ASSIMILATION_STUDY*". À titre d'exemple, on peut ajouter +des paramètres dans le mot-clé "*AlgorithmParameters*", comme décrit dans la +dernière partie de la section :ref:`section_examples`. + +A la fin de ces actions, lorsque tous les champs ou les mots-clés ont été +correctement définis, chaque ligne de l'arborescence des commandes doit +présenter un drapeau vert. Cela signifie que l'ensemble du cas est valide et +dûment rempli (et qu'il peut être sauvegardé). .. _adao_jdcexample00: .. image:: images/adao_jdcexample01.png @@ -147,22 +147,22 @@ d Au final, il faut enregistrer le cas ADAO en utilisant le bouton "*Enregistrer*" |eficas_save|, ou le bouton "*Enregistrer sous*" |eficas_saveas|, ou en -choisissant l'entrée "*Enregistrer/ Enregistrer sous*" dans le menu "*ADAO*". Il -est alors demandé un emplacement, à choisir dans l'arborescence des fichiers, et -un nom, qui sera complété par l'extension "*.comm*" utilisée pour les fichiers -de l'éditeur intégré de cas. Cette action va générer une paire de fichiers -décrivant le cas ADAO, avec le même nom de base, le premier présentant une +choisissant l'entrée "*Enregistrer/ Enregistrer sous*" dans le menu "*ADAO*". Il +est alors demandé un emplacement, à choisir dans l'arborescence des fichiers, et +un nom, qui sera complété par l'extension "*.comm*" utilisée pour les fichiers +de l'éditeur intégré de cas. Cette action va générer une paire de fichiers +décrivant le cas ADAO, avec le même nom de base, le premier présentant une extension "*.comm*" et le second une extension "*.py*" [#]_. .. _section_u_step3: -ÉTAPE 3 : Exporter le cas ADAO comme un schéma YACS +ÉTAPE 3 : Exporter le cas ADAO comme un schéma YACS +++++++++++++++++++++++++++++++++++++++++++++++++++ -Lorsque le cas ADAO est complété, il doit être converti ou exporté sous la forme -d'un schéma YACS pour pouvoir exécuter le calcul d'assimilation de données. Cela -peut être réalisé facilement en utilisant le bouton "*Exporter vers YACS*" -|eficas_yacs|, ou de manière équivalente en choisissant l'entrée "*Exporter vers +Lorsque le cas ADAO est complété, il doit être converti ou exporté sous la forme +d'un schéma YACS pour pouvoir exécuter le calcul d'assimilation de données. Cela +peut être réalisé facilement en utilisant le bouton "*Exporter vers YACS*" +|eficas_yacs|, ou de manière équivalente en choisissant l'entrée "*Exporter vers YACS*" dans le menu principal "*ADAO*", ou dans le menu contextuel du cas dans le navigateur d'objets SALOME. @@ -171,89 +171,89 @@ le navigateur d'objets SALOME. :align: center :scale: 75% .. centered:: - **Sous-menu "Exporter vers YACS" pour générer le schéma YACS à partir d'un cas ADAO** + **Sous-menu "Exporter vers YACS" pour générer le schéma YACS à partir d'un cas ADAO** -Cela conduit à générer automatiquement un schéma YACS, et à activer le module -YACS sur ce schéma. Le fichier YACS, associé au schéma, est stocké dans le même -répertoire et avec le même nom de base de fichier que le cas ADAO enregistré, +Cela conduit à générer automatiquement un schéma YACS, et à activer le module +YACS sur ce schéma. Le fichier YACS, associé au schéma, est stocké dans le même +répertoire et avec le même nom de base de fichier que le cas ADAO enregistré, changeant simplement son extension en "*.xml*". Attention, *si le nom de fichier -XML existe déjà, le fichier est écrasé sans avertissement sur le remplacement du +XML existe déjà, le fichier est écrasé sans avertissement sur le remplacement du fichier XML*. .. _section_u_step4: -ÉTAPE 4 : Compléter et modifier le schéma YACS, et l'enregistrer +ÉTAPE 4 : Compléter et modifier le schéma YACS, et l'enregistrer ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .. index:: single: Analysis -Lorsque le schéma YACS est généré et ouvert dans SALOME à travers l'interface -graphique du module YACS, on peut modifier ou compléter le schéma comme tout -schéma YACS standard. Des noeuds ou des blocs peuvent être ajoutés, copiés ou -modifiés pour élaborer une analyse complexe, ou pour insérer des capacités -d'assimilation de données ou d'optimisation dans des schémas de calculs YACS +Lorsque le schéma YACS est généré et ouvert dans SALOME à travers l'interface +graphique du module YACS, on peut modifier ou compléter le schéma comme tout +schéma YACS standard. Des noeuds ou des blocs peuvent être ajoutés, copiés ou +modifiés pour élaborer une analyse complexe, ou pour insérer des capacités +d'assimilation de données ou d'optimisation dans des schémas de calculs YACS plus complexes. -Le principal complément nécessaire dans un schéma YACS est une étape de -post-processing. L'évaluation du résultat doit être réalisée dans le contexte -physique de simulation utilisé par la procédure d'assimilation de données. Le -post-processing peut être fournit à travers le mot-clé "*UserPostAnalysis*" -d'ADAO sous la forme d'un fichier de script ou d'une chaîne de caractères, par -des patrons ("templates"), ou peut être construit comme des noeuds YACS. Ces -deux manières de construire le post-processing peuvent utiliser toutes les -capacités de SALOME. On se reportera à la partie traitant des -:ref:`section_ref_output_variables`, ou à l'aide de chaque algorithme, pour la -description complète de ces éléments. - -En pratique, le schéma YACS dispose d'un port de sortie "*algoResults*" dans le -bloc de calcul, qui donne accès à un objet structuré nommé ci-après "*ADD*" par -exemple, qui contient tous les résultats de calcul. Ces résultats peuvent être -obtenus en récupérant les variables nommées stockées au cours des calculs. -L'information principale est la variable "*Analysis*", qui peut être obtenue par -une commande python (par exemple dans un noeud script intégré ("in-line script -node") ou un script fourni à travers le mot-clé "*UserPostAnalysis*":: +Le principal complément nécessaire dans un schéma YACS est une étape de +post-processing. L'évaluation du résultat doit être réalisée dans le contexte +physique de simulation utilisé par la procédure d'assimilation de données. Le +post-processing peut être fournit à travers le mot-clé "*UserPostAnalysis*" +d'ADAO sous la forme d'un fichier de script ou d'une chaîne de caractères, par +des patrons ("templates"), ou peut être construit comme des noeuds YACS. Ces +deux manières de construire le post-processing peuvent utiliser toutes les +capacités de SALOME. On se reportera à la partie traitant des +:ref:`section_ref_output_variables`, ou à l'aide de chaque algorithme, pour la +description complète de ces éléments. + +En pratique, le schéma YACS dispose d'un port de sortie "*algoResults*" dans le +bloc de calcul, qui donne accès à un objet structuré nommé ci-après "*ADD*" par +exemple, qui contient tous les résultats de calcul. Ces résultats peuvent être +obtenus en récupérant les variables nommées stockées au cours des calculs. +L'information principale est la variable "*Analysis*", qui peut être obtenue par +une commande python (par exemple dans un noeud script intégré ("in-line script +node") ou un script fourni à travers le mot-clé "*UserPostAnalysis*":: Analysis = ADD.get("Analysis")[:] -"*Analysis*" est un objet complexe, similaire à une liste de valeurs calculées à -chaque étape du calcul d'assimilation. Pour obtenir et afficher l'évaluation -optimale de l'état par assimilation de données, dans un script fournit par -l'intermédiaire du mot-clé "*UserPostAnalysis*", on peut utiliser:: +"*Analysis*" est un objet complexe, similaire à une liste de valeurs calculées à +chaque étape du calcul d'assimilation. Pour obtenir et afficher l'évaluation +optimale de l'état par assimilation de données, dans un script fournit par +l'intermédiaire du mot-clé "*UserPostAnalysis*", on peut utiliser:: Xa = ADD.get("Analysis")[-1] print "Optimal state:", Xa print -Cette variable ``Xa`` est un vecteur de valeurs, qui représente la solution du -problème d'évaluation par assimilation de données ou par optimisation, notée +Cette variable ``Xa`` est un vecteur de valeurs, qui représente la solution du +problème d'évaluation par assimilation de données ou par optimisation, notée :math:`\mathbf{x}^a` dans la section :ref:`section_theory`. -Une telle méthode peut être utilisée pour imprimer les résultats, ou pour les -convertir dans des structures qui peuvent être nécessaires à un post-processing -natif ou externe à SALOME. Un exemple simple est disponible dans la section +Une telle méthode peut être utilisée pour imprimer les résultats, ou pour les +convertir dans des structures qui peuvent être nécessaires à un post-processing +natif ou externe à SALOME. Un exemple simple est disponible dans la section :ref:`section_examples`. .. _section_u_step5: -ÉTAPE 5 : Exécuter le schéma YACS et obtenir les résultats +ÉTAPE 5 : Exécuter le schéma YACS et obtenir les résultats ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -Le schéma YACS est maintenant complet et peut être exécuté. La paramétrisation -et l'exécution de ce cas YACS est entièrement compatible avec la manière -standard de traiter un schéma YACS, comme décrit dans le *Guide de l'utilisateur +Le schéma YACS est maintenant complet et peut être exécuté. La paramétrisation +et l'exécution de ce cas YACS est entièrement compatible avec la manière +standard de traiter un schéma YACS, comme décrit dans le *Guide de l'utilisateur du module YACS*. -Pour rappeler la manière la plus simple de procéder, le schéma YACS doit être -compilé en utilisant le bouton |yacs_compile|, ou l'entrée équivalente du menu -YACS, pour préparer le schéma à son exécution. Ensuite, le schéma compilé peut -être démarré, exécuté pas à pas ou en utilisant des points d'arrêt, etc. - -La sortie standard est restituée dans la "*fenêtre de sortie de YACS*" (ou -"*YACS Container Log*"), à laquelle on accède par un clic droit sur la fenêtre -"*proc*" dans l'interface graphique YACS. Les erreurs sont présentées soit -dans la "*fenêtre de sortie de YACS*", ou à la ligne de commande dans la fenêtre -de commandes (si l'environnement SALOME a été lancé par une commande explicite, -et non par un menu ou une icône de bureau). Par exemple, la sortie de l'exemple +Pour rappeler la manière la plus simple de procéder, le schéma YACS doit être +compilé en utilisant le bouton |yacs_compile|, ou l'entrée équivalente du menu +YACS, pour préparer le schéma à son exécution. Ensuite, le schéma compilé peut +être démarré, exécuté pas à pas ou en utilisant des points d'arrêt, etc. + +La sortie standard est restituée dans la "*fenêtre de sortie de YACS*" (ou +"*YACS Container Log*"), à laquelle on accède par un clic droit sur la fenêtre +"*proc*" dans l'interface graphique YACS. Les erreurs sont présentées soit +dans la "*fenêtre de sortie de YACS*", ou à la ligne de commande dans la fenêtre +de commandes (si l'environnement SALOME a été lancé par une commande explicite, +et non par un menu ou une icône de bureau). Par exemple, la sortie de l'exemple simple ci-dessus est de la forme suivante:: Entering in the assimilation study @@ -263,15 +263,15 @@ simple ci-dessus est de la forme suivante:: Optimal state: [0.5, 0.5, 0.5] -présentée dans la "*fenêtre de sortie de YACS*". +présentée dans la "*fenêtre de sortie de YACS*". -L'exécution peut aussi être conduite en utilisant un script de commandes Shell, -comme décrit dans la section :ref:`section_advanced`. +L'exécution peut aussi être conduite en utilisant un script de commandes Shell, +comme décrit dans la section :ref:`section_advanced`. -.. [#] 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. +.. [#] 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. -.. [#] Pour de plus amples informations sur l'éditeur intégré de cas, voir le *module EFICAS* et son aide intégrée disponible dans le menu principal *Aide* de l'environnement SALOME. +.. [#] Pour de plus amples informations sur l'éditeur intégré de cas, voir le *module EFICAS* et son aide intégrée disponible dans le menu principal *Aide* de l'environnement SALOME. -.. [#] L'utilisation du code de simulation physique dans les opérateurs de base de l'assimilation de données est illustrée ou décrite dans les parties principales qui suivent. +.. [#] L'utilisation du code de simulation physique dans les opérateurs de base de l'assimilation de données est illustrée ou décrite dans les parties principales qui suivent. -.. [#] Ce fichier python intermédiaire peut aussi être utilisé comme décrit dans la section :ref:`section_advanced`. +.. [#] Ce fichier python intermédiaire peut aussi être utilisé comme décrit dans la section :ref:`section_advanced`. -- 2.39.2