ManteletReunion4 < Stages

Tags: , view all tags

Présents : Mireille, André, Brice, Grégory

Objet : Contraintes, caractérisation des sorties et analyse d'un workflow dans Aida

Points abordés:

Utilisation de Characterisation au niveau des outils (ou briques)

Analyse du workflow

Erreurs détectées lors de l'analyse

Etapes

Utilisation de Characterisation au niveau des outils

Le but de Characterisation dans Aida est de verifier que les contraintes imposees par un outil sur les entrees sont respectees par les images fournies en entrees. La partie d'Aida qui sera chargee de cette verification (que l'on appelera par la suite analyse ou compilation) devra considerer trois types de fichier:

le fichier de contraintes: ce fichier donne la liste des contraintes qu'un outil impose a ses entrees

le fichier Characterisation: ce fichier fourni l'ensemble des meta-donnees disponibles sur une image (entree ou sortie d'un outil)

le "modele" Characterisation d'une sortie: ce fichier decrit le sous-ensemble de meta-donnees systematiquement connues pour l'image produite en sortie de l'outil. (ce fichier est different pour chaque sortie et pour chaque outil)

Contraintes

Dans la majorite des cas, chaque contrainte ne concerne qu'une seule entree et donc qu'un seul fichier Characterisation. Mais certains outils doivent verifier des contraintes portant sur plusieurs entrees (dans le cas d'une superposition d'images, toutes les images doivent avoir la meme taille). Pour cette derniere raison, il est important que le fichier de contraintes soit associe a l'outil dans sa globalite, et non pas a chaque entree.

L'idee de depart concernant le format de ce fichier etait d'utiliser un fichier XML ou UType de type Characterisation. Cependant, Characterisation impose la presence de certains noeuds dont certains ont une valeur par defaut: ces derniers posent probleme parce-qu'alors, la partie d'Aida chargee de l'analyse va comprendre cette valeur par defaut comme une contrainte (alors que l'on ne voulait pas la considerer comme telle !). De plus, le fait que les contraintes peuvent concerner plusieurs entrees est impossible a representer avec la version actuelle de Characterisation.

Par consequent, nous devons absolument utiliser soit un autre type de fichier XML soit utiliser un fichier texte. La premiere solution restreint enormement la complexite des contraintes. Utiliser un fichier texte semble donc une meilleure solution. Neanmoins, cela nous oblige a mettre en place une certaine syntaxe sur l'ecriture des contraintes ainsi que de creer un parser pour ce type de fichier.

Modele Characterisation d'une sortie

La sortie d'un outil est caracterisee par un fichier Characterisation. Autrement dit, chaque outil qui modifie une ou plusieurs proprietes de l'image est capable de construire un modele de ce que serait le fichier Characterisation de l'image produite en sortie. Bien entendu, seules les proprietes modifiees de maniere constante (cad la valeur de la propriete ne changera pas apres traitement quelque soit l'image d'entree) seront inscrites dans le modele Characterisation associe a la sortie en question.

Ce modele Characterisation pose probleme lors de l'analyse d'un workflow. En effet, le modele contient seulement les proprietes "constantes" de l'image produite en sortie de l'outil. Si on utilise ce modele comme entree d'un nouvel outil, il est fort probable que toutes les contraintes ne se limitent pas aux seules proprietes donnees dans ce modele.

Pour resoudre ce probleme, au moins deux solutions peuvent etre donnees soit on genere le fichier Characterisation lie a l'image produite en sortie a partir de l'en-tete FITS de cette meme image, soit on impose que le fichier Characterisation associe a l'image de sortie soit genere par l'outils lui-meme. Dans le premier cas, il faudrait etre sur que l'outils remplit entierement l'en-tete FITS de l'image produite, si, bien sur, cette image est format FITS. Meme si l'en-tete FITS est remplit, certaines proprietes du fichier Characterisation obtenue pourraient etre vide car absentes de l'en-tete FITS. La deuxieme solution serait alors meilleur. En effet, contrairement a la precedente, elle presente l'avantage de fournir des fichiers Characterisations beaucoup plus complet. Mais elle presente egalement l'inconvenient de dependre du concepteur de l'outil pour qui cette tache represente plus de travail (apprentissage de Characterisation, redaction du fichier en accord avec le XSD, etc...). En depis de son defaut, nous choisirons cette derniere solution au probleme d'incompletude explique ci-dessus.

Analyse du workflow

Deux niveaux d'analyse

Entre autre pour le probleme d'incompletude lie au modele Characterisation d'une sortie, il est interessant de diviser l'analyse en deux parties:

L'analyse syntaxique est lancee AVANT l'execution du workflow. Elle a pour but de verifier la coherence entre les contraintes donnees et les modeles Characterisation, en ignorant les contraintes portant sur des proprietes absentes du modele. La seule verification complete qu'elle effectuera sera dans les cas ou l'image est donnee directement (cad que ce n'est pas une image issue de la sortie d'un outils), car le fichier Characterisation complet existera. La concordance entre le type du fichier donne en entree et le type exige par l'entree est egalement verifiee dans cette etape.

L'analyse effective est lancee PENDANT l'execution du workflow. Elle verifie les contraintes grace aux fichiers Characterisation complet qui sont soit donnes dans le cas d'un fichier donne, soit generes dans le cas d'un lien entre une sortie et une entree.

Arret de l'execution du workflow

Dans certains cas, il pourrait etre utile de stopper l'execution du workflow a une certaine etape. L'exemple le plus evident concerne l'affichage des erreurs qui proposent quelques solutions: si une erreur lors de l'analyse propose des solutions, il serait interessant de pouvoir interrompre momentanement l'execution du workflow afin d'avertir l'utilisateur et de lui demander de choisir une solution. S'il n'y a pas de solutions a proposer, l'execution est definitivement interrompue et le message d'erreur est affiche. Dans d'autres cas, il pourrait s'averer utile d'ignorer les erreurs d'analyse pour un ou plusieurs outils ou pour l'integralite du workflow.

Par consequent, on considera pour le moment trois types d'arrets ou trois drapeaux (ou encore trois "flags" pour les anglophones):

ignore
break
stop.

Test dans Aida

Comme tous les outils donnes dans Aida ne generent pas le fichier Characterisation associe a la sortie, les premiers tests sur Aida de l'analyse se feront avec des outils qui ne font rien excepte genere un fichier Characterisation complet.

Erreurs détectées lors de l'analyse

Afin de pouvoir prevenir l'utilisateur de toute erreur survenue durant l'analyse du workflow, une boite de dialogue sera utilisee uniquement pour l'analyse du workflow. Elle permettra entre autre d'afficher toutes les erreurs detectees pendant l'analyse et d'eventuellement proposer des solutions !

Plusieurs solutions pour proposer des solutions a une erreur d'analyse peuvent etre proposees:

proposer les outils d'Aida appartenant a une certaine categorie (exemple: redimensionnement, decoupage, ....). L'inconvenient est qu'aucune certitude ne peut etre etablie etant donne que les outils sont places dans les categories par les concepteurs d'outils et donc qu'il peut exister des noms de categorie synonymes et qu'une categorie peut contenir des outils sans aucun rapport avec les autres.
detecter quels outils parmis ceux presents dans la liste peuvent changer la propriete Characterisation source de l'erreur. Mais, il est absolument pas certains que l'outils fassent exactement ce qu'il faut pour corriger le probleme (meme si le propriete source de l'erreur a la valeur attendue).
un fichier texte ou XML qui liste les erreurs et leur associe des solutions sous la forme d'identifiant d'outils Aida. Cette solution semble correspondre a ce que l'on veut.