13.15. Algorithme de calcul « SimulatedAnnealing »¶

13.15.1. Description¶

Cet algorithme réalise une estimation de l’état d’un système par minimisation sans gradient d’une fonctionnelle d’écart $J$ , en utilisant la méta-heuristique de recherche de recuit simulé. Elle est basée sur une réduction de l’erreur $J$ tant que c’est possible, en autorisant une remontée temporaire de cette erreur pour éviter de rester bloqué dans un minimum local. La remontée de l’erreur est pilotée par une loi statistique de température, d’où l’analogie avec le recuit des métaux qui donne son nom à la méthode. La méthode ne requiert pas d’information particulière sur la fonctionnelle et ne nécessite pas les dérivées (sauf dans sa version hybride de type « DualAnnealing »).

Elle entre dans la même catégorie que les Algorithme de calcul « DerivativeFreeOptimization », Algorithme de calcul « DifferentialEvolution », Algorithme de calcul « ParticleSwarmOptimization », Algorithme de calcul « TabuSearch ».

C’est une méthode d’optimisation mono-objectif, permettant la recherche du minimum global d’une fonctionnelle d’erreur $J$ quelconque de type $L^1$ , $L^2$ ou $L^{\infty}$ , avec ou sans pondérations, comme décrit dans la section pour Approfondir l’estimation d’état par des méthodes d’optimisation. Comme c’est une méta-heuristique, hormis dans des cas particuliers, l’atteinte d’un résultat optimal global ou local n’est pas garantie (sauf dans sa version hybride de type « DualAnnealing »). La fonctionnelle d’erreur par défaut est celle de moindres carrés pondérés augmentés, classiquement utilisée en assimilation de données.

Il existe diverses variantes de cet algorithme. On propose ici les formulations stables et robustes suivantes :

« GeneralizedSimulatedAnnealing » (Generalized Simulated Annealing ou GSA, voir [Tsallis96]), algorithme classique combinant les approches classiques et rapides de recuit simulé. Il est performant, robuste et définit une référence pour les méthodes de recuit simulé.
« DualAnnealing » (Dual Annealing, voir [Xiang97]), algorithme combinant le GSA précédent à une stratégie de recherche locale, appliquée aux états acceptables du point de vue du recuit simulé, ce qui améliore la rapidité et la précision du GSA. Cette amélioration nécessite les opérateurs tangent et adjoint.

Voici quelques suggestions pratiques pour une utilisation efficace de ces algorithmes :

La variante recommandée de cet algorithme est le « DualAnnealing » car il est à la fois robuste et sa convergence est très performante, surtout en grande dimension pour un tel algorithme. Néanmoins, comme elle nécessite les opérateurs tangent et adjoint, il n’est pas toujours judicieux d’utiliser cette caractéristique d’accélération.
Dans le cas où la fonction d’écart ou l’opérateur d’observation ne sont pas dérivables, l’algorithme « GeneralizedSimulatedAnnealing » convient et réalise la même optimisation de recuit simulé que la variante accélérée.
Le contrôle de la convergence le plus aisé se fait en laissant les paramètres par défaut, en laissant le recuit simulé se stabiliser. Néanmoins, comme la convergence stochastique peut être longue, on peut aussi restreindre les calculs par la limitation du nombre d’évaluation de la fonction de simulation. Cela ne limite la convergence théorique, mais permet néanmoins de restreindre notablement le nombre de calculs.

Ces conseils sont à utiliser comme des indications expérimentales, et non comme des prescriptions, car ils sont à apprécier ou à adapter selon la physique de chaque problème que l’on traite.

13.15.2. Quelques propriétés notables des méthodes implémentées¶

Pour compléter la description on synthétise ici quelques propriétés notables, des méthodes de l’algorithme ou de leurs implémentations. Ces propriétés peuvent avoir une influence sur la manière de l’utiliser ou sur ses performances de calcul. Pour de plus amples renseignements, on se reportera aux références plus complètes indiquées à la fin du descriptif de cet algorithme.

