Résultats et conclusion

Dans ce chapitre, nous avons traité le problème de la cohérence des directives ctin avec des directives order prédéfinies par l’utilisateur. Il s’agit de vérifier que chaque directive ctin peut être correctement calculée en utilisant la traversée du graphe définie par l’utilisateur. L’algorithme de cohérence analyse un ctin et retourne vrai si les directives order sont cohérentes vis-à-vis de ce

4.5. RÉSULTATS ET CONCLUSION

Fs(I^′,t^′) → Fd(I,t)

Trouver les chemins C_setC_d

< d_t < 0 m← 0 m← m + 1 n← niveau de Cs Déterminer N_set N_d au niveau m Num_ f ils Ns Num_ f ils Nd m≤ n référence absolue dl6= 0 règle 2 incohérent cohérent règle 4 6= abs bornes warning > Num_ f ils Ns Num_ f ils Nd vrai faux faux faux faux ^faux faux faux faux faux vrai vrai vrai ^vrai vrai vrai vrai vrai

FIG. 4.10 – Organigramme de programmation de l’algorithme de vérification de la cohérence des directives order. Ceci est le cas le plus général applicable à toutes sortes de connexions ctin (avec références relatives, absolues ou un mélange des deux).

a b s

1 i

N_i

FIG. 4.11 – Connexion Fs(absi) → Fd(i) entre deux fonctions de base rattachées à deux espaces

1D avec une référence absolue abs_i. Les cercles en noir et blanc représentent respectivement les modules source et destination. La valeur de la référence absolue est abs_i= abs avec 1 < abs < N_i.

ctin, faux sinon. Cet algorithme est appliqué à chaque ctin defini par l’utilisateur. Pour un graphe

modulaire donné, si toutes les valeurs retournées sont vrai, on peut alors supposer que les directives

order sont cohérentes. Nous avons testé l’algorithme sur des applications réelles, ainsi que sur des

applications simulées. Le test sur l’une des applications réelles a conduit à la détection d’une paire d’incohérences qui n’a jamais été détectée à l’œil nu.

Le temps de calcul de l’algorithme, qui tourne sur des centaines de ctin, est très petit (de l’ordre de quelques dixièmes de seconde), ce qui montre qu’il peut être appliqué à toutes les applications réelles.

Dans la conception d’une nouvelle application YAO, l’écriture des directives order est une phase coûteuse en temps et susceptible de générer des erreurs. En outre, c’est une tâche délicate, car les directives order indiquent comment le graphe modulaire est traversé et ceci a un impact di-rect sur le temps de calcul de l’application. En général, l’aspect performance n’est pas négligeable dans les applications d’assimilation variationnelle de données. Ces problématiques sont à la base de la suite des travaux de cette thèse. L’algorithme de cohérence permet d’éviter les erreurs lors de l’écriture des directives order par un utilisateur. Le chapitre qui suit traite le problème de la génération automatique de directives order cohérentes. Ce point est important, car la génération automatique peut générer toutes les directives order possibles, ce qui permet par la suite de faire un choix particulier qui optimise un critère donné.

Chapitre 5

Génération automatique des directives

order

Les directives order définies par l’utilisateur permettent le calcul des modules du graphe mo-dulaire dans un ordre topologique. En général, plusieurs ordres topologiques existent dans un graphe orienté acyclique (DAG¹). Dans le formalisme YAO, l’utilisateur peut spécifier une traver-sée particulière d’un espace de calcul. Cette travertraver-sée est exprimée à l’aide de boucles imbriquées relativement aux axes de l’espace de calcul, par le biais des directives order. Ce chapitre propose une méthode pour la génération automatique de ces directives order. Une profonde compréhension de la structure du graphe, donnée par les directives ctin, permet d’extraire des informations utiles afin de proposer automatiquement des directives order cohérentes et donc de permettre le calcul des modules selon un ordre topologique.

