Salome HOME
Updating copyright date information
[modules/adao.git] / doc / en / examples.rst
index 2485285dbb38aa460b6ac9baf780da5070e8b598..2268edef9b4c7fc921778757ab7a535c679e69e7 100644 (file)
@@ -1,7 +1,30 @@
+..
+   Copyright (C) 2008-2016 EDF R&D
+
+   This file is part of SALOME ADAO module.
+
+   This library is free software; you can redistribute it and/or
+   modify it under the terms of the GNU Lesser General Public
+   License as published by the Free Software Foundation; either
+   version 2.1 of the License, or (at your option) any later version.
+
+   This library is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+   Lesser General Public License for more details.
+
+   You should have received a copy of the GNU Lesser General Public
+   License along with this library; if not, write to the Free Software
+   Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307 USA
+
+   See http://www.salome-platform.org/ or email : webmaster.salome@opencascade.com
+
+   Author: Jean-Philippe Argaud, jean-philippe.argaud@edf.fr, EDF R&D
+
 .. _section_examples:
 
 ================================================================================
-Tutorials on using the ADAO module
+**[DocU]** Tutorials on using the ADAO module
 ================================================================================
 
 .. |eficas_new| image:: images/eficas_new.png
@@ -22,7 +45,7 @@ first one shows how to build a simple data assimilation case defining explicitly
 all the required input data through the GUI. The second one shows, on the same
 case, how to define input data using external sources through scripts. We
 describe here always Python scripts because they can be directly inserted in
-YACS script nodes, but external files can use other langages.
+YACS script nodes, but external files can use other languages.
 
 The mathematical notations used afterward are explained in the section
 :ref:`section_theory`.
@@ -31,10 +54,10 @@ Building an estimation case with explicit data definition
 ---------------------------------------------------------
 
 This simple example is a demonstration one, and describes how to set a BLUE
-estimation framework in order to get *ponderated (or fully weighted) least
-square estimated state* of a system from an observation of the state and from an
-*a priori* knowledge (or background) of this state. In other words, we look for
-the weighted middle between the observation and the background vectors. All the
+estimation framework in order to get the *fully weighted least square estimated
+state* of a system from an observation of the state and from an *a priori*
+knowledge (or background) of this state. In other words, we look for the
+weighted middle between the observation and the background vectors. All the
 numerical values of this example are arbitrary.
 
 Experimental setup
@@ -42,7 +65,7 @@ Experimental setup
 
 We choose to operate in a 3-dimensional space. 3D is chosen in order to restrict
 the size of numerical object to explicitly enter by the user, but the problem is
-not dependant of the dimension and can be set in dimension 10, 100, 1000... The
+not dependent of the dimension and can be set in dimension 10, 100, 1000... The
 observation :math:`\mathbf{y}^o` is of value 1 in each direction, so::
 
     Yo = [1 1 1]
@@ -94,17 +117,17 @@ button or menu of SALOME, and you will see:
   .. centered::
     **Activating the module ADAO in SALOME**
 
-Choose the "*New*" button in this window. You will directly get the EFICAS
-interface for variables definition, along with the SALOME "*Object browser*".
-You can then click on the "*New*" button |eficas_new| to create a new ADAO case,
-and you will see:
+Choose the "*New*" button in this window. You will directly get the embedded
+case editor interface for variables definition, along with the SALOME "*Object
+browser*". You can then click on the "*New*" button |eficas_new| to create a new
+ADAO case, and you will see:
 
   .. _adao_viewer:
   .. image:: images/adao_viewer.png
     :align: center
     :width: 100%
   .. centered::
-    **The EFICAS editor for cases definition in module ADAO**
+    **The embedded editor for cases definition in module ADAO**
 
 Then, fill in the variables to build the ADAO case by using the experimental set
 up described above. All the technical information given above will be directly
