files pair, which resides in ``<ADAO JDC file directory>``) 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 ``<SALOME main installation dir>`` 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
``<ADAO Python file>`` in the template, and it is converted to YACS as an
``<ADAO YACS xml scheme>`` as a ".xml" file named "AdaoStudy1.xml". After that,
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="<ADAO JDC file directory>"
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 ``<SALOME main installation directory>``, 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 ``<SALOME main installation directory>``, one needs only to save the
following Shell script::
#!/bin/bash
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
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:
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:
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)
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).
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
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
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
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
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
.. 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:
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]
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
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.
* *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.
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:
*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
*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
*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
*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
*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
*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
*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
*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
(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
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.
*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
*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
*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
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
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
*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
*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
*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
*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
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
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
*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
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`.
*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
*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
*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
*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
*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
*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
*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
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
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
*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
*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
*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
*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
*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
(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
*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
.. _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
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
- ``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
- ``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
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.
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.
.. _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
+++++++++++++++++++++++++++++++++++++++++++++++++++++
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.
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.
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.
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"<section_ref_algorithm_MeasurementsOptimalPositioningTask_examples>`.
-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.
+++++++++++++++++++++++++
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`.
*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 :
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
.. 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
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
- 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`,
.. 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}`
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
-----------------------------------------------
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.
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
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
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
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é ``<Fichier Python
+automatiquement créé dans le même répertoire. Il est nommé ``<Fichier Python
ADAO>`` dans le modèle "type", et il est converti vers YACS comme un ``<Schéma
xml YACS ADAO>`` 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
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 :
::
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
: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.
* *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.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
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.
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
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.
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.
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
(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
pair: Variant ; MLEF
pair: Variant ; IEnKF
pair: Variant ; E3DVAR
+ pair: Variant ; 3D-Var-Ben
pair: Variant ; EnKS
pair: Variant ; EnSRKF
pair: Variant ; RRSQRT
- "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
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
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
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*).
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.
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
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
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}`
(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
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 :
::
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]
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
...
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*"
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
.. 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}'
.. 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
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
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
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
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.
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
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.
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.
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"<section_ref_algorithm_MeasurementsOptimalPositioningTask_examples>`.
-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.
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.
*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.
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.
++++++++++++++++++++++++++++++++++++++
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`.
+
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,
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.
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]``
*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]``
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
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
.. 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
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
-------------------------------------------------------
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.
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,
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
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 à
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.**
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`.
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
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}`
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
# ==============================================================================
if __name__ == "__main__":
- print('\n AUTODIAGNOSTIC\n')
+ print("\n AUTODIAGNOSTIC\n")
# ==============================================================================
if __name__ == "__main__":
- print('\n AUTODIAGNOSTIC\n')
+ print("\n AUTODIAGNOSTIC\n")
# ==============================================================================
if __name__ == "__main__":
- print('\n AUTODIAGNOSTIC\n')
+ print("\n AUTODIAGNOSTIC\n")
# ==============================================================================
if __name__ == "__main__":
- print('\n AUTODIAGNOSTIC\n')
+ print("\n AUTODIAGNOSTIC\n")
# ==============================================================================
if __name__ == "__main__":
- print('\n AUTODIAGNOSTIC\n')
+ print("\n AUTODIAGNOSTIC\n")
# ==============================================================================
if __name__ == "__main__":
- print('\n AUTODIAGNOSTIC\n')
+ print("\n AUTODIAGNOSTIC\n")
# ==============================================================================
if __name__ == "__main__":
- print('\n AUTODIAGNOSTIC\n')
+ print("\n AUTODIAGNOSTIC\n")
# ==============================================================================
if __name__ == "__main__":
- print('\n AUTODIAGNOSTIC\n')
+ print("\n AUTODIAGNOSTIC\n")
# ==============================================================================
if __name__ == "__main__":
- print('\n AUTODIAGNOSTIC\n')
+ print("\n AUTODIAGNOSTIC\n")
# ==============================================================================
if __name__ == "__main__":
- print('\n AUTODIAGNOSTIC\n')
+ print("\n AUTODIAGNOSTIC\n")
# ==============================================================================
if __name__ == "__main__":
- print('\n AUTODIAGNOSTIC\n')
+ print("\n AUTODIAGNOSTIC\n")
# ==============================================================================
if __name__ == "__main__":
- print('\n AUTODIAGNOSTIC\n')
+ print("\n AUTODIAGNOSTIC\n")
# ==============================================================================
if __name__ == "__main__":
- print('\n AUTODIAGNOSTIC\n')
+ print("\n AUTODIAGNOSTIC\n")
# ==============================================================================
if __name__ == "__main__":
- print('\n AUTODIAGNOSTIC\n')
+ print("\n AUTODIAGNOSTIC\n")
# ==============================================================================
if __name__ == "__main__":
- print('\n AUTODIAGNOSTIC\n')
+ print("\n AUTODIAGNOSTIC\n")
# ==============================================================================
if __name__ == "__main__":
- print('\n AUTODIAGNOSTIC\n')
+ print("\n AUTODIAGNOSTIC\n")
# ==============================================================================
if __name__ == "__main__":
- print('\n AUTODIAGNOSTIC\n')
+ print("\n AUTODIAGNOSTIC\n")
# ==============================================================================
if __name__ == "__main__":
- print('\n AUTODIAGNOSTIC\n')
+ print("\n AUTODIAGNOSTIC\n")
# ==============================================================================
if __name__ == "__main__":
- print('\n AUTODIAGNOSTIC\n')
+ print("\n AUTODIAGNOSTIC\n")
# ==============================================================================
if __name__ == "__main__":
- print('\n AUTODIAGNOSTIC\n')
+ print("\n AUTODIAGNOSTIC\n")
# ==============================================================================
if __name__ == "__main__":
- print('\n AUTODIAGNOSTIC\n')
+ print("\n AUTODIAGNOSTIC\n")
# ==============================================================================
if __name__ == "__main__":
- print('\n AUTODIAGNOSTIC\n')
+ print("\n AUTODIAGNOSTIC\n")
# ==============================================================================
if __name__ == "__main__":
- print('\n AUTODIAGNOSTIC\n')
+ print("\n AUTODIAGNOSTIC\n")
# ==============================================================================
if __name__ == "__main__":
- print('\n AUTODIAGNOSTIC\n')
+ print("\n AUTODIAGNOSTIC\n")
# ==============================================================================
if __name__ == "__main__":
- print('\n AUTODIAGNOSTIC\n')
+ print("\n AUTODIAGNOSTIC\n")
# ==============================================================================
if __name__ == "__main__":
- print('\n AUTODIAGNOSTIC\n')
+ print("\n AUTODIAGNOSTIC\n")
# ==============================================================================
if __name__ == "__main__":
- print('\n AUTODIAGNOSTIC\n')
+ print("\n AUTODIAGNOSTIC\n")
# ==============================================================================
if __name__ == "__main__":
- print('\n AUTODIAGNOSTIC\n')
+ print("\n AUTODIAGNOSTIC\n")
# ==============================================================================
if __name__ == "__main__":
- print('\n AUTODIAGNOSTIC\n')
+ print("\n AUTODIAGNOSTIC\n")
# ==============================================================================
if __name__ == "__main__":
- print('\n AUTODIAGNOSTIC\n')
+ print("\n AUTODIAGNOSTIC\n")
# ==============================================================================
if __name__ == "__main__":
- print('\n AUTODIAGNOSTIC\n')
+ print("\n AUTODIAGNOSTIC\n")
# ==============================================================================
if __name__ == "__main__":
- print('\n AUTODIAGNOSTIC\n')
+ print("\n AUTODIAGNOSTIC\n")
# ==============================================================================
if __name__ == "__main__":
- print('\n AUTODIAGNOSTIC\n')
+ print("\n AUTODIAGNOSTIC\n")
# ==============================================================================
if __name__ == "__main__":
- print('\n AUTODIAGNOSTIC\n')
+ print("\n AUTODIAGNOSTIC\n")
# ==============================================================================
if __name__ == "__main__":
- print('\n AUTODIAGNOSTIC\n')
+ print("\n AUTODIAGNOSTIC\n")
# ==============================================================================
if __name__ == "__main__":
- print('\n AUTODIAGNOSTIC\n')
+ print("\n AUTODIAGNOSTIC\n")
# ==============================================================================
if __name__ == "__main__":
- print('\n AUTODIAGNOSTIC\n')
+ print("\n AUTODIAGNOSTIC\n")
# ==============================================================================
if __name__ == "__main__":
- print('\n AUTODIAGNOSTIC\n')
+ print("\n AUTODIAGNOSTIC\n")
# ==============================================================================
if __name__ == "__main__":
- print('\n AUTODIAGNOSTIC\n')
+ print("\n AUTODIAGNOSTIC\n")
# ==============================================================================
if __name__ == "__main__":
- print('\n AUTODIAGNOSTIC\n')
+ print("\n AUTODIAGNOSTIC\n")
# ==============================================================================
if __name__ == "__main__":
- print('\n AUTODIAGNOSTIC\n')
+ print("\n AUTODIAGNOSTIC\n")
# ==============================================================================
if __name__ == "__main__":
- print('\n AUTODIAGNOSTIC\n')
+ print("\n AUTODIAGNOSTIC\n")