Dans le chapitre précédent, l’algorithme de vérification de la cohérence valide ou invalide les directives order définies par l’utilisateur. L’invalidation est suivie par la notification de la connexion, qui n’est pas calculable par ces directives order. L’utilisateur peut modifier les direc-tives order et exécuter à nouveau l’algorithme de vérification. Parfois, des incohérences sont dues aux directives ctin ; dans ce cas, soit le graphe modulaire contient des circuits, soit il est acyclique, mais ne peut pas être traversé par un ordre topologique sous la forme de boucles imbriquées. L’uti-lisateur peut itérer plusieurs fois le processus de modification des directives order, mais ne reçoit qu’une validation ou une invalidation de l’algorithme de vérification de la cohérence. En effet, l’algorithme présenté au chapitre précédent retourne faux sans détecter l’origine du problème, qui peut découler des incohérences dans la définition des directives ctin. Dans la section 4.3, nous avons déjà parlé de cette situation pour la connexion Fp(i, j, k) → Fp(i, j, k). Cette connexion

si-gnifie que pour calculer F_p(i, j, k), le module F_p(i, j, k) a déjà été calculé, ce qui n’a aucun sens.

Puisque l’objectif de ce chapitre est de générer automatiquement les directives order, nous devons détecter les problèmes qui résultent d’une mauvaise écriture des ctin qui empêchent la génération d’une traversée valide par des directives order.

Etant donné qu’il existe plusieurs ensembles de directives order possibles permettant d’assu-rer une traversée du graphe modulaire, il faut donc en choisir une particulière et la proposer à l’utilisateur. Cette détermination ne peut se faire que si l’on définit un critère permettant ce choix. Ceci peut par exemple se faire en définissant une heuristique de choix particulière qui réduirait au mieux le temps de calcul. Nous n’abordons pas, dans ce chapitre, la question du choix d’une traversée “optimale”. Par contre, nous présentons la méthodologie et un algorithme générique de base qui permet la génération de l’ensamble des directives order.

En général, si l’on traite d’une application réelle, il n’est pas possible d’écrire en un seul bloc² l’ensemble des directives order contenant toutes les fonctions de base qui définissent la traversée. Certaines connexions peuvent avoir besoin d’un sens pour un axe et d’autres connexions le sens opposé pour le même axe, de qui rend impossible l’utilisation d’une même boucle. En outre, une connexion, pour être satisfaite, pourrait avoir besoin de traverser d’abord l’axe i, tandis qu’une autre connexion pourrait avoir besoin de traverser au préalable l’axe j. Par conséquent, généralement, le processus génère plusieurs blocs de directives order, chacun contenant un certain nombre de fonctions de base F_p. La génération de chaque bloc se caractérise par :

1. le choix d’un ensemble de fonctions de base et l’ordre dans lequel ces fonctions sont exécu-tées ;

2. le choix d’une traversée de l’espace. Concrètement, cela conduit au choix des axes (par exemple i est le premier axe, j est le deuxième et k est le troisième, ou une combinaison quelconque des trois axes) et le choix des sens suivant chaque axe (ascendant ou descen-dant). Chaque bloc sera identifié par l’axe relatif à sa boucle extérieure.

Une directive ctin génère une connexion de base du graphe modulaire, définie par le point de grille générique (I,t) de la fonction de base destination Fd et le point de grille (I^′,t^′) de la fonction de base source Fs. Dans le chapitre précédent, nous avons dit que la boucle extérieure du temps agit comme une barrière de calcul, qui garantit que les modules à t+ d_t avec d_t < 0 ont déjà

été calculés. Cette considération vaut également pour la génération automatique des directives

order. Une connexion avec dt < 0 ne contient aucune information sur la façon dont le parcours

doit être fait, puisqu’elle n’ajoute aucune contrainte. Ainsi, dans la suite du chapitre, nous ne considérerons pas ce genre de connexions, mais uniquement les connexions avec dt = 0. Lorsque

nous notons Fs(I^′) → Fd(I), sans mentionner le temps, cela signifie que nous considérons que dt

est implicitement nul. Dans cette première partie du chapitre, nous supposons que les ctin sont composées uniquement de références relatives, nous traiterons les références absolues à la section 5.6.

5.1 Graphe de Dépendance Réduit (GDR)

Les directives ctin représentent les dépendances entre les modules et définissent un ensemble de contraintes de précédence. Une fonction de base F_p est un ensemble d’instructions de pro-grammation définies par l’utilisateur dans le fichier module, qui sont exécutées quand un module 2Un bloc de directives order est une directive order extérieure (une boucle extérieure), qui peut éventuellement contenir d’autres directives order imbriquées. Plusieurs blocs sont, en général, nécessaires pour définir un parcours.