Les méthodes d’optimisation proposées par cet algorithme effectuent une recherche globale du minimum, permettant en théorie d’atteindre un état globalement optimal sur le domaine de recherche. Cette optimalité globale est néanmoins obtenue « à convergence », ce qui signifie en temps long ou infini lors d’une optimisation itérative « à valeurs réelles » (par opposition à « à valeurs entières »).

Les méthodes proposées par cet algorithme ne requièrent pas de dérivation de la fonction objectif ou de l’un des opérateurs, permettant d’éviter ce temps de calcul supplémentaire dans le cas où les dérivées sont calculées numériquement par de multiples évaluations.

Les méthodes proposées par cet algorithme ne présentent pas de parallélisme interne ni de dérivation numérique d’opérateur(s), et ne peuvent donc profiter de ressources informatiques de répartition de calculs. Les méthodes sont séquentielles, et un usage éventuel des ressources du parallélisme est donc réservé aux opérateurs d’observation ou d’évolution, donc aux codes de l’utilisateur.

Les méthodes proposées par cet algorithme atteignent leur convergence sur un ou plusieurs critères de résidu ou de nombre. En pratique, il peut y avoir plusieurs critères de convergence actifs simultanément.

Le résidu peut être une mesure standard basée sur un écart (« écart calculs-mesures » par exemple), ou une valeur remarquable lié à l’algorithme (« nullité d’un gradient » par exemple).

Le nombre est fréquemment un élément remarquable lié à l’algorithme, comme un nombre d’itérations ou un nombre d’évaluations, mais cela peut aussi être par exemple un nombre de générations pour un algorithme évolutionnaire.

Il convient de régler soigneusement les seuils de convergence, pour limiter le coût calcul global de l’algorithme, ou pour assurer une adaptation de la convergence au cas physique traité.

13.15.3. Commandes requises et optionnelles¶

Les commandes générales requises, disponibles en édition dans l’interface graphique ou textuelle, sont les suivantes :

Background: Vecteur. La variable désigne le vecteur d’ébauche ou d’initialisation, usuellement noté $\mathbf{x}^b$ . Sa valeur est définie comme un objet de type « Vector » ou « VectorSerie ». Sa disponibilité en sortie est conditionnée par le booléen « Stored » associé en entrée.

BackgroundError: Matrice. La variable désigne la matrice de covariance des erreurs d’ébauche, usuellement notée $\mathbf{B}$ . Sa valeur est définie comme un objet de type « Matrix », de type « ScalarSparseMatrix », ou de type « DiagonalSparseMatrix », comme décrit en détail dans la section Conditions requises pour décrire des matrices de covariance. Sa disponibilité en sortie est conditionnée par le booléen « Stored » associé en entrée.

EvolutionError: Matrice. La variable désigne la matrice de covariance des erreurs a priori d’évolution, usuellement notée $\mathbf{Q}$ . Sa valeur est définie comme un objet de type « Matrix », de type « ScalarSparseMatrix », ou de type « DiagonalSparseMatrix », comme décrit en détail dans la section Conditions requises pour décrire des matrices de covariance. Sa disponibilité en sortie est conditionnée par le booléen « Stored » associé en entrée.

EvolutionModel: Opérateur. La variable désigne l’opérateur d’évolution du modèle, usuellement noté $M$ , qui décrit un pas élémentaire d’évolution dynamique ou itérative. Sa valeur est définie comme un objet de type « Function » ou de type « Matrix ». Dans le cas du type « Function », différentes formes fonctionnelles peuvent être utilisées, comme décrit dans la section Conditions requises pour les fonctions décrivant un opérateur. Si un contrôle $U$ est inclus dans le modèle d’observation, l’opérateur doit être appliqué à une paire $(X,U)$ .

Observation: Liste de vecteurs. La variable désigne le vecteur d’observation utilisé en assimilation de données ou en optimisation, et usuellement noté $\mathbf{y}^o$ . Sa valeur est définie comme un objet de type « Vector » si c’est une unique observation (temporelle ou pas) ou « VectorSerie » si c’est une succession d’observations. Sa disponibilité en sortie est conditionnée par le booléen « Stored » associé en entrée.

