MicromegasFramework

From Linear_Collider_LAPP

Jump to: navigation, search

Micromegas Framework pour la reconstruction et l'analyse des données TestBeam


Contents

Démarrage rapide

1. Démarrer un serveur X si vous êtes sous Windows: http://www.nomachine.com/download.php
2. Se connecter  par ssh sur lappsl5.in2p3.fr avec l'option " Enables X11 forwarding"
prompt%> ssh -Y lappsl.in2p3.fr 
3. Importer puis compiler le code source depuis le depot Subversion
 prompt%>  svn co https://lapp-svn.in2p3.fr/subversion/groups/lc/micromegasFrameWork/trunk
                    
 prompt%>  cd trunk
 prompt%>  make all
4 Pour exécuter la reconstruction à partir de données de l'acquisition  
prompt%>  source env.csh
prompt%>  ./bin/reconstruction SteerFiles/TestBeam2012/calice_cubic_metter.xml root

Créér son propre programme d'analyse dans le Framework

1.Installer et compiler le Framework ( voir chapitre précédent )
2.Ajouter votre fichier source ( myfile.cpp ) dans le répertoire  src/analyse/root
3.Compiler le programme avec la commande suivante  
prompt%> make bin/root/myfile
4. Définisser les variables d'environements nécessaires:
prompt%>  source env.csh
5. Vérifier que votre version de ROOT correspond a celle du Framework, sinon faites le nécessaire.
prompt%>grep root-config Makefile ( Version utilisée dans le Framework ) 
prompt%>echo $ROOTSYS ( version de ROOT pour votre session en cours )


6. Exécuter votre programme
prompt%> prompt bin/root/myfile

Règles appliquées dans le Framework

Référenciel

Les objets geometriques definis dans le package "geometry" renvoient la position de leur centre

  1. getX() -> milieu de l'objet sur l'axe X
  2. getY() -> milieu de l'objet sur l'axe Y
  3. getZ() -> Les objets ont une épaisseur null sur l'axe Z
  • Les positions des Hits (MTChannel ou ChannelHit) correspondent donc au centre

des Channels ( Pad ou strip )

Les positions du centre des chambres sont definies dans le ficher xml

  • Dans un meme Run, et donc un meme fichier XML les chambres partagent le meme referenciel.
  • exemples:
<chamber type="GASSIPLEXSTRIPCHAMBER1"  xPos="3" yPos="8" zPos="0" id="1"/>
Le centre de cette chambre est en position x = 3 , y = 8 , z = 0
<chamber type="GASSIPLEXCHAMBER1"  xPos="3" yPos="8" zPos="56"
Le centre de cette chambre est en position x = 3 , y = 8 , z = 56
<chamber type="MICROROCCHAMBER6" xPos = "48" yPos = "48" zPos="156"
Le centre de cette chambre est en position x = 48 , y = 48 , z = 156

Timestamp

L'unite des timestamps en sortie de reconstruction est la millisecond.
Les timestamps sont calculés depuis le 1 janv 1970
Jean Jacquemier 15.10.09

Définition d'un run et d'un événement Microroc DAQ LAbview

  1. Le programme de reconstruction crée un evenement par lecture Dif: 1 événement == 1 lecture de tous les chips d'une Dif
  2. Le programme merge fusionne ces evenements par GlobalTriggerCounter identiques

Définition d'un run et d'un événement Microroc DAQ XDAQ

  • Le programme de reconstruction crée un evenement par lecture lcioEvent

Donc 1 événement == 1 lecture de tous les chips de toutes les Dif contenues dans une collection RU_XDAQ. Tous les hits de cet evenement ont les memes bcId_abs et bcId_dif, mais des bcid_hit differents

Définition d'un run et d'un événement Hardroc + Dirac

A la suite de la reunion du 14 octobre 2009. Il est decidé que:

    1. / Dans le fichier ROOT cree lors de la reconstruction:

- 1 Arbre (TTree) par Run - 1 Run correspond a 1 prise de données réelles. - Dans un Run il ne peut y avoir qu' une cofiguration de DIF et de Hardroc

    1. / Definition d'un evenement créé lors de la reconstruction :

- Hardroc + Dirac: 1 événement == 1 lecture de tous les chips d'une Dif (donc il peut y avoir des MTChannel avec des timestamps différents dans un MTEvent ) - Gassiplex : 1 événement == 1 Trigger PM == 1 ecriture Gassiplex Jean Jacquemier: octobre 2009.

Reconstruction des calibration Dirac

- Pour l'instant, seul les calibrations avec 1 chip sont autorisé. - Les chamberId, dif Id, boardId et chip id doivent impérativement etre égal a 1

Les valeurs "charge" lues dans les fichiers brutes sont stockées dans le parametre analogValue de la classe ChannelHit

Calcul de la période de Bunch crossing.

la période de Bunch crossing d'une DIF est obtenue en additionnant les valeurs de low_register et high_register de la DIF.
Jean Jacquemier: octobre 2009
*** 
*** ceci demande à connaître ce que sont précisément ces valeurs et où les trouver
*** il faut en outre savoir si ces données sont valables pour Hardroc1 et/ou Hardroc2 et/ou Dirac
*** Laurent Fournier - 15.10.2009


Réponse de Guillaune:  les termes de low_register et high_register n'existe que pour le DIRAC. Mais c'est bien ce qui te permet de connaitre la période de la clock et donc du BCID pour ce chip.
Pour les HRs, tu auras dans la prochaine version du format de données un bit qui selon qui soit à 1 ou 0 te donnera l'information si la clock du BCID tourne à 5MHz ou 2.5MHz.
Guillaume Vouters 24.03.2010

