13.17. Liste des commandes et mots-clés pour un cas d’assimilation de données ou d’optimisation¶

On résume ici l’ensemble des commandes et des mots-clés disponibles pour décrire un cas de calcul en évitant les particularités de chaque algorithme. C’est donc un inventaire commun des commandes.

Le jeu de commandes pour un cas d’assimilation de données ou d’optimisation est lié à la description d’un cas de calcul, qui est une procédure en Assimilation de Données (désignée en interface graphique par la commande « ASSIMILATION_STUDY »), en Méthodes avec Réduction (désignée en interface graphique par la commande « REDUCTION_STUDY ») ou en méthodes Optimisation (désignée en interface graphique par la commande « OPTIMIZATION_STUDY »).

Tous les termes possibles, imbriqués ou non, sont classés par ordre alphabétique. Ils ne sont pas obligatoirement requis pour tous les algorithmes. Les commandes ou mots-clés disponibles sont les suivants:

AlgorithmParameters: Dictionnaire. La variable définit l’algorithme d’assimilation de données ou d’optimisation choisi par le mot-clé « Algorithm », et ses éventuels paramètres optionnels. Les choix potentiels par ce mot-clé « Algorithm » sont disponibles à travers l’interface graphique ou dans la documentation de référence contenant une sous-section spécifique pour chacun d’eux. Il existe par exemple le « 3DVAR », le « Blue », etc. De manière facultative, la commande permet aussi d’ajouter des paramètres pour contrôler l’algorithme choisi. Leurs valeurs sont définies explicitement ou dans un objet de type « Dict ». On se reportera à la Description des options d’un algorithme par « AlgorithmParameters » pour l’usage détaillé de cette partie de la commande.

ASSIMILATION_STUDY: Commande obligatoire. C’est la commande générale qui décrit un cas utilisant des méthodes d’assimilation de données. Dans l’interface graphique, elle contient hiérarchiquement toutes les autres commandes.

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.

ControlInput: Vecteur. La variable indique le vecteur de contrôle utilisé pour forcer le modèle d’évolution à chaque pas, usuellement noté $\mathbf{U}$ . Sa valeur est définie comme un objet de type « Vector » ou « VectorSerie ». Lorsqu’il n’y a pas de contrôle, sa valeur doit être une chaîne vide “”.

Debug

Valeur booléenne. La variable définit le niveau de sorties et d’informations intermédiaires de débogage. Les choix sont limités entre 0 (pour False) et 1 (pour True).

Exemple : {"Debug":False}

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)$ .

ExecuteInContainer: Chaîne de caractères. Cette variable permet de choisir le mode d’exécution 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éé 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éé 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 ».

Avertissement

Dans sa présente version, cette commande est expérimentale, et reste donc susceptible de changements dans les prochaines versions.

InputVariables: Commande optionnelle. La variable permet d’indiquer le nom et la taille des variables physiques qui sont rassemblées dans le vecteur d’état. Cette information est destinée à être utilisée dans le traitement algorithmique interne des données.

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)$ .

Observers: Liste de fonctions liées à des variables. La variable permet de définir des observateurs internes, qui sont des fonctions liées à une variable particulière d’algorithme, qui sont exécutées chaque fois que cette variable est modifiée. C’est une manière pratique de suivre des variables d’intérêt durant le processus d’assimilation de données ou d’optimisation, en l’affichant ou en la traçant, etc. Des exemples courants (squelettes ou « templates ») sont fournis pour aider l’utilisateur ou pour faciliter l’élaboration d’un cas.

OPTIMIZATION_STUDY: Commande obligatoire. C’est la commande générale qui décrit un cas utilisant des méthodes d’optimisation. Dans l’interface graphique, elle contient hiérarchiquement toutes les autres commandes.

OutputVariables: Commande optionnelle. La variable permet d’indiquer le nom et la taille des variables physiques qui sont rassemblées dans le vecteur d’observation. Cette information est destinée à être utilisée dans le traitement algorithmique interne des données.

REDUCTION_STUDY: Commande obligatoire. C’est la commande générale qui décrit un cas utilisant des méthodes contenant de la réduction. Dans l’interface graphique, elle contient hiérarchiquement toutes les autres commandes.

StudyName: Chaîne de caractères. La variable est une chaîne de caractères quelconque pour identifier ou décrire l’étude ADAO par un nom ou une déclaration.

StudyRepertory: Chaîne de caractères. Si il existe, le répertoire désigné par cette chaîne de caractères est utilisé comme base pour les calculs, et il est aussi utilisé pour trouver les fichiers de script qui sont définis par nom sans répertoire, qui peuvent définir certaines variables.

UserDataInit: Nom de script. La variable permet d’initialiser certains paramètres ou certaines données automatiquement avant le traitement de données d’entrée pour l’assimilation de données ou l’optimisation. Pour cela, elle indique un nom de fichier de script à exécuter avant d’entrer dans l’initialisation des variables choisies.

UserPostAnalysis: Chaîne de caractères multi-lignes. La variable permet de traiter des paramètres ou des résultats après le déroulement de l’algorithme d’assimilation de données ou d’optimisation. Sa valeur est définie soit par un nom de patron prédéfini, soit par nom de un fichier script, soit par une chaîne de caractères, permettant de produire directement du code de post-processing dans un cas ADAO. Des exemples courants (squelettes ou « templates ») sont fournis pour aider l’utilisateur ou pour faciliter l’élaboration d’un cas. On se reportera à la description des Conditions requises pour décrire un post-traitement dédié après calcul ADAO pour avoir la liste des modèles et leur format. Remarque importante : ce traitement n’est exécuté que lorsque le cas est exécuté en TUI ou exporté en YACS.