ObservationError: Matrice. La variable désigne la matrice de covariance des erreurs a priori d’ébauche, usuellement notée $\mathbf{R}$ . Cette matrice est définie comme un objet de type « Matrix », de type « ScalarSparseMatrix », ou de type « DiagonalSparseMatrix », comme décrit en détail dans la section Conditions requises pour décrire des matrices de covariance. Sa disponibilité en sortie est conditionnée par le booléen « Stored » associé en entrée.

ObservationOperator: Opérateur. La variable désigne l’opérateur d’observation, usuellement noté $H$ , qui transforme les paramètres d’entrée $\mathbf{x}$ en résultats $\mathbf{y}$ qui sont à comparer aux observations $\mathbf{y}^o$ . Sa valeur est définie comme un objet de type « Function » ou de type « Matrix ». Dans le cas du type « Function », différentes formes fonctionnelles peuvent être utilisées, comme décrit dans la section Conditions requises pour les fonctions décrivant un opérateur. Si un contrôle $U$ est inclus dans le modèle d’observation, l’opérateur doit être appliqué à une paire $(X,U)$ .

Les commandes optionnelles générales, disponibles en édition dans l’interface graphique ou textuelle, sont indiquées dans la Liste des commandes et mots-clés pour un cas d’assimilation de données ou d’optimisation. De plus, les paramètres de la commande « AlgorithmParameters » permettent d’indiquer les options particulières, décrites ci-après, de l’algorithme. On se reportera à la Description des options d’un algorithme par « AlgorithmParameters » pour le bon usage de cette commande.

Les options sont les suivantes :

Bounds

Liste de paires de valeurs réelles. Cette clé permet de définir des paires de bornes supérieure et inférieure pour chaque variable d’état optimisée. Les bornes doivent être données par une liste de liste de paires de bornes inférieure/supérieure pour chaque variable, avec une valeur None chaque fois qu’il n’y a pas de borne. Les bornes peuvent toujours être spécifiées, mais seuls les optimiseurs sous contraintes les prennent en compte. Si la liste est vide, cela équivaut à une absence de bornes.

Exemple : {"Bounds":[[2.,5.],[1.e-2,10.],[-30.,None],[None,None]]}

EstimationOf

Nom prédéfini. Cette clé permet de choisir le type d’estimation à réaliser. Cela peut être soit une estimation de l’état, avec la valeur « State », ou une estimation de paramètres, avec la valeur « Parameters ». Le choix par défaut est « Parameters ».

Exemple : {"EstimationOf":"Parameters"}

MaximumNumberOfIterations

Valeur entière. Cette clé indique le nombre maximum d’itérations internes possibles en optimisation itérative. Le défaut est 15000, qui est très similaire à une absence de limite sur ce nombre d’itérations. Il est ainsi recommandé d’adapter ce paramètre aux besoins pour des problèmes réels. Pour certains optimiseurs, le nombre de pas effectif d’arrêt peut être légèrement différent de la limite à cause d’exigences de contrôle interne de l’algorithme. On peut se reporter à la partie décrivant les manières de Contrôler la convergence pour des cas de calculs et algorithmes itératifs pour des recommandations plus détaillées.

Exemple : {"MaximumNumberOfIterations":100}

MaximumNumberOfFunctionEvaluations

Valeur entière. Cette clé indique le nombre maximum d’évaluations possibles de la fonctionnelle à optimiser. Le défaut est de 15000, qui est une limite arbitraire. Il est ainsi recommandé d’adapter ce paramètre aux besoins pour des problèmes réels. Pour certains optimiseurs, le nombre effectif d’évaluations à l’arrêt peut être légèrement différent de la limite à cause d’exigences de déroulement interne de l’algorithme.

Exemple : {"MaximumNumberOfFunctionEvaluations":50}

Minimizer: Nom prédéfini. Cette clé permet de changer le minimiseur pour l’optimiseur. Le choix par défaut est « LBFGSB », et les choix possibles sont « LBFGSB » (minimisation non linéaire sous contraintes, voir [Byrd95], [Morales11], [Zhu97]), « TNC » (minimisation non linéaire sous contraintes), « CG » (minimisation non linéaire sans contraintes), « BFGS » (minimisation non linéaire sans contraintes), Il est fortement conseillé de conserver la valeur par défaut.

QualityCriterion