@@ -279,17 +302,19 @@ some input data, for example for debug purpose or for repetitive execution
 process, and it is the most versatile method in order to parametrize the input
 data. **But be careful, script methodology is not a "safe" procedure, in the
 sense that erroneous data, or errors in calculations, can be directly injected
-into the YACS scheme execution.**
+into the YACS scheme execution. The user have to carefully verify the content of
+his scripts.**
 
 Adding parameters to control the data assimilation algorithm
 ------------------------------------------------------------
 
 One can add some optional parameters to control the data assimilation algorithm
-calculation. This is done by using the "*AlgorithmParameters*" keyword in the
-definition of the ADAO case, which is an keyword of the "*ASSIMILATION_STUDY*"
-general command. This keyword requires a Python dictionary, containing some
-key/value pairs. The list of possible optional parameters are given in the
-subsection :ref:`section_reference`.
+calculation. This is done by using optional parameters in the
+"*AlgorithmParameters*" command of the ADAO case definition, which is a keyword of
+the "*ASSIMILATION_STUDY*" general command. This keyword requires an explicit
+definition of the values or a Python dictionary, containing some key/value
+pairs. The list of possible optional parameters are given in the section
+:ref:`section_reference` and its subsections.
 
 This dictionary has to be defined, for example, in an external Python script
 file, using the mandatory variable name "*AlgorithmParameters*" for the
@@ -302,10 +327,10 @@ default values, and can exist without being used. For example::
         }
 
 If no bounds at all are required on the control variables, then one can choose
-the "*BFGS*" or "*CG*" minimisation algorithm for all the variational data
+the "*BFGS*" or "*CG*" minimization algorithm for all the variational data
 assimilation or optimization algorithms. For constrained optimization, the
 minimizer "*LBFGSB*" is often more robust, but the "*TNC*" is sometimes more
-performant.
+effective.
 
 Then the script can be added to the ADAO case, in a file entry describing the
 "*AlgorithmParameters*" keyword, as follows:
@@ -379,13 +404,13 @@ and, with an arbitrary standard deviation of 1% on each error component::
 
     R = 0.0001 * diagonal( lenght(Yo) )
 
-All the informations required for estimation by data assimilation are then
+All the information required for estimation by data assimilation are then
 defined.
 
 Skeletons of the scripts describing the setup
 +++++++++++++++++++++++++++++++++++++++++++++
 
-We give here the essential parts of each script used afterwards to build the
+We give here the essential parts of each script used afterward to build the
 ADAO case. Remember that using these scripts in real Python files requires to
 correctly define the path to imported modules or codes (even if the module is in
 the same directory that the importing Python file. We indicate the path
@@ -471,7 +496,7 @@ convenience::
         #
         return numpy.array( HX )
 
-We does not need the linear compagnion operators ``"TangentOperator"`` and
+We does not need the linear companion operators ``"TangentOperator"`` and
 ``"AdjointOperator"`` because they will be approximated using ADAO capabilities.
 
 We insist on the fact that these non-linear operator ``"DirectOperator"``,
@@ -532,7 +557,7 @@ the following parameters can be defined in a Python script file named
 Finally, it is common to post-process the results, retrieving them after the
 data assimilation phase in order to analyze, print or show them. It requires to
 use a intermediary Python script file in order to extract these results at the
-end of the adata assimilation or optimization process. The following example
+end of the a data assimilation or optimization process. The following example
 Python script file, named ``Script_UserPostAnalysis.py``, illustrates the fact::
 
     from Physical_data_and_covariance_matrices import True_state
@@ -612,4 +637,4 @@ The state at the first step is the randomly generated background state
 available in the "*YACS Container Log*" window, obtained through the right click
 menu of the "*proc*" window in the YACS executed scheme.
 
-.. [#] For more information on YACS, see the *YACS module User's Guide* available in the main "*Help*" menu of SALOME platform.
+.. [#] For more information on YACS, see the *YACS module* and its integrated help available from the main menu *Help* of the SALOME platform.