Erreur de numerotation des chips Hardroc1

Pour contourner l'erreur de numerotation des chips  hardroc1
il faut inverser le bit via une symetrie axiale. 12345678 <-> 87654321
=> Concerne uniquement les Hardroc1
Jean Jacquemier: juillet 2009

Suppression de la première ligne des données HR1

la première ligne de chaque hardroc qui repond a chaque lecture Dif  est à enlever           
pour les HR1 lors de la prise de données avec XDAQ.
C'est a dire que lorsque vous reconstruisez des données pour les HR2, il
n'y a plus besoin de skiper cette première ligne que ce soit avec des
fichiers venant de XDAQ ou LABVIEW, et lorsque vous reconstruisez des
fichiers de calibrations LABVIEW pour les HR1, il n'y a pas besoin non
plus de supprimer cette première ligne. 
Pour de ce qui est de skiper les lignes avec BCID Hardroc a 0 ou 1, ceci est valable
pour les HR1 et HR2, seulement pour les fichiers venant de XDAQ. C'est a
dire que lors des calibrations avec LABVIEW, pas besoin de les supprimer.
Guillaume Vouters: 18 septembre 2009
.
Dans la reconstruction pour les Hardroc 1, les données sont considérées comme erronnées dans les conditions suivantes :
- il s'agit de la première ligne de chaque chip d'une DIF (une liste des DIFs est maintenue à cet usage),
- le BcId d'un hit (pour chaque chip) vaut 0 ou 1, testé pour chaque chip.
Laurent Fournier, 15.10.2009

Unicité des Dif Id

Chaque DIF a son propre numéro et du coup on ne pourra pas avoir 2 
DIFs avec le même numéro et donc 2 chambres avec des DIFs avec le même 
numéro.
Guillaume Vouters 12 octobre 2009

Banir les methodes GetSize() et GetEntries()

Sur un objet de type MTEvent, pour connaitre le nombre de hits (MTChannel) il faut utiliser la methode
evt->GetNchannel() et banir les methodes GetSize() et GetEntries()
Les MTChannel sont ranges dans un TCLoneArray de la classe MTEvent.
Pour ganger du temps lors de la reconstruction on utilise l'operateur C++ "new with placement"  a la place de  
l'operateur new standard.
Ceci permet de ne pas refaire de reservation memoire a chaque evenement mais d'utiliser la memoire qui n'est  
plus utilisee ( on gagne egalement le temps de liberation de la memoire )
L'inconvenient de cette methode est que nous reserve 1000 MTChannels par defaut dans un MTEvent est donc la  
reponse de l'appel GetEntries sur le TCloneArray retourne systemeatiquement 1000 .
Il faut donc proscrire l'appel a cette méthode et utiliser GetNChannel() a la place.
Jean Jacquemier 19 octobre 2009

Mesh and Drift voltage

Les valeurs de Drift and Mesh voltage sont a mettre dans la classe MTEvent ( prises de données toutes les sec ) Max 14 octobre 2009


Nombre de chip maximum par DIF

Les valeurs A3 et A0 (160 et 163 ) ne peuvent pas etre affecte comme chip id. Sinon le programme de reconstruction Dirac ne fonctionnera pas. Guillaume 09-11-09


Period de Bunch Crossing de la DIF

Il est nécessaire de connaitre la periode de bunch crossing de la DIF pour calculer le timestamp d'un événement. Guillaume et Cyril ajouterons donc cette valeur dans le données de Slow Control Jean 23-03-10

Documention Doxygen du code source

http://lappweb.in2p3.fr/LC/Doxygen/pro/classes.html

Documention Doxygen de ILCConfigDB pour accès a la base de donnée oracle

http://lappweb.in2p3.fr/LC/Doxygen/ILCConfdb/html/index.html

Modélisation UML

http://lappweb.in2p3.fr/LC/Misc/UML/framework_uml/index.html

Accès aux différentes versions du code géré avec Subversion

https://lapp-svn.in2p3.fr/viewvc/viewvc.cgi/lc/

Definition des tags SVN

  • Tag dictionary_4: Version validé du code de reconstruction avec les donnees du test beam septembre 2009 pour

Gassiplex, hardroc1 et hardroc2. Version 4 du dictionnaire ROOT

Types de Detecteurs pris en charge:

  • On utilise un repère orthonorme
 X 
/\
 |
 |
 | 
 x------> Y   