Nom prédéfini. Cette clé indique le critère de qualité, qui est minimisé pour trouver l’estimation optimale de l’état. Le défaut est le critère usuel de l’assimilation de données nommé « DA », qui est le critère de moindres carrés pondérés augmentés. Le critère possible est dans la liste suivante, dans laquelle les noms équivalents sont indiqués par un signe « <=> » : [« AugmentedWeightedLeastSquares » <=> « AWLS » <=> « DA », « WeightedLeastSquares » <=> « WLS », « LeastSquares » <=> « LS » <=> « L2 », « AbsoluteValue » <=> « L1 », « MaximumError » <=> « ME » <=> « Linf »]. On pourra se reporter à la section pour Approfondir l’estimation d’état par des méthodes d’optimisation afin de disposer de la définition détaillée de ces critères de qualité.

Exemple : {"QualityCriterion":"DA"}

SetSeed

Valeur entière. Cette clé permet de donner un nombre entier pour fixer la graine du générateur aléatoire utilisé dans l’algorithme. Par défaut, la 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 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.

Exemple : {"SetSeed":123456789}

StoreSupplementaryCalculations

Liste de noms. Cette liste indique les noms des variables supplémentaires, qui peuvent être disponibles au cours du déroulement ou à la fin de l’algorithme, si elles sont initialement demandées par l’utilisateur. Leur disponibilité implique, potentiellement, des calculs ou du stockage coûteux. La valeur par défaut est donc une liste vide, aucune de ces variables n’étant calculée et stockée par défaut (sauf les variables inconditionnelles). Les noms possibles pour les variables supplémentaires sont dans la liste suivante (la description détaillée de chaque variable nommée est donnée dans la suite de cette documentation par algorithme spécifique, dans la sous-partie « Informations et variables disponibles à la fin de l’algorithme ») : [ « Analysis », « BMA », « CostFunctionJ », « CostFunctionJb », « CostFunctionJo », « CostFunctionJAtCurrentOptimum », « CostFunctionJbAtCurrentOptimum », « CostFunctionJoAtCurrentOptimum », « CurrentIterationNumber », « CurrentOptimum », « CurrentState », « EnsembleOfSimulations », « EnsembleOfStates », « IndexOfOptimum », « Innovation », « InnovationAtCurrentState », « OMA », « OMB », « SimulatedObservationAtBackground », « SimulatedObservationAtCurrentOptimum », « SimulatedObservationAtCurrentState », « SimulatedObservationAtOptimum », ].

Exemple : {"StoreSupplementaryCalculations":["CurrentState", "Residu"]}

Variant

Nom prédéfini. Cette clé permet de choisir l’une des variantes possibles pour l’algorithme principal. La variante par défaut est la formulation « DualAnnealing » d’origine, et les choix possibles sont « GeneralizedSimulatedAnnealing » (Generalized Simulated Annealing ou GSA), « DualAnnealing » (Dual Annealing).

Il est conseillé d’essayer la variante « DualAnnealing » avec un très faible nombre d’itérations et un nombre limité d’évaluations de la fonction de simulation.

Exemple : {"Variant":"DualAnnealing"}

13.15.4. Informations et variables disponibles à la fin de l’algorithme¶

En sortie, après exécution de l’algorithme, on dispose d’informations et de variables issues du calcul. La description des Variables et informations disponibles en sortie indique la manière de les obtenir, par la méthode nommée get, depuis la variable « ADD » du post-processing en interface graphique, ou depuis le cas en interface textuelle. Les variables d’entrée, mises à disposition de l’utilisateur en sortie pour faciliter l’écriture des procédures de post-processing, sont décrites dans un Inventaire des informations potentiellement disponibles en sortie.

Sorties permanentes (non conditionnelles)

Les sorties non conditionnelles de l’algorithme sont les suivantes :

Analysis

Liste de vecteurs. Chaque élément de cette variable est un état optimal $\mathbf{x}^*$ en optimisation, une interpolation ou une analyse $\mathbf{x}^a$ en assimilation de données.

Exemple : xa = ADD.get("Analysis")[-1]

CostFunctionJ

Liste de valeurs. Chaque élément est une valeur de fonctionnelle d’écart $J$ choisie.

