From: Jean-Philippe ARGAUD Date: Thu, 12 Oct 2023 14:08:11 +0000 (+0200) Subject: Documentation review corrections X-Git-Tag: V9_12_0a1~1 X-Git-Url: http://git.salome-platform.org/gitweb/?a=commitdiff_plain;h=80497f93b6d39999dceb283de1771a4095c06a7d;p=modules%2Fadao.git Documentation review corrections --- diff --git a/doc/en/advanced.rst b/doc/en/advanced.rst index c8cf3a8..5ba9509 100644 --- a/doc/en/advanced.rst +++ b/doc/en/advanced.rst @@ -42,13 +42,13 @@ It is possible to convert and execute an ADAO command file (JDC, or ".comm/.py" files pair, which resides in ````) automatically by using a template Shell script containing all the required steps. If the SALOME main launching command , named ``salome``, is not available in a classical -terminal, the user has to know where are the main SALOME launching files, and in -particular the ``salome`` one. The directory in which this script resides is +terminal, the user has to know where are the main SALOME launching files, and +in particular the ``salome`` one. The directory in which this script resides is symbolically named ```` and has to be replaced by the good one in the Shell file template. -When an ADAO command file is build by the ADAO graphical editor and saved, if it -is named for example "AdaoStudy1.comm", then a companion file named +When an ADAO command file is build by the ADAO graphical editor and saved, if +it is named for example "AdaoStudy1.comm", then a companion file named "AdaoStudy1.py" is automatically created in the same directory. It is named ```` in the template, and it is converted to YACS as an ```` as a ".xml" file named "AdaoStudy1.xml". After that, @@ -59,10 +59,10 @@ In all launching command Shell files examples, we choose to start and stop the SALOME application server in the same script. It is not mandatory, but it is useful to avoid stalling SALOME sessions. -The simplest example consist in only launching the given YACS sheme, which was -previously generated by the user in the graphical interface. In this case, after -having replaced the strings between ``<...>`` symbols, one needs only to save -the following Shell script:: +The simplest example consist in only launching the given YACS scheme, which was +previously generated by the user in the graphical interface. In this case, +after having replaced the strings between ``<...>`` symbols, one needs only to +save the following Shell script:: #!/bin/bash USERDIR="" @@ -73,9 +73,9 @@ the following Shell script:: It is then required to change it to be in executable mode. -A more complete example consist in launching execution of a YACS scheme given by -the user, having previously verified its availability. For that, replacing the -text ````, one needs only to save the +A more complete example consist in launching execution of a YACS scheme given +by the user, having previously verified its availability. For that, replacing +the text ````, one needs only to save the following Shell script:: #!/bin/bash @@ -141,8 +141,8 @@ YACS calculation scheme, obtained in the graphical interface by using the ADAO recalled here (see YACS documentation for more information) through a simple example. As described in documentation, a XML scheme can be loaded in a Python. We give here a whole sequence of command lines to test the validity of the -scheme before executing it, adding some initial supplementary ones to explicitly -load the types catalog to avoid weird difficulties:: +scheme before executing it, adding some initial supplementary ones to +explicitly load the types catalog to avoid weird difficulties:: import pilot import SALOMERuntime @@ -288,12 +288,12 @@ in a R variable. The other lines are identical. The example thus becomes:: One notices the explicit ``str`` and ``list`` type conversions to ensure that the data are transmitted as known standard types from "*rPython*" package. Moreover, it is the data that can be transferred between the two languages, not -functions or methods. It is therefore necessary to prepare generically in Python -the functions to execute required by ADAO, and to forward them correctly the -data available in R. +functions or methods. It is therefore necessary to prepare generically in +Python the functions to execute required by ADAO, and to forward them correctly +the data available in R. -The most comprehensive cases, proposed in :ref:`subsection_tui_advanced`, can be -executed in the same way, and they give the same result as in the standard +The most comprehensive cases, proposed in :ref:`subsection_tui_advanced`, can +be executed in the same way, and they give the same result as in the standard Python interface. .. _section_advanced_eficas_gui: @@ -321,7 +321,7 @@ If necessary, explicit messages can be used to identify the required environment variables that are missing. However, **this command should not be run in the SALOME Python console** (because in this case it is enough to activate the module since we already are in the graphical environment...) or in -an independant Python install, but it can be run in a "SALOME shell" session +an independent Python install, but it can be run in a "SALOME shell" session obtained from the "Tools/Extensions" menu of SALOME. .. _section_advanced_execution_mode: @@ -415,15 +415,15 @@ available in every ADAO case. It can be reached in the module's graphical user interface (GUI) as well as in the textual interface (TUI). Setting it to "*1*" will send messages in the log window of the YACS scheme execution. -The second one consist in using the "*logging*" native module of Python (see the -Python documentation http://docs.python.org/library/logging.html for more +The second one consist in using the "*logging*" native module of Python (see +the Python documentation http://docs.python.org/library/logging.html for more information on this module). Everywhere in the YACS scheme, mainly through the scripts entries, the user can set the logging level in accordance to the needs of detailed information. The different logging levels are: "*DEBUG*", "*INFO*", "*WARNING*", "*ERROR*", "*CRITICAL*". All the information flagged with a -certain level will be printed for whatever activated level above this particular -one (included). The easiest way is to change the log level by using the -following Python lines:: +certain level will be printed for whatever activated level above this +particular one (included). The easiest way is to change the log level by using +the following Python lines:: import logging logging.getLogger().setLevel(logging.DEBUG) @@ -463,7 +463,7 @@ accompanying the command "*OneFunction*" by textual interaface. By default, this parallel mode is disabled ("*EnableMultiProcessing=0*"). The parallel mode will only use local resources (both multi-cores or multi-processors) of the computer on which execution is running, requiring by default as many resources -as available. If necessary, one can reduce the available ressources by limiting +as available. If necessary, one can reduce the available resources by limiting the possible number of parallel processes using the keyword "*NumberOfProcesses*", set to desired maximum number (or to "0" for automatic control, which is the default value). diff --git a/doc/en/glossary.rst b/doc/en/glossary.rst index 98e4c76..02d8f89 100644 --- a/doc/en/glossary.rst +++ b/doc/en/glossary.rst @@ -65,7 +65,7 @@ Glossary Computational implementation of the set composed of the numerical simulator and a particular set of all the input and control variables of the simulator. These variables enable the digital simulator to be able to - numerically represent the system's behaviour. + numerically represent the system's behavior. observations or measurements These are quantities that come from measuring instruments and @@ -79,7 +79,7 @@ Glossary boundary conditions These are particular input and control variables of the simulator, which - characterize the description of the system's behaviour at the border of + characterize the description of the system's behavior at the border of the simulation spatial domain. initial conditions diff --git a/doc/en/gui_in_salome.rst b/doc/en/gui_in_salome.rst index 336325a..ea62e78 100644 --- a/doc/en/gui_in_salome.rst +++ b/doc/en/gui_in_salome.rst @@ -93,8 +93,8 @@ or opening an already existing one: Choosing the "*New*" button, an embedded case editor [#]_ will be opened, along with the standard "*Object browser*". You can then click on the "*New*" button -|eficas_new| (or choose the "*New*" entry in the "*ADAO*" main menu) to create a -new ADAO case, and you will see: +|eficas_new| (or choose the "*New*" entry in the "*ADAO*" main menu) to create +a new ADAO case, and you will see: .. _adao_viewer: .. image:: images/adao_viewer.png @@ -117,15 +117,16 @@ operators describing the problem [#]_. The structured editor indicates hierarchical types, values or keywords allowed. Incomplete or incorrect keywords are identified by a visual error red flag. Possible values are indicated for keywords defined with a limited list of -values, and adapted entries are given for the other keywords. Some help messages -are contextually provided in the editor reserved places. +values, and adapted entries are given for the other keywords. Some help +messages are contextually provided in the editor reserved places. A new case is set up with the minimal list of commands. All the mandatory commands or keywords are already present, none of them can be suppressed. Optional keywords can be added by choosing them in a list of suggestions of allowed ones for the main command, for example the "*ASSIMILATION_STUDY*" command. As an example, one can add parameters in the "*AlgorithmParameters*" -keyword, as described in the last part of the section :ref:`section_tutorials_in_salome`. +keyword, as described in the last part of the section +:ref:`section_tutorials_in_salome`. At the end, when all fields or keywords have been correctly defined, each line of the commands tree must have a green flag. This indicates that the whole case @@ -140,22 +141,23 @@ is valid and completed (and can be saved). Finally, you have to save your ADAO case by pushing the "*Save*" button |eficas_save|, or the "*Save as*" button |eficas_saveas|, or by choosing the -"*Save/Save as*" entry in the "*ADAO*" menu. You will be prompted for a location -in your file tree and a name, that will be completed by a "*.comm*" extension -used for the embedded case editor. This will generate a pair of files describing -the ADAO case, with the same base name, the first one being completed by a -"*.comm*" extension and the second one by a "*.py*" extension [#]_. +"*Save/Save as*" entry in the "*ADAO*" menu. You will be prompted for a +location in your file tree and a name, that will be completed by a "*.comm*" +extension used for the embedded case editor. This will generate a pair of files +describing the ADAO case, with the same base name, the first one being +completed by a "*.comm*" extension and the second one by a "*.py*" extension +[#]_. .. _section_u_step3: STEP 3: Export the ADAO case as a YACS scheme +++++++++++++++++++++++++++++++++++++++++++++ -When the ADAO case is completed, you have to export it as a YACS scheme in order -to execute the data assimilation calculation. This can be easily done by using -the "*Export to YACS*" button |eficas_yacs|, or equivalently choose the "*Export -to YACS*" entry in the "*ADAO*" main menu, or in the contextual case menu in the -SALOME object browser. +When the ADAO case is completed, you have to export it as a YACS scheme in +order to execute the data assimilation calculation. This can be easily done by +using the "*Export to YACS*" button |eficas_yacs|, or equivalently choose the +"*Export to YACS*" entry in the "*ADAO*" main menu, or in the contextual case +menu in the SALOME object browser. .. _adao_exporttoyacs01: .. image:: images/adao_exporttoyacs.png @@ -164,11 +166,12 @@ SALOME object browser. .. centered:: **"Export to YACS" sub-menu to generate the YACS scheme from the ADAO case** -This will lead to automatically generate a YACS scheme, and open the YACS module -on this scheme. The YACS file, associated with the scheme, will be stored in the -same directory and with the same base name as the ADAO saved case, only changing -its extension to "*.xml*". Be careful, *if the XML file name already exist, the -file will be overwritten without prompting for replacing the XML file*. +This will lead to automatically generate a YACS scheme, and open the YACS +module on this scheme. The YACS file, associated with the scheme, will be +stored in the same directory and with the same base name as the ADAO saved +case, only changing its extension to "*.xml*". Be careful, *if the XML file +name already exist, the file will be overwritten without prompting for +replacing the XML file*. .. _section_u_step4: @@ -204,9 +207,9 @@ command (for example in an in-line script node or a script provided through the Analysis = ADD.get("Analysis")[:] -"*Analysis*" is a complex object, similar to a list of values calculated at each -step of data assimilation calculation. In order to get and print the optimal -data assimilation state evaluation, in a script provided through the +"*Analysis*" is a complex object, similar to a list of values calculated at +each step of data assimilation calculation. In order to get and print the +optimal data assimilation state evaluation, in a script provided through the "*UserPostAnalysis*" keyword, one can use:: Xa = ADD.get("Analysis")[-1] @@ -232,15 +235,15 @@ with a YACS scheme, as described in the *YACS module User's Guide*. To recall the simplest way to proceed, the YACS scheme has to be compiled using the button |yacs_compile|, or the equivalent YACS menu entry, to prepare the -scheme to run. Then the compiled scheme can be started, executed step by step or -using breakpoints, etc. +scheme to run. Then the compiled scheme can be started, executed step by step +or using breakpoints, etc. The standard output will be pushed into the "*YACS Container Log*", obtained through the right click menu of the "*proc*" window in the YACS GUI. The errors are shown either in the "*YACS Container Log*", or at the command line in the -terminal window (if SALOME has been launched by its explicit command, and not by -a menu or a desktop icon). As an example, the output of the above simple case is -of the following form:: +terminal window (if SALOME has been launched by its explicit command, and not +by a menu or a desktop icon). As an example, the output of the above simple +case is of the following form:: Entering in the assimilation study Name is set to........: Test @@ -251,8 +254,8 @@ of the following form:: shown in the "*YACS Container Log*". -The execution can also be done using a Shell script, as described in the section -:ref:`section_advanced`. +The execution can also be done using a Shell script, as described in the +section :ref:`section_advanced`. .. [#] For more information on YACS, see the *YACS module* and its integrated help available from the main menu *Help* of the SALOME platform. diff --git a/doc/en/license.rst b/doc/en/license.rst index 2569ef4..125ad45 100644 --- a/doc/en/license.rst +++ b/doc/en/license.rst @@ -70,5 +70,5 @@ year added: * *SALOME The Open Source Integration Platform for Numerical Simulation*, http://www.salome-platform.org/ -The documentation of the module is also fully covered by the license and the -requirement of quoting. +The documentation of the module, including figures and examples, is also fully +covered by the license and the requirement of quoting. diff --git a/doc/en/methodology.rst b/doc/en/methodology.rst index 72522ca..698f33d 100644 --- a/doc/en/methodology.rst +++ b/doc/en/methodology.rst @@ -98,7 +98,7 @@ is the real practical way to compare simulations and observations. It is usually done by sampling, projection or integration, of the simulation outputs, but it can be more complicated. Often, because the observation operator directly follows the simulation one in simple data assimilation schemes, this -observation operator heavily use the postprocessing and extraction capacities +observation operator heavily use the post-processing and extraction capacities of the simulation code. .. _section_m_step2: diff --git a/doc/en/ref_algorithm_3DVAR.rst b/doc/en/ref_algorithm_3DVAR.rst index bc0c530..1f16ed6 100644 --- a/doc/en/ref_algorithm_3DVAR.rst +++ b/doc/en/ref_algorithm_3DVAR.rst @@ -120,10 +120,10 @@ StoreSupplementaryCalculations *List of names*. This list indicates the names of the supplementary variables, that can be available during or at the end of the algorithm, if - they are initially required by the user. Their avalability involves, + they are initially required by the user. Their availability involves, potentially, costly calculations or memory consumptions. The default is then a void list, none of these variables being calculated and stored by default - (excepted the unconditionnal variables). The possible names are in the + (excepted the unconditional variables). The possible names are in the following list (the detailed description of each named variable is given in the following part of this specific algorithmic documentation, in the sub-section "*Information and variables available at the end of the diff --git a/doc/en/ref_algorithm_4DVAR.rst b/doc/en/ref_algorithm_4DVAR.rst index 5b24352..5a09e9f 100644 --- a/doc/en/ref_algorithm_4DVAR.rst +++ b/doc/en/ref_algorithm_4DVAR.rst @@ -89,10 +89,10 @@ StoreSupplementaryCalculations *List of names*. This list indicates the names of the supplementary variables, that can be available during or at the end of the algorithm, if - they are initially required by the user. Their avalability involves, + they are initially required by the user. Their availability involves, potentially, costly calculations or memory consumptions. The default is then a void list, none of these variables being calculated and stored by default - (excepted the unconditionnal variables). The possible names are in the + (excepted the unconditional variables). The possible names are in the following list (the detailed description of each named variable is given in the following part of this specific algorithmic documentation, in the sub-section "*Information and variables available at the end of the diff --git a/doc/en/ref_algorithm_AdjointTest.rst b/doc/en/ref_algorithm_AdjointTest.rst index 07d899f..8484f44 100644 --- a/doc/en/ref_algorithm_AdjointTest.rst +++ b/doc/en/ref_algorithm_AdjointTest.rst @@ -80,10 +80,10 @@ StoreSupplementaryCalculations *List of names*. This list indicates the names of the supplementary variables, that can be available during or at the end of the algorithm, if - they are initially required by the user. Their avalability involves, + they are initially required by the user. Their availability involves, potentially, costly calculations or memory consumptions. The default is then a void list, none of these variables being calculated and stored by default - (excepted the unconditionnal variables). The possible names are in the + (excepted the unconditional variables). The possible names are in the following list (the detailed description of each named variable is given in the following part of this specific algorithmic documentation, in the sub-section "*Information and variables available at the end of the diff --git a/doc/en/ref_algorithm_Blue.rst b/doc/en/ref_algorithm_Blue.rst index 9cc3a1a..9578656 100644 --- a/doc/en/ref_algorithm_Blue.rst +++ b/doc/en/ref_algorithm_Blue.rst @@ -100,10 +100,10 @@ StoreSupplementaryCalculations *List of names*. This list indicates the names of the supplementary variables, that can be available during or at the end of the algorithm, if - they are initially required by the user. Their avalability involves, + they are initially required by the user. Their availability involves, potentially, costly calculations or memory consumptions. The default is then a void list, none of these variables being calculated and stored by default - (excepted the unconditionnal variables). The possible names are in the + (excepted the unconditional variables). The possible names are in the following list (the detailed description of each named variable is given in the following part of this specific algorithmic documentation, in the sub-section "*Information and variables available at the end of the diff --git a/doc/en/ref_algorithm_ControledFunctionTest.rst b/doc/en/ref_algorithm_ControledFunctionTest.rst index 466bf1f..7b3b1db 100644 --- a/doc/en/ref_algorithm_ControledFunctionTest.rst +++ b/doc/en/ref_algorithm_ControledFunctionTest.rst @@ -76,10 +76,10 @@ StoreSupplementaryCalculations *List of names*. This list indicates the names of the supplementary variables, that can be available during or at the end of the algorithm, if - they are initially required by the user. Their avalability involves, + they are initially required by the user. Their availability involves, potentially, costly calculations or memory consumptions. The default is then a void list, none of these variables being calculated and stored by default - (excepted the unconditionnal variables). The possible names are in the + (excepted the unconditional variables). The possible names are in the following list (the detailed description of each named variable is given in the following part of this specific algorithmic documentation, in the sub-section "*Information and variables available at the end of the diff --git a/doc/en/ref_algorithm_DerivativeFreeOptimization.rst b/doc/en/ref_algorithm_DerivativeFreeOptimization.rst index 20d11d0..ecd5d5b 100644 --- a/doc/en/ref_algorithm_DerivativeFreeOptimization.rst +++ b/doc/en/ref_algorithm_DerivativeFreeOptimization.rst @@ -78,10 +78,10 @@ StoreSupplementaryCalculations *List of names*. This list indicates the names of the supplementary variables, that can be available during or at the end of the algorithm, if - they are initially required by the user. Their avalability involves, + they are initially required by the user. Their availability involves, potentially, costly calculations or memory consumptions. The default is then a void list, none of these variables being calculated and stored by default - (excepted the unconditionnal variables). The possible names are in the + (excepted the unconditional variables). The possible names are in the following list (the detailed description of each named variable is given in the following part of this specific algorithmic documentation, in the sub-section "*Information and variables available at the end of the diff --git a/doc/en/ref_algorithm_DifferentialEvolution.rst b/doc/en/ref_algorithm_DifferentialEvolution.rst index 4ada6fb..84bb0f4 100644 --- a/doc/en/ref_algorithm_DifferentialEvolution.rst +++ b/doc/en/ref_algorithm_DifferentialEvolution.rst @@ -82,10 +82,10 @@ StoreSupplementaryCalculations *List of names*. This list indicates the names of the supplementary variables, that can be available during or at the end of the algorithm, if - they are initially required by the user. Their avalability involves, + they are initially required by the user. Their availability involves, potentially, costly calculations or memory consumptions. The default is then a void list, none of these variables being calculated and stored by default - (excepted the unconditionnal variables). The possible names are in the + (excepted the unconditional variables). The possible names are in the following list (the detailed description of each named variable is given in the following part of this specific algorithmic documentation, in the sub-section "*Information and variables available at the end of the diff --git a/doc/en/ref_algorithm_EnsembleBlue.rst b/doc/en/ref_algorithm_EnsembleBlue.rst index a107feb..52bce00 100644 --- a/doc/en/ref_algorithm_EnsembleBlue.rst +++ b/doc/en/ref_algorithm_EnsembleBlue.rst @@ -63,10 +63,10 @@ StoreSupplementaryCalculations *List of names*. This list indicates the names of the supplementary variables, that can be available during or at the end of the algorithm, if - they are initially required by the user. Their avalability involves, + they are initially required by the user. Their availability involves, potentially, costly calculations or memory consumptions. The default is then a void list, none of these variables being calculated and stored by default - (excepted the unconditionnal variables). The possible names are in the + (excepted the unconditional variables). The possible names are in the following list (the detailed description of each named variable is given in the following part of this specific algorithmic documentation, in the sub-section "*Information and variables available at the end of the diff --git a/doc/en/ref_algorithm_EnsembleKalmanFilter.rst b/doc/en/ref_algorithm_EnsembleKalmanFilter.rst index 77cf15f..a32589e 100644 --- a/doc/en/ref_algorithm_EnsembleKalmanFilter.rst +++ b/doc/en/ref_algorithm_EnsembleKalmanFilter.rst @@ -46,7 +46,9 @@ We notice that there is no analysis performed at the initial time step (numbered 0 in the time indexing) because there is no forecast at this time (the background is stored as a pseudo analysis at the initial time step). If the observations are provided in series by the user, the first one is therefore -not used. +not used. For a good understanding of time management, please refer to the +:ref:`schema_d_AD_temporel` and the explanations in the section +:ref:`section_theory_dynamic`. In case of linear of "slightly" non-linear operators, one can easily use the :ref:`section_ref_algorithm_ExtendedKalmanFilter` or even the @@ -70,19 +72,20 @@ following stable and robust formulations are proposed here: pair: Variant ; MLEF pair: Variant ; IEnKF pair: Variant ; E3DVAR + pair: Variant ; 3D-Var-Ben pair: Variant ; EnKS pair: Variant ; EnSRKF pair: Variant ; RRSQRT - "EnKF" (Ensemble Kalman Filter, see [Evensen94]_), original stochastic algorithm, allowing consistent treatment of non-linear evolution operator, - "ETKF" (Ensemble-Transform Kalman Filter), deterministic EnKF algorithm, allowing treatment of non-linear evolution operator with a lot less members (one recommends to use a number of members on the order of 10 or even sometimes less), -- "ETKF-N" (Ensemble-Transform Kalman Filter of finite size N), ETKF algorithm of "finite size N", yhat doesn't need inflation that is often required with the other algorithms, -- "MLEF" (Maximum Likelihood Kalman Filter, see [Zupanski05]_), deterministic EnKF algorithm, allowing in addition the consistent treament of non-linear observation operator, +- "ETKF-N" (Ensemble-Transform Kalman Filter of finite size N), ETKF algorithm of "finite size N", that doesn't need inflation that is often required with the other algorithms, +- "MLEF" (Maximum Likelihood Kalman Filter, see [Zupanski05]_), deterministic EnKF algorithm, allowing in addition the consistent treatment of non-linear observation operator, - "IEnKF" (Iterative EnKF), deterministic EnKF algorithm, improving treament of operators non-linearities -- "E3DVAR" (EnKF 3DVAR), algorithm coupling ensemble and variational assimilation, which uses in parallel a 3DVAR variational assimilation and an EnKF algorithm to improve the estimation of *a posteriori* error covariances +- "E3DVAR" (EnKF 3DVAR, or 3D-Var-Ben), algorithm coupling ensemble and variational assimilation, which uses in parallel a 3DVAR variational assimilation for a single best estimate and an EnKF ensemble algorithm to improve the estimation of *a posteriori* error covariances - "EnKS" (Ensemble Kalman Smoother), smoothing algorithm with a fixed time lag L. -Without being a universal recommandation, one recommend to use "EnKF" +Without being a universal recommendation, one recommend to use "EnKF" formulation as a reference algorithm, **"ETKF-N" ou "IEnKF" formulation for robust performance**, and the other algorithms (in this order) as means to obtain a less costly data assimilation with (hopefully) the same quality. @@ -130,10 +133,10 @@ StoreSupplementaryCalculations *List of names*. This list indicates the names of the supplementary variables, that can be available during or at the end of the algorithm, if - they are initially required by the user. Their avalability involves, + they are initially required by the user. Their availability involves, potentially, costly calculations or memory consumptions. The default is then a void list, none of these variables being calculated and stored by default - (excepted the unconditionnal variables). The possible names are in the + (excepted the unconditional variables). The possible names are in the following list (the detailed description of each named variable is given in the following part of this specific algorithmic documentation, in the sub-section "*Information and variables available at the end of the diff --git a/doc/en/ref_algorithm_EnsembleOfSimulationGenerationTask.rst b/doc/en/ref_algorithm_EnsembleOfSimulationGenerationTask.rst index a1ca8e4..ab5743c 100644 --- a/doc/en/ref_algorithm_EnsembleOfSimulationGenerationTask.rst +++ b/doc/en/ref_algorithm_EnsembleOfSimulationGenerationTask.rst @@ -91,10 +91,10 @@ StoreSupplementaryCalculations *List of names*. This list indicates the names of the supplementary variables, that can be available during or at the end of the algorithm, if - they are initially required by the user. Their avalability involves, + they are initially required by the user. Their availability involves, potentially, costly calculations or memory consumptions. The default is then a void list, none of these variables being calculated and stored by default - (excepted the unconditionnal variables). The possible names are in the + (excepted the unconditional variables). The possible names are in the following list (the detailed description of each named variable is given in the following part of this specific algorithmic documentation, in the sub-section "*Information and variables available at the end of the diff --git a/doc/en/ref_algorithm_ExtendedBlue.rst b/doc/en/ref_algorithm_ExtendedBlue.rst index f8ec2cb..e6c6297 100644 --- a/doc/en/ref_algorithm_ExtendedBlue.rst +++ b/doc/en/ref_algorithm_ExtendedBlue.rst @@ -85,10 +85,10 @@ StoreSupplementaryCalculations *List of names*. This list indicates the names of the supplementary variables, that can be available during or at the end of the algorithm, if - they are initially required by the user. Their avalability involves, + they are initially required by the user. Their availability involves, potentially, costly calculations or memory consumptions. The default is then a void list, none of these variables being calculated and stored by default - (excepted the unconditionnal variables). The possible names are in the + (excepted the unconditional variables). The possible names are in the following list (the detailed description of each named variable is given in the following part of this specific algorithmic documentation, in the sub-section "*Information and variables available at the end of the diff --git a/doc/en/ref_algorithm_ExtendedKalmanFilter.rst b/doc/en/ref_algorithm_ExtendedKalmanFilter.rst index f643acc..ffb379a 100644 --- a/doc/en/ref_algorithm_ExtendedKalmanFilter.rst +++ b/doc/en/ref_algorithm_ExtendedKalmanFilter.rst @@ -44,11 +44,11 @@ Conceptually, we can represent the temporal pattern of action of the evolution and observation operators in this algorithm in the following way, with **x** the state, **P** the state error covariance, *t* the discrete iterative time : - .. _schema_temporel_KF: - .. image:: images/schema_temporel_KF.png + .. _schema_temporel_EKF: + .. figure:: images/schema_temporel_KF.png :align: center :width: 100% - .. centered:: + **Timeline of steps in extended Kalman filter data assimilation** In this scheme, the analysis **(x,P)** is obtained by means of the @@ -62,7 +62,7 @@ This filter can also be used to estimate (jointly or solely) parameters and not the state, in which case neither the time nor the evolution have any meaning. The iteration steps are then linked to the insertion of a new observation in the recursive estimation. One should consult the section -:ref:`section_theory_dynamique` for the implementation concepts. +:ref:`section_theory_dynamic` for the implementation concepts. In case of more pronounced non-linear operators, one can easily use a :ref:`section_ref_algorithm_EnsembleKalmanFilter` or a @@ -111,10 +111,10 @@ StoreSupplementaryCalculations *List of names*. This list indicates the names of the supplementary variables, that can be available during or at the end of the algorithm, if - they are initially required by the user. Their avalability involves, + they are initially required by the user. Their availability involves, potentially, costly calculations or memory consumptions. The default is then a void list, none of these variables being calculated and stored by default - (excepted the unconditionnal variables). The possible names are in the + (excepted the unconditional variables). The possible names are in the following list (the detailed description of each named variable is given in the following part of this specific algorithmic documentation, in the sub-section "*Information and variables available at the end of the diff --git a/doc/en/ref_algorithm_FunctionTest.rst b/doc/en/ref_algorithm_FunctionTest.rst index 3fb792c..80776bf 100644 --- a/doc/en/ref_algorithm_FunctionTest.rst +++ b/doc/en/ref_algorithm_FunctionTest.rst @@ -73,10 +73,10 @@ StoreSupplementaryCalculations *List of names*. This list indicates the names of the supplementary variables, that can be available during or at the end of the algorithm, if - they are initially required by the user. Their avalability involves, + they are initially required by the user. Their availability involves, potentially, costly calculations or memory consumptions. The default is then a void list, none of these variables being calculated and stored by default - (excepted the unconditionnal variables). The possible names are in the + (excepted the unconditional variables). The possible names are in the following list (the detailed description of each named variable is given in the following part of this specific algorithmic documentation, in the sub-section "*Information and variables available at the end of the diff --git a/doc/en/ref_algorithm_GradientTest.rst b/doc/en/ref_algorithm_GradientTest.rst index 70de467..c858d20 100644 --- a/doc/en/ref_algorithm_GradientTest.rst +++ b/doc/en/ref_algorithm_GradientTest.rst @@ -117,10 +117,10 @@ StoreSupplementaryCalculations *List of names*. This list indicates the names of the supplementary variables, that can be available during or at the end of the algorithm, if - they are initially required by the user. Their avalability involves, + they are initially required by the user. Their availability involves, potentially, costly calculations or memory consumptions. The default is then a void list, none of these variables being calculated and stored by default - (excepted the unconditionnal variables). The possible names are in the + (excepted the unconditional variables). The possible names are in the following list (the detailed description of each named variable is given in the following part of this specific algorithmic documentation, in the sub-section "*Information and variables available at the end of the diff --git a/doc/en/ref_algorithm_InterpolationByReducedModelTask.rst b/doc/en/ref_algorithm_InterpolationByReducedModelTask.rst index caa3d50..6ca9a67 100644 --- a/doc/en/ref_algorithm_InterpolationByReducedModelTask.rst +++ b/doc/en/ref_algorithm_InterpolationByReducedModelTask.rst @@ -85,10 +85,10 @@ StoreSupplementaryCalculations *List of names*. This list indicates the names of the supplementary variables, that can be available during or at the end of the algorithm, if - they are initially required by the user. Their avalability involves, + they are initially required by the user. Their availability involves, potentially, costly calculations or memory consumptions. The default is then a void list, none of these variables being calculated and stored by default - (excepted the unconditionnal variables). The possible names are in the + (excepted the unconditional variables). The possible names are in the following list (the detailed description of each named variable is given in the following part of this specific algorithmic documentation, in the sub-section "*Information and variables available at the end of the diff --git a/doc/en/ref_algorithm_KalmanFilter.rst b/doc/en/ref_algorithm_KalmanFilter.rst index ec4b040..620d9fa 100644 --- a/doc/en/ref_algorithm_KalmanFilter.rst +++ b/doc/en/ref_algorithm_KalmanFilter.rst @@ -51,10 +51,10 @@ and observation operators in this algorithm in the following way, with **x** the state, **P** the state error covariance, *t* the discrete iterative time : .. _schema_temporel_KF: - .. image:: images/schema_temporel_KF.png + .. figure:: images/schema_temporel_KF.png :align: center :width: 100% - .. centered:: + **Timeline of steps in Kalman filter data assimilation** In this scheme, the analysis **(x,P)** is obtained by means of the @@ -68,7 +68,7 @@ This filter can also be used to estimate (jointly or solely) parameters and not the state, in which case neither the time nor the evolution have any meaning. The iteration steps are then linked to the insertion of a new observation in the recursive estimation. One should consult the section -:ref:`section_theory_dynamique` for the implementation concepts. +:ref:`section_theory_dynamic` for the implementation concepts. In case of non-linearity of the operators, even slightly marked, it will be preferred a :ref:`section_ref_algorithm_ExtendedKalmanFilter`, or a @@ -104,10 +104,10 @@ StoreSupplementaryCalculations *List of names*. This list indicates the names of the supplementary variables, that can be available during or at the end of the algorithm, if - they are initially required by the user. Their avalability involves, + they are initially required by the user. Their availability involves, potentially, costly calculations or memory consumptions. The default is then a void list, none of these variables being calculated and stored by default - (excepted the unconditionnal variables). The possible names are in the + (excepted the unconditional variables). The possible names are in the following list (the detailed description of each named variable is given in the following part of this specific algorithmic documentation, in the sub-section "*Information and variables available at the end of the diff --git a/doc/en/ref_algorithm_LinearLeastSquares.rst b/doc/en/ref_algorithm_LinearLeastSquares.rst index a9fb5ad..e27f5ae 100644 --- a/doc/en/ref_algorithm_LinearLeastSquares.rst +++ b/doc/en/ref_algorithm_LinearLeastSquares.rst @@ -47,7 +47,7 @@ on a succession of observations, placing the estimate in a recursive framework partly similar to a Kalman Filter. A standard estimate is made at each observation step on the state predicted by the incremental evolution model. -In all cases, it is recommanded to prefer at least a +In all cases, it is recommended to prefer at least a :ref:`section_ref_algorithm_Blue`, or a :ref:`section_ref_algorithm_ExtendedBlue` or a :ref:`section_ref_algorithm_3DVAR`. @@ -71,10 +71,10 @@ StoreSupplementaryCalculations *List of names*. This list indicates the names of the supplementary variables, that can be available during or at the end of the algorithm, if - they are initially required by the user. Their avalability involves, + they are initially required by the user. Their availability involves, potentially, costly calculations or memory consumptions. The default is then a void list, none of these variables being calculated and stored by default - (excepted the unconditionnal variables). The possible names are in the + (excepted the unconditional variables). The possible names are in the following list (the detailed description of each named variable is given in the following part of this specific algorithmic documentation, in the sub-section "*Information and variables available at the end of the diff --git a/doc/en/ref_algorithm_LinearityTest.rst b/doc/en/ref_algorithm_LinearityTest.rst index 9d11307..8a14bd5 100644 --- a/doc/en/ref_algorithm_LinearityTest.rst +++ b/doc/en/ref_algorithm_LinearityTest.rst @@ -138,10 +138,10 @@ StoreSupplementaryCalculations *List of names*. This list indicates the names of the supplementary variables, that can be available during or at the end of the algorithm, if - they are initially required by the user. Their avalability involves, + they are initially required by the user. Their availability involves, potentially, costly calculations or memory consumptions. The default is then a void list, none of these variables being calculated and stored by default - (excepted the unconditionnal variables). The possible names are in the + (excepted the unconditional variables). The possible names are in the following list (the detailed description of each named variable is given in the following part of this specific algorithmic documentation, in the sub-section "*Information and variables available at the end of the diff --git a/doc/en/ref_algorithm_LocalSensitivityTest.rst b/doc/en/ref_algorithm_LocalSensitivityTest.rst index 4a22bf7..d432567 100644 --- a/doc/en/ref_algorithm_LocalSensitivityTest.rst +++ b/doc/en/ref_algorithm_LocalSensitivityTest.rst @@ -63,10 +63,10 @@ StoreSupplementaryCalculations *List of names*. This list indicates the names of the supplementary variables, that can be available during or at the end of the algorithm, if - they are initially required by the user. Their avalability involves, + they are initially required by the user. Their availability involves, potentially, costly calculations or memory consumptions. The default is then a void list, none of these variables being calculated and stored by default - (excepted the unconditionnal variables). The possible names are in the + (excepted the unconditional variables). The possible names are in the following list (the detailed description of each named variable is given in the following part of this specific algorithmic documentation, in the sub-section "*Information and variables available at the end of the diff --git a/doc/en/ref_algorithm_MeasurementsOptimalPositioningTask.rst b/doc/en/ref_algorithm_MeasurementsOptimalPositioningTask.rst index cc02459..e115e18 100644 --- a/doc/en/ref_algorithm_MeasurementsOptimalPositioningTask.rst +++ b/doc/en/ref_algorithm_MeasurementsOptimalPositioningTask.rst @@ -131,10 +131,10 @@ StoreSupplementaryCalculations *List of names*. This list indicates the names of the supplementary variables, that can be available during or at the end of the algorithm, if - they are initially required by the user. Their avalability involves, + they are initially required by the user. Their availability involves, potentially, costly calculations or memory consumptions. The default is then a void list, none of these variables being calculated and stored by default - (excepted the unconditionnal variables). The possible names are in the + (excepted the unconditional variables). The possible names are in the following list (the detailed description of each named variable is given in the following part of this specific algorithmic documentation, in the sub-section "*Information and variables available at the end of the diff --git a/doc/en/ref_algorithm_NonLinearLeastSquares.rst b/doc/en/ref_algorithm_NonLinearLeastSquares.rst index ea78aab..daf6535 100644 --- a/doc/en/ref_algorithm_NonLinearLeastSquares.rst +++ b/doc/en/ref_algorithm_NonLinearLeastSquares.rst @@ -86,10 +86,10 @@ StoreSupplementaryCalculations *List of names*. This list indicates the names of the supplementary variables, that can be available during or at the end of the algorithm, if - they are initially required by the user. Their avalability involves, + they are initially required by the user. Their availability involves, potentially, costly calculations or memory consumptions. The default is then a void list, none of these variables being calculated and stored by default - (excepted the unconditionnal variables). The possible names are in the + (excepted the unconditional variables). The possible names are in the following list (the detailed description of each named variable is given in the following part of this specific algorithmic documentation, in the sub-section "*Information and variables available at the end of the diff --git a/doc/en/ref_algorithm_ObservationSimulationComparisonTest.rst b/doc/en/ref_algorithm_ObservationSimulationComparisonTest.rst index 852833d..7b2bed7 100644 --- a/doc/en/ref_algorithm_ObservationSimulationComparisonTest.rst +++ b/doc/en/ref_algorithm_ObservationSimulationComparisonTest.rst @@ -83,10 +83,10 @@ StoreSupplementaryCalculations *List of names*. This list indicates the names of the supplementary variables, that can be available during or at the end of the algorithm, if - they are initially required by the user. Their avalability involves, + they are initially required by the user. Their availability involves, potentially, costly calculations or memory consumptions. The default is then a void list, none of these variables being calculated and stored by default - (excepted the unconditionnal variables). The possible names are in the + (excepted the unconditional variables). The possible names are in the following list (the detailed description of each named variable is given in the following part of this specific algorithmic documentation, in the sub-section "*Information and variables available at the end of the diff --git a/doc/en/ref_algorithm_ParallelFunctionTest.rst b/doc/en/ref_algorithm_ParallelFunctionTest.rst index d3f3918..09ddbd6 100644 --- a/doc/en/ref_algorithm_ParallelFunctionTest.rst +++ b/doc/en/ref_algorithm_ParallelFunctionTest.rst @@ -73,10 +73,10 @@ StoreSupplementaryCalculations *List of names*. This list indicates the names of the supplementary variables, that can be available during or at the end of the algorithm, if - they are initially required by the user. Their avalability involves, + they are initially required by the user. Their availability involves, potentially, costly calculations or memory consumptions. The default is then a void list, none of these variables being calculated and stored by default - (excepted the unconditionnal variables). The possible names are in the + (excepted the unconditional variables). The possible names are in the following list (the detailed description of each named variable is given in the following part of this specific algorithmic documentation, in the sub-section "*Information and variables available at the end of the diff --git a/doc/en/ref_algorithm_ParticleSwarmOptimization.rst b/doc/en/ref_algorithm_ParticleSwarmOptimization.rst index 5a2f78c..1028779 100644 --- a/doc/en/ref_algorithm_ParticleSwarmOptimization.rst +++ b/doc/en/ref_algorithm_ParticleSwarmOptimization.rst @@ -57,19 +57,19 @@ robust formulations are proposed here: pair: Variant ; AIS PSO pair: Variant ; APSO -- "CanonicalPSO" (Canonical Particule Swarm Optimisation, see +- "CanonicalPSO" (Canonical Particle Swarm Optimization, see [ZambranoBigiarini13]_), classical algorithm called "canonical" of particle swarm, robust and defining a reference for particle swarm algorithms, -- "OGCR" (Simple Particule Swarm Optimisation), simplified algorithm of - particle swarm with no bounds on insects or velocities, not recommanded +- "OGCR" (Simple Particle Swarm Optimization), simplified algorithm of + particle swarm with no bounds on insects or velocities, not recommended because less robust, but sometimes a lot more efficient, -- "SPSO-2011" (Standard Particle Swarm Optimisation 2011, voir - [ZambranoBigiarini13]_), 2011 reference algorithm of particule swarm, robust, +- "SPSO-2011" (Standard Particle Swarm Optimization 2011, voir + [ZambranoBigiarini13]_), 2011 reference algorithm of particle swarm, robust, efficient and defined as a reference for particle swarm algorithms. This algorithm is sometimes called ":math:`\omega`-PSO" or "Inertia PSO" because it incorporates a so-called inertia contribution, or also called "AIS" (for "Asynchronous Iteration Strategy") or "APSO" (for "Advanced Particle Swarm - Optimisation") because it incorporates evolutionary updating of the best + Optimization") because it incorporates evolutionary updating of the best elements, leading to intrinsically improved convergence of the algorithm. The following are a few practical suggestions for the effective use of these @@ -82,7 +82,7 @@ algorithms: of the state space. Usually, the best performances are obtained for populations of 70 to 500 particles. Even if the default value for this elementary parameter comes from extended knowledge on these algorithms, it is - recommanded to adapt it to the difficulty of the given problems. + recommended to adapt it to the difficulty of the given problems. - The recommended number of generations for population evolution is often around 50, but it can easily vary between 25 and 500. - The maximum number of evaluations of the simulation function should usually @@ -159,10 +159,10 @@ StoreSupplementaryCalculations *List of names*. This list indicates the names of the supplementary variables, that can be available during or at the end of the algorithm, if - they are initially required by the user. Their avalability involves, + they are initially required by the user. Their availability involves, potentially, costly calculations or memory consumptions. The default is then a void list, none of these variables being calculated and stored by default - (excepted the unconditionnal variables). The possible names are in the + (excepted the unconditional variables). The possible names are in the following list (the detailed description of each named variable is given in the following part of this specific algorithmic documentation, in the sub-section "*Information and variables available at the end of the diff --git a/doc/en/ref_algorithm_QuantileRegression.rst b/doc/en/ref_algorithm_QuantileRegression.rst index 00ea2ad..793d5f4 100644 --- a/doc/en/ref_algorithm_QuantileRegression.rst +++ b/doc/en/ref_algorithm_QuantileRegression.rst @@ -63,10 +63,10 @@ StoreSupplementaryCalculations *List of names*. This list indicates the names of the supplementary variables, that can be available during or at the end of the algorithm, if - they are initially required by the user. Their avalability involves, + they are initially required by the user. Their availability involves, potentially, costly calculations or memory consumptions. The default is then a void list, none of these variables being calculated and stored by default - (excepted the unconditionnal variables). The possible names are in the + (excepted the unconditional variables). The possible names are in the following list (the detailed description of each named variable is given in the following part of this specific algorithmic documentation, in the sub-section "*Information and variables available at the end of the diff --git a/doc/en/ref_algorithm_SamplingTest.rst b/doc/en/ref_algorithm_SamplingTest.rst index 7f13cca..c585b57 100644 --- a/doc/en/ref_algorithm_SamplingTest.rst +++ b/doc/en/ref_algorithm_SamplingTest.rst @@ -97,10 +97,10 @@ StoreSupplementaryCalculations *List of names*. This list indicates the names of the supplementary variables, that can be available during or at the end of the algorithm, if - they are initially required by the user. Their avalability involves, + they are initially required by the user. Their availability involves, potentially, costly calculations or memory consumptions. The default is then a void list, none of these variables being calculated and stored by default - (excepted the unconditionnal variables). The possible names are in the + (excepted the unconditional variables). The possible names are in the following list (the detailed description of each named variable is given in the following part of this specific algorithmic documentation, in the sub-section "*Information and variables available at the end of the diff --git a/doc/en/ref_algorithm_TabuSearch.rst b/doc/en/ref_algorithm_TabuSearch.rst index 23d206e..b008932 100644 --- a/doc/en/ref_algorithm_TabuSearch.rst +++ b/doc/en/ref_algorithm_TabuSearch.rst @@ -90,10 +90,10 @@ StoreSupplementaryCalculations *List of names*. This list indicates the names of the supplementary variables, that can be available during or at the end of the algorithm, if - they are initially required by the user. Their avalability involves, + they are initially required by the user. Their availability involves, potentially, costly calculations or memory consumptions. The default is then a void list, none of these variables being calculated and stored by default - (excepted the unconditionnal variables). The possible names are in the + (excepted the unconditional variables). The possible names are in the following list (the detailed description of each named variable is given in the following part of this specific algorithmic documentation, in the sub-section "*Information and variables available at the end of the diff --git a/doc/en/ref_algorithm_TangentTest.rst b/doc/en/ref_algorithm_TangentTest.rst index 6853c61..8176552 100644 --- a/doc/en/ref_algorithm_TangentTest.rst +++ b/doc/en/ref_algorithm_TangentTest.rst @@ -84,10 +84,10 @@ StoreSupplementaryCalculations *List of names*. This list indicates the names of the supplementary variables, that can be available during or at the end of the algorithm, if - they are initially required by the user. Their avalability involves, + they are initially required by the user. Their availability involves, potentially, costly calculations or memory consumptions. The default is then a void list, none of these variables being calculated and stored by default - (excepted the unconditionnal variables). The possible names are in the + (excepted the unconditional variables). The possible names are in the following list (the detailed description of each named variable is given in the following part of this specific algorithmic documentation, in the sub-section "*Information and variables available at the end of the diff --git a/doc/en/ref_algorithm_UnscentedKalmanFilter.rst b/doc/en/ref_algorithm_UnscentedKalmanFilter.rst index f4e6006..60e2197 100644 --- a/doc/en/ref_algorithm_UnscentedKalmanFilter.rst +++ b/doc/en/ref_algorithm_UnscentedKalmanFilter.rst @@ -44,7 +44,9 @@ We notice that there is no analysis performed at the initial time step (numbered 0 in the time indexing) because there is no forecast at this time (the background is stored as a pseudo analysis at the initial time step). If the observations are provided in series by the user, the first one is therefore -not used. +not used. For a good understanding of time management, please refer to the +:ref:`schema_d_AD_temporel` and the explanations in the section +:ref:`section_theory_dynamic`. In case of linear of "slightly" non-linear operators, one can easily use the :ref:`section_ref_algorithm_ExtendedKalmanFilter` or even the @@ -94,10 +96,10 @@ StoreSupplementaryCalculations *List of names*. This list indicates the names of the supplementary variables, that can be available during or at the end of the algorithm, if - they are initially required by the user. Their avalability involves, + they are initially required by the user. Their availability involves, potentially, costly calculations or memory consumptions. The default is then a void list, none of these variables being calculated and stored by default - (excepted the unconditionnal variables). The possible names are in the + (excepted the unconditional variables). The possible names are in the following list (the detailed description of each named variable is given in the following part of this specific algorithmic documentation, in the sub-section "*Information and variables available at the end of the diff --git a/doc/en/ref_assimilation_keywords.rst b/doc/en/ref_assimilation_keywords.rst index ff43032..7434b0c 100644 --- a/doc/en/ref_assimilation_keywords.rst +++ b/doc/en/ref_assimilation_keywords.rst @@ -23,14 +23,14 @@ .. _section_ref_assimilation_keywords: -List of commands and keywords for data assimilation or optimisation case +List of commands and keywords for data assimilation or optimization case ------------------------------------------------------------------------ We summarize here all the commands and keywords available to describe a calculation case, by avoiding the particularities of each algorithm. It is therefore a common inventory of commands. -The set of commands for an data assimilation or optimisation case is related to +The set of commands for an data assimilation or optimization case is related to the description of a calculation case, that is a *Data Assimilation* procedure (chosen in graphical user interface by the command "*ASSIMILATION_STUDY*"), a *Reduction Method* procedure (chosen in graphical user interface by the diff --git a/doc/en/ref_entry_types.rst b/doc/en/ref_entry_types.rst index 1191809..4c5e2cb 100644 --- a/doc/en/ref_entry_types.rst +++ b/doc/en/ref_entry_types.rst @@ -28,7 +28,7 @@ List of possible input types Each variable to be entered for the use of ADAO can be represented by means of particular "pseudo-types", which help to logically fill it in and validate it -computationaly. These pseudo-types explicitly represent mathematical forms +computationally. These pseudo-types explicitly represent mathematical forms (:ref:`section_ref_entry_types_math`) or simple computer forms (:ref:`section_ref_entry_types_info`), which are detailed here. :ref:`section_notations` are also used, together with diff --git a/doc/en/ref_observations_requirements.rst b/doc/en/ref_observations_requirements.rst index 23d79ce..7c0cd0a 100644 --- a/doc/en/ref_observations_requirements.rst +++ b/doc/en/ref_observations_requirements.rst @@ -101,7 +101,7 @@ of measurements, or several fields physically homogeneous or not. - ``case.setObservation( Vector=True, DataFile = 'data.npy' )``` Use note: in a given study, only the last record (whether a single vector or a -series of vectors) can be used, as only one observation concept exists per CADD +series of vectors) can be used, as only one observation concept exists per ADAO study. Use of a time series of spatial observations @@ -151,7 +151,7 @@ of which we consider a history. - ``case.setObservation( VectorSerie=True, DataFile = 'data.npy' )``` Use note: in a given study, only the last record (whether a single vector or a -series of vectors) can be used, as only one observation concept exists per CADD +series of vectors) can be used, as only one observation concept exists per ADAO study. Use of a single spatio-temporal observation diff --git a/doc/en/ref_operator_requirements.rst b/doc/en/ref_operator_requirements.rst index 9e7452d..d0b15ab 100644 --- a/doc/en/ref_operator_requirements.rst +++ b/doc/en/ref_operator_requirements.rst @@ -246,7 +246,7 @@ become the following:: return "a vector similar to X" **Important:** the names "*DirectOperator*", "*TangentOperator*" and -"*AdjointOperator*" are mandatory when using an independant Python script. The +"*AdjointOperator*" are mandatory when using an independent Python script. The type of the ``X``, Y``, ``dX`` input or output arguments can be either a list of float values, a Numpy array or a Numpy matrix. The user function has to treat these cases in his script. diff --git a/doc/en/ref_options_AlgorithmParameters.rst b/doc/en/ref_options_AlgorithmParameters.rst index 1539610..c419800 100644 --- a/doc/en/ref_options_AlgorithmParameters.rst +++ b/doc/en/ref_options_AlgorithmParameters.rst @@ -38,20 +38,19 @@ There are several convenient methods for providing these options, either using the ADAO EFICAS graphical interface (GUI) or the textual interface (TUI). The method is determined as follows: -#. First, in the graphical user interface (GUI), using the "*Parameters*" +#. Either in the graphical user interface (GUI), using the "*Parameters*" keyword in the "*AlgorithmParameters*" command, which allows you to choose between "*Defaults*" (use of explicit keywords pre-populated by the default values of the parameters) and "*Dict*" (use of a dictionary to fill in the necessary keywords), -#. Then secondly or thirdly, in the graphical user interface (GUI), only in the - case "*Dict*" of "*Parameters*", by the included keyword "*FROM*" which - allows to choose between an entry by string or an entry by Python script - file. -#. Fourth, in textual interface (TUI), using the "*Parameters*" keyword in the +#. Or in the graphical user interface (GUI), only in the case "*Dict*" of + "*Parameters*", by the included keyword "*FROM*" which allows to choose + between an entry by string or an entry by Python script file. +#. Or in textual interface (TUI), using the "*Parameters*" keyword in the "*AlgorithmParameters*" command, in a similar way to the graphical interface, by filling in the explicit keywords described in the documentation of each algorithm. -#. Fifth, in textual interface (TUI), using the keyword "*Parameters*" in the +#. Or in textual interface (TUI), using the keyword "*Parameters*" in the command "*AlgorithmParameters*", providing a script containing a dictionary similar to methods two and three and compatible with these GUI entries. diff --git a/doc/en/ref_output_variables.rst b/doc/en/ref_output_variables.rst index 1a2e756..8187eb1 100644 --- a/doc/en/ref_output_variables.rst +++ b/doc/en/ref_output_variables.rst @@ -23,8 +23,8 @@ .. _section_ref_output_variables: -Variables and informations available at the output --------------------------------------------------- +Variables and information available at the output +------------------------------------------------- How to obtain the information available at the output +++++++++++++++++++++++++++++++++++++++++++++++++++++ diff --git a/doc/en/scripts/simple_Blue.rst b/doc/en/scripts/simple_Blue.rst index cdfbe52..0802fee 100644 --- a/doc/en/scripts/simple_Blue.rst +++ b/doc/en/scripts/simple_Blue.rst @@ -8,4 +8,4 @@ confidence in errors on the two information are considered identical. The operator. The interpolated resulting field is simply the "middle" between the two fields, -with an increased confidence on the errors. +with an increased confidence (that is, a smaller variance) on the errors. diff --git a/doc/en/scripts/simple_ControledFunctionTest2.rst b/doc/en/scripts/simple_ControledFunctionTest2.rst index e23455d..d696243 100644 --- a/doc/en/scripts/simple_ControledFunctionTest2.rst +++ b/doc/en/scripts/simple_ControledFunctionTest2.rst @@ -10,10 +10,11 @@ because they are not useful in this test). Using the command "*CheckingPoint*", one add also a particular state :math:`\mathbf{x}` to test the operator on, and using the command "*ControlInput*", one add a fixed control :math:`\mathbf{u}`. -The test is repeated here 15 times, and a final statistic makes it possible to -quickly verify the operator's good behavior. The simplest diagnostic consists -in checking, at the very end of the display, the order of magnitude of -variations in the values indicated as the mean of the differences between the -repeated outputs and their mean, under the part entitled "*Characteristics of -the mean of the differences between the outputs Y and their mean Ym*". For a -satisfactory operator, these values should be close to the numerical zero. +The test is arbitrarily repeated here 15 times, and a final statistic makes it +possible to quickly verify the operator's good behavior. The simplest +diagnostic consists in checking, at the very end of the display, the order of +magnitude of variations in the values indicated as the mean of the differences +between the repeated outputs and their mean, under the part entitled +"*Characteristics of the mean of the differences between the outputs Y and +their mean Ym*". For a satisfactory operator, these values should be close to +the numerical zero. diff --git a/doc/en/scripts/simple_ExtendedBlue.rst b/doc/en/scripts/simple_ExtendedBlue.rst index c77a778..63e2661 100644 --- a/doc/en/scripts/simple_ExtendedBlue.rst +++ b/doc/en/scripts/simple_ExtendedBlue.rst @@ -8,4 +8,4 @@ confidence in errors on the two information are considered identical. The operator. The interpolated resulting field is simply the "middle" between the two fields, -with an increased confidence on the errors. +with an increased confidence (that is, a smaller variance) on the errors. diff --git a/doc/en/scripts/simple_InterpolationByReducedModelTask1.rst b/doc/en/scripts/simple_InterpolationByReducedModelTask1.rst index 6dfb2a6..8a17cf8 100644 --- a/doc/en/scripts/simple_InterpolationByReducedModelTask1.rst +++ b/doc/en/scripts/simple_InterpolationByReducedModelTask1.rst @@ -3,14 +3,14 @@ First example ............. -This example describes the implementation of a reconstruction by interpolation, -following the building of a reduced representation by an **optimal measurement -positioning** search task. +This example describes the implementation of a **reconstruction by +interpolation**, following the building of a reduced representation by an +*optimal measurement positioning* search. -To illustrate, we use the very simple artificial fields (generated in such a -way as to exist in a vector space of dimension 2) that for the :ref:`study +To illustrate, we use the same very simple artificial fields (generated in such +a way as to exist in a vector space of dimension 2) that for the :ref:`study examples with "MeasurementsOptimalPositioningTask"`. -The preliminary ADAO search yields 2 optimal positions for the measurements, -which are then used to establish a physical field interpolation based on -measurements at the optimum locations. +The preliminary positioning ADAO search yields 2 optimal positions for the +measurements, which are then used to establish a physical field interpolation +based on measurements at the optimum locations. diff --git a/doc/en/snippets/Header2Algo09.rst b/doc/en/snippets/Header2Algo09.rst index 0119958..707d2cd 100644 --- a/doc/en/snippets/Header2Algo09.rst +++ b/doc/en/snippets/Header2Algo09.rst @@ -2,5 +2,6 @@ Python (TUI) use examples +++++++++++++++++++++++++ Here is one or more very simple examples of the proposed algorithm and its -parameters, written in :ref:`section_tui`. Moreover, the information given as -input also allows to define an equivalent case in :ref:`section_gui_in_salome`. +parameters, written in :ref:`section_tui`. Moreover, when it is possible, the +information given as input also allows to define an equivalent case in +:ref:`section_gui_in_salome`. diff --git a/doc/en/snippets/Variant_PSO.rst b/doc/en/snippets/Variant_PSO.rst index 2e44455..fbbfbe1 100644 --- a/doc/en/snippets/Variant_PSO.rst +++ b/doc/en/snippets/Variant_PSO.rst @@ -8,12 +8,12 @@ Variant *Predefined name*. This key allows to choose one of the possible variants for the main algorithm. The default variant is the original "CanonicalPSO", and the possible choices are - "CanonicalPSO" (Canonical Particule Swarm Optimisation), - "OGCR" (Simple Particule Swarm Optimisation), - "SPSO-2011" (Standard Standard Particle Swarm Optimisation 2011). + "CanonicalPSO" (Canonical Particle Swarm Optimization), + "OGCR" (Simple Particle Swarm Optimization), + "SPSO-2011" (Standard Standard Particle Swarm Optimization 2011). It is recommended to try the "CanonicalPSO" variant with about 100 particles - for robust performance, and to reduce the number of particules to about 40 + for robust performance, and to reduce the number of particles to about 40 for all variants other than the original "CanonicalPSO" formulation. Example : diff --git a/doc/en/theory.rst b/doc/en/theory.rst index dc2da5b..382b5c9 100644 --- a/doc/en/theory.rst +++ b/doc/en/theory.rst @@ -71,7 +71,7 @@ changing the required option "*EstimationOf*" in the algorithm parameters. Before introducing the :ref:`section_theory_da_framework` in a next section, these two types of applications are briefly described. At the end, some detailed information allow :ref:`section_theory_more_assimilation` and -:ref:`section_theory_optimization`, as well as :ref:`section_theory_dynamique` +:ref:`section_theory_optimization`, as well as :ref:`section_theory_dynamic` and having :ref:`section_theory_reduction`. Fields reconstruction or measures interpolation @@ -264,7 +264,7 @@ minimize the following function :math:`J`: .. 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` is classically designed as the "*3D-Var*" functional in data -assimlation (see for example [Talagrand97]_) or as the generalized Tikhonov +assimilation (see for example [Talagrand97]_) or as the generalized Tikhonov regularization functional in optimization (see for example [WikipediaTI]_). Since :math:`\mathbf{B}` and :math:`\mathbf{R}` covariance matrices are proportional to the variances of errors, their presence in both terms of the @@ -301,11 +301,11 @@ solution. It is indicated here that these methods of "*3D-Var*" and "*BLUE*" may be extended to dynamic or time-related problems, called respectively "*4D-Var*" -and "*Kalman filter (KF)*" and their derivatives. They have to take into +and "*Kalman Filter (KF)*" and their derivatives. They have to take into account an evolution operator to establish an analysis at the right time steps of the gap between observations and simulations, and to have, at every moment, the propagation of the background through the evolution model. The next section -provides information on :ref:`section_theory_dynamique`. In +provides information on :ref:`section_theory_dynamic`. In the same way, these methods can be used in case of non linear observation or evolution operators. Many other variants have been developed to improve the numerical quality of the methods or to take into account computer requirements @@ -345,7 +345,7 @@ links: - EKF: :ref:`section_ref_algorithm_ExtendedKalmanFilter`, - EnKF: :ref:`section_ref_algorithm_EnsembleKalmanFilter`, - DFO: :ref:`section_ref_algorithm_DerivativeFreeOptimization`, -- Incr-Var: Incremental version Variational optimisation, +- Incr-Var: Incremental version Variational optimization, - KF: :ref:`section_ref_algorithm_KalmanFilter`, - LLS: :ref:`section_ref_algorithm_LinearLeastSquares`, - NLLS: :ref:`section_ref_algorithm_NonLinearLeastSquares`, @@ -528,7 +528,7 @@ requires to minimize the goal function :math:`J`: .. 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}) which is named the "*3D-Var*" objective function. It can be seen as a *least -squares minimization* extented form, obtained by adding a regularizing term +squares minimization* extended form, obtained by adding a regularizing term using :math:`\mathbf{x}-\mathbf{x}^b`, and by weighting the differences using :math:`\mathbf{B}` and :math:`\mathbf{R}` the two covariance matrices. The minimization of the :math:`J` function leads to the *best* :math:`\mathbf{x}` @@ -615,7 +615,7 @@ it is available in the ADAO module: The reader interested in the subject of optimization can look at [WikipediaMO]_ as a general entry point. -.. _section_theory_dynamique: +.. _section_theory_dynamic: Going further in data assimilation for dynamics ----------------------------------------------- @@ -802,14 +802,14 @@ estimation of the state (:math:`\mathbf{x}`). A possible representation is as follows, particularly appropriate for iterative Kalman filtering algorithms: .. _schema_d_AD_temporel: - .. image:: images/schema_temporel_KF.png + .. figure:: images/schema_temporel_KF.png :align: center :width: 100% - .. centered:: + **Timeline of steps for data assimilation operators in dynamics** with **P** the state error covariance and *t* the discrete iterative time. In this scheme, the analysis **(x,P)** is obtained by means of the "*correction*" by observing the "*prediction*" of the previous state. The concepts described in this diagram can be directly and simply used in ADAO to elaborate study -cases, and are included in the description of some algorithms. +cases, and are included in the description and the examples of some algorithms. diff --git a/doc/en/tui.rst b/doc/en/tui.rst index c121808..0326746 100644 --- a/doc/en/tui.rst +++ b/doc/en/tui.rst @@ -100,7 +100,7 @@ use in the commands. Thereafter, the case has to be build by preparing and storing the data that define the study. The commands order does not matter, it is sufficient that all the concepts, required by the algorithm used, are present. The user can refer -to the :ref:`section_reference` and its subparts to get details about commands +to the :ref:`section_reference` and its sub-parts to get details about commands by algorithm. Here, we define successively the chosen data assimilation or optimization algorithm and its parameters, then the *a priori* state :math:`\mathbf{x}^b` (named ``Background``) and its errors covariance @@ -139,8 +139,8 @@ operator from :math:`\mathbf{R}^3` into itself: In the most frequent case of a non-linear operator of :math:`\mathbf{R}^n` into :math:`\mathbf{R}^p`, it has to be previously available as a Python function, -known in the current name space, which takes a ``numpy`` vector (or an ordered -list) of size :math:`n` as input and which returns as output a ``numpy`` vector +known in the current name space, which takes a Numpy vector (or an ordered +list) of size :math:`n` as input and which returns as output a Numpy vector of size :math:`p`. When the non-linear operator is the only one to be defined by the keyword "*OneFunction*", its adjoint is directly established by numerical calculations and it can be parametrized by the keyword diff --git a/doc/en/tutorials_in_salome.rst b/doc/en/tutorials_in_salome.rst index 9b9028f..8269a01 100644 --- a/doc/en/tutorials_in_salome.rst +++ b/doc/en/tutorials_in_salome.rst @@ -328,7 +328,7 @@ Adding parameters to control the data assimilation algorithm One can add some optional parameters to control the data assimilation algorithm calculation. This is done by using optional parameters in the "*AlgorithmParameters*" command of the ADAO case definition, which is a keyword -of the general case ommand (to choose between "*ASSIMILATION_STUDY*", +of the general case command (to choose between "*ASSIMILATION_STUDY*", "*OPTIMIZATION_STUDY*" or "*REDUCTION_STUDY*"). This keyword requires an explicit definition of the values from default ones, or from a Python dictionary, containing some key/value pairs. The list of possible optional diff --git a/doc/fr/advanced.rst b/doc/fr/advanced.rst index 3ace83a..9dd5f57 100644 --- a/doc/fr/advanced.rst +++ b/doc/fr/advanced.rst @@ -52,7 +52,7 @@ 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 @@ -455,7 +455,7 @@ 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 +affichées à tous les niveaux au-dessus de celui-ci (inclus). La méthode la plus facile consiste à changer le niveau de surveillance en utilisant les lignes Python suivantes : :: diff --git a/doc/fr/gui_in_salome.rst b/doc/fr/gui_in_salome.rst index 4bffbfb..e29c26c 100644 --- a/doc/fr/gui_in_salome.rst +++ b/doc/fr/gui_in_salome.rst @@ -97,8 +97,8 @@ l'ouverture d'une étude déjà existante: 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 : +cliquer sur le bouton "*Nouveau*" (ou choisir l'entrée "*Nouveau*" dans le +menu principal "*ADAO*") pour créer un nouveau cas ADAO, et on obtient : .. _adao_viewer: .. image:: images/adao_viewer.png diff --git a/doc/fr/index.rst b/doc/fr/index.rst index 4164da9..3fe66cd 100644 --- a/doc/fr/index.rst +++ b/doc/fr/index.rst @@ -60,7 +60,7 @@ La première partie est l':ref:`section_intro`. La seconde partie présente :ref:`section_methodology`. Pour un utilisateur courant, les parties suivantes présentent des :ref:`section_docu_examples`, rapidement accessibles par l'ensemble des pointeurs vers les sous-parties. Des présentations didactiques -sont détaillés dans les :ref:`section_tutorials_in_salome` ou les +sont détaillées dans les :ref:`section_tutorials_in_salome` ou les :ref:`section_tutorials_in_python`, et complétées par des indications sur les :ref:`section_advanced`, avec l'obtention de renseignements supplémentaires ou l'usage par scripts de commandes hors interface de contrôle graphique. diff --git a/doc/fr/license.rst b/doc/fr/license.rst index 75cd67a..78afadb 100644 --- a/doc/fr/license.rst +++ b/doc/fr/license.rst @@ -70,5 +70,5 @@ l'année en cours : * *SALOME The Open Source Integration Platform for Numerical Simulation*, http://www.salome-platform.org/ -La documentation du module est également entièrement couverte par la licence et -l'obligation de citation. +La documentation du module, y compris les figures et les exemples, est +également entièrement couverte par la licence et l'obligation de citation. diff --git a/doc/fr/methodology.rst b/doc/fr/methodology.rst index edc258e..94c7e02 100644 --- a/doc/fr/methodology.rst +++ b/doc/fr/methodology.rst @@ -114,7 +114,7 @@ et d'extraction du code de simulation. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 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 +les **informations 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. @@ -126,10 +126,10 @@ 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 +informations utiles peuvent être obtenues à 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. +technique permettent d'évaluer l'intérêt 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 @@ -143,7 +143,7 @@ faciliter l'évaluation de la qualité globale des résultats numériques 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 +intrinsèques, leurs particularités, sont importantes à connaître, pour pouvoir introduire ces informations dans les calculs d'assimilation de données ou d'optimisation. @@ -202,7 +202,7 @@ 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. +méthode 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. diff --git a/doc/fr/ref_algorithm_3DVAR.rst b/doc/fr/ref_algorithm_3DVAR.rst index 741d4cd..3b154f2 100644 --- a/doc/fr/ref_algorithm_3DVAR.rst +++ b/doc/fr/ref_algorithm_3DVAR.rst @@ -72,10 +72,12 @@ reste la covariance d'ébauche initialement fournie par l'utilisateur. Pour êtr explicite, contrairement aux filtres de type Kalman, la covariance d'erreurs sur les états n'est pas remise à jour. -Une extension du 3DVAR, couplant en parallèle une méthode 3DVAR avec un filtre -de Kalman d'ensemble, permet d'améliorer l'estimation des covariances d'erreurs -*a posteriori*. On atteint cette extension en utilisant le variant "E3DVAR" de -l'algorithme de filtrage :ref:`section_ref_algorithm_EnsembleKalmanFilter`. +Une extension du 3DVAR, couplant en parallèle une méthode 3DVAR, pour +l'estimation d'un unique meilleur état, avec un filtre de Kalman d'ensemble +pour l'estimation des covariances d'erreurs, permet d'améliorer l'estimation de +ces covariances d'erreurs *a posteriori*. On atteint cette extension en +utilisant le variant "E3DVAR" de l'algorithme de filtrage +:ref:`section_ref_algorithm_EnsembleKalmanFilter`. .. ------------------------------------ .. .. include:: snippets/Header2Algo02.rst diff --git a/doc/fr/ref_algorithm_EnsembleKalmanFilter.rst b/doc/fr/ref_algorithm_EnsembleKalmanFilter.rst index 7f7e4d3..cc2d20d 100644 --- a/doc/fr/ref_algorithm_EnsembleKalmanFilter.rst +++ b/doc/fr/ref_algorithm_EnsembleKalmanFilter.rst @@ -39,15 +39,18 @@ Il s'applique aux cas d'opérateurs d'observation et d'évolution incrémentale (processus) non-linéaires et présente d'excellentes qualités de robustesse et de performances. Il peut être interprété comme une réduction d'ordre du filtre de Kalman classique, avec une remarquable qualité d'assimilation de ce -filtrage pour les problèmes de grande taille. Il peut être rapproché de -l':ref:`section_ref_algorithm_UnscentedKalmanFilter` dont les qualités sont +filtrage pour les problèmes de grande taille. Il peut être rapproché d'un +:ref:`section_ref_algorithm_UnscentedKalmanFilter` dont les qualités sont similaires pour les systèmes non-linéaires. On remarque qu'il n'y a pas d'analyse effectuée au pas de temps initial (numéroté 0 dans l'indexage temporel) car il n'y a pas de prévision à cet instant (l'ébauche est stockée comme pseudo-analyse au pas initial). Si les observations sont fournies en série par l'utilisateur, la première n'est donc -pas utilisée. +pas utilisée. Pour une bonne compréhension de la gestion du temps, on se +reportera au :ref:`schema_d_AD_temporel` et aux explications décrites dans la +section pour :ref:`section_theory_dynamic`. + Dans le cas d'opérateurs linéaires ou "faiblement" non-linéaire, on peut aisément utiliser l':ref:`section_ref_algorithm_ExtendedKalmanFilter` ou même @@ -72,6 +75,7 @@ la littérature. On propose ici les formulations stables et robustes suivantes : pair: Variant ; MLEF pair: Variant ; IEnKF pair: Variant ; E3DVAR + pair: Variant ; 3D-Var-Ben pair: Variant ; EnKS pair: Variant ; EnSRKF pair: Variant ; RRSQRT @@ -81,7 +85,7 @@ la littérature. On propose ici les formulations stables et robustes suivantes : - "ETKF-N" (Ensemble-Transform Kalman Filter of finite size N), algorithme d'ETKF dit de "taille finie N", évitant de recourir à une inflation souvent nécessaire avec les autres algorithmes, - "MLEF" (Maximum Likelihood Kalman Filter, voir [Zupanski05]_), algorithme déterministe d'EnKF, permettant en plus de traiter de manière consistante un opérateur d'observation non-linéaire), - "IEnKF" (Iterative EnKF), algorithme déterministe d'EnKF, améliorant le traitement des non-linéarités des opérateurs, -- "E3DVAR" (EnKF 3DVAR), algorithme couplant assimilation d'ensemble et variationnelle, qui utilise en parallèle une assimilation variationnelle 3DVAR et un algorithme d'EnKF pour améliorer l'estimation des covariances d'erreurs *a posteriori*, +- "E3DVAR" (EnKF 3DVAR, ou 3D-Var-Ben), algorithme couplant assimilation d'ensemble et variationnelle, qui utilise en parallèle une assimilation variationnelle 3DVAR pour l'estimation d'un unique meilleur état et un algorithme d'ensemble EnKF pour améliorer l'estimation des covariances d'erreurs *a posteriori*, - "EnKS" (Ensemble Kalman Smoother), algorithme de lissage avec un décalage fixe. Sans pouvoir prétendre à l'universalité, on recommande d'utiliser la diff --git a/doc/fr/ref_algorithm_ExtendedKalmanFilter.rst b/doc/fr/ref_algorithm_ExtendedKalmanFilter.rst index 971c2c1..e5f4f47 100644 --- a/doc/fr/ref_algorithm_ExtendedKalmanFilter.rst +++ b/doc/fr/ref_algorithm_ExtendedKalmanFilter.rst @@ -45,11 +45,11 @@ opérateurs d'évolution et d'observation dans cet algorithme de la manière suivante, avec **x** l'état, **P** la covariance d'erreur d'état, *t* le temps itératif discret : - .. _schema_temporel_KF: - .. image:: images/schema_temporel_KF.png + .. _schema_temporel_EKF: + .. figure:: images/schema_temporel_KF.png :align: center :width: 100% - .. centered:: + **Schéma temporel des étapes en assimilation de données par filtre de Kalman étendu** Dans ce schéma, l'analyse **(x,P)** est obtenue à travers la "*correction*" par @@ -63,7 +63,7 @@ Ce filtre peut aussi être utilisé pour estimer (conjointement ou uniquement) des paramètres et non pas l'état, auquel cas ni le temps ni l'évolution n'ont plus de signification. Les pas d'itération sont alors liés à l'insertion d'une nouvelle observation dans l'estimation récursive. On consultera la section -:ref:`section_theory_dynamique` pour les concepts de mise en oeuvre. +:ref:`section_theory_dynamic` pour les concepts de mise en oeuvre. Dans le cas d'opérateurs plus fortement non-linéaires, on peut utiliser un :ref:`section_ref_algorithm_EnsembleKalmanFilter` ou un diff --git a/doc/fr/ref_algorithm_InputValuesTest.rst b/doc/fr/ref_algorithm_InputValuesTest.rst index 33f79f7..9b00fb6 100644 --- a/doc/fr/ref_algorithm_InputValuesTest.rst +++ b/doc/fr/ref_algorithm_InputValuesTest.rst @@ -33,7 +33,7 @@ Algorithme de vérification "*InputValuesTest*" Cet algorithme permet de vérifier le contenu des variables d'entrée courantes et la manière dont les données sont interprétées ou lues lors de leur acquisition, à travers l'affichage des informations de taille et des -statistique sur les entrées. Il permet aussi de restituer la totalité du +statistiques sur les entrées. Il permet aussi de restituer la totalité du contenu des variables lues sous forme imprimée pour vérification (*attention, si une variable est de grande taille, cette restitution peut être informatiquement problématique*). @@ -51,7 +51,7 @@ informatiquement problématique*). Comme la commande *"ObservationOperator"*, dans l'interface graphique, est requise pour TOUS les algorithmes de vérification, il faut fournir une - valeur, malgré le fait que cette commandes ne soit pas nécessaires pour cet + valeur, malgré le fait que cette commandes ne soit pas nécessaire pour cet test (et sa valeur n'est donc pas utilisée). La manière la plus simple est de donner "1" comme un STRING, pour un *"ObservationOperator"* devant être de type *Matrix* creuse. diff --git a/doc/fr/ref_algorithm_KalmanFilter.rst b/doc/fr/ref_algorithm_KalmanFilter.rst index c513b4b..905015b 100644 --- a/doc/fr/ref_algorithm_KalmanFilter.rst +++ b/doc/fr/ref_algorithm_KalmanFilter.rst @@ -52,10 +52,10 @@ suivante, avec **x** l'état, **P** la covariance d'erreur d'état, *t* le temps itératif discret : .. _schema_temporel_KF: - .. image:: images/schema_temporel_KF.png + .. figure:: images/schema_temporel_KF.png :align: center :width: 100% - .. centered:: + **Schéma temporel des étapes en assimilation de données par filtre de Kalman** Dans ce schéma, l'analyse **(x,P)** est obtenue à travers la "*correction*" par @@ -69,7 +69,7 @@ Ce filtre peut aussi être utilisé pour estimer (conjointement ou uniquement) des paramètres et non pas l'état, auquel cas ni le temps ni l'évolution n'ont plus de signification. Les pas d'itération sont alors liés à l'insertion d'une nouvelle observation dans l'estimation récursive. On consultera la section -:ref:`section_theory_dynamique` pour les concepts de mise en oeuvre. +:ref:`section_theory_dynamic` pour les concepts de mise en oeuvre. En cas de non-linéarité des opérateurs, même peu marquée, on lui préférera un :ref:`section_ref_algorithm_ExtendedKalmanFilter`, ou un diff --git a/doc/fr/ref_algorithm_SamplingTest.rst b/doc/fr/ref_algorithm_SamplingTest.rst index 6d58807..dc20b3d 100644 --- a/doc/fr/ref_algorithm_SamplingTest.rst +++ b/doc/fr/ref_algorithm_SamplingTest.rst @@ -45,7 +45,7 @@ L'échantillonnage des états :math:`\mathbf{x}` peut être fourni explicitement ou sous la forme d'hyper-cubes, explicites ou échantillonnés selon des distributions 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. Lorsque un état n'est pas observable, une valeur *"NaN"* est +importante. Lorsqu'un état n'est pas observable, une valeur *"NaN"* est retournée. Il est aussi possible de fournir un ensemble de simulations :math:`\mathbf{y}` diff --git a/doc/fr/ref_algorithm_UnscentedKalmanFilter.rst b/doc/fr/ref_algorithm_UnscentedKalmanFilter.rst index 2689ddb..cbeec6f 100644 --- a/doc/fr/ref_algorithm_UnscentedKalmanFilter.rst +++ b/doc/fr/ref_algorithm_UnscentedKalmanFilter.rst @@ -45,7 +45,9 @@ On remarque qu'il n'y a pas d'analyse effectuée au pas de temps initial (numéroté 0 dans l'indexage temporel) car il n'y a pas de prévision à cet instant (l'ébauche est stockée comme pseudo-analyse au pas initial). Si les observations sont fournies en série par l'utilisateur, la première n'est donc -pas utilisée. +pas utilisée. Pour une bonne compréhension de la gestion du temps, on se +reportera au :ref:`schema_d_AD_temporel` et aux explications décrites dans la +section pour :ref:`section_theory_dynamic`. Dans le cas d'opérateurs linéaires ou "faiblement" non-linéaire, on peut aisément utiliser l':ref:`section_ref_algorithm_ExtendedKalmanFilter` ou même diff --git a/doc/fr/ref_covariance_requirements.rst b/doc/fr/ref_covariance_requirements.rst index 32c1b9c..7b20bfa 100644 --- a/doc/fr/ref_covariance_requirements.rst +++ b/doc/fr/ref_covariance_requirements.rst @@ -125,7 +125,7 @@ alors être spécifiée de manière unique par le multiplicateur :math:`m`: 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 +il est converti 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 : :: @@ -157,12 +157,12 @@ diagonale. La matrice peut alors être définie uniquement par un vecteur 0 & \cdots & 0 & v_{n} \end{pmatrix} -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 -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 -script Python 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 positives). +Par exemple, une matrice simple diagonale unitaire des covariances 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_operator_requirements.rst b/doc/fr/ref_operator_requirements.rst index cd93062..c7738a2 100644 --- a/doc/fr/ref_operator_requirements.rst +++ b/doc/fr/ref_operator_requirements.rst @@ -68,7 +68,7 @@ fournir une fonction qui réalise complètement et uniquement l'opération fonctionnelle**. Cette fonction est généralement donnée comme une **fonction ou un script -Python**, qui peuvent en particulier être exécuté comme une fonction Python +Python**, qui peuvent en particulier être exécutée comme une fonction Python indépendante ou dans un noeud YACS. Cette fonction ou ce script peuvent, sans différences, lancer des codes externes ou utiliser des appels et des méthodes internes Python ou SALOME. Si l'algorithme nécessite les 3 aspects de @@ -222,12 +222,12 @@ suivre le squelette suivant:: ... return "un vecteur similaire à 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. +Une 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 (en particulier les filtres non ensemblistes), il -faut que les fonctions tangente et adjointe puisse renvoyer les matrices +faut que les fonctions tangente et adjointe puissent renvoyer les matrices équivalentes à l'opérateur linéaire. Dans ce cas, lorsque, respectivement, les arguments ``dX`` ou ``Y`` valent ``None``, le script de l'utilisateur doit renvoyer la matrice associée. Les squelettes des fonctions "*TangentOperator*" diff --git a/doc/fr/ref_options_AlgorithmParameters.rst b/doc/fr/ref_options_AlgorithmParameters.rst index cf3ac14..6478f08 100644 --- a/doc/fr/ref_options_AlgorithmParameters.rst +++ b/doc/fr/ref_options_AlgorithmParameters.rst @@ -38,23 +38,22 @@ Il existe plusieurs méthodes pratiques pour fournir ces options, que ce soit en utilisant l'interface graphique EFICAS d'ADAO (GUI) ou l'interface textuelle (TUI). La méthode est déterminée de la manière suivante : -#. Premièrement, en interface graphique (GUI), à 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 +#. Soit en interface graphique (GUI), à 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 ou troisièmement, en interface graphique (GUI), 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. -#. Quatrièmement, en interface textuelle (TUI), à l'aide du mot-clé - "*Parameters*" dans la commande "*AlgorithmParameters*", de manière - semblable à l'interface graphique, en renseignant les mots-clés explicites - décrits dans la documentation de chaque algorithme. -#. Cinquièmement, en interface textuelle (TUI), à l'aide du mot-clé - "*Parameters*" dans la commande "*AlgorithmParameters*", en fournissant un - script contenant un dictionnaire similaire aux méthodes deux et trois et - compatibles avec ces entrées en GUI. +#. Soit en interface graphique (GUI), 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. +#. Soit en interface textuelle (TUI), à l'aide du mot-clé "*Parameters*" dans + la commande "*AlgorithmParameters*", de manière semblable à l'interface + graphique, en renseignant les mots-clés explicites décrits dans la + documentation de chaque algorithme. +#. Soit en interface textuelle (TUI), à l'aide du mot-clé "*Parameters*" dans + la commande "*AlgorithmParameters*", en fournissant un script contenant un + dictionnaire similaire aux méthodes deux et trois et compatibles avec ces + entrées en GUI. Ces deux dernières options sont celles que l'on peut utiliser dans l'interface textuelle (TUI) de manière similaire et compatible aux deux précédentes basées @@ -108,7 +107,7 @@ commande "*Dict*" qui apparaît, comme montré dans la figure qui suit : .. centered:: **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 +Dans le champ de saisie, il faut utiliser des guillemets simples pour une définition standard de dictionnaire, comme par exemple:: '{"MaximumNumberOfIterations":25,"SetSeed":1000}' diff --git a/doc/fr/ref_output_variables.rst b/doc/fr/ref_output_variables.rst index 6e14905..26718bc 100644 --- a/doc/fr/ref_output_variables.rst +++ b/doc/fr/ref_output_variables.rst @@ -76,17 +76,17 @@ Exemples de scripts Python pour obtenir ou traiter les sorties .. index:: single: AnalysisSaver (UserPostAnalysis) .. index:: single: AnalysisPrinterAndSaver (UserPostAnalysis) -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 +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. +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 +retours à 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*" pour la section "*UserPostAnalysis*") consiste à afficher, dans la diff --git a/doc/fr/scripts/simple_3DVAR1.rst b/doc/fr/scripts/simple_3DVAR1.rst index c1295d7..09affa1 100644 --- a/doc/fr/scripts/simple_3DVAR1.rst +++ b/doc/fr/scripts/simple_3DVAR1.rst @@ -14,7 +14,7 @@ de manière statique dans le modèle. Le recalage s'effectue sur la base d'un jeu initial de coefficients (état d'ébauche désigné par ``Xb`` dans l'exemple), et avec l'information :math:`\mathbf{y}^o` (désignée par ``Yobs`` dans l'exemple) de 5 mesures -obtenues à aux points de contrôle internes. On se place ici en expériences +obtenues aux points de contrôle internes. On se place ici en expériences jumelles (voir :ref:`section_methodology_twin`), et les mesures sont considérées comme parfaites. On choisit de privilégier les observations, au détriment de l'ébauche, par l'indication artificielle d'une très importante diff --git a/doc/fr/scripts/simple_3DVAR2.rst b/doc/fr/scripts/simple_3DVAR2.rst index 4e07966..524adc1 100644 --- a/doc/fr/scripts/simple_3DVAR2.rst +++ b/doc/fr/scripts/simple_3DVAR2.rst @@ -18,7 +18,7 @@ manière ici un peu plus lente qu'avec un Filtre de Kalman. Remarque concernant les covariances *a posteriori* : classiquement, l'analyse itérative 3DVAR remet à jour uniquement l'état et non pas sa covariance. Comme les hypothèses d'opérateurs et de covariance *a priori* - restent inchangées ici au court de l'évolution, la covariance *a + restent inchangées ici au cours de l'évolution, la covariance *a posteriori* est constante. Le tracé qui suit de cette covariance *a posteriori* permet d'insister sur cette propriété tout à fait attendue de l'analyse 3DVAR. Une hypothèse plus évoluée est proposée dans l'exemple qui diff --git a/doc/fr/scripts/simple_AdjointTest.rst b/doc/fr/scripts/simple_AdjointTest.rst index af656b6..70dc89c 100644 --- a/doc/fr/scripts/simple_AdjointTest.rst +++ b/doc/fr/scripts/simple_AdjointTest.rst @@ -2,7 +2,7 @@ Cet exemple décrit le test de la qualité de l'adjoint d'un opérateur quelconque, dont la formulation directe est donnée et dont la formulation -adjointe est ici approximé par défaut. Les informations nécessaires sont +adjointe est ici approximée par défaut. Les informations nécessaires sont minimales, à savoir ici un opérateur :math:`F` (décrit pour le test par la commande d'observation "*ObservationOperator*"), et un état :math:`\mathbf{x}^b` sur lequel le tester (décrit pour le test par la commande diff --git a/doc/fr/scripts/simple_Blue.rst b/doc/fr/scripts/simple_Blue.rst index 7908e70..0d77021 100644 --- a/doc/fr/scripts/simple_Blue.rst +++ b/doc/fr/scripts/simple_Blue.rst @@ -8,4 +8,4 @@ identiques. Le modèle :math:`H` observe complètement le champ disponible, c'es un opérateur de sélection matriciel. Le champ interpolé résultant est simplement le "milieu" entre les deux champs, -avec une confiance améliorée sur les erreurs. +avec une confiance améliorée (i.e. une variance plus petite) sur les erreurs. diff --git a/doc/fr/scripts/simple_ControledFunctionTest2.rst b/doc/fr/scripts/simple_ControledFunctionTest2.rst index 6c05fa8..a0ee794 100644 --- a/doc/fr/scripts/simple_ControledFunctionTest2.rst +++ b/doc/fr/scripts/simple_ControledFunctionTest2.rst @@ -3,7 +3,7 @@ Deuxième exemple Ce nouvel exemple décrit le test du bon fonctionnement d'un opérateur quelconque nommé ``ControledQuadFunction``, disponible sous forme -fonctionnelle. Il est définit par la commande "*ObservationOperator*" selon la +fonctionnelle. Il est défini par la commande "*ObservationOperator*" selon la :ref:`section_ref_operator_funcs` (ici, même avec cette forme fonctionnelle, on peut exceptionnellement ne pas définir les formes tangente et adjointe de l'opérateur car elles ne sont pas utiles dans ce test). Par la commande @@ -11,11 +11,11 @@ l'opérateur car elles ne sont pas utiles dans ce test). Par la commande lequel tester l'opérateur, et par la commande "*ControlInput*" on ajoute un contrôle fixe :math:`\mathbf{u}`. -Ce test est répété ici 15 fois, et une statistique finale permet de vérifier -rapidement le bon comportement de l'opérateur. Le diagnostic le plus simple -consiste à vérifier, à la toute fin de l'affichage, l'ordre de grandeur des -variations des valeurs indiquées comme la moyenne des différences entre les -sorties répétées et leur moyenne, sous la partie titrée "*Characteristics of -the mean of the differences between the outputs Y and their mean Ym*". Pour -qu'un opérateur soit satisfaisant, ces valeurs doivent être proches du zéro -numérique. +Ce test est arbitrairement répété ici 15 fois, et une statistique finale permet +de vérifier rapidement le bon comportement de l'opérateur. Le diagnostic le +plus simple consiste à vérifier, à la toute fin de l'affichage, l'ordre de +grandeur des variations des valeurs indiquées comme la moyenne des différences +entre les sorties répétées et leur moyenne, sous la partie titrée +"*Characteristics of the mean of the differences between the outputs Y and +their mean Ym*". Pour qu'un opérateur soit satisfaisant, ces valeurs doivent +être proches du zéro numérique. diff --git a/doc/fr/scripts/simple_ExtendedBlue.rst b/doc/fr/scripts/simple_ExtendedBlue.rst index 7b38c90..9167451 100644 --- a/doc/fr/scripts/simple_ExtendedBlue.rst +++ b/doc/fr/scripts/simple_ExtendedBlue.rst @@ -8,4 +8,4 @@ identiques. Le modèle :math:`H` observe complètement le champ disponible, c'es un opérateur de sélection matriciel. Le champ interpolé résultant est simplement le "milieu" entre les deux champs, -avec une confiance améliorée sur les erreurs. +avec une confiance améliorée (i.e. une variance plus petite) sur les erreurs. diff --git a/doc/fr/scripts/simple_InterpolationByReducedModelTask1.rst b/doc/fr/scripts/simple_InterpolationByReducedModelTask1.rst index a47fa08..8d01c6f 100644 --- a/doc/fr/scripts/simple_InterpolationByReducedModelTask1.rst +++ b/doc/fr/scripts/simple_InterpolationByReducedModelTask1.rst @@ -3,14 +3,14 @@ Premier exemple ............... -Cet exemple décrit la mise en oeuvre d'une reconstruction par interpolation, -faisant suite à l'établissement d'une représentation réduite par une tâche de -recherche de **positionnement optimal de mesures**. +Cet exemple décrit la mise en oeuvre d'une **reconstruction par +interpolation**, faisant suite à l'établissement d'une représentation réduite +par une recherche de *positionnement optimal de mesures*. -Pour l'illustration, on utilise la collection artificielle de champs physiques -très simple (engendré de manière à exister dans un espace vectoriel de -dimension 2) que pour les :ref:`exemples d'étude avec +Pour l'illustration, on utilise la même collection artificielle de champs +physiques très simple (engendré de manière à exister dans un espace vectoriel +de dimension 2) que pour les :ref:`exemples d'étude avec "MeasurementsOptimalPositioningTask"`. -La recherche ADAO préalable permet d'obtenir 2 positions optimales pour les -mesures, qui servent ensuite à établir une interpolation de champ physique à -partir de mesures aux positions optimales. +La recherche de positionnement ADAO préalable permet d'obtenir 2 positions +optimales pour les mesures, qui servent ensuite à établir une interpolation de +champ physique à partir de mesures aux positions optimales. diff --git a/doc/fr/snippets/EntryTypeVector.rst b/doc/fr/snippets/EntryTypeVector.rst index 7f9e3a4..76c4087 100644 --- a/doc/fr/snippets/EntryTypeVector.rst +++ b/doc/fr/snippets/EntryTypeVector.rst @@ -5,4 +5,5 @@ comme un vecteur. C'est une simple collection ordonnée de nombres réels. Les vecteurs peuvent être décrits en version ligne ou colonne sans faire de différence. Les détails des :ref:`section_ref_observations_requirements` - permettent d'illustrer différentes manières possible d'écrire cette entrée. + permettent d'illustrer différentes manières possibles d'écrire cette + entrée. diff --git a/doc/fr/snippets/EntryTypeVectorSerie.rst b/doc/fr/snippets/EntryTypeVectorSerie.rst index 3e74847..bcac5f0 100644 --- a/doc/fr/snippets/EntryTypeVectorSerie.rst +++ b/doc/fr/snippets/EntryTypeVectorSerie.rst @@ -4,4 +4,5 @@ *Liste de liste de valeurs réelles*. Cela indique une variable qui doit être remplie comme une liste de vecteurs. C'est une collection ordonnée de vecteurs. Les détails des :ref:`section_ref_observations_requirements` - permettent d'illustrer différentes manières possible d'écrire cette entrée. + permettent d'illustrer différentes manières possibles d'écrire cette + entrée. diff --git a/doc/fr/snippets/ExecuteInContainer.rst b/doc/fr/snippets/ExecuteInContainer.rst index 333f185..9ba5159 100644 --- a/doc/fr/snippets/ExecuteInContainer.rst +++ b/doc/fr/snippets/ExecuteInContainer.rst @@ -5,13 +5,13 @@ ExecuteInContainer dans YACS en container spécifique. En son absence ou si sa valeur est "No", il n'est pas utilisé de container séparé pour l'exécution et elle se déroule dans le processus principal de YACS. Si sa valeur est "Mono", un container - YACS spécifique est crée et il est utilisé pour héberger l'exécution de tous + YACS spécifique est créé et il est utilisé pour héberger l'exécution de tous les noeuds dans un même processus. Si sa valeur est "Multi", un container - YACS spécifique est crée et il est utilisé pour héberger l'exécution de + YACS spécifique est créé et il est utilisé pour héberger l'exécution de chaque noeud dans un processus spécifique. La valeur par défaut est "No", et les choix possibles sont "No", "Mono" et "Multi". .. warning:: - Dans sa présente version, cet commande est expérimentale, et reste donc + Dans sa présente version, cette commande est expérimentale, et reste donc susceptible de changements dans les prochaines versions. diff --git a/doc/fr/snippets/Header2Algo09.rst b/doc/fr/snippets/Header2Algo09.rst index 3e7ea72..aea5820 100644 --- a/doc/fr/snippets/Header2Algo09.rst +++ b/doc/fr/snippets/Header2Algo09.rst @@ -2,6 +2,7 @@ Exemples d'utilisation en Python (TUI) ++++++++++++++++++++++++++++++++++++++ Voici un ou des exemples très simple d'usage de l'algorithme proposé et de ses -paramètres, écrit en :ref:`section_tui`. De plus, les informations indiquées en -entrée permettent aussi de définir un cas équivalent en interface graphique -:ref:`section_gui_in_salome`. +paramètres, écrit en :ref:`section_tui`. De plus, lorsque c'est possible, les +informations indiquées en entrée permettent aussi de définir un cas équivalent +en interface graphique :ref:`section_gui_in_salome`. + diff --git a/doc/fr/snippets/ResiduFormula_LinearityTest.rst b/doc/fr/snippets/ResiduFormula_LinearityTest.rst index a81aeaf..328a8d9 100644 --- a/doc/fr/snippets/ResiduFormula_LinearityTest.rst +++ b/doc/fr/snippets/ResiduFormula_LinearityTest.rst @@ -6,7 +6,7 @@ ResiduFormula 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), + l'opérateur normalisé par sa valeur nominale, 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, diff --git a/doc/fr/snippets/SetSeed.rst b/doc/fr/snippets/SetSeed.rst index 6041c68..aa02c52 100644 --- a/doc/fr/snippets/SetSeed.rst +++ b/doc/fr/snippets/SetSeed.rst @@ -6,7 +6,7 @@ SetSeed graine est laissée non initialisée, et elle utilise ainsi l'initialisation par défaut de l'ordinateur, qui varie donc à chaque étude. Pour assurer la reproductibilité de résultats impliquant des tirages aléatoires, il est - fortement conseiller d'initialiser la graine. Une valeur simple est par + fortement conseillé d'initialiser la graine. Une valeur simple est par exemple 123456789. Il est conseillé de mettre un entier à plus de 6 ou 7 chiffres pour bien initialiser le générateur aléatoire. diff --git a/doc/fr/snippets/SimulatedObservationAtBackground.rst b/doc/fr/snippets/SimulatedObservationAtBackground.rst index 3971736..98d4b6e 100644 --- a/doc/fr/snippets/SimulatedObservationAtBackground.rst +++ b/doc/fr/snippets/SimulatedObservationAtBackground.rst @@ -4,7 +4,7 @@ SimulatedObservationAtBackground *Liste de vecteurs*. Chaque élément est un vecteur d'observation simulé par l'opérateur d'observation à partir de l'ébauche :math:`\mathbf{x}^b`. C'est - la prévision à partir de l'ébauche, elle est parfois appellée "*Dry*". + la prévision à partir de l'ébauche, elle est parfois appelée "*Dry*". Exemple : ``hxb = ADD.get("SimulatedObservationAtBackground")[-1]`` diff --git a/doc/fr/snippets/SimulatedObservationAtOptimum.rst b/doc/fr/snippets/SimulatedObservationAtOptimum.rst index 42ec326..b28b567 100644 --- a/doc/fr/snippets/SimulatedObservationAtOptimum.rst +++ b/doc/fr/snippets/SimulatedObservationAtOptimum.rst @@ -5,7 +5,7 @@ SimulatedObservationAtOptimum *Liste de vecteurs*. Chaque élément est un vecteur d'observation obtenu par l'opérateur d'observation à partir de la simulation d'analyse ou d'état optimal :math:`\mathbf{x}^a`. C'est l'observation de la prévision à partir de - l'analyse ou de l'état optimal, et elle est parfois appellée "*Forecast*". + l'analyse ou de l'état optimal, et elle est parfois appelée "*Forecast*". Exemple : ``hxa = ADD.get("SimulatedObservationAtOptimum")[-1]`` diff --git a/doc/fr/theory.rst b/doc/fr/theory.rst index 6da0912..5c4a9dc 100644 --- a/doc/fr/theory.rst +++ b/doc/fr/theory.rst @@ -79,7 +79,7 @@ algorithmes. Avant d'introduire la :ref:`section_theory_da_framework` dans une prochaine section, on décrit brièvement ces deux types d'applications. A la fin de ce chapitre, quelques informations permettent d'aller plus loin pour :ref:`section_theory_more_assimilation` et :ref:`section_theory_optimization`, -ainsi que pour :ref:`section_theory_dynamique` et avoir +ainsi que pour :ref:`section_theory_dynamic` et avoir :ref:`section_theory_reduction`. Reconstruction de champs ou interpolation de données @@ -326,7 +326,7 @@ et de "*Filtre de Kalman (KF)*" et leurs dérivés. Elles doivent alors prendre en compte un 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. On -se reportera à la section suivante pour :ref:`section_theory_dynamique`. De +se reportera à la section suivante pour :ref:`section_theory_dynamic`. De la même manière, ces méthodes peuvent aussi être utilisées dans le cas d'opérateurs d'observation ou d'évolution non linéaires. Un grand nombre de variantes ont été développées pour accroître la qualité numérique des méthodes @@ -645,7 +645,7 @@ la sélection éventuelle d'un critère de qualité : .. index:: single: Linf (QualityCriterion) .. math:: J(\mathbf{x})=||\mathbf{y}^o-\mathbf{H}.\mathbf{x}||_{L^{\infty}} -Ces mesures d'erreurs peuvent ne être pas différentiables comme pour les deux +Ces mesures d'erreurs peuvent ne pas être différentiables comme pour les deux dernières, mais certaines méthodes d'optimisation peuvent quand même les traiter : heuristiques et méta-heuristiques pour les problèmes à valeurs réelles, etc. Comme précédemment, les principaux désavantages de ces méthodes @@ -660,7 +660,7 @@ mentionne que quelques méthodes qui sont disponibles dans ADAO : Le lecteur intéressé par le sujet de l'optimisation pourra utilement commencer sa recherche grâce au point d'entrée [WikipediaMO]_. -.. _section_theory_dynamique: +.. _section_theory_dynamic: Approfondir l'assimilation de données pour la dynamique ------------------------------------------------------- @@ -853,15 +853,15 @@ représentation simple est la suivante, particulièrement adaptée aux algorithm itératifs de filtrage de type Kalman : .. _schema_d_AD_temporel: - .. image:: images/schema_temporel_KF.png + .. figure:: images/schema_temporel_KF.png :align: center :width: 100% - .. centered:: - **Schéma d'action des opérateurs pour l'assimilation de données en dynamique** + + **Schéma temporel d'action des opérateurs pour l'assimilation de données en dynamique** avec **P** la covariance d'erreur d'état et *t* le temps itératif discret. Dans ce schéma, l'analyse **(x,P)** est obtenue à travers la "*correction*" par l'observation de la "*prévision*" de l'état précédent. Les concepts décrits dans ce schéma peuvent directement et simplement être utilisés dans ADAO pour -construire des cas d'études, et sont repris dans la description de certains -algorithmes. +construire des cas d'études, et sont repris dans la description et les exemples +de certains algorithmes. diff --git a/doc/fr/tui.rst b/doc/fr/tui.rst index 89b0d30..d208203 100644 --- a/doc/fr/tui.rst +++ b/doc/fr/tui.rst @@ -98,7 +98,7 @@ quelconque, au choix de l'utilisateur : 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. +usage dans les commandes elles-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 commandes n'a pas d'importance, @@ -145,9 +145,9 @@ d'opérateur linéaire, on utilise la syntaxe suivante pour un opérateur de 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 -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 +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 diff --git a/doc/fr/tutorials_in_python.rst b/doc/fr/tutorials_in_python.rst index 8c05e97..6b265f5 100644 --- a/doc/fr/tutorials_in_python.rst +++ b/doc/fr/tutorials_in_python.rst @@ -41,7 +41,7 @@ présente ici toujours des scripts Python car ils sont directement insérables dans les définitions de script de l'interface Python, mais les fichiers externes peuvent utiliser d'autres langages. -Ces exemples sont intentionnellement décrits de manière semblables aux +Ces exemples sont intentionnellement décrits de manière semblable aux :ref:`section_tutorials_in_salome` car ils sont similaires à ceux que l'on peut traiter dans l'interface graphique SALOME. On peut d'ailleurs directement obtenir une forme scriptée d'un cas construit dans l'interface graphique à @@ -295,9 +295,9 @@ Dans la pratique, cette démarche par scripts est la manière la plus facile pou récupérer des informations 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 cas ADAO. +des données d'entrée, par exemple à des fins 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 cas ADAO. L'utilisateur doit vérifier avec soin le contenu de ses scripts.** diff --git a/doc/fr/tutorials_in_salome.rst b/doc/fr/tutorials_in_salome.rst index bca3804..6996815 100644 --- a/doc/fr/tutorials_in_salome.rst +++ b/doc/fr/tutorials_in_salome.rst @@ -52,7 +52,7 @@ le même cas, comment définir les données d'entrée à partir de sources exter directement insérables dans les noeuds de script de YACS, mais les fichiers externes peuvent utiliser d'autres langages. -Ces exemples sont intentionnellement décrits de manière semblables aux +Ces exemples sont intentionnellement décrits de manière semblable aux :ref:`section_tutorials_in_python` car ils sont similaires à ceux que l'on peut traiter dans l'interface textuelle Python (TUI). Les notations mathématiques utilisées ci-dessous sont expliquées dans la section :ref:`section_theory`. @@ -332,11 +332,11 @@ Dans la pratique, cette démarche par scripts est la manière la plus facile pou récupérer des informations 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 cas ADAO. +des données d'entrée, par exemple à des fins 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 cas ADAO. 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 @@ -561,8 +561,8 @@ linéaire tangent ``"TangentOperator"`` et linéaire adjoint 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. +détectées ou corrigées uniquement par l'environnement ADAO d'assimilation de +données et d'optimisation. Dans cet environnement d'expériences jumelles, l'observation :math:`\mathbf{y}^o` et sa matrice des covariances d'erreur :math:`\mathbf{R}` @@ -666,7 +666,7 @@ scripts n'est pas une procédure "sûre", en ce sens que des données erronées 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 le 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 diff --git a/src/daComposant/daAlgorithms/3DVAR.py b/src/daComposant/daAlgorithms/3DVAR.py index 10c1fe4..502e541 100644 --- a/src/daComposant/daAlgorithms/3DVAR.py +++ b/src/daComposant/daAlgorithms/3DVAR.py @@ -223,4 +223,4 @@ class ElementaryAlgorithm(BasicObjects.Algorithm): # ============================================================================== if __name__ == "__main__": - print('\n AUTODIAGNOSTIC\n') + print("\n AUTODIAGNOSTIC\n") diff --git a/src/daComposant/daAlgorithms/4DVAR.py b/src/daComposant/daAlgorithms/4DVAR.py index 514a0dd..73a6aed 100644 --- a/src/daComposant/daAlgorithms/4DVAR.py +++ b/src/daComposant/daAlgorithms/4DVAR.py @@ -161,4 +161,4 @@ class ElementaryAlgorithm(BasicObjects.Algorithm): # ============================================================================== if __name__ == "__main__": - print('\n AUTODIAGNOSTIC\n') + print("\n AUTODIAGNOSTIC\n") diff --git a/src/daComposant/daAlgorithms/AdjointTest.py b/src/daComposant/daAlgorithms/AdjointTest.py index 5962ee0..4d5679e 100644 --- a/src/daComposant/daAlgorithms/AdjointTest.py +++ b/src/daComposant/daAlgorithms/AdjointTest.py @@ -216,4 +216,4 @@ class ElementaryAlgorithm(BasicObjects.Algorithm): # ============================================================================== if __name__ == "__main__": - print('\n AUTODIAGNOSTIC\n') + print("\n AUTODIAGNOSTIC\n") diff --git a/src/daComposant/daAlgorithms/Blue.py b/src/daComposant/daAlgorithms/Blue.py index 9409ff7..4136722 100644 --- a/src/daComposant/daAlgorithms/Blue.py +++ b/src/daComposant/daAlgorithms/Blue.py @@ -151,4 +151,4 @@ class ElementaryAlgorithm(BasicObjects.Algorithm): # ============================================================================== if __name__ == "__main__": - print('\n AUTODIAGNOSTIC\n') + print("\n AUTODIAGNOSTIC\n") diff --git a/src/daComposant/daAlgorithms/ControledFunctionTest.py b/src/daComposant/daAlgorithms/ControledFunctionTest.py index d6597c1..e28d68e 100644 --- a/src/daComposant/daAlgorithms/ControledFunctionTest.py +++ b/src/daComposant/daAlgorithms/ControledFunctionTest.py @@ -265,4 +265,4 @@ class ElementaryAlgorithm(BasicObjects.Algorithm): # ============================================================================== if __name__ == "__main__": - print('\n AUTODIAGNOSTIC\n') + print("\n AUTODIAGNOSTIC\n") diff --git a/src/daComposant/daAlgorithms/DerivativeFreeOptimization.py b/src/daComposant/daAlgorithms/DerivativeFreeOptimization.py index 2f04da2..da60983 100644 --- a/src/daComposant/daAlgorithms/DerivativeFreeOptimization.py +++ b/src/daComposant/daAlgorithms/DerivativeFreeOptimization.py @@ -420,4 +420,4 @@ class ElementaryAlgorithm(BasicObjects.Algorithm): # ============================================================================== if __name__ == "__main__": - print('\n AUTODIAGNOSTIC\n') + print("\n AUTODIAGNOSTIC\n") diff --git a/src/daComposant/daAlgorithms/DifferentialEvolution.py b/src/daComposant/daAlgorithms/DifferentialEvolution.py index 814c526..ecf3cf8 100644 --- a/src/daComposant/daAlgorithms/DifferentialEvolution.py +++ b/src/daComposant/daAlgorithms/DifferentialEvolution.py @@ -286,4 +286,4 @@ class ElementaryAlgorithm(BasicObjects.Algorithm): # ============================================================================== if __name__ == "__main__": - print('\n AUTODIAGNOSTIC\n') + print("\n AUTODIAGNOSTIC\n") diff --git a/src/daComposant/daAlgorithms/EnsembleBlue.py b/src/daComposant/daAlgorithms/EnsembleBlue.py index 132a7e5..ca857ca 100644 --- a/src/daComposant/daAlgorithms/EnsembleBlue.py +++ b/src/daComposant/daAlgorithms/EnsembleBlue.py @@ -129,4 +129,4 @@ class ElementaryAlgorithm(BasicObjects.Algorithm): # ============================================================================== if __name__ == "__main__": - print('\n AUTODIAGNOSTIC\n') + print("\n AUTODIAGNOSTIC\n") diff --git a/src/daComposant/daAlgorithms/EnsembleKalmanFilter.py b/src/daComposant/daAlgorithms/EnsembleKalmanFilter.py index 232bdf9..52409e7 100644 --- a/src/daComposant/daAlgorithms/EnsembleKalmanFilter.py +++ b/src/daComposant/daAlgorithms/EnsembleKalmanFilter.py @@ -259,4 +259,4 @@ class ElementaryAlgorithm(BasicObjects.Algorithm): # ============================================================================== if __name__ == "__main__": - print('\n AUTODIAGNOSTIC\n') + print("\n AUTODIAGNOSTIC\n") diff --git a/src/daComposant/daAlgorithms/EnsembleOfSimulationGenerationTask.py b/src/daComposant/daAlgorithms/EnsembleOfSimulationGenerationTask.py index da04670..4f94c24 100644 --- a/src/daComposant/daAlgorithms/EnsembleOfSimulationGenerationTask.py +++ b/src/daComposant/daAlgorithms/EnsembleOfSimulationGenerationTask.py @@ -94,4 +94,4 @@ class ElementaryAlgorithm(BasicObjects.Algorithm): # ============================================================================== if __name__ == "__main__": - print('\n AUTODIAGNOSTIC\n') + print("\n AUTODIAGNOSTIC\n") diff --git a/src/daComposant/daAlgorithms/ExtendedBlue.py b/src/daComposant/daAlgorithms/ExtendedBlue.py index c9f3f7d..d89f6de 100644 --- a/src/daComposant/daAlgorithms/ExtendedBlue.py +++ b/src/daComposant/daAlgorithms/ExtendedBlue.py @@ -151,4 +151,4 @@ class ElementaryAlgorithm(BasicObjects.Algorithm): # ============================================================================== if __name__ == "__main__": - print('\n AUTODIAGNOSTIC\n') + print("\n AUTODIAGNOSTIC\n") diff --git a/src/daComposant/daAlgorithms/ExtendedKalmanFilter.py b/src/daComposant/daAlgorithms/ExtendedKalmanFilter.py index 3e555c3..068ff51 100644 --- a/src/daComposant/daAlgorithms/ExtendedKalmanFilter.py +++ b/src/daComposant/daAlgorithms/ExtendedKalmanFilter.py @@ -135,4 +135,4 @@ class ElementaryAlgorithm(BasicObjects.Algorithm): # ============================================================================== if __name__ == "__main__": - print('\n AUTODIAGNOSTIC\n') + print("\n AUTODIAGNOSTIC\n") diff --git a/src/daComposant/daAlgorithms/FunctionTest.py b/src/daComposant/daAlgorithms/FunctionTest.py index 4f82588..0ced726 100644 --- a/src/daComposant/daAlgorithms/FunctionTest.py +++ b/src/daComposant/daAlgorithms/FunctionTest.py @@ -243,4 +243,4 @@ class ElementaryAlgorithm(BasicObjects.Algorithm): # ============================================================================== if __name__ == "__main__": - print('\n AUTODIAGNOSTIC\n') + print("\n AUTODIAGNOSTIC\n") diff --git a/src/daComposant/daAlgorithms/GradientTest.py b/src/daComposant/daAlgorithms/GradientTest.py index 3c97c55..99b4ad1 100644 --- a/src/daComposant/daAlgorithms/GradientTest.py +++ b/src/daComposant/daAlgorithms/GradientTest.py @@ -403,4 +403,4 @@ def dessiner( # ============================================================================== if __name__ == "__main__": - print('\n AUTODIAGNOSTIC\n') + print("\n AUTODIAGNOSTIC\n") diff --git a/src/daComposant/daAlgorithms/InputValuesTest.py b/src/daComposant/daAlgorithms/InputValuesTest.py index 9564527..b152e25 100644 --- a/src/daComposant/daAlgorithms/InputValuesTest.py +++ b/src/daComposant/daAlgorithms/InputValuesTest.py @@ -126,4 +126,4 @@ class ElementaryAlgorithm(BasicObjects.Algorithm): # ============================================================================== if __name__ == "__main__": - print('\n AUTODIAGNOSTIC\n') + print("\n AUTODIAGNOSTIC\n") diff --git a/src/daComposant/daAlgorithms/InterpolationByReducedModelTask.py b/src/daComposant/daAlgorithms/InterpolationByReducedModelTask.py index fc25688..2cc8039 100644 --- a/src/daComposant/daAlgorithms/InterpolationByReducedModelTask.py +++ b/src/daComposant/daAlgorithms/InterpolationByReducedModelTask.py @@ -106,4 +106,4 @@ class ElementaryAlgorithm(BasicObjects.Algorithm): # ============================================================================== if __name__ == "__main__": - print('\n AUTODIAGNOSTIC\n') + print("\n AUTODIAGNOSTIC\n") diff --git a/src/daComposant/daAlgorithms/InterpolationByReducedModelTest.py b/src/daComposant/daAlgorithms/InterpolationByReducedModelTest.py index 2b371a5..f764d01 100644 --- a/src/daComposant/daAlgorithms/InterpolationByReducedModelTest.py +++ b/src/daComposant/daAlgorithms/InterpolationByReducedModelTest.py @@ -187,4 +187,4 @@ class ElementaryAlgorithm(BasicObjects.Algorithm): # ============================================================================== if __name__ == "__main__": - print('\n AUTODIAGNOSTIC\n') + print("\n AUTODIAGNOSTIC\n") diff --git a/src/daComposant/daAlgorithms/KalmanFilter.py b/src/daComposant/daAlgorithms/KalmanFilter.py index a1633d7..2087a69 100644 --- a/src/daComposant/daAlgorithms/KalmanFilter.py +++ b/src/daComposant/daAlgorithms/KalmanFilter.py @@ -114,4 +114,4 @@ class ElementaryAlgorithm(BasicObjects.Algorithm): # ============================================================================== if __name__ == "__main__": - print('\n AUTODIAGNOSTIC\n') + print("\n AUTODIAGNOSTIC\n") diff --git a/src/daComposant/daAlgorithms/LinearLeastSquares.py b/src/daComposant/daAlgorithms/LinearLeastSquares.py index 278e7f2..195a4c0 100644 --- a/src/daComposant/daAlgorithms/LinearLeastSquares.py +++ b/src/daComposant/daAlgorithms/LinearLeastSquares.py @@ -106,4 +106,4 @@ class ElementaryAlgorithm(BasicObjects.Algorithm): # ============================================================================== if __name__ == "__main__": - print('\n AUTODIAGNOSTIC\n') + print("\n AUTODIAGNOSTIC\n") diff --git a/src/daComposant/daAlgorithms/LinearityTest.py b/src/daComposant/daAlgorithms/LinearityTest.py index eae562f..a151f55 100644 --- a/src/daComposant/daAlgorithms/LinearityTest.py +++ b/src/daComposant/daAlgorithms/LinearityTest.py @@ -354,4 +354,4 @@ class ElementaryAlgorithm(BasicObjects.Algorithm): # ============================================================================== if __name__ == "__main__": - print('\n AUTODIAGNOSTIC\n') + print("\n AUTODIAGNOSTIC\n") diff --git a/src/daComposant/daAlgorithms/LocalSensitivityTest.py b/src/daComposant/daAlgorithms/LocalSensitivityTest.py index 89f5962..e939b08 100644 --- a/src/daComposant/daAlgorithms/LocalSensitivityTest.py +++ b/src/daComposant/daAlgorithms/LocalSensitivityTest.py @@ -91,4 +91,4 @@ class ElementaryAlgorithm(BasicObjects.Algorithm): # ============================================================================== if __name__ == "__main__": - print('\n AUTODIAGNOSTIC\n') + print("\n AUTODIAGNOSTIC\n") diff --git a/src/daComposant/daAlgorithms/MeasurementsOptimalPositioningTask.py b/src/daComposant/daAlgorithms/MeasurementsOptimalPositioningTask.py index 2e08abe..f434b4c 100644 --- a/src/daComposant/daAlgorithms/MeasurementsOptimalPositioningTask.py +++ b/src/daComposant/daAlgorithms/MeasurementsOptimalPositioningTask.py @@ -192,4 +192,4 @@ class ElementaryAlgorithm(BasicObjects.Algorithm): # ============================================================================== if __name__ == "__main__": - print('\n AUTODIAGNOSTIC\n') + print("\n AUTODIAGNOSTIC\n") diff --git a/src/daComposant/daAlgorithms/NonLinearLeastSquares.py b/src/daComposant/daAlgorithms/NonLinearLeastSquares.py index 8292632..c5aebb8 100644 --- a/src/daComposant/daAlgorithms/NonLinearLeastSquares.py +++ b/src/daComposant/daAlgorithms/NonLinearLeastSquares.py @@ -168,4 +168,4 @@ class ElementaryAlgorithm(BasicObjects.Algorithm): # ============================================================================== if __name__ == "__main__": - print('\n AUTODIAGNOSTIC\n') + print("\n AUTODIAGNOSTIC\n") diff --git a/src/daComposant/daAlgorithms/ObservationSimulationComparisonTest.py b/src/daComposant/daAlgorithms/ObservationSimulationComparisonTest.py index bff5def..f109bbd 100644 --- a/src/daComposant/daAlgorithms/ObservationSimulationComparisonTest.py +++ b/src/daComposant/daAlgorithms/ObservationSimulationComparisonTest.py @@ -362,4 +362,4 @@ class ElementaryAlgorithm(BasicObjects.Algorithm): # ============================================================================== if __name__ == "__main__": - print('\n AUTODIAGNOSTIC\n') + print("\n AUTODIAGNOSTIC\n") diff --git a/src/daComposant/daAlgorithms/ObserverTest.py b/src/daComposant/daAlgorithms/ObserverTest.py index 1e68d87..669b2d3 100644 --- a/src/daComposant/daAlgorithms/ObserverTest.py +++ b/src/daComposant/daAlgorithms/ObserverTest.py @@ -79,4 +79,4 @@ class ElementaryAlgorithm(BasicObjects.Algorithm): # ============================================================================== if __name__ == "__main__": - print('\n AUTODIAGNOSTIC\n') + print("\n AUTODIAGNOSTIC\n") diff --git a/src/daComposant/daAlgorithms/ParallelFunctionTest.py b/src/daComposant/daAlgorithms/ParallelFunctionTest.py index f4a5116..cc4ae0c 100644 --- a/src/daComposant/daAlgorithms/ParallelFunctionTest.py +++ b/src/daComposant/daAlgorithms/ParallelFunctionTest.py @@ -260,4 +260,4 @@ class ElementaryAlgorithm(BasicObjects.Algorithm): # ============================================================================== if __name__ == "__main__": - print('\n AUTODIAGNOSTIC\n') + print("\n AUTODIAGNOSTIC\n") diff --git a/src/daComposant/daAlgorithms/ParticleSwarmOptimization.py b/src/daComposant/daAlgorithms/ParticleSwarmOptimization.py index bfb5a38..1a9c8f5 100644 --- a/src/daComposant/daAlgorithms/ParticleSwarmOptimization.py +++ b/src/daComposant/daAlgorithms/ParticleSwarmOptimization.py @@ -215,4 +215,4 @@ class ElementaryAlgorithm(BasicObjects.Algorithm): # ============================================================================== if __name__ == "__main__": - print('\n AUTODIAGNOSTIC\n') + print("\n AUTODIAGNOSTIC\n") diff --git a/src/daComposant/daAlgorithms/QuantileRegression.py b/src/daComposant/daAlgorithms/QuantileRegression.py index 6cee1b6..b483d8f 100644 --- a/src/daComposant/daAlgorithms/QuantileRegression.py +++ b/src/daComposant/daAlgorithms/QuantileRegression.py @@ -183,4 +183,4 @@ class ElementaryAlgorithm(BasicObjects.Algorithm): # ============================================================================== if __name__ == "__main__": - print('\n AUTODIAGNOSTIC\n') + print("\n AUTODIAGNOSTIC\n") diff --git a/src/daComposant/daAlgorithms/SamplingTest.py b/src/daComposant/daAlgorithms/SamplingTest.py index 1b96a78..9c7304c 100644 --- a/src/daComposant/daAlgorithms/SamplingTest.py +++ b/src/daComposant/daAlgorithms/SamplingTest.py @@ -196,4 +196,4 @@ class ElementaryAlgorithm(BasicObjects.Algorithm): # ============================================================================== if __name__ == "__main__": - print('\n AUTODIAGNOSTIC\n') + print("\n AUTODIAGNOSTIC\n") diff --git a/src/daComposant/daAlgorithms/TabuSearch.py b/src/daComposant/daAlgorithms/TabuSearch.py index 7eab87e..20254a1 100644 --- a/src/daComposant/daAlgorithms/TabuSearch.py +++ b/src/daComposant/daAlgorithms/TabuSearch.py @@ -276,4 +276,4 @@ class ElementaryAlgorithm(BasicObjects.Algorithm): # ============================================================================== if __name__ == "__main__": - print('\n AUTODIAGNOSTIC\n') + print("\n AUTODIAGNOSTIC\n") diff --git a/src/daComposant/daAlgorithms/TangentTest.py b/src/daComposant/daAlgorithms/TangentTest.py index 6972d8f..a61c55e 100644 --- a/src/daComposant/daAlgorithms/TangentTest.py +++ b/src/daComposant/daAlgorithms/TangentTest.py @@ -229,4 +229,4 @@ class ElementaryAlgorithm(BasicObjects.Algorithm): # ============================================================================== if __name__ == "__main__": - print('\n AUTODIAGNOSTIC\n') + print("\n AUTODIAGNOSTIC\n") diff --git a/src/daComposant/daAlgorithms/UnscentedKalmanFilter.py b/src/daComposant/daAlgorithms/UnscentedKalmanFilter.py index 3c707d5..79ebf8f 100644 --- a/src/daComposant/daAlgorithms/UnscentedKalmanFilter.py +++ b/src/daComposant/daAlgorithms/UnscentedKalmanFilter.py @@ -156,4 +156,4 @@ class ElementaryAlgorithm(BasicObjects.Algorithm): # ============================================================================== if __name__ == "__main__": - print('\n AUTODIAGNOSTIC\n') + print("\n AUTODIAGNOSTIC\n") diff --git a/src/daComposant/daCore/Aidsm.py b/src/daComposant/daCore/Aidsm.py index 7e5d913..f581670 100644 --- a/src/daComposant/daCore/Aidsm.py +++ b/src/daComposant/daCore/Aidsm.py @@ -875,4 +875,4 @@ class Aidsm(object): # ============================================================================== if __name__ == "__main__": - print('\n AUTODIAGNOSTIC\n') + print("\n AUTODIAGNOSTIC\n") diff --git a/src/daComposant/daCore/AssimilationStudy.py b/src/daComposant/daCore/AssimilationStudy.py index 3ac26ad..4fb85f2 100644 --- a/src/daComposant/daCore/AssimilationStudy.py +++ b/src/daComposant/daCore/AssimilationStudy.py @@ -40,4 +40,4 @@ class AssimilationStudy(_Aidsm): # ============================================================================== if __name__ == "__main__": - print('\n AUTODIAGNOSTIC\n') + print("\n AUTODIAGNOSTIC\n") diff --git a/src/daComposant/daCore/BasicObjects.py b/src/daComposant/daCore/BasicObjects.py index 276f87a..ce6314f 100644 --- a/src/daComposant/daCore/BasicObjects.py +++ b/src/daComposant/daCore/BasicObjects.py @@ -2560,4 +2560,4 @@ def MultiFonction( # ============================================================================== if __name__ == "__main__": - print('\n AUTODIAGNOSTIC\n') + print("\n AUTODIAGNOSTIC\n") diff --git a/src/daComposant/daCore/ExtendedLogging.py b/src/daComposant/daCore/ExtendedLogging.py index 02bfaf4..a3f8595 100644 --- a/src/daComposant/daCore/ExtendedLogging.py +++ b/src/daComposant/daCore/ExtendedLogging.py @@ -181,4 +181,4 @@ def logtimer(f): # ============================================================================== if __name__ == "__main__": - print('\n AUTODIAGNOSTIC\n') + print("\n AUTODIAGNOSTIC\n") diff --git a/src/daComposant/daCore/Interfaces.py b/src/daComposant/daCore/Interfaces.py index 0dbfbf4..3b65b80 100644 --- a/src/daComposant/daCore/Interfaces.py +++ b/src/daComposant/daCore/Interfaces.py @@ -1323,4 +1323,4 @@ class EficasGUI(object): # ============================================================================== if __name__ == "__main__": - print('\n AUTODIAGNOSTIC\n') + print("\n AUTODIAGNOSTIC\n") diff --git a/src/daComposant/daCore/NumericObjects.py b/src/daComposant/daCore/NumericObjects.py index d14db9d..429cf14 100644 --- a/src/daComposant/daCore/NumericObjects.py +++ b/src/daComposant/daCore/NumericObjects.py @@ -1169,4 +1169,4 @@ def multiXOsteps(selfA, Xb, Y, U, HO, EM, CM, R, B, Q, oneCycle, # ============================================================================== if __name__ == "__main__": - print('\n AUTODIAGNOSTIC\n') + print("\n AUTODIAGNOSTIC\n") diff --git a/src/daComposant/daCore/Persistence.py b/src/daComposant/daCore/Persistence.py index ff5709f..930918b 100644 --- a/src/daComposant/daCore/Persistence.py +++ b/src/daComposant/daCore/Persistence.py @@ -1062,4 +1062,4 @@ class CompositePersistence(object): # ============================================================================== if __name__ == "__main__": - print('\n AUTODIAGNOSTIC\n') + print("\n AUTODIAGNOSTIC\n") diff --git a/src/daComposant/daCore/PlatformInfo.py b/src/daComposant/daCore/PlatformInfo.py index 6bfcbbe..8f1db00 100644 --- a/src/daComposant/daCore/PlatformInfo.py +++ b/src/daComposant/daCore/PlatformInfo.py @@ -566,4 +566,4 @@ class SystemUsage(object): # ============================================================================== if __name__ == "__main__": - print('\n AUTODIAGNOSTIC\n') + print("\n AUTODIAGNOSTIC\n") diff --git a/src/daComposant/daCore/Reporting.py b/src/daComposant/daCore/Reporting.py index f724d16..22cd12b 100644 --- a/src/daComposant/daCore/Reporting.py +++ b/src/daComposant/daCore/Reporting.py @@ -307,4 +307,4 @@ ReportStorage = __ReportC__ # ============================================================================== if __name__ == "__main__": - print('\n AUTODIAGNOSTIC\n') + print("\n AUTODIAGNOSTIC\n") diff --git a/src/daComposant/daCore/Templates.py b/src/daComposant/daCore/Templates.py index 7e0e830..0a318c9 100644 --- a/src/daComposant/daCore/Templates.py +++ b/src/daComposant/daCore/Templates.py @@ -271,4 +271,4 @@ UserPostAnalysisTemplates.store( # ============================================================================== if __name__ == "__main__": - print('\n AUTODIAGNOSTIC\n') + print("\n AUTODIAGNOSTIC\n")