Z Rentrant
Suivent des vues cote PAD ( vue de dessous pour les electroniciens. Avec l'axe Z rentrant )
et les DIFs a gauche


  • GASSIPLEX

- Beta 2.1 : 1 Chambre composee de 1 Board composee de 96 Chip composes de 1 Channel : XML Steername: GASSIPLEXCHAMBER1

Board display for GASSIPLEXCHAMBER1 Chip display for GASSIPLEXCHAMBER1

- Beta 2.4 : 1 Chambre composee de 4 Board composees de 96 Chip composes de 1 Channel : XML Steername: GASSIPLEXCHAMBER4

Board display for GASSIPLEXCHAMBER4 Chip display for GASSIPLEXCHAMBER4

-Gassiplex Strip: Chambre composant de 1 GassiplexStripBoard de 96 Chip composes de 1 Channel: XML Steername GASSIPLEXSTRIPCHAMBER1

  • longeur des pads 10 cm
  • largeur des pads 250 micron
  • Il y a 96 pads tous les un a cote des autres, sur une seul ligne.
  • longeur chambre: 10 cm
  • largeur de la chambre: 250 micron * 96 = 24000 micron soit 2,4 cm

Les pads peuvent etre dans le sens vertical ou horizontal

  • Gassiplex avec stip horizontal

Board display for GASSIPLEXSTRIPCHAMBER1 avec strip horizontal

  • Gassiplex avec stip vertical

Board display for GASSIPLEXSTRIPCHAMBER1 avec strip vertical

  • Gassiplex numerotation STRIP <-> ADC

N umero des strip et ADC


  • HARDROC1

- ASU Test Beam 2009 et calibration: 1 Chambre (Hardroc1Chamber) composee de 1 PCB ( Hardroc1Board) composee de 4 Chip HR1 (Hardroc1Chip ) composees de 64 Channel ( Hardroc1Channel ) : XML Steername: HARDROC1CHAMBER

Board display for HARDROC1CHAMBER Chip display for HARDROC1CHAMBER Channel display for HARDROC1CHAMBER

  • HARDROC2

- 1 ASU "Calibration 2009" : 1 Chambre ( Hardroc2Chamber ) composee de 1 ASU ( Hardroc2Board ) compose de 24 Chip HR2 (Hardroc2Chip ) composes de 64 Channel ( Hardroc2Channel )  : XML Steername: HARDROC2CHAMBER1

Board display for HARDROC2CHAMBER1 Chip display for HARDROC2CHAMBER1 Channel display for HARDROC2CHAMBER1

- 2 ASU  : 1 Chambre ( Hardroc2Chamber ) composee de 2 ASU ( Hardroc2Board ) composes de 24 Chip HR2 (Hardroc2Chip ) composes de 64 Channel ( Hardroc2Channel )  : XML Steername: HARDROC2CHAMBER2

Board display for HARDROC2CHAMBER2 Chip display for HARDROC2CHAMBER2 Channel display for HARDROC2CHAMBER2

- 6 ASU  : 1 Chambre ( Hardroc2Chamber ) composee de 6 ASU ( Hardroc2Board ) composes de 24 Chip HR2 (Hardroc2Chip ) composes de 64 Channel ( Hardroc2Channel )  : XML Steername: HARDROC2CHAMBER6

Board display for HARDROC2CHAMBER6 Chip display for HARDROC2CHAMBER6

- 5 ASU "metre carre" : 1 Chambre ( Hardroc2Chamber ) composee de 5 ASU ( Hardroc2Board ) composes de 24 Chip HR2 (Hardroc2Chip ) composes de 64 Channel ( Hardroc2Channel )  : XML Steername: METRECARRECHAMBER

Board display for Image:METRECARRECHAMBER.jpg Chip display for METRECARRECHAMBER


  • DIRAC

- DIRAC : 1 Chamber composee de 1 Board composee de 1 Chip : XML Steername: DIRACCHAMBER1


  • MICROROC

- 1 ASU "Calibration 2011" : 1 Chambre ( MicrorocChamber ) composee de 1 ASU ( MicrorocBoard ) compose de 24 Chip MR (MicrorocChip ) composes de 64 Channel ( MicrorocChannel )  : XML Steername: MICROROCCHAMBER1

- 6 ASU "CTest Faisceau 2011" : 1 Chambre ( MicrorocChamber ) composee de 6 ASU ( MicrorocBoard ) compose de 24 Chip MR (MicrorocChip ) composes de 64 Channel ( MicrorocChannel )  : XML Steername: MICROROCCHAMBER6

- 1 ASU Test  : 1 Chambre ( MicrorocChamber ) composee de 1 ASU Test ( MicrorocBoard ) composes de 1 Chip MR (MicrorocChip ) composes de 64 Channel ( MicrorocChannel )  : XML Steername: MICROROCTESTCHAMBER


  • Mettre Carre Microroc 1 et 2
  1. distance entre partie active d'un ASU a l autre: 5 mm
  2. distance entre pad: 0.2 mm ( uniquement pour les pad qui sont sur un meme ASU )
  3. longueur des PAds: 9.8mm



  • MICROCCHAMBER4MR

- Chambre generique, composee de:1 Asu par chamber, 4 chip Microroc par asu, 1 Dif, resistive ou pas

  • STANDARDMICROCCHAMBER

- 1 Asu par chamber, 4 chip Microroc par asu, 1 Dif

  • RESENTEREEMICROROCCHAMBER

- Couche résistive avec sérigraphie enterrée, 1 Asu par chamber, 4 chip Microroc par asu, 1 Dif

  • RESMOTIFMICROROCCHAMBER

- Couche résistive avec sérigraphie de surface ( par motif ) 1 Asu par chamber, 4 chip Microroc par asu, 1 Dif

  • RESVIAMICROROCCHAMBER

- Couche résistive avec via 1 Asu par chamber, 4 chip Microroc par asu, 1 Dif

Fichier de configuration au format XML

Les fichiers de configuration sont les même pour la reconstruction et l'analyse.

  • Espace de nom:
<micromegas xmlns:run="http://lappweb.in2p3.fr/LC">
  • Information sur le Run
 <run name="run01"/>
 <info date="040409"/>
  • Detail du fichier de slow control. Le framework lit le fichier de slow control, genere au CERN en test faiceau par labvieuw, en fonction des paramètres suivants:
 <slowcontrol path="/lapp_data/LC/Detecteurs/MicroMegas/data/TB2009/May/SlowControl/slowControl_tb2009.txt">
   <scParam scId="0"  type="timeStamp"    id="0" name="timeStamp" />
   <scParam scId="1"  type="chamber"      id="0" name="Beta2.1D" />
   <scParam scId="2"  type="chamber"      id="1" name="Beta2.1E" />
   <scParam scId="3"  type="chamber"      id="2" name="Beta2.1A" />
   <scParam scId="4"  type="chamber"      id="3" name="Beta2.4" />
   <scParam scId="5"  type="chamber"      id="4" name="ASU7" />
   <scParam scId="6"  type="chamber"      id="5" name="ASU4" />
   <scParam scId="7"  type="PM"           id="0" name="PM1" />
   <scParam scId="8"  type="PM"           id="1" name="PM2" />
   <scParam scId="9"  type="PM"           id="2" name="PM3" />
   <scParam scId="10" type="PM"           id="-1" name="dummy(2 double)" />
   <scParam scId="11" type="PM"           id="3" name="PMAlice1" />
   <scParam scId="12" type="PM"           id="4" name="PMAlice2" />
   <scParam scId="13" type="chamber"      id="-1" name="dummy(4 double)" />
   <scParam scId="14" type="chamber"      id="-1" name="dummy(4 double)" />
   <scParam scId="15" type="chamber"      id="-1" name="dummy(4 double)" />
   <scParam scId="16" type="pressure"     id="0" name="pressure" />
   <scParam scId="17" type="overPressure" id="0" name="overPressure" />
   <scParam scId="18" type="temperature"  id="0" name="temperature" />
 </slowcontrol>


  • Fichiers d'acquisition avec des données brutes.
 <input path="./data/hardroc/bck_310509_191343_1.cfg" type="crossdaq" />
 <input path="./data/hardroc/bck_060609_163355_1.cfg" type="crossdaq" />
  • Fichier de sortie au format ROOT
 <output path="./data/hardroc/bck_060609_163355_1.root" />
  • Detecteur information.
  1. L'unité des positions xPos, yPos et zPos est le centimètre, mais il est possible de la changé en utilisant le mot clef "unit"
-meter  "m" 
-decimeter "dm"
-cetimeter "cm"
-millimeter "mm"
-micrometer "um"
  1. Exemple avec des chambres Hardroc
 <detector name="TB2008" description = "Detector du TB2008 utilise au CERN pendant le Test Beam 2008">
    <chamber type="HARDROCKCHAMBER1" xPos = "0" yPos = "0" zPos= "0" unit="mm" id = "1" > 
      <dif id = "13" >
        <board type = "HARDROCKBOARD" id = "0">
          <chip id =  "1" /> <chip id =  "2" /> <chip id =  "3" /> <chip id =  "4" />
        </board>
      </dif>
    </chamber>
    <chamber type="HARDROCKCHAMBER1" xPos = "0" yPos = "0" zPos="10" id = "4">
      <dif id = "16" >
        <board type = "HARDROCKBOARD" id = "1">
          <chip id =  "1" /> <chip id =  "2" /> <chip id =  "3" /> <chip id =  "4" />
        </board>
      </dif>
    </chamber>
    <chamber type="HARDROCKCHAMBER1" xPos = "0" yPos = "0" zPos="20" id = "7">
      <dif id = "11" >
        <board type = "HARDROCKBOARD" id = "2">
          <chip id =  "1" /> <chip id =  "2" /> <chip id =  "3" /> <chip id =  "4" />
        </board>
      </dif>
    </chamber>
  </detector>
</micromegas>

Soft Id

OFFSET_CHAMBER 1 000 000 000 // 1 000 000 000
NB_CHAMBER     100  // chamber id on 2 digit

OFFSET_DIF     10000000 //10 000 000
NB_DIF         100  // diff id on 2 digit

OFFSET_CHIP    100000 // 100 000
NB_CHIP        1000  // chip id on 3 digit

OFFSET_COLUMN  100
NB_COL         100  // col id on 2 digit

OFFSET_ROW     1
NB_ROW         100  // row id on 2 digit


    SoftId =
    OFFSET_CHAMBER * chamber Id   ( Max 99 chambers)
  + OFFSET_DIF     * dif Id       ( Max 99 dif by chamber)
  + OFFSET_CHIP    * chip Id      ( Max 999 chip by dif )
  + OFFSET_COLUMN  * column       ( Max 99 column by dif )
  + OFFSET_ROW     * row          ( Max 99 row by dif )


Pour retrouver les Id a partir d'un channel soft id:

chamberId = ( fSoftId / OFFSET_CHAMBER ) % NB_CHAMBER;
diffId = ( fSoftId / OFFSET_DIF ) % NB_DIF;
chipId = ( fSoftId / OFFSET_CHIP ) % NB_CHIP;
row = ( fSoftId / OFFSET_ROW ) % NB_ROW;
col = ( fSoftId / OFFSET_COLUMN ) % NB_COL;

Mapping Maicroroc 2

Mapping microroc 2

Timestamp et BCID

Origine de temps

  • Le donnee du SlowControl du CERN sont datees a partir du 1 janv 1904 et sont en seconde
  • le script python pour le slowcontrol ( tools/slowControlConcat.py), converti les timestamp en milliseconde depuis le 1 janv 1970
  • La reconstruction des hardroc genere des timestamp en milliseconde depuis le 1 janv 1970
  • Les données gasipplex ont des timestamp en seconde, depuis le 1 janv 1904.

La recontruction les convertit en milliseconde depuis le 1 janv 1970 La classe Event donne un timestamp en millisecond alors que pour la classe Lcio::Event le timestamp en exprimé en nano seconde

HR1

Données écrit par la DIF

  • timestamp (32 bits) de la DIF en second * 1000. (1 janv 1970)
  • DIF Trigger counter -> Donnée non conservée dans les données reconstruites
  • Acq Trigger counter -> Donnée non conservée dans les données reconstruites
  • Global Trigger counter -> Donnée non conservée dans les données reconstruites
  • Absolute BCID ->BCID très long pour se repérer dans un run de manière précise
  • Time DIF Trigger counter -> BCID like synchronisé avec celui des HRs (permet de retrouver précisément le moment ou la particule est passée dans les données des HRs)

Event timestamp

Event timestamp = globalTime + ( bcid_absOrg + bcperiod / 1000 ) millisecond

avec:

  • globalTime = timestamp DIF (voir ci dessus)
  • bcid_absOrg = Absolute BCID (voir ci dessus)
  • bcperiod = 200


Hit timestamp et bcid

  • timestamp = globalTime
  • bcid_abs = Absolute BCID (voir ci dessus)
  • bcId_dif = Time DIF Trigger counter (voir ci dessus)
  • bcId_hit = BCID (24 bits) envoye par le chip Hardroc1
  • bcId_Fine = 0

HR2

  1. t(hit) = t(lecture) - t2 + t3
  2. l(lecture) = t0 + (t1 - t10)
  • t0 = timestamp unix (32 bits, avec ou sans millisecondes)
  • t1 = BcId absolu (bcId_Abs, 48 bits)
  • t10 = premiere lecture de t1
  • t2 = BcId pour la DIF (bcId_HRHit, 24 bits)
  • t3 = BCId pour la HR (bcId_Hit, 24 bits en CODE GRAY

CaloEvent

slcio et MTEvent

  • Le DAQ XDAQ opère en mode RAM Full, donc de nombreux événements (passage de particules dans le detecteur) sont écrits dans le

même evenement LCIO.

  • Après le reconstruction les évenements MTEvent sont des copies de ces évenements LCIO dans notre propre format.

construction des CaloEvent

  • Pour construire événements distincts, les hits d'un événement MTEvent sont ordonnés dans le temps en utilisant leur temps BCID.
  • La réponse du calorimètre à une particule incidente, est l'enregistrement de beaucoup de hits avec le même temps BCID.
  • La figure ci-dessous montre le nombre de hits sur l'axe vertical en fonction du temps BCID pour un évenement LCIO

image:Bcid.jpeg

  • Un temps BCID contenant plus de 15 hits définit la graine d'un événement CaloEvent
  • Les hits adjacents à cette graine dans un intervalle de ± 5 cycles sont ajoutés pour former un événement.
  • Les graines doivent être distantes de plus de 5 cycles pour ne pas etre rejetées. Ceci afin d'éviter de mélanger

des hits provemant de particules incidentes differentes.

  • Par conséquent événements sont séparés par 5 cycles BCID et donc d'au moins 1 ms.

Analyse

Root data type Rappel: 1 byte <=> 8 bits


       * Char_t Signed Character 1 byte (char)                   -> [-120,126]
       * UChar_t Unsigned Character 1 byte (unsigned char)       -> [0   ,255]
       * Short_t Signed Short integer 2 bytes (short)            ->[-32 768 , 32 767]
       * UShort_t Unsigned Short integer 2 bytes (unsigned short)->[0       , 65 535]
       * Int_t Signed integer 4 bytes (int)                      ->[-2 147 483 646,2 147 483 646]
       * UInt_t Unsigned integer 4 bytes (unsigned int)          ->[0             ,4 294 967 295]
       * Float16_t Float 4 bytes written with a truncated mantissa
       * Float_t Float 4 bytes (float)
       * Double32_t Double 8 bytes in memory, written as a 4 bytes float
       * Double_t Double 8 bytes
       * Long64_t Portable signed long integer 8 bytes
       * Long_t Signed long integer 8 bytes (long)
      
       * ULong64_t Portable unsigned long integer 8 bytes
       * ULong_t Unsigned long integer 8 bytes (unsigned long)

Logiciels d'acquisition

Liste des logiciels utilités pour l'acquisition de données ainsi que leur TAG pour les fichier XML "steerfile"

TAG à utiliser dans le fichier XML "steefile" par chip et par logiciel d'acquisition
Hardroc1 Hardroc2 Microroc Microroc format donnee < 14 Dirac Gassiplex Dif_synchro
XDAQ IPNL xdaqHR2 xdaqMR
Labview acquisition labviewHR2 labviewMR labviewOldMR labviewDirac difSynchro
Labview test Microroc testMicroroc testMicroroc
Labview calibration calibHR1 calibHR2 calibMicroroc calibMicroroc
ancien XDaq ( avant 2009 ) crossdaqHR1 crossdaqHR2
Centaure centaure

Status Labview au 1er decembre 2009

Cyril, voici le compte rendu de notre discussion de ce matin à propos des logiciels existants labview pour la calibration et l'acquisition:

- Hardroc1

  - logiciel: Acquisition_4HR1_V*   ( Même logiciel pour acquisition et calibration )
    - 2 formats de fichier différents
        -1 Calibration: Fichier TEXT:
           En  entête:  Informations sur calibration puis sur des lignes différentes les données DIF + Hardroc1
        -2 Acquisition: Fichier TEXT
             Configuration (SC )des chip +   donnees DIF et Hardroc1 ( identique au format crossdaq )

- Hardroc 2

   -logiciel:  Acqusition_48HR2_V* ( Même logiciel pour acquisition et calibration  )
    - 2 formats de fichier différents
       -1 Calibration: Fichier TEXT ( très proche de fichier calibration HR1 )
           En en entête:    Information sur calibration puis sur des lignes différentes les données DIF + Hardroc2
       -2 Acquisition: Fichier TEXT

Configuration (SC )des chip + donnees DIF et Hardroc2 ( identique au format crossdaq )

- Dirac:

  - logiciel : Acquisition_nASU_1dirac2 ( Même logiciel pour acquisition et calibration  )
    -   - 2 formats de fichier différents
        -1 Calibration: Fichier TEXT:
            En en entête:  Information sur calibration + données decodee voie/voie
       - 2 Acquisition Ficher binaire:
              Configuration (SC )des chip +   donnees DIF et Dirac


Tests a réaliser: ( Jean ) - Acquisition HR1 + HR2

 tester la lecture des données labview HR2 avec le parser Crossdaq, les données doivent être semblables. La configuration des Chip (SC ) est également présente dans les fichiers générés par Labview


Modification à apporter : ( Cyril )

1/ Calibration HR1 + HR2 
- Ajouter la configuration ( SC  ) des Chip sur une ligne a la fin de l'en tete.
- Ces données de configuration auront le même format que celle dans CrossDaq
2/ Calibration Dirac ( à confirmer avec renaud. )
- Ajouter le SC des Chip sur une ligne a la fin de l'entête
- Modifier le format des données pour qu'il soit identique au format acquisition. 


 -Passer en format bianire pour Acq HR avec labview


Test des MicroRoc et calibration des ASU avec MicroRoc

- Les MicroRoc ont des numero de serie de 1 à plus de 300.Mais dans le slowcontrol les chip id sont codés sur 8 bits, donc de 0 a 255

- Solution pour associer les numero de serie des chips aux ID des chips sur les ASU:

  • Les Microroc sont testés 1 à 1. Le programme Labview "test MicroRoc" ajoute en début de fichier résultat le numero de série du Chip.
  • Le programme de reconstruction ( dans le framework) utilisera ce numero de serie et l'enregistrera dans la Classe MicrorocChip#serialNumber
  • Une fois les meilleurs MicroRoc sélectionnés et intégré sur les ASU, il faudra faire un fichier de correspondance ( à la main ) entre les id des Chips

sur un ASU et le numero de série des chip.

  • Exemple:
Relation entre MicroRoc serial Number est chip Id sur 8 bits pour un ASU
Serail Number sur ASU 1 Serail Number sur ASU 2 Serail Number sur ASU 3 Serail Number sur ASU 4 Serail Number sur ASU 5 Serail Number sur ASU 6
Chip ID 1 123 321 004 005 007 035
Chip ID 2 321 123 023 023 322 124
Chip ID ... 043 098 209 283 321 245
Chip ID 24 213 297 013 172 063 253


Ajout du parametre dif Synchro au données SLAB

utiliser addDifSynchro


Fusion ( Merge ) des evenements

Il existe plusieurs type de merge.

1/ Merge des TTree Slab entre eux.

Apres avoir reconstruit un Run avec plusieurs fichiers SLAB, il faut utiliser: - merge option -g Ce programme fusionne les événements ayants les même GlobalTriggerCounter un nouveau fichier root contenant les evenement fusionnées est créé, il porte le nom du fichier en entrée + _GT ( GlobalTrigger)


2/ Merge TTree Slab avec TTree AHCAL:

- merge option -g Ce programme fusionne les événements ayants les même Dif_Synchro

Procedure reconstruction complete

1/ Reconstruire un fichier root avec les fichiers brutes de 1 a n SLAB, et un fichier brute Dif_Syncrho. : Utiliser le programme "reconstruction"

=> On obtient 1 fichier root avec 1 TTree DifSynchro et n TTree Slab


2/ Ajouter le paramètre DifSynchro aux TTree de données venant des SLAB: Utiliser "addDifSynchro"

=> On obtient 1 nouveau fichier root ( extendion _DS est ajouté au nom de fichier ) avec n TTree SLAB ( Le TTree difSynchro n'étant pas conservé dans le nouveau fichier)


3/ Fusionner 2 ou plus TTree Slab en un seul TTree metre carré. La fusion se fait ave le paramètre GlobalTriggercounter :utiliser "merge avec option -g"

=> On obtient 1 nouveau fichier root ( extendion _MGT est ajouté au nom de fichier ) contenant 1 seul TTree avecpour chaque événement la fusion des 3 Slabs


4/ Convertir un fichier AHCAL lcio en fichier Root avec un TTree Micromegas LAPP au format de notre framework. Utilisé "ahcalReco".

=> On obtient 1 nouveau fichier root contenant 1 seul TTree


5/ Fusionner plusieurs TTree Slab et un TTree AHCAL en un seul TTree metre carré. La fusion se fait ave le paramètre Dif Synchro :utiliser "merge avec option -d"

=> On obtient 1 nouveau fichier root ( extendion _MDS est ajouté au nom de fichier ) contenant 1 seul TTree avec les hits des 3 slabs plus du AHCAL

Base de Donnée Numero Microroc

Image:Emplacement composant M2 MetreCarre N°2.pdf



Reconstruction de la lecture analogique avec les Microroc

  • Il est décidé en réunion technique ( 21 juin 2011 ) que:
  1. la lecture analogique serait systematiquement faite avec la lecture digitale, Il y a donc deux possibilités:
    1. Lecture digitale seules.
    2. lecture digitale + analogique.
  2. Le trigger se déclenchera a partir de la meche. Donc pour chaque lecture analogique, correspondra forcement une lecture digital. Donc un bloc C0 D0 correspondera

forcement avec un bloc B0 A0

  • On utiliser les informations de la Dif pour crée un Hit qui contiendra des données analogique et numérique.


  • Cyril et Jean decide qu'un nouveau format de donnée sera crée pour la lecture digitale + analogique. Format 12
  • Changement de stratégie.
  1. Il est désormais possible de reconstruire des Hits anaologiques seuls (sans hit digital) en activant l optin forceanalog

du programme bin/reconstruction. ATTENTION ces hit n'auront pas de valeur bcId_hit.

Reconstruction Gassiplex avec Centaure

Lors de l enregistrement d'un evenement gassiplex, Centaure force l ecriture d'une valeur pour chaque Channel; donc 96 valeures par chip. Le programme de reconstruction affecte les 96 premieres valeures a la Chambre dont l'id est le plus petit dans le fichier XML Ensuite; si c est une chambre avec 4 Chip il affecte alors les 3*96 valeures suivantes a la meme chambre, sinon a la chambre qui a l id juste superieur


Reconstructiondes donnees Microroc analogique du TestBeam August 2011

Durant les prises de donn'ees analogique avec les microroc en Aout 2011 au SPS, le code des Dif ne fournissait pas les valeurs Absolute_DIF et BCID DIF.

Donc il n' est pas possible de faire de coupure en temps sur ces bcid.

Il est donc decider ( dans le bureau de Max, en presence de Renaud et Jean le mardi 23 Aout 2011 ) de:

  • conserver tous les hits digital.
  • affecter une valeur analogique uniquement au hits digital enregistres en dernier dans la memoire du Microroc.
  • aucun hits analogique pur sera enregistré
  • si le flag -forceanalog est egal 1, alors on crée en plus, tous les hits analogiques


Modification suite au test beam de Desy juillet 2013 ( dans le bureau de Max et Jean le lundi 29 juillet 2013): Les proto Splam ont 2 voies bruyantes sur 2 chip differents. -> DeltaT negatif (???) -> Les valeurs analogiques sont donc attribues a des hit digitaux incohérents( 1er dans la memoire ) Donc modification du parser: Si lecture analogique : -> conserver tous les Hit digital -> affecter au hit digital la valeur analogique correspondante si DeltaT compris entre 0 et 2. Et non plus au premier hits dans la memoire

LowRegister, HighRegister, AfterRegister, BeforeRegister

Les 4 registres LowRegister, HighRegister, AfterRegister, BeforeRegister ne sont pris en compte que pour le Dirac Il est donc normal que ces valeurs soit null pour le run avec les autres Chips


Logbook version Excel

/LC/Detecteurs/MicroMegas/Offline/micromegasFrameWork/trunk/src/analyse/TB2011/Testbeam_august_2011/bokkeeping_tb_august_2011.xls


Reconstruction des données Testbeam aout 2011 au SPS

  1. A partir de la version SVN 1286 ( TAG production_1.0 ) Le programme de fusion des événements venant des 3 Slab et du télescope ( ./bin/root/merge ) s'assure désormais que le global trigger counter des chacun des dernières événement de chacun des arbres sont identiques. Ceci pour s'assurer de la bonne synchronisation des données. Dans le cas ou cette vérification n'est bonne bonne, aucun merge n'est fait.
  2. Chaque reconstruction ou merge doit être noté dans le fichier Excel servant de bookkeeping. /LC/Detecteurs/MicroMegas/Offline/micromegasFrameWork/trunk/src/analyse/TB2011/Testbeam_august_2011/bookkeeping_tb_august_2011.xls Note : Ce fichier est accessible également depuis Windows.

Notez:

  • Le nom du fichier roor après reconstruction
  • Le nom du fichier roor après merge
  • La revision SVN du framework utilisé
  1. Chaque fichier root ( fusionne ou non ) doit être copié ici:
/lapp_data/LC/Detecteurs/MicroMegas/data/TB2011/SPS_H4_aug_2011/Production

Ceci pour permettre aux autres utilisateurs de procéder a des analyses sur ces fichiers.


Mise a jour de la base de donnée

  1. A partir de la revision 1385 le programme de reconstruction et celui de merge mette automatiquement

a jour la base de donnée si les fichiers brutes sont présents dans la base de donnée au lancement de ces programme.


Correspondance entre AsicConfiguration dans la base de donnée Oracle et des parametres des Chips Microroc


Pour le Chip:

  • ThresholdDac_0 : BB0
  • ThresholdDac_1 : BB1
  • ThresholdDac_2 : BB2
  • Shaper_lg (low shaper) :SWLG
  • Shaper_hg (high shaper):SWHG
  • chid Id  :HEADER
  • Bypassed : True si il n'y a pas de d'info pour ce chip dans le SlowControl, sinon false
  • Gain : Uniquement utilisé pour les chips Dirac et Hardroc

Pour la channel ( voie )

  • pedestal offset: B0B3
  • stimulate: CTEST
  • enable: transformé en mask0 , mask1 et mask2 ( avec les methodes GetMask0() correspondantes )

Acces a la geometrie dans l'analyse via la base donnee

  • Il est desormais possible de recuperer pendant l'analyse toutes les informations de la geometrie du detecteur

utilisee pendant la reconstruction

  1. Ainsi on peut trouver:
    1. le type d'une chambre ( MICROROCCHAMBER6, HARDROCIPNLCHAMBER6 ... ) a partir de l'id d'une Chambre
    2. Les coordonnées d'un chambre
    3. ...
  • Cela n'est possible que pour le Run reconstruit via la production "officielle"


  • example pour des CaloHit
int main(int argc, char**argv){
  if ( argc !=2  ) {
  FILE_LOG(logERROR)  << "usage: caloExample rootFile " << endl;
  exit(1);
 }
 Detector detector;
 string rootName;
 rootName.assign(argv[1]);
 int nbHit = 0;
 int nbEvt = 0;
 TFile f(rootName.c_str());
 TIter nextkey(f.GetListOfKeys());
 TKey *key;
 while (key = (TKey*)nextkey())
 {
   TString keyname = key->GetName();
   TTree *tree = (TTree*)key->ReadObj();
   cout << "---------------------------- NEW TTREE ---------------------------"<< endl;
   nbEvt =0;
   nbHit = 0;
   unsigned int runId = 0;
   try {
     CaloRun *run=dynamic_cast<CaloRun *>(tree->GetUserInfo()->First());
     if ( run != NULL)
     {
       runId =  run->GetRunId() ;
       cout << "RunId[" << run->GetRunId() << "] " << endl ;
     }
   }
   catch ( ... ) {}
   Detector detector;
   Toolbox::getDetector(runId,detector);
   CaloEvent *evt =  new CaloEvent();
   TBranch *branch= tree->GetBranch("CaloEvent");
   branch->SetAddress(&evt);
   CaloHit* hit =NULL;
   int nbEntries = tree->GetEntries();
   for ( int evtNum = 0; evtNum < nbEntries ; evtNum++)
   {
     tree->GetEntry(evtNum);
     nbEvt++;
     int nbHits = evt->GetNHits();
     for(int i=0 ; i < nbHits ; i++)
     {
       hit = (CaloHit*)evt->GetHits()->UncheckedAt(i);
       Int_t layer = hit->GetLayer();
       Chamber& chamber = detector.getChamberById(layer);
       cout << "Hit in chamber id " << layer <<", chamber type " << chamber.getType() << endl;
     }
   } // end event
 } // end run ( TTree )
return 0;
}


Classement des Hits dans le temps

Lors de la reconstruction les Hits sont ajoutés au MTEvent dans l'ordre ou XDaq les a enregistrés. A priori, ces hits sont enregistrés lecture de RAMFULL de chip par chip. Donc pas dans un ordre chronologique.

Procedure pour classer les Hits dans un ordre chronologique

  • Les BCID_Dif et BCID_Hit sont synchro. Ce sont des compteurs sur 24 bits avec une horloge à 200ns.

Ils sont remis a zero quand le compteur atteint sou maximum (toutes les 3.3554432 sec) ou quand la Dif recoit un stop acquisition (RAMFULL ou trigger)

  • Pour classer les hits chronologiquement dans un MTEvent:
temps absolu = BCID_Abs + ( BCID_Dif - BCID_Hit )
  1. Si le resultat de (BCID_Dif - BCID_Hit) est négatif, c'est qu'il y a eu une erreur de l'ecletronique, l'evenement n'est donc pas valide.


Définition des FLAGS pour la reconstructuion

  1. define VALID 0x1
  2. define UNKNOW_NOT_VALID 0x2
  3. define BAD_CHIP_ID 0x4
  4. define BAD_BOARD_ID 0x8
  5. define BAD_DIF_ID 0x10
  6. define CRC_ERROR 0x20
  7. define ONLY_FFFF 0x40
  8. define ONLY_AAAA 0x80
  9. define ONLY_5555 0x100
  10. define GLOBAL_HEADER_ERROR 0x200
  11. define FRAME_HEADER_ERROR 0x400
  12. define TRAILER_C3_FOUND 0x800
  13. define END_OF_FILE_ERROR 0x1000

Event Display

  • Cet Event Display permet de visualiser des événements de type MTEvent et CaloEvent

Mode d'empoi

  • La procédure qui suit utilise le login lcdet, mais vous pouvez aussi le faire ave votre propre login et votre Framework

= Lancement

  1. Se loger sur lappsl5 en tant que lcdet
  2. prompt%> cd framework/trunk/
  3. prompt%> source env.csh
  4. prompt%> ./bin/root/EventDisplay /lapp_data/LC/data/TB2012/SPS_H2_19_to_28_nov_2012/Production/CaloHits/CaloHit_DHCAL_716578_I0_0.slcio.root SteerFiles/TestBeam2012/19_28_nov_h2.xml

Utilisation

Boutons

  • Image:Openfile.png Ouvrir un fichier de données
  • Image:Openxmlfile.png Ouvrir un fichier XML contenant la geométrie
  • Image:Nextprev.png Affiche l'evenement précédent ou suivant
  • Vous pouvez également entrer directement le numero de l'évenement a afficher
  • Image:Zoomplusmoins.png Zoom +/- pour la visualisation 3D
  • Image:Quit.png Quitte l'application
  • Un fichier XML valide doit etre ouvert avant des pouvoir utiliser les 3 boutons suivants:
  • Image:Colorhit.png Utilise des couleurs différentes pour les hits Micromegas et RPC
  • Image:Filter.png N'affiche que les hits Micromegas
  • Image:Geometrie.png Affiche les chambres en plus des hits

L'histogramme de la partie gauche de l'application

  • Cet histogramme contient les DeltaT de chaque hits.
  • Si vous sélectionnez une partie de l'axe X alors seuls les hits ayant

un DeltaT dans la fenêtre sélectionnée seront affichés sur le graphique 3D

  • Les DeltaT min et max des hits sont affichés de part et d'autre du curseur

Le curseur DeltaT au dessus des graphique

  • Ce curseur permet de filtrés les hits ayant

un DeltaT dans la fenêtre sélectionnée.

  • Vous pouvez ajuster ce curseur à gauche, à droite ou le déplacer
Personal tools