Exemple : J = ADD.get("CostFunctionJ")[:]

CostFunctionJb

Liste de valeurs. Chaque élément est une valeur de fonctionnelle d’écart $J^b$ , c’est-à-dire de la partie écart à l’ébauche. Si cette partie n’existe pas dans la fonctionnelle, sa valeur est nulle.

Exemple : Jb = ADD.get("CostFunctionJb")[:]

CostFunctionJo

Liste de valeurs. Chaque élément est une valeur de fonctionnelle d’écart $J^o$ , c’est-à-dire de la partie écart à l’observation.

Exemple : Jo = ADD.get("CostFunctionJo")[:]

Ensemble des sorties à la demande (conditionnelles ou non)

L’ensemble des sorties (conditionnelles ou non) de l’algorithme, classées par ordre alphabétique, est le suivant :

Analysis

Liste de vecteurs. Chaque élément de cette variable est un état optimal $\mathbf{x}^*$ en optimisation, une interpolation ou une analyse $\mathbf{x}^a$ en assimilation de données.

Exemple : xa = ADD.get("Analysis")[-1]

BMA

Liste de vecteurs. Chaque élément est un vecteur d’écart entre l’ébauche et l’état optimal.

Exemple : bma = ADD.get("BMA")[-1]

CostFunctionJ

Liste de valeurs. Chaque élément est une valeur de fonctionnelle d’écart $J$ choisie.

Exemple : J = ADD.get("CostFunctionJ")[:]

CostFunctionJb

Liste de valeurs. Chaque élément est une valeur de fonctionnelle d’écart $J^b$ , c’est-à-dire de la partie écart à l’ébauche. Si cette partie n’existe pas dans la fonctionnelle, sa valeur est nulle.

Exemple : Jb = ADD.get("CostFunctionJb")[:]

CostFunctionJo

Liste de valeurs. Chaque élément est une valeur de fonctionnelle d’écart $J^o$ , c’est-à-dire de la partie écart à l’observation.

Exemple : Jo = ADD.get("CostFunctionJo")[:]

CostFunctionJAtCurrentOptimum

Liste de valeurs. Chaque élément est une valeur de fonctionnelle d’écart $J$ . A chaque pas, la valeur correspond à l’état optimal trouvé depuis le début.

Exemple : JACO = ADD.get("CostFunctionJAtCurrentOptimum")[:]

CostFunctionJbAtCurrentOptimum

Liste de valeurs. Chaque élément est une valeur de fonctionnelle d’écart $J^b$ , c’est-à-dire de la partie écart à l’ébauche. A chaque pas, la valeur correspond à l’état optimal trouvé depuis le début. Si cette partie n’existe pas dans la fonctionnelle, sa valeur est nulle.

Exemple : JbACO = ADD.get("CostFunctionJbAtCurrentOptimum")[:]

CostFunctionJoAtCurrentOptimum

Liste de valeurs. Chaque élément est une valeur de fonctionnelle d’écart $J^o$ , c’est-à-dire de la partie écart à l’observation. A chaque pas, la valeur correspond à l’état optimal trouvé depuis le début.

Exemple : JoACO = ADD.get("CostFunctionJoAtCurrentOptimum")[:]

CurrentIterationNumber

Liste d’entiers. Chaque élément est l’index d’itération courant au cours du déroulement itératif de l’algorithme utilisé. Il y a une valeur d’index d’itération par pas d’assimilation correspondant à un état observé.

Exemple : cin = ADD.get("CurrentIterationNumber")[-1]

CurrentOptimum

Liste de vecteurs. Chaque élément est le vecteur d’état optimal au pas de temps courant au cours du déroulement itératif de l’algorithme d’optimisation utilisé. Ce n’est pas nécessairement le dernier état.

Exemple : xo = ADD.get("CurrentOptimum")[:]

CurrentState

Liste de vecteurs. Chaque élément est un vecteur d’état courant utilisé au cours du déroulement itératif de l’algorithme utilisé.

Exemple : xs = ADD.get("CurrentState")[:]

EnsembleOfSimulations

