Salome HOME
Updating copyright date information
[modules/adao.git] / doc / en / ref_operator_requirements.rst
index faa63c343ddd2fe349f85a6d71107be07f0b892e..fb3b6c5db138f3874248b838fef05cc681430838 100644 (file)
@@ -1,5 +1,5 @@
 ..
-   Copyright (C) 2008-2015 EDF R&D
+   Copyright (C) 2008-2017 EDF R&D
 
    This file is part of SALOME ADAO module.
 
@@ -102,7 +102,11 @@ adjoint operators. The finite differences approximation order can also be chosen
 through the GUI, using the keyword "*CenteredFiniteDifference*", with 0 for an
 uncentered schema of first order (which is the default value), and with 1 for a
 centered schema of second order (of twice the first order computational cost).
-If necessary and if possible, :ref:`subsection_ref_parallel_df` can be used.
+If necessary and if possible, :ref:`subsection_ref_parallel_df` can be used. In
+all cases, an internal cache mechanism is used to restrict the number of
+operator evaluations at the minimum possible in a sequential or parallel
+execution scheme for numerical approximations of the tangent and adjoint
+operators, to avoid redundant calculations.
 
 This first operator definition form allows easily to test the functional form
 before its use in an ADAO case, greatly reducing the complexity of operator
@@ -244,8 +248,10 @@ Here is the switch template::
 
 All various modifications could be done from this template hypothesis.
 
-Special case of controlled evolution or observation operator
-++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+.. _section_ref_operator_control:
+
+Special case of controled evolution or observation operator
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 
 In some cases, the evolution or the observation operator is required to be
 controlled by an external input control, given *a priori*. In this case, the
@@ -269,3 +275,34 @@ that the derivatives has to be done only partially against :math:`\mathbf{x}`.
 In such a case with explicit control, only the second functional form (using
 "*ScriptWithFunctions*") and third functional form (using "*ScriptWithSwitch*")
 can be used.
+
+Additional notes on nondimensionalization of operators
+++++++++++++++++++++++++++++++++++++++++++++++++++++++
+
+.. index:: single: Nondimensionalization
+.. index:: single: Dimensionless
+
+It is common that physical quantities, in input or output of the operators, have
+significant differences in magnitude or rate of change. One way to avoid
+numerical difficulties is to use, or to set, a nondimensionalization of the
+calculations carried out in operators [WikipediaND]_. In principle, since
+physical simulation should be as dimensionless as possible, it is firstly
+recommended to use the existing capacity of nondimensionalization of the
+calculation code.
+
+However, in the common case where we can not dispose of it, it is often useful
+to surround the calculation to remove dimension for input or output. A simple
+way to do this is to convert the input parameters :math:`\mathbf{x}` which are
+arguments of a function like "*DirectOperator*". One mostly use the default
+values :math:`\mathbf{x}^b` (background, or nominal value). Provided that each
+component of :math:`\mathbf{x}^b` is non zero, one can indeed put:
+
+.. math:: \mathbf{x} = \mathbf{\alpha}\mathbf{x}^b
+
+and then optimize the multiplicative parameter :math:`\mathbf{\alpha}`.  This
+parameter has as default value (or as background) a vector of 1. Be careful,
+applying a process of nondimensionalization also requires changing the error
+covariances associated in an ADAO formulation of the optimization problem.
+
+Such a process is rarely enough to avoid all the numerical problems, but it
+often improves a lot the numeric conditioning of the optimization.