kaliveda-dev team mailing list archive

[John Frankland <1271634@xxxxxxxxxxxxxxxxxx>]

Le traitement des modules étalons (identification/coherence/calibration) a été entièrement refait
en juillet-août 2013, et testé sur les données de la 5eme campagne (dernière génération,
celle qui a été faite avec 1.8.11).

Le traitement dans 1.9 est en principe le même - en tout cas j'ai vérifié que les parties concernées
de KVINDRAReconNuc.cpp sont identiques pour les deux versions. Donc, à part les implémentations
des identifications spécifiques à chaque campagne, ça devrait fonctionner pareil.

Je viens de contrôler des données 5eme campagne derniere generation
(runs 6020-6024, Xe+Sn 32AMeV), utilisant la petite classe d'analyse ci-jointe.
Voici les résultats:

tous les codes d'identification attendus (2-5, 6, 8) sont présents, avec des distributions de Z associées qui ont un sens (i.e. Z<=4 pour idcode2, Z<=15 pour idcode3, Z<=30+ pour idcode4).
les codes d'identification correspondent bien au téléscope d'identification et au détecteur d'arrêt (i.e. idcode4:CI_CSI ou CI_SI75; particules s'arrêtant dans SI75 ont code 4 (+5,6,8))

SAUF: pour les particules identifiées en CSI_R_L (hors gamma), il y en a
~20% avec idcode5. Parmi celles-là, ~71% sont des gammas (CSI_R_L code
10), ~27% sont des isotopes H, et ~2% sont des isotopes He (et, encore
plus rare, il y a des Z>2 aussi). En regardant quelques cas particule
par particule, il s'agit de particules bien identifiées  en CSI_R_L,
toutes les autres identifications échouent (avec code 6 - point en-
dessous de la premiere ligne - ou code 8 - point en-dehors de la
grille), les CI/SI75/SILI sont proches du piedestal, et pourtant on
traite la particule comme si elle était passée à travers les étalons, en
plus on la traite comme si elle était chargée même quand elle a Z=0, et
résultat final: code d'identification général 5!

Donc il y a un bug dans la cohérence Etalons que je vais tenter de
trouver et résoudre; je vais mettre une rustine pour récupérer ces
quelques particules à l'analyse (pour la 5ème). Pour le reste des
problèmes constatés avec les données E494S, soit il y a un bug dans
l'implémentation de certaines identifications pour ces modules, soit
c'est un méchant effet de bord dû aux modifs faites dans la description
de la géométrie (qui est derrière qui? où sont les étalons? etc. etc.)
dans cette version...

** Attachment added: "ma petite classe d'analyse"
   https://bugs.launchpad.net/kaliveda/+bug/1271634/+attachment/3955107/+files/CheckEtalonModules.tar

** Also affects: kaliveda/1.8
   Importance: Undecided
       Status: New

** Changed in: kaliveda/1.8
    Milestone: None => 1.8.11

** Changed in: kaliveda/1.9
    Milestone: None => 1.9.0

** Changed in: kaliveda/1.8
     Assignee: (unassigned) => John Frankland (frankland)

** Changed in: kaliveda/1.9
     Assignee: (unassigned) => John Frankland (frankland)

** Changed in: kaliveda/1.8
   Importance: Undecided => High

** Changed in: kaliveda/1.9
   Importance: Undecided => High

** Changed in: kaliveda/1.8
       Status: New => Confirmed

** Changed in: kaliveda/1.9
       Status: New => Confirmed

-- 
You received this bug notification because you are a member of KaliVeda
Development Team, which is subscribed to KaliVeda.
https://bugs.launchpad.net/bugs/1271634

Title:
  algorithme d'identification dans les modules etalons

Status in KaliVeda data analysis framework:
  Confirmed
Status in KaliVeda 1.8 series:
  Confirmed
Status in KaliVeda 1.9 series:
  Confirmed

Bug description:
  Analyse de runs INDRA solo de e494s.
  Raw->recon, recon->ident et analyse utilisent KaliVeda 1.9.

  Un grand nombre d'incohérences est relevé dans les identifications des
  modules étalons.

  - il n'y a aucun code 4, ni CI-CsI, ni CI-SI75, alors que les grilles
  existent.

  - les particules arrêtées dans Si75 ont un code 3 et sont mal identifiées (e.g. les alphas du Cf reçoivent 
    un z=1, cette ligne Z=1 n'existe pas sur la grille CI-SI75).

  - les particules arrêtées dans le SiLi sont bien identifiées, avec un
  code 3 : OK

  - les cartes SiLi-CsI voient des z=1, identifiées en code 2. Les d et t de basse énergie sont mal identifiés (A=1), à cause du tracé  
    actuel des lignes fragment sur CsI RxL (démarre au piedestal). On maitrise cela.

  - pour les particules qui atteignent le CsI :
         1/3 a le code 2, et les identifications sont correctes. 

         2/3 ont le code 5 avec  des spectres RxL  discontinus.
             p, d, t, alphas sont correctement identifiés sur ces bouts de ligne.
             Parmi celles-ci  1/4 ont une composante lente > piedestal et une composante rapide absente (ident A=1, Z=0, ECsI=0 MeV).
              Le SiLi est au piedestal.
              Il reste des gamma (mêmes Z, A, E que ci-dessus). 

     Voila où j'en suis. Nous avons regardé les sources avec Guilain, sans comprendred'où viennet les pb. Sinon que le premier test pour voir si la particule a traversé les silicium est GetSi75 et GetSiLi, qui sont toujours présents dès que le CsI est touché, ce n'est peut-être pas assez précis. Plus loin (méthodes cohérence) il y a une vérification que tous les paramètres sont > piedestal, cela tient-il compte du piedestal variable ?
  Les valeurs chiffrées concernent le module 1002, mais les modules des couronnes 11, 12 et 13 ont le même comportement.

To manage notifications about this bug go to:
https://bugs.launchpad.net/kaliveda/+bug/1271634/+subscriptions