Liste de vecteurs ou matrice. Chaque élément est une collection ordonnée de vecteurs d’état physique ou d’état simulé éventuellement observé $\mathbf{y}$ . Ce sont des sorties d’opérateur $H$ , c’est-à-dire des états d’observation simulés (nommés « snapshots » en terminologie de bases réduites). A chaque index de pas, il y a 1 état par colonne si cette liste est sous forme matricielle, ou 1 état par élément si c’est effectivement une liste. Important : la numérotation du support ou des points, sur lequel ou auxquels sont fournis une valeur d’état dans chaque vecteur, est implicitement celle de l’ordre naturel de numérotation du vecteur d’état, de 0 à la « taille moins 1 » de ce vecteur.

Exemple : {"EnsembleOfSimulations":[y1, y2, y3...]}

EnsembleOfStates

Liste de vecteurs ou matrice. Chaque élément est une collection ordonnée de vecteurs d’état physique ou d’état paramétrique $\mathbf{x}$ . Ce sont des entrées d’opérateur $H$ , c’est-à-dire des états courants avant observation. A chaque index de pas, il y a 1 état par colonne si cette liste est sous forme matricielle, ou 1 état par élément si c’est effectivement une liste. Important : la numérotation du support ou des points, sur lequel ou auxquels sont fournis une valeur d’état dans chaque vecteur, est implicitement celle de l’ordre naturel de numérotation du vecteur d’état, de 0 à la « taille moins 1 » de ce vecteur.

Exemple : {"EnsembleOfStates":[x1, x2, x3...]}

IndexOfOptimum

Liste d’entiers. Chaque élément est l’index d’itération de l’optimum obtenu au cours du déroulement itératif de l’algorithme d’optimisation utilisé. Ce n’est pas nécessairement le numéro de la dernière itération.

Exemple : ioo = ADD.get("IndexOfOptimum")[-1]

Innovation

Liste de vecteurs. Chaque élément est un vecteur d’innovation, qui est en statique l’écart de l’optimum à l’ébauche, et en dynamique l’incrément d’évolution.

Exemple : d = ADD.get("Innovation")[-1]

InnovationAtCurrentState

Liste de vecteurs. Chaque élément est un vecteur d’innovation à l’état courant avant analyse.

Exemple : ds = ADD.get("InnovationAtCurrentState")[-1]

OMA

Liste de vecteurs. Chaque élément est un vecteur d’écart entre l’observation et l’état optimal dans l’espace des observations.

Exemple : oma = ADD.get("OMA")[-1]

OMB

Liste de vecteurs. Chaque élément est un vecteur d’écart entre l’observation et l’état d’ébauche dans l’espace des observations.

Exemple : omb = ADD.get("OMB")[-1]

SimulatedObservationAtBackground

Liste de vecteurs. Chaque élément est un vecteur d’observation simulé par l’opérateur d’observation à partir de l’ébauche $\mathbf{x}^b$ . C’est la prévision à partir de l’ébauche, elle est parfois appelée « Dry ».

Exemple : hxb = ADD.get("SimulatedObservationAtBackground")[-1]

SimulatedObservationAtCurrentOptimum

Liste de vecteurs. Chaque élément est un vecteur d’observation simulé par l’opérateur d’observation à partir de l’état optimal au pas de temps courant au cours du déroulement de l’algorithme d’optimisation, c’est-à-dire dans l’espace des observations.

Exemple : hxo = ADD.get("SimulatedObservationAtCurrentOptimum")[-1]

SimulatedObservationAtCurrentState

Liste de vecteurs. Chaque élément est un vecteur d’observation simulé par l’opérateur d’observation à partir de l’état courant, c’est-à-dire dans l’espace des observations.

Exemple : hxs = ADD.get("SimulatedObservationAtCurrentState")[-1]

SimulatedObservationAtOptimum

Liste de vecteurs. Chaque élément est un vecteur d’observation obtenu par l’opérateur d’observation à partir de la simulation d’analyse ou d’état optimal $\mathbf{x}^a$ . C’est l’observation de la prévision à partir de l’analyse ou de l’état optimal, et elle est parfois appelée « Forecast ».

Exemple : hxa = ADD.get("SimulatedObservationAtOptimum")[-1]

13.15.5. Voir aussi¶

Références vers d’autres sections :

Références bibliographiques :