• Table of contents
• Doc ref:
• Sur ces premières demandes simulateurs/ZhairesRunner :
  • Rappel des demandes
  • Principales réflexions
    • Workflow
    • Dataflow
  • Propositions
• Sur ces premières demandes base de données
  • Rappels des premières demandes
  • Principales réflexions
  • Propositions
• Proposition pour le nouveau package de "simu/analyse"
  • Contenu
  • Nom
  • Liens avec ZHAireSRunner de Matias Tueros
  • Package fork de ZHAireSRunner

Doc ref:¶

CR réunion simulation ZHAires du 17 juin 2022

Lors de cette réunion une refonte du package ZHaireSRunner a été décidée.

Sur ces premières demandes simulateurs/ZhairesRunner :¶

Rappel des demandes¶

• D_S1 poursuivre l'intégration d'autres étapes dans le pipeline comme par exemple
  • étape de validation
  • étape de pré-simulation (en vue de la simulation des neutrinos de haute énergie par exemple)
  • ou étape de traitement comme:
    • interpoler un réseau avec la simulation "starShape"
    • ajouter la réponse de l'antenne
    • appliquer un trigger sur les traces
  • ...
• D_S2 il faut conserver la possibilité d'exécuter le pipeline étape par étape (débuggage ou validation)
• D_S3 mettre les sorties au format ROOT défini tel que défini par GRAND
• D_S4 envisager que l'on puisse utiliser un autre simulateur que Aires/ZHAires, comme Corsika/Coreas (il y a des similitudes au niveau des paramètre d'entrées )

Principales réflexions¶

• D_S1, D_S2, D_S4 vont dans le sens de l'utilisation d'un outil de workflow haut niveau (D_S2), c'est à dire indépendant des fonctionnalité des tâches lancées (D_S4)
• D_S4 : donc possiblement un même fichier de paramètres pourrait utiliser pour les 2 simulateurs. Ceci indique la nécessité de séparer les paramètres et de la tâche associée. Il faut recourir à un fichier de paramètre de manière systématique. c'est le cas pour les étapes 2 et 4 mais pas 1 et 3.

Workflow¶

• L'outil de workflow doit
  • permettre de voir l'enchainement des tâches
  • permettre d'ajouter une étape supplémentaire ou de la commenter
• ZhairesRunner ne contient pas de workflow mais des scheduler à travers TheLibraryRunner
• Remarques sur les workflow
  • un workflow permet aussi bien de décrire un pipeline de simulation que d'analyse de données avec la même syntax
  • il y a un très grand nombre de biblio/framework de workflow disponibles, peut-être qu'un conviendrait à nos besoins ... comme cosmos?
  • les workflow utilisent des "scheduler" ou DRM pour lancer les job suivant la plateforme de calculs, c'est un élément centrale d'un workflow qui est souvent dispo sous former de pluggin ...

Dataflow¶

• la dataflow c'est l'ensemble de l'arborescences, fichiers, format de fichier attendus ou produits par une tâche.
• par expérience, la vérification des entrées/sorties entre tâches est très ardus et devient très vite lourd à écrire et à gérer

Propositions¶

• Paramètres
  • le format de fichier de paramètres INI est déjà utilisé, je propose de généraliser ce format.
  • j'ai du code déjà prêt pour enrichir la syntax INI, comme la reconnaissance de dictionnaire, list et du type float, integer
• Dataflow
  • Comme pour un langage de programmation non typé, je propose d'utiliser un workflow sans description explicite des entrée/sorties. Par contre, chaque tâche doit documenter ses entrées/sorties et c'est au créateur du pipeline d'adapter les données ou leur organisation pour le bon enchaînement des tâches.
• Workflow
  • Compte tenu que Matias a écrit les principaux scheduler (unix, SLURM) pour le CCIN2P3 il reste "que" la gestion de l'enchainement des tâches à coder
  • tINI_workflow est une proposition de description de workflow à l'aide d'un fichier INI, donc sans écrire de code.

Sur ces premières demandes base de données¶

Rappels des premières demandes¶

• D_DB_1 regrouper les simulations/traitements dans une base de données
• D_DB_2 intégrer une simulation que si elle a passé les critères de qualité
• D_DB_3 pouvoir intégrer les simulations existantes
• D_DB_4 pouvoir requêter sur différents critères, aussi bien ceux de simulation et que ceux relatifs aux traitements
• D_DB_5 doit contenir une traçabilité des versions des traitements ou du simulateur

Principales réflexions¶

• Par rapport à la base sqlite existante et compte tenu de l'utilisation recommandée d'un workflow (voir ci-dessus), il faut séparer la base de données utilisée par le scheduler du workflow et les attributs physiques relatifs aux simulation/données d'une gerbe
• D_DB_2, D_DB_3 : indiquent que les données de simulations sont intégrées dans la base de manière conditionnelle et après son exécution
• Je pense qu'il serait souhaitable d'avoir des bases utilisateurs et une ou plusieurs des bases officielles
• à explorer : une approche "decentralisée", ie les simulations ou données peuvent avoir leur base qui peut-être ajouté à une base de bases, requêtes parallèles type "mapreduce" possible.
• à explorer : GUI pour base sqlite, comme SQLiteBrowser
• à explorer : base sans containte de format, ie les métadonnées associés à un fichier de données sont fournit par un fichier JSON. C'est le principe de la base Euclid EAS mais avec le format XML.
• à faire après une description correcte de l'ensemble des produits ie fichier ROOT, quelle métadata à conserver dans la base pour chaque produit, tâche à créer , plusieurs itérations à prévoir ...

Propositions¶

• Conserver dans un premier temps le moteur SQLlite
• Compte tenu des contraintes un ensemble de scripts sont à développer pour la gestion des bases
  • grand_db_add
  • grand_db_rm
  • grand_db_connect
  • grand_db_query
  • ...autres ?

Proposition pour le nouveau package de "simu/analyse"¶

Le package regrouperait les pipeline "officielle" de GRAND de simulation et d'analyse.

Contenu¶

• moteur de workflow, contenant aussi les scheduler
• scripts haut niveau de simulation lié ZHAireS
• scripts haut niveau de simulation lié à GRAND s'appuyant sur GRANDLIB
• scripts haut niveau d'analyse lié à GRAND s'appuyant sur GRANDLIB
• gestion de la base de données GRAND

Ce sont en fait des packages indépendants, l'espace de nom n'a pas de racine commune.

• ajout des scripts haut niveau de simulation lié Coreas
• le moteur de workflow pourrait devenir un package à part entière, ne faisant que du workflow

Nom¶

Je propose le nom de "GrandPipeline", car c'est pour GRAND et "Pipeline" car cela reste ouvert, aussi bien valable pour la simu que l'analyse

Liens avec ZHAireSRunner de Matias Tueros¶

• TheInpurGenetor : passe dans la partie ZHAireS
• TheLibraryRunner : passe dans la partie workflow
• TheLibraryAnalyst/PostProcessing : passe dans la partie ZHAireS sans doute pour la validation
• CanicalInterpolation : passe dans la partie ZHAireS

Package fork de ZHAireSRunner¶

C'est GrandPipeline dans grand-mother

Aborted