DAS Multi-détecteur Expérience Principale Détecteur 1 Détecteur 2 Détecteur N Chassis1 : Gamer Chassis2 : Gamer MUST2Système X Description de configuration.

Présentation au sujet: "DAS Multi-détecteur Expérience Principale Détecteur 1 Détecteur 2 Détecteur N Chassis1 : Gamer Chassis2 : Gamer MUST2Système X Description de configuration."— Transcription de la présentation:

1 DAS Multi-détecteur Expérience Principale Détecteur 1 Détecteur 2 Détecteur N Chassis1 : Gamer Chassis2 : Gamer MUST2Système X Description de configuration complexe multi-système : -Système « conventionnel » type MUST2 (Données issues d'une CPU) -Système avec des Gamer producteurs de données -Système externes type MIDAS...

2 DAS COMMANDE SETUP Détec 1Détec 2 Configur ation Actions Gamer 1Gamer 2 Configur ation Actions Must2 X

3 CONFIGURATION ● Configuration matérielle multi-chassis & multi-cpu ● Définition des paramètres associés au module ● Définition des Actions ● Sauvegarde et restitution ●... Remarques : Dans un premier temps on conservera la structure des répertoires actuelle soit : / /ganacq_manip/ /das-save / /ganacq_manip/ /das-save En cas de présence de Gamer il est essentiel de connaître sa fonction de producteur de données ou non. Si c'est le cas il devra être identifié par numeros IP ou Nom (si connu DNS). Cela aura une incidence sur les Actions liées au détecteur et sur le panneau de commande avec le Merger en particulier. Difficulté: le noyau C++ aujourd'hui ne gère qu'un document (une configuration), si on souhaite regrouper plusieurs configurations dans un même DAS (une seule Virtual machine) il serai bon d'étendre le noyau C++ pour qu'il manipule une liste de document. En attendant, on se contentera d'une configuration mono-détecteur mais multi-chassis & multi-(cpu- gamer)

4 ACTIONS Un fichier (ou liste) d'action est associé à chaque producteur de données (CPU, GAMER) Ainsi dans notre exemple on aura une liste d'action pour le détecteur 2, et deux pour le détecteur 1 (un pour chaque Gamer) Quatre phases sont prédéfinies dans cette liste: ● Une phase d'initialisation (executer lors du « acq init_v ») ● Une phase en début de Run (startacq) ● Une phase Trigger (à chaque déclenchement) ● Une phase en fin de Run (stopacq) Une liste de commande standard sera disponible (échelle, commande spécifique sur module....), ensuite les commandes seront orientées dans leur fichier destination (.START,.STOP, le fichier listant les actions compilé par la suite) Un mécanisme permettra de lister tous les modules susceptibles d'être lus ainsi que leurs paramètres. L'utilisateur pourra à sa guise sélectionner ceux qui devront être lu et ainsi modifier le masquage des voies.

5 COMMANDE Cette partie sera dans un premier temps partie intégrante de DAS mais devra peut-être un jour s'en détacher pour rejoindre le Run Control (à voir) Pour le moment il sera proche du précédent avec les mêmes fontionnalités MergerDétecteur 1Détecteur 2 Game r 1 Game r 2 Analyse et Tapeserver Ici le Merger a trois flux en entrée : 2 pour Détecteur1 (les Gamer) et 1 pour Détecteur2 (Must2 par ex) C'est pourquoi on doit identifier par numero IP les Gamer dans la configuration des modules.