From e55035dd18c63c6c6da68f376ed493286a5d7e7f Mon Sep 17 00:00:00 2001 From: Jean-Philippe ARGAUD Date: Fri, 9 Nov 2012 21:31:25 +0100 Subject: [PATCH] Improving documentation by separate reference --- doc/index.rst | 25 ++-- doc/intro.rst | 2 + doc/reference.rst | 325 ++++++++++++++++++++++++++++++++++++++++++++ doc/using.rst | 340 ++-------------------------------------------- 4 files changed, 352 insertions(+), 340 deletions(-) create mode 100644 doc/reference.rst diff --git a/doc/index.rst b/doc/index.rst index 0072e44..7e4afc2 100644 --- a/doc/index.rst +++ b/doc/index.rst @@ -15,21 +15,23 @@ optimal estimate of the inaccessible true value of a system state over time. It uses information coming from experimental measurements or observations, and from numerical *a priori* models, including information about their errors. Parts of the framework are also known under the names of *parameter estimation*, *inverse -problems*, *bayesian estimation*, *optimal interpolation*, etc. More details can +problems*, *Bayesian estimation*, *optimal interpolation*, etc. More details can be found in the section :ref:`section_theory`. -The documentation of this module is divided in parts. The first one is an -introduction. The second part briefly introduces data assimilation and concepts. -The third part describes how to use the module ADAO. The fourth part gives -examples on ADAO usage. Users interested in quick use of the module can jump to -this fourth section :ref:`section_examples`, but a valuable use of the module -requires to read and come back regularly to the third one :ref:`section_using`. -The last part focuses on advanced usages of the module, how to get more -information, or how to use it by scripting, without the graphical user interface -(GUI). +The documentation of this module is divided in parts. The first one +:ref:`section_intro` is an introduction. The second part :ref:`section_theory` +briefly introduces data assimilation, optimization and concepts. The third part +:ref:`section_using` describes how to use the module ADAO. The fourth part +:ref:`section_reference` gives a detailed description of all the ADAO commands +and keywords. The fifth part :ref:`section_examples` gives examples on ADAO +usage. Users interested in quick use of the module can jump to this section, but +a valuable use of the module requires to read and come back regularly to the +third and fourth ones. The last part :ref:`section_advanced` focuses on advanced +usages of the module, how to get more information, or how to use it by +scripting, without the graphical user interface (GUI). In all this documentation, we use standard notations of linear algebra, data -assimilation (as described in [Ide97]) and optimization. In particular, vectors +assimilation (as described in [Ide97]_) and optimization. In particular, vectors are written horizontally or vertically without making difference. Matrices are written either normally, or with a condensed notation, consisting in the use of a space to separate values and a "``;``" to separate the rows, in a continuous @@ -44,6 +46,7 @@ Table of contents intro theory using + reference examples advanced bibliography diff --git a/doc/intro.rst b/doc/intro.rst index c0267ce..c04b160 100644 --- a/doc/intro.rst +++ b/doc/intro.rst @@ -1,3 +1,5 @@ +.. _section_intro: + ================================================================================ Introduction to ADAO ================================================================================ diff --git a/doc/reference.rst b/doc/reference.rst new file mode 100644 index 0000000..7a47ee8 --- /dev/null +++ b/doc/reference.rst @@ -0,0 +1,325 @@ +.. _section_reference: + +================================================================================ +Reference description of the ADAO commands and keywords +================================================================================ + + +This section presents the reference description of the commands and keywords +available through the GUI or through scripts. + +Each command or keyword to be defined through the ADAO GUI has some properties. +The first property is to be a required command, an optional command or a keyword +describing a type of input. The second property is to be an "open" variable with +a fixed type but with any value allowed by the type, or a "restricted" variable, +limited to some specified values. The mathematical notations used afterwards are +explained in the section :ref:`section_theory`. + +List of possible input types +++++++++++++++++++++++++++++ + +.. index:: single: Dict +.. index:: single: Function +.. index:: single: Matrix +.. index:: single: String +.. index:: single: Script +.. index:: single: Vector + +The different type-style commands are: + +:Dict: + *Type of an input*. This indicates a variable that has to be filled by a + dictionary, usually given as a script. + +:Function: + *Type of an input*. This indicates a variable that has to be filled by a + function, usually given as a script. + +:Matrix: + *Type of an input*. This indicates a variable that has to be filled by a + matrix, usually given either as a string or as a script. + +:String: + *Type of an input*. This indicates a string, such as a name or a literal + representation of a matrix or vector, such as "1 2 ; 3 4". + +:Script: + *Type of an input*. This indicates a script given as an external file. + +:Vector: + *Type of an input*. This indicates a variable that has to be filled by a + vector, usually given either as a string or as a script. + +List of commands +++++++++++++++++ + +.. index:: single: ASSIMILATION_STUDY +.. index:: single: Algorithm +.. index:: single: AlgorithmParameters +.. index:: single: Background +.. index:: single: BackgroundError +.. index:: single: Debug +.. index:: single: InputVariables +.. index:: single: Observation +.. index:: single: ObservationError +.. index:: single: ObservationOperator +.. index:: single: Observers +.. index:: single: OutputVariables +.. index:: single: Study_name +.. index:: single: Study_repertory +.. index:: single: UserDataInit +.. index:: single: UserPostAnalysis + +The different commands are the following: + +:ASSIMILATION_STUDY: + *Required command*. This is the general command describing an ADAO case. It + hierarchicaly contains all the other commands. + +:Algorithm: + *Required command*. This is a string to indicates the data assimilation + algorithm chosen. The choices are limited and available through the GUI. + There exists for example: "3DVAR", "Blue"... See below the list of + algorithms and associated parameters. + +:AlgorithmParameters: + *Optional command*. This command allows to add some optional parameters to + control the data assimilation algorithm calculation. It is defined as a + "*Dict*" type object. See below the list of algorithms and associated + parameters. + +:Background: + *Required command*. This indicates the backgroud vector used for data + assimilation, previously noted as :math:`\mathbf{x}^b`. It is defined as a + "*Vector*" type object, that is, given either as a string or as a script. + +:BackgroundError: + *Required command*. This indicates the backgroud error covariance matrix, + previously noted as :math:`\mathbf{B}`.It is defined as a "*Matrix*" type + object, that is, given either as a string or as a script. + +:Debug: + *Required command*. This let choose the level of trace and intermediary + debug informations. The choices are limited between 0 (for False) and 1 (for + True) and available through the GUI. + +:InputVariables: + *Optional command*. This command allows to indicates the name and size of + physical variables that are bundled together in the control vector. This + information is dedicated to data processed inside of data assimilation + algorithm. + +:Observation: + *Required command*. This indicates the observation vector used for data + assimilation, previously noted as :math:`\mathbf{y}^o`. It is defined as a + "*Vector*" type object, that is, given either as a string or as a script. + +:ObservationError: + *Required command*. This indicates the observation error covariance matrix, + previously noted as :math:`\mathbf{R}`.It is defined as a "*Matrix*" type + object, that is, given either as a string or as a script. + +:ObservationOperator: + *Required command*. This indicates the observation operator, previously + noted :math:`H`, which transforms the input parameters :math:`\mathbf{x}` + to results :math:`\mathbf{y}` to be compared to observations + :math:`\mathbf{y}^o`. + +:Observers: + *Optional command*. This command allows to set internal observers, that are + functions linked with a particular variable, which will be executed each + time this variable is modified. It is a convenient way to monitor interest + variables during the data assimilation process, by printing or plotting it, + etc. + +:OutputVariables: + *Optional command*. This command allows to indicates the name and size of + physical variables that are bundled together in the output observation + vector. This information is dedicated to data processed inside of data + assimilation algorithm. + +:Study_name: + *Required command*. This is an open string to describe the study by a name + or a sentence. + +:Study_repertory: + *Optional command*. If available, this repertory is used to find all the + script files that can be used to define some other commands by scripts. + +:UserDataInit: + *Optional command*. This commands allows to initialise some parameters or + data automatically before data assimilation algorithm processing. + +:UserPostAnalysis: + *Optional command*. This commands allows to process some parameters or data + automatically after data assimilation algorithm processing. It is defined as + a script or a string, allowing to put simple code directly inside the ADAO + case. + +.. _subsection_algo_options: + +List of possible options for the algorithms ++++++++++++++++++++++++++++++++++++++++++++ + +.. index:: single: Blue +.. index:: single: LinearLeastSquares +.. index:: single: 3DVAR +.. index:: single: NonLinearLeastSquares +.. index:: single: EnsembleBlue +.. index:: single: QuantileRegression + +.. index:: single: AlgorithmParameters +.. index:: single: Minimizer +.. index:: single: Bounds +.. index:: single: MaximumNumberOfSteps +.. index:: single: CalculateAPosterioriCovariance +.. index:: single: CostDecrementTolerance +.. index:: single: ProjectedGradientTolerance +.. index:: single: GradientNormTolerance +.. index:: single: SetSeed +.. index:: single: Quantile + +Each algorithm can be controled using some generic or specific options given +throught the "*AlgorithmParameters*" optional command, as follows:: + + AlgorithmParameters = { + "Minimizer" : "CG", + "MaximumNumberOfSteps" : 10, + } + +This section describes the available options by algorithm. If an option is +specified for an algorithm that doesn't support it, the option is simply left +unused. + +:"Blue": + + :CalculateAPosterioriCovariance: + This boolean key allows to enable the calculation and the storage of the + covariance matrix of a posteriori anlysis errors. Be careful, this is a + numericaly costly step. The default is "False". + +:"LinearLeastSquares": + no option + +:"3DVAR": + + :Minimizer: + This key allows to choose the optimization minimizer. The default choice + is "LBFGSB", and the possible ones are "LBFGSB" (nonlinear constrained + minimizer, see [Byrd95]_ and [Zhu97]_), "TNC" (nonlinear constrained + minimizer), "CG" (nonlinear unconstrained minimizer), "BFGS" (nonlinear + unconstrained minimizer), "NCG" (Newton CG minimizer). + + :Bounds: + This key allows to define upper and lower bounds for every control + variable being optimized. Bounds can be given by a list of list of pairs + of lower/upper bounds for each variable, with possibly ``None`` every time + there is no bound. The bounds can always be specified, but they are taken + into account only by the constrained minimizers. + + :MaximumNumberOfSteps: + This key indicates the maximum number of iterations allowed for iterative + optimization. The default is 15000, which very similar to no limit on + iterations. It is then recommended to adapt this parameter to the needs on + real problems. For some minimizers, the effective stopping step can be + slightly different due to algorihtm internal control requirements. + + :CalculateAPosterioriCovariance: + This boolean key allows to enable the calculation and the storage of the + covariance matrix of a posteriori anlysis errors. Be careful, this is a + numericaly costly step. The default is "False". + + :CostDecrementTolerance: + This key indicates a limit value, leading to stop successfully the + iterative optimization process when the cost function decreases less than + this tolerance at the last step. The default is 10e-7, and it is + recommended to adapt it the needs on real problems. + + :ProjectedGradientTolerance: + This key indicates a limit value, leading to stop successfully the + iterative optimization process when all the components of the projected + gradient are under this limit. It is only used for constrained algorithms. + The default is -1, that is the internal default of each algorithm, and it + is not recommended to change it. + + :GradientNormTolerance: + This key indicates a limit value, leading to stop successfully the + iterative optimization process when the norm of the gradient is under this + limit. It is only used for non-constrained algorithms. The default is + 10e-5 and it is not recommended to change it. + +:"NonLinearLeastSquares": + + :Minimizer: + This key allows to choose the optimization minimizer. The default choice + is "LBFGSB", and the possible ones are "LBFGSB" (nonlinear constrained + minimizer, see [Byrd95]_ and [Zhu97]_), "TNC" (nonlinear constrained + minimizer), "CG" (nonlinear unconstrained minimizer), "BFGS" (nonlinear + unconstrained minimizer), "NCG" (Newton CG minimizer). + + :Bounds: + This key allows to define upper and lower bounds for every control + variable being optimized. Bounds can be given by a list of list of pairs + of lower/upper bounds for each variable, with possibly ``None`` every time + there is no bound. The bounds can always be specified, but they are taken + into account only by the constrained minimizers. + + :MaximumNumberOfSteps: + This key indicates the maximum number of iterations allowed for iterative + optimization. The default is 15000, which very similar to no limit on + iterations. It is then recommended to adapt this parameter to the needs on + real problems. For some minimizers, the effective stopping step can be + slightly different due to algorihtm internal control requirements. + + :CostDecrementTolerance: + This key indicates a limit value, leading to stop successfully the + iterative optimization process when the cost function decreases less than + this tolerance at the last step. The default is 10e-7, and it is + recommended to adapt it the needs on real problems. + + :ProjectedGradientTolerance: + This key indicates a limit value, leading to stop successfully the + iterative optimization process when all the components of the projected + gradient are under this limit. It is only used for constrained algorithms. + The default is -1, that is the internal default of each algorithm, and it + is not recommended to change it. + + :GradientNormTolerance: + This key indicates a limit value, leading to stop successfully the + iterative optimization process when the norm of the gradient is under this + limit. It is only used for non-constrained algorithms. The default is + 10e-5 and it is not recommended to change it. + +:"EnsembleBlue": + + :SetSeed: + This key allow to give an integer in order to fix the seed of the random + generator used to generate the ensemble. A convenient value is for example + 1000. By default, the seed is left uninitialized, and so use the default + initialization from the computer. + +:"QuantileRegression": + + :Quantile: + This key allows to define the real value of the desired quantile, between + 0 and 1. The default is 0.5, corresponding to the median. + + :Minimizer: + This key allows to choose the optimization minimizer. The default choice + and only available choice is "MMQR" (Majorize-Minimize for Quantile + Regression). + + :MaximumNumberOfSteps: + This key indicates the maximum number of iterations allowed for iterative + optimization. The default is 15000, which very similar to no limit on + iterations. It is then recommended to adapt this parameter to the needs on + real problems. + + :CostDecrementTolerance: + This key indicates a limit value, leading to stop successfully the + iterative optimization process when the cost function or the surrogate + decreases less than this tolerance at the last step. The default is 10e-6, + and it is recommended to adapt it the needs on real problems. + +Examples of using these commands are available in the section +:ref:`section_examples` and in example files installed with ADAO module. diff --git a/doc/using.rst b/doc/using.rst index 4b76a92..faf3a2b 100644 --- a/doc/using.rst +++ b/doc/using.rst @@ -12,24 +12,25 @@ Using the ADAO module :align: middle This section presents the usage of the ADAO module in SALOME. It is complemented -by advanced usage procedures the section :ref:`section_advanced`, and by +by advanced usage procedures in the section :ref:`section_advanced`, and by examples in the section :ref:`section_examples`. Logical procedure to build an ADAO test case -------------------------------------------- The construction of an ADAO case follows a simple approach to define the set of -input data, either static or dynamic data, and then generates a complete block -diagram used in YACS. Many variations exist for the definition of input data, -but the logical sequence remains unchanged. +input data, and then generates a complete executable block diagram used in YACS. +Many variations exist for the definition of input data, but the logical sequence +remains unchanged. -First of all, the user is considered to know the input data needed to set up the -data assimilation study. These data can be in SALOME or not. +First of all, the user is considered to know its personnal input data needed to +set up the data assimilation study. These data can already be available in +SALOME or not. **Basically, the procedure of using ADAO involves the following steps:** #. **Activate the ADAO module and use the editor GUI,** -#. **Build and modify the ADAO case and save it,** +#. **Build and/or modify the ADAO case and save it,** #. **Export the ADAO case as a YACS scheme,** #. **Modify and supplement the YACS scheme and save it,** #. **Execute the YACS case and obtain the results.** @@ -43,9 +44,9 @@ Activate the ADAO module and use the editor GUI +++++++++++++++++++++++++++++++++++++++++++++++ As always for a module, it has to be activated by choosing the appropriate -module button (or menu) in the toolbar of SALOME. If there is no study loaded, a -popup appears, allowing to choose between creating a new study, or opening an -already existing one: +module button (or menu) in the toolbar of SALOME. If there is no SALOME study +loaded, a popup appears, allowing to choose between creating a new study, or +opening an already existing one: .. _adao_activate1: .. image:: images/adao_activate.png @@ -219,325 +220,6 @@ in the data assimilation optimization procedure. The variable value at a given (consisting in the solution of the evaluation problem) can be obtained using the step "*-1*" as in a standard list. -Reference description of the commands and keywords available through the GUI ------------------------------------------------------------------------------ - -Each command or keyword to be defined through the ADAO GUI has some properties. -The first property is to be a required command, an optional command or a keyword -describing a type of input. The second property is to be an "open" variable with -a fixed type but with any value allowed by the type, or a "restricted" variable, -limited to some specified values. The mathematical notations used afterwards are -explained in the section :ref:`section_theory`. - -List of possible input types -++++++++++++++++++++++++++++ - -.. index:: single: Dict -.. index:: single: Function -.. index:: single: Matrix -.. index:: single: String -.. index:: single: Script -.. index:: single: Vector - -The different type-style commands are: - -:Dict: - *Type of an input*. This indicates a variable that has to be filled by a - dictionary, usually given as a script. - -:Function: - *Type of an input*. This indicates a variable that has to be filled by a - function, usually given as a script. - -:Matrix: - *Type of an input*. This indicates a variable that has to be filled by a - matrix, usually given either as a string or as a script. - -:String: - *Type of an input*. This indicates a string, such as a name or a literal - representation of a matrix or vector, such as "1 2 ; 3 4". - -:Script: - *Type of an input*. This indicates a script given as an external file. - -:Vector: - *Type of an input*. This indicates a variable that has to be filled by a - vector, usually given either as a string or as a script. - -List of commands -++++++++++++++++ - -.. index:: single: ASSIMILATION_STUDY -.. index:: single: Algorithm -.. index:: single: AlgorithmParameters -.. index:: single: Background -.. index:: single: BackgroundError -.. index:: single: Debug -.. index:: single: InputVariables -.. index:: single: Observation -.. index:: single: ObservationError -.. index:: single: ObservationOperator -.. index:: single: Observers -.. index:: single: OutputVariables -.. index:: single: Study_name -.. index:: single: Study_repertory -.. index:: single: UserDataInit -.. index:: single: UserPostAnalysis - -The different commands are the following: - -:ASSIMILATION_STUDY: - *Required command*. This is the general command describing an ADAO case. It - hierarchicaly contains all the other commands. - -:Algorithm: - *Required command*. This is a string to indicates the data assimilation - algorithm chosen. The choices are limited and available through the GUI. - There exists for example: "3DVAR", "Blue"... See below the list of - algorithms and associated parameters. - -:AlgorithmParameters: - *Optional command*. This command allows to add some optional parameters to - control the data assimilation algorithm calculation. It is defined as a - "*Dict*" type object. See below the list of algorithms and associated - parameters. - -:Background: - *Required command*. This indicates the backgroud vector used for data - assimilation, previously noted as :math:`\mathbf{x}^b`. It is defined as a - "*Vector*" type object, that is, given either as a string or as a script. - -:BackgroundError: - *Required command*. This indicates the backgroud error covariance matrix, - previously noted as :math:`\mathbf{B}`.It is defined as a "*Matrix*" type - object, that is, given either as a string or as a script. - -:Debug: - *Required command*. This let choose the level of trace and intermediary - debug informations. The choices are limited between 0 (for False) and 1 (for - True) and available through the GUI. - -:InputVariables: - *Optional command*. This command allows to indicates the name and size of - physical variables that are bundled together in the control vector. This - information is dedicated to data processed inside of data assimilation - algorithm. - -:Observation: - *Required command*. This indicates the observation vector used for data - assimilation, previously noted as :math:`\mathbf{y}^o`. It is defined as a - "*Vector*" type object, that is, given either as a string or as a script. - -:ObservationError: - *Required command*. This indicates the observation error covariance matrix, - previously noted as :math:`\mathbf{R}`.It is defined as a "*Matrix*" type - object, that is, given either as a string or as a script. - -:ObservationOperator: - *Required command*. This indicates the observation operator, previously - noted :math:`H`, which transforms the input parameters :math:`\mathbf{x}` - to results :math:`\mathbf{y}` to be compared to observations - :math:`\mathbf{y}^o`. - -:Observers: - *Optional command*. This command allows to set internal observers, that are - functions linked with a particular variable, which will be executed each - time this variable is modified. It is a convenient way to monitor interest - variables during the data assimilation process, by printing or plotting it, - etc. - -:OutputVariables: - *Optional command*. This command allows to indicates the name and size of - physical variables that are bundled together in the output observation - vector. This information is dedicated to data processed inside of data - assimilation algorithm. - -:Study_name: - *Required command*. This is an open string to describe the study by a name - or a sentence. - -:Study_repertory: - *Optional command*. If available, this repertory is used to find all the - script files that can be used to define some other commands by scripts. - -:UserDataInit: - *Optional command*. This commands allows to initialise some parameters or - data automatically before data assimilation algorithm processing. - -:UserPostAnalysis: - *Optional command*. This commands allows to process some parameters or data - automatically after data assimilation algorithm processing. It is defined as - a script or a string, allowing to put simple code directly inside the ADAO - case. - -.. _subsection_algo_options: - -List of possible options for the algorithms -+++++++++++++++++++++++++++++++++++++++++++ - -.. index:: single: Blue -.. index:: single: LinearLeastSquares -.. index:: single: 3DVAR -.. index:: single: NonLinearLeastSquares -.. index:: single: EnsembleBlue -.. index:: single: QuantileRegression - -.. index:: single: AlgorithmParameters -.. index:: single: Minimizer -.. index:: single: Bounds -.. index:: single: MaximumNumberOfSteps -.. index:: single: CalculateAPosterioriCovariance -.. index:: single: CostDecrementTolerance -.. index:: single: ProjectedGradientTolerance -.. index:: single: GradientNormTolerance -.. index:: single: SetSeed -.. index:: single: Quantile - -Each algorithm can be controled using some generic or specific options given -throught the "*AlgorithmParameters*" optional command, as follows:: - - AlgorithmParameters = { - "Minimizer" : "CG", - "MaximumNumberOfSteps" : 10, - } - -This section describes the available options by algorithm. If an option is -specified for an algorithm that doesn't support it, the option is simply left -unused. - -:"Blue": - - :CalculateAPosterioriCovariance: - This boolean key allows to enable the calculation and the storage of the - covariance matrix of a posteriori anlysis errors. Be careful, this is a - numericaly costly step. The default is "False". - -:"LinearLeastSquares": - no option - -:"3DVAR": - - :Minimizer: - This key allows to choose the optimization minimizer. The default choice - is "LBFGSB", and the possible ones are "LBFGSB" (nonlinear constrained - minimizer, see [Byrd95]_ and [Zhu97]_), "TNC" (nonlinear constrained - minimizer), "CG" (nonlinear unconstrained minimizer), "BFGS" (nonlinear - unconstrained minimizer), "NCG" (Newton CG minimizer). - - :Bounds: - This key allows to define upper and lower bounds for every control - variable being optimized. Bounds can be given by a list of list of pairs - of lower/upper bounds for each variable, with possibly ``None`` every time - there is no bound. The bounds can always be specified, but they are taken - into account only by the constrained minimizers. - - :MaximumNumberOfSteps: - This key indicates the maximum number of iterations allowed for iterative - optimization. The default is 15000, which very similar to no limit on - iterations. It is then recommended to adapt this parameter to the needs on - real problems. For some minimizers, the effective stopping step can be - slightly different due to algorihtm internal control requirements. - - :CalculateAPosterioriCovariance: - This boolean key allows to enable the calculation and the storage of the - covariance matrix of a posteriori anlysis errors. Be careful, this is a - numericaly costly step. The default is "False". - - :CostDecrementTolerance: - This key indicates a limit value, leading to stop successfully the - iterative optimization process when the cost function decreases less than - this tolerance at the last step. The default is 10e-7, and it is - recommended to adapt it the needs on real problems. - - :ProjectedGradientTolerance: - This key indicates a limit value, leading to stop successfully the - iterative optimization process when all the components of the projected - gradient are under this limit. It is only used for constrained algorithms. - The default is -1, that is the internal default of each algorithm, and it - is not recommended to change it. - - :GradientNormTolerance: - This key indicates a limit value, leading to stop successfully the - iterative optimization process when the norm of the gradient is under this - limit. It is only used for non-constrained algorithms. The default is - 10e-5 and it is not recommended to change it. - -:"NonLinearLeastSquares": - - :Minimizer: - This key allows to choose the optimization minimizer. The default choice - is "LBFGSB", and the possible ones are "LBFGSB" (nonlinear constrained - minimizer, see [Byrd95]_ and [Zhu97]_), "TNC" (nonlinear constrained - minimizer), "CG" (nonlinear unconstrained minimizer), "BFGS" (nonlinear - unconstrained minimizer), "NCG" (Newton CG minimizer). - - :Bounds: - This key allows to define upper and lower bounds for every control - variable being optimized. Bounds can be given by a list of list of pairs - of lower/upper bounds for each variable, with possibly ``None`` every time - there is no bound. The bounds can always be specified, but they are taken - into account only by the constrained minimizers. - - :MaximumNumberOfSteps: - This key indicates the maximum number of iterations allowed for iterative - optimization. The default is 15000, which very similar to no limit on - iterations. It is then recommended to adapt this parameter to the needs on - real problems. For some minimizers, the effective stopping step can be - slightly different due to algorihtm internal control requirements. - - :CostDecrementTolerance: - This key indicates a limit value, leading to stop successfully the - iterative optimization process when the cost function decreases less than - this tolerance at the last step. The default is 10e-7, and it is - recommended to adapt it the needs on real problems. - - :ProjectedGradientTolerance: - This key indicates a limit value, leading to stop successfully the - iterative optimization process when all the components of the projected - gradient are under this limit. It is only used for constrained algorithms. - The default is -1, that is the internal default of each algorithm, and it - is not recommended to change it. - - :GradientNormTolerance: - This key indicates a limit value, leading to stop successfully the - iterative optimization process when the norm of the gradient is under this - limit. It is only used for non-constrained algorithms. The default is - 10e-5 and it is not recommended to change it. - -:"EnsembleBlue": - - :SetSeed: - This key allow to give an integer in order to fix the seed of the random - generator used to generate the ensemble. A convenient value is for example - 1000. By default, the seed is left uninitialized, and so use the default - initialization from the computer. - -:"QuantileRegression": - - :Quantile: - This key allows to define the real value of the desired quantile, between - 0 and 1. The default is 0.5, corresponding to the median. - - :Minimizer: - This key allows to choose the optimization minimizer. The default choice - and only available choice is "MMQR" (Majorize-Minimize for Quantile - Regression). - - :MaximumNumberOfSteps: - This key indicates the maximum number of iterations allowed for iterative - optimization. The default is 15000, which very similar to no limit on - iterations. It is then recommended to adapt this parameter to the needs on - real problems. - - :CostDecrementTolerance: - This key indicates a limit value, leading to stop successfully the - iterative optimization process when the cost function or the surrogate - decreases less than this tolerance at the last step. The default is 10e-6, - and it is recommended to adapt it the needs on real problems. - -Examples of using these commands are available in the section -:ref:`section_examples` and in example files installed with ADAO module. - .. [#] For more information on EFICAS, see the *EFICAS module* available in SALOME GUI. .. [#] For more information on YACS, see the *YACS module User's Guide* available in the main "*Help*" menu of SALOME GUI. -- 2.39.2