Guide pratique pour utiliser la DAQ
Étude des MRPCs au dome
Listes des machines utiles
-
MongoDB ASIC/Configuration/Runs: lyoilcdaq01 (CC IN2P3 Proxmox)
-
MQTT Broker/MongoDB: lyoilc07 (Bureau 210-Laurent)
-
Graphyte/Grafana: lyocms09 (dôme -CMS)
-
SY127: lyoilcdaq01 (CC IN2P3 Proxmox)
-
Wiener : lyoilcdaq01 (CC IN2P3 Proxmox)
Redémarrage du PC (lyosdhcal11)
Normalement tout le software nécessaire est installé sur lyosdhcal11 et les services nécessaires sont automatiquement redémarrés au boot.
Avant de lancer quelques commandes, il faut définir un certain nombre de variables d'environnement qui sont dans le fichier
.pmdaqsetup :
source /usr/local/pmdaq/etc/pmdaq.bashrc
export PNS_NAME=lyosdhcal11.in2p3.fr
export MGDBLOGIN=acqxxx/RPCyyyyy@lyocmszzzz:27017@LYONROC
export DAQMONGO=test_dif:4
export DAQSETUP=TESTMRPC2025
Le fichier pmdaq.bashrccontient principalement les PATH vers les librairies et les scripts:
- PNS_NAME est le nom du PC où le service de nom de la daq est executé
- MGDBLOGIN est l'account de la base donnée pour les paramètres des ASICs et le configurations de DAQ
- DAQMONGO est la version de configuration de la daq à utiliser
- DAQSETUP est le nom de l'expérience
La configuration definie par DAQMONGO peut etre vu en utilisant mgjob:
mgjob --download --name test_dif --version 4
et on obtient dans /dev/shm/mgjob/test_dif_4.json dans lequel les 3 processus (Event builder, Controle du trigger et lecture de l'ASU) sont declares:
{
"apps": [
{
"host": "lyosdhcal11.in2p3.fr",
"instance": 0,
"name": "evb_builder",
"params": {
"collectingPort": 5556,
"directory": "/data/local/MRPC/",
"processor": [
"proc_binarywriter"
],
"purge": 0
},
"port": 7777
},
{
"host": "lyosdhcal11.in2p3.fr",
"instance": 0,
"name": "lyon_ipdc",
"params": {
"device": "DCCCCC01",
"spilloff": 10000,
"spillon": 2000000,
"spillregister": 64
},
"port": 7777
},
{
"host": "lyosdhcal11.in2p3.fr",
"instance": 0,
"name": "lyon_pmr",
"params": {
"dif": {
"db": {
"mode": "mongo",
"state": "TEST_DIF",
"version": 1
},
"geom": [
[
8,
0
]
]
}
},
"port": 7777
}
],
"pns": "lyosdhcal11.in2p3.fr",
"session": "test_dif",
"type": "daq",
"version": 4
}
Après avoir sourcer ce fichier:
source .pmdaqsetup
on peut redémarrer les service de daq pmdaq et pns
sudo service pns restart
sudo service pmdaq restart
De manière générale chaque fois que pmdaq est redémarré on peut espionné le processus avec la command spylog
alias spylog='ps -laef | grep pmd | awk '\''{print "tail -f /tmp/pmd"$4".log"}'\'' | /bin/bash - '
Il suffit de relancer la commande dans un terminal chaque fois que l'on aura redémarrer le service pmdaq
Démarrage de prises de données
Visualisation et contrôle des données de slow control
L'ensemble des capteurs et des alimenations sont contrôlés par MQTT et accessible via une page web:
Logging
On peut se déconnecter/reconnecter si l'on a pas d'accès au hardware, la connection au broker MQTT pouvant être parfois instable
Contrôle de la basse tension
La basse tension est faite par l'alimentation GENESYS contrôlée par le board pico feb_lv
Une fois la LV mise ON , on doit voir la DIF sur la chambre s'allumer. Les 2 sorties USB de la DIF sont connectées au PC via un hub et l'on peut vérifier dans un terminal que le board est bien vu avec:
sudo ListDevices.py
On obtient ainsi la liste des devices FTDI connectés et on doit normalement voir apparaître la connexion a l'IPDC DCCCCC01 et celle au PMR numéro 8 FT101008
Contrôle de la haute tension
La haute tension est fournie par une alimentation CAEN SY1527 contrôlée par un processus Sy1527Pico qui tourne sur lyocms09, si l'accès à cette alimentation
n'apparaît pas , il faut se connecter à lyocms09 et lancer
sudo service Sy1527Pico restart
sudo service Sy1527Pico status
puis faire un disconnect/connect dans l'onglet Broker.
On doit obtenir:
qui permet le contrôle de tous les canaux de la SY1527.
Remarque
Un accès console est aussi possible avec
telnet lyoac28 1527
Mesure des paramètres environnementaux
Plusieurs capteurs sont lus par des boards rapsberry PICO : des capteurs Bosch BME280 mesurant P,T,H, et des capteurs d'humidité dans le gaz Honeywell HIH8000.
Les valeurs lues sont publiées sous MQTT et sont accessibles dans l'onglet P/T/H Status
On peut bien évidemment noter les valeurs au début de chaque prise de données mais il est aussi possible de corriger continûment la haute tension de canaux spécifiés en fonction des valeurs lues de pression et température
Correction de la HV avec le service hvcontrol
Normalement nous devons corriger continûment la haute tension pour les variations de pression et de température. Ceci est réalisé par le service linux hvcontrol dont la configuration est faite par le fichier /etc/hvcontrol.json
{
"broker":"lyoilc07.in2p3.fr",
"port":1883,
"session":"pico_dome",
"dp_temperature":"pico_dome/telescope_inlet/hih",
"dp_pressure":"pico_dome/cms_inlet/bme",
"dp_wiener":"pico_dome/dome_iseg/CMD",
"dp_caen":"pico_dome/dome_caen/CMD",
"csv_file":"/home/acqilc/algeco/drivehv.csv"
}
-
Les tags broker, port, et session définissent l'accès au broker
-
dp_temperature donne le chemin vers les messages de température à utiliser
-
dp_pression donne le chemin vers le capteur de pression BME280
-
dp_wiener et dp_caen sont les chemins vers le contrôle de HV pour les alimentions ISEG ou le crate SY1527
-
Enfin csv_file est le nom du fichier utilisé pour spécifier la/les HV désirée(s)
Dans notre cas où un seul canal de HV est utilisé le fichier csv se réduit à:
channel,hvset,hvmin,hvmax,type
5,10000,1000,15000,1
Mais par exemple pour la tour de détecteur Pulsalys on a:
channel,hvset,hvmin,hvmax,type
0,0,0,8000,0
1,500,100,8000,0
2,1200,100,8000,0
3,500,100,8000,0
4,1200,100,8000,0
5,1200,100,8000,0
6,1200,100,8000,0
7,500,100,8000,0
8,500,100,8000,0
0,500,100,10000,1
1,500,100,10000,1
2,500,100,10000,1
3,500,100,10000,1
La colonne type est le type d'alimentation contrôlée 0=Wiener, 1=SY1527
Pour chaque nouvelle publication de la pression P, le programme calcule pour chaque canal la valeur de HV à appliquer pour celle requise dans la colonne hvset ensuivant la formule suivante:
def calVset(Vreq,P,T,unit="K",b=0.2,a=0.8):
P0=990
T0=293.15
corr=b+a*(P/P0*T0/(T))
if (unit!="K"):
corr=b+a*(P/P0*T0/(T+273.15))
return (Vreq*corr)
# et l'appel se fait avec
vreq=calVset(self.channels[k]["vset"],self.P,self.T,unit="C",b=0,a=1.0)
print(k,self.channels[k]["vset"],vreq,self.channels[k]["vlast"])
if (vreq<self.channels[k]["vmin"]):
continue
if (vreq>self.channels[k]["vmax"]):
continue
if (abs(vreq-self.channels[k]["vlast"])<5):
continue
La HV est donc modifié si elle est entre hvmin et hvmax et que la différence par rapport à la dernière valeur est supérieure à 5 V.
Prise de données
Utilisation de combdaq
On va utiliser le script combdaq pour interagir avec les processus pmdaq
Ce script analyse le fichier de configuration de la daq et envoie les transitions ou les commandes aux processus enregistrés. C'est pour cela que les variables suivantes sont définies dans le fichier .pmdaqsetup
export PNS_NAME=lyosdhcal11.in2p3.fr
export MGDBLOGIN=acqXXX/RYYYY@lyocmsmu04:27017@LYONROC
export DAQMONGO=test_dif:4
export DAQSETUP=TESTMRPC2025
PNS_NAME donne accès à l'état de la daq définie par le configuration spécifiée par DAQMONGO stockée dans la base accessible par MGDBLOGIN . Le dernier tag DAQSETUP est utilisé pour récupérer un numéro de run différent pour chaque setup.
On a défini un certain nombre d'alias pour simplifier les appels principaux
alias CONFIGURE='combdaq--daq-configure'
alias INIT='combdaq --daq-initialise'
alias PAUSE='combdaq --trig-pause'
alias REGISTER='combdaq --daq-register'
alias REMOVE='combdaq --jc-destroy'
alias RESTART='combdaq --daq-restart'
alias RESUME='combdaq --trig-resume'
alias RUN='combdaq --daq-start'
alias SPY='combdaq --daq-status'
alias STOP='combdaq --daq-stop'
alias VIEW='combdaq --jc-info'
Initialisation et commandes utiles
Pour réinitialiser une prise de donnée on commence par retirer tous les plugins des instances de pmdaqutilisée avec:
REMOVE
On peut ensuite recharger ces plugins et initialiser les accès au hardware (bus USB, Ethernet, base de données) avec:
INIT
On peut ensuite visualiser l'état des processus avec:
SPY
Il faut ensuite configurer la carte trigger et le front-end. La configuration de l'IPDC dépend du mode de fonctionnement désiré et cela va être décrit dans les sections suivantes:
Run Piédestal
Pour un run de piédestal on peut utiliser la suite de commandes que l'on trouve dans
/home/acqilc/algeco/newconf/start_pedestal
# Settings par défaut du trigger
combdaq -M CALIBON -A lyon_ipdc -P '{"value":0}'
combdaq -M CALIBOFF -A lyon_ipdc -P '{}'
combdaq -M SETCALIBCOUNT -A lyon_ipdc -P '{"nclock":0}'
combdaq -M SPILLOFF -A lyon_ipdc -P '{"nclock":1000}'
combdaq -M SPILLON -A lyon_ipdc -P '{"nclock":100000000}'
# On déclenche les fenêtres de manière interne
combdaq -M SETEXTERNAL -A lyon_ipdc -P '{"value":0}'
combdaq -M LEMOMASK -A lyon_ipdc -P '{"value":0}'
combdaq -M SETSPILLREGISTER -A lyon_ipdc -P '{"value":64}'
# Seule les busy provenant de la carte centrale sont utilisé
combdaq -M ENABLE -A lyon_ipdc -P '{"value":5}'
# pas de trigger externe pour la lecture des ASICs
combdaq -M TRIGEXT -A lyon_pmr -P '{"value":0}'
#
# Choix de la configuration des paramètres des ASICs
#
combdaq --daq-downloaddb --name lyon_pmr --dbstate=MRPC_G128 --dbversion=8
#
# Configurations des ASICs
#
CONFIGURE
#
# Choix de seuils de départ et reconfiguration
#
combdaq -M SETTHRESHOLDS -A lyon_pmr -P '{"B0":120,"B1":1000,"B2":1000}'
#RUN --comment "test ped"
#combdaq -M SCURVE -A lyon_pmr -P '{"last":190,"first":70,"channel":255,"step":1,"ntrg":30,"window":15000,"level":0}'
On peut ensuite démarrer un run de piédestal
RUN --comment "test ped"
#
# SCurve de 190 à 70 sur tous les canaux(255) par pas de 1 avec 30 fenetres
# de 15000 clock et sur le seuil 0
#
combdaq -M SCURVE -A lyon_pmr -P '{"last":190,"first":70,"channel":255,"step":1,"ntrg":30,"window":15000,"level":0}'
On espionne avec spylog pour voir la progression et on envoie
STOP
une fois le scan terminé.
On peut également parcourir le gain de chaque canal pour un seuil donné avec:
RUN --comment "test gain curve"
#
# Scan de gain entre 2 et 256 sur tous les canaux(255) par pas de 1 avec 30 fenetres
# de 15000 clock et pour un seuil B0 à 130
#
combdaq -M GAINCURVE -A lyon_pmr -P '{"last":256,"first":2,"channel":255,"step":1,"ntrg":30,"window":15000,"threshold":130}'
que l'on espionnera et arrêtera de la même manière.
Run normal
Un run normal utilise le mécanisme de busy et de fenêtre sans déclenchement externe. Le script de configuration se trouve dans /home/acqilc/algeco/newconf/start_normal :
combdaq -M CALIBON -A lyon_ipdc -P '{"value":0}'
combdaq -M CALIBOFF -A lyon_ipdc -P '{}'
combdaq -M SETCALIBCOUNT -A lyon_ipdc -P '{"nclock":0}'
combdaq -M SPILLOFF -A lyon_ipdc -P '{"nclock":1000}'
combdaq -M SPILLON -A lyon_ipdc -P '{"nclock":100000000}'
combdaq -M SETEXTERNAL -A lyon_ipdc -P '{"value":0}'
combdaq -M LEMOMASK -A lyon_ipdc -P '{"value":0}'
combdaq -M SETSPILLREGISTER -A lyon_ipdc -P '{"value":4}'
combdaq -M ENABLE -A lyon_ipdc -P '{"value":5}'
combdaq -M TRIGEXT -A lyon_pmr -P '{"value":0}'
combdaq --daq-downloaddb --name lyon_pmr --dbstate=MRPC_G128 --dbversion=8
CONFIGURE
combdaq -M SETTHRESHOLDS -A lyon_pmr -P '{"B0":130,"B1":1000,"B2":1000}'
La seule différence avec les runs de calibration est la valeur de SETSPILLREGISTER=4 qui permet un réarmement automatique de l'envoi de fenêtres d'acquisition en l'absence de busy.
Un run peut ensuite être démarrer avec les deux commandes suivantes
RUN --comment "Un test de run continu"
# relache l'envoi de fenetre
RESUME
#
# Si l'on veut faire une pause dans le run on peut utiliser
# le mecanisme PAUSE/RESUME
PAUSE
RESUME
#
# Enfin on arrete le run avec STOP
#
STOP
Ce type de run est intéressant pour étudier le bruit, ou si plusieurs chambres sont lues simultanément pour acquérir le maximum de traces
Run cosmique avec PMs
Dans ce dernier cas, la fin de fenêtre peut être déclenché par l'arrivée d'un déclenchement externe et la lecture n'est effectuée que si ce déclenchement a été vu (Reset sinon)
Le fichier de commandes de configuration se trouve dans /home/acqilc/algeco/newconf/start_mrpc
combdaq -M CALIBON -A lyon_ipdc -P '{"value":0}'
combdaq -M CALIBOFF -A lyon_ipdc -P '{}'
combdaq -M SETCALIBCOUNT -A lyon_ipdc -P '{"nclock":0}'
combdaq -M SPILLOFF -A lyon_ipdc -P '{"nclock":1000}'
combdaq -M SPILLON -A lyon_ipdc -P '{"nclock":100000000}'
#
# Les 2 commandes suivantes definissent l'utilisation
# d'un trigger externe dans la gestion des fenetres
#
combdaq -M SETEXTERNAL -A lyon_ipdc -P '{"value":2}'
combdaq -M LEMOMASK -A lyon_ipdc -P '{"value":2}'
combdaq -M SETSPILLREGISTER -A lyon_ipdc -P '{"value":4}'
combdaq -M ENABLE -A lyon_ipdc -P '{"value":5}'
#
# La commande suivante evite la lecture des ASICs en l'abscence de trigger
#
combdaq -M TRIGEXT -A lyon_pmr -P '{"value":1}'
combdaq --daq-downloaddb --name lyon_pmr --dbstate=MRPC_G128 --dbversion=8
CONFIGURE
combdaq -M SETTHRESHOLDS -A lyon_pmr -P '{"B0":145,"B1":1000,"B2":1000}'
La prise de donnée est ensuite identique à celle faite en mode NORMAL
Scan en Haute Tension
Le scan en haute tension se fait après la configuration en mode NORMAL ou cosmique . Il utilise le fichier csv défini dans /etc/hvcontrol.json pour modifier la HV demandée sur la chambre et enchaîne les runs pour chaque tension désirée.
Le programme mrpcscan se trouve dans /home/acqilc/algeco. Il est guidé par le fichier JSON /home/acqilc/algeco/scan.json, ce dernier pouvant être modifié ou changé (dernière ligne de mrpcscan)
{
"default_hv":{
"caen_5":[5,8000,1000,15000,1]
},
"channels":[[5,1]],
"list":[8000, 8500, 9000, 9500, 10000, 10500, 11000],
"minutes":40,
"comment":"Scan MRPC 4gaps 3 (mylar) 7 points 8kV to 11kV 40min",
"pmr":{
"db_state": "MRPC_G128",
"db_version": 8,
"B0": 145,
"B1": 1000,
"B2":1000
}
}
Le tag default_hvredéfinit le fichier local drivehv.csv (qui est celui spécifié pour le démon hvcontrol)
Le tag channels est la liste de canaux à scanner , ici le canal 5 sur le crate de type 1
Le tag list est la liste de points en HV à effectuer.
minutes est la durée de chaque run, comment est le commentaire à ajouter a chaque run.
Enfin pmr spécifie les paramètres à appliquer lors de la configuration de chaque PMR au début de chaque run.
Le programme boucle sur la liste de points HV, modifie le fichier drivehv.csv pour chaque canal spécifié, reconfigure les PMR avec les valeurs données dans pmr et démarre un run de 40 minutes avec un commentaire commençant par comment et contenant la valeur de HV de chaque chambre et le tag pmr
Outils d'analyse
J'ai installé mon software d'analyse rocanalysis sur le PC d'acquisition il est disponible sous gitlab
Il contient un ensemble de software de reconstruction à partir des fichier de données créés par pmdaq
Rocanalysis
Configuration
Sur lyosdhcal11, rocanalysis est installé dans /home/acqilc/rocanalysis. Les scripts pour utiliser le soft sont dans le sous-répertoire test_mrpc
cd /home/acqilc/rocanalysis/lmana/test_mrprc
source doinit
export PYTHONPATH=../scripts:$PYTHONPATH
Le programme principal btrse trouve dans /usr/local/rocanalysis/bin il doit analyser un fichier JSON lui donnant la localisation des données ainsi que les plugins de reconstruction à utiliser. Un script process.shet un fichier JSON template2025.json sont fournis pour automatiser le processing des runs:
{
"plugins":[
"proc_hr2Reco","proc_pmrReco"
],
"reco":{
"hr2":{"histos":3,"nplans":1,"wmin":6,"wmax":7},
"pmr":{"clusters":1,"tracks":0,"histos":1,"store":0,"display":0,
"trees":0,
"track_algo":{
"minpoint":1,
"dcut":2.75,
"pcut":0.03
}
}
},
"runs":
[
[RUNNUMBER,"/data/local/MRPC/","SMM_25*_*"]
],
"process":
{
"directory":"/home/acqilc/rocanalysis/lmana/test_mrpc/results/",
"maxEvents":2000000,
"firstEvent":0,
},
"setup_desc": {
"file":"/home/acqilc/rocanalysis/lmana/test_mrpc/etc/DOME_MRPC_SETUP.json"
}
}
Le script process.sh remplace RUNNUMBER par le numéro de run XXX et crée le fichier /tmp/runXXXX.json puis lance btr sur ce fichier en background et redirige les log dans /tmp/runXXX.log
On peut donc faire:
./process.sh 1234
tail -f /tmp/run1234.log
pour processer et surveiller l'analyse du run 1234. Les histogrammes sont écrits dans le répertoire spécifié sous le nom:
/home/acqilc/rocanalysis/lmana/test_mrpc/results/histo1234_0.root
Remarques
La géométrie et la connectique sont décrites dans le fichier de setup_desc
Le tag plugins décrit les différents plugins appelés dans l'ordre et leur paramètres
Les 3 fichies de géométrie sont les suivants:
MRPC_DOME_1.json
{
"_id": 1,
"comment": "Setup description for MRPC test",
"content": {
"geometry_desc": {
"file":"/home/acqilc/rocanalysis/lmana/etc/geometry/MRPC_CHAMBERS_1.json"
},
"sdhcal_desc": {
"file":"/home/acqilc/rocanalysis/lmana/etc/geometry/MRPC_DIFS_1.json"
}
},
"geom_type": "setup_desc",
"name": "MRPC_DOME",
"time": 1683730825.7968464,
"version": 1
}
MRC_CHAMBERS_1.json
{
"_id": 1,
"comment": "MRPC position",
"content": {
"chambers": [
{
"id": 0,
"name": "slot-0",
"num": 0,
"plan": 0,
"type": "ASU",
"x0": -0.42,
"x1": 50.0,
"y0": 0.0,
"y1": 32.86,
"z0": 95.17,
"z1": 95.17
}
]
},
"geom_type": "geometry_desc",
"name": "MRPC_CHAMBERS",
"time": 1675259763.3072646,
"version": 1
}
MRPC_DIFS_1.json
{
"_id": 1,
"comment": "DIFS list for MRPC",
"content": {
"difs": [
{
"chamber": 0,
"di": 0,
"dj": 0,
"id": 8,
"poli": 1,
"polj": 1,
"pos": "C",
"type": "HR2PAD"
}
]
},
"geom_type": "sdhcal_desc",
"name": "MRPC_DIFS",
"time": 1683730407.9910915,
"version": 1
}
Analyse des Scurves
Pour les Scurves, on fait varier un de 3 seuils B0,1 ou 2 et l'on compte le nombre de fois où un canal est touché dans N fenêtres, sachant que le canal est échantilloné à 5 MHz. On obtient ainsi pour chaque canal i un histogramme /Reco/hr2/D#dif/A#asic/B01SCURVE/Padc#canal i dont la transition vers 0 marque le piédestal et la largeur le bruit:
Sur cett image , on note un nombre de coup saturant à 3700 pour un B0 inférieur à 96 (le piédestal). Sachant que on a pris 29 fenêtres par point de B0 et que les ASICs saturent à 27 échantillons on voit qu'en dessous de 96 on écahntillone continuement. La largeur de la transition, ajustable par une fonction erf nous permet de mesurer le bruit. Cependant on note une queue de signal jusqu'à B0=125 correspodant à un bruit piqué par le setup
Le script rocanalysis/lmana/scripts/fitpmr.py contient une analyse systematique de tous ces histogrammes. On ajoute d'abord le répertoire dans le path:
export PYTHONPATH=/home/acqilc/rocanalysis/lmana/scripts:$PYTHONPATH
python
et dans python
import fitpmr as fr
for i in range(1,25):
fr.fithr2(1273,8,i,"B01SCURVE",76,200,draw=True)
où
- 1273 est le numero de run
- 8 est le numéro de DIF
- 76 est la valeur de B0 minimale
- 200 est la valuer de B0 maximale
On obtient ainsi une vue des piédestaux et du bruit de chaque canal.
Par exemple pour l'ASIC 22 qui correspond à la connection de la masse de la HV on a sur ce run le résumé suivant dans le fichier output/run1273/pmr8/summary_pedestal_D8_A22.txt:
| Canal | < Pedestal> | Noise | Maximum |
|---|---|---|---|
| 0 | 93.5 | 1.1 | 111.50 |
| 1 | 89.5 | 1.1 | 99.50 |
| 2 | 88.5 | 1.2 | 99.50 |
| 3 | 88.5 | 1.1 | 99.50 |
| 4 | 87.5 | 1.8 | 98.50 |
| 5 | 87.5 | 1.3 | 99.50 |
| 6 | 88.5 | 1.0 | 100.50 |
| 7 | 88.5 | 1.1 | 101.50 |
| 8 | 88.5 | 1.7 | 98.50 |
| 9 | 87.5 | 1.1 | 98.50 |
| 10 | 88.5 | 1.1 | 98.50 |
| 11 | 88.5 | 1.6 | 99.50 |
| 12 | 88.5 | 1.1 | 99.50 |
| 13 | 89.5 | 1.0 | 101.50 |
| 14 | 88.5 | 1.2 | 96.50 |
| 15 | 88.5 | 1.0 | 99.50 |
| 16 | 87.5 | 1.5 | 96.50 |
| 17 | 87.5 | 1.3 | 98.50 |
| 18 | 87.5 | 1.1 | 96.50 |
| 19 | 104.5 | 1.0 | 107.50 |
| 20 | 88.5 | 1.5 | 96.50 |
| 21 | 87.5 | 1.1 | 99.50 |
| 22 | 88.5 | 1.2 | 97.50 |
| 23 | 88.5 | 1.3 | 98.50 |
| 24 | 88.5 | 1.3 | 98.50 |
| 25 | 88.5 | 1.8 | 97.50 |
| 26 | 87.5 | 1.0 | 98.50 |
| 27 | 87.5 | 1.1 | 96.50 |
| 28 | 87.5 | 1.3 | 96.50 |
| 29 | 88.5 | 1.2 | 101.50 |
| 30 | 91.5 | 1.0 | 101.50 |
| 31 | 87.5 | 1.4 | 99.50 |
| 32 | 88.5 | 1.2 | 96.50 |
| 33 | 104.5 | 1.2 | 107.50 |
| 34 | 88.5 | 1.2 | 101.50 |
| 35 | 86.5 | 1.1 | 95.50 |
| 36 | 86.5 | 1.2 | 96.50 |
| 37 | 88.5 | 1.3 | 96.50 |
| 38 | 87.5 | 1.2 | 98.50 |
| 39 | 88.5 | 1.0 | 100.50 |
| 40 | 88.5 | 1.1 | 99.50 |
| 41 | 88.5 | 1.0 | 99.50 |
| 42 | 87.5 | 1.1 | 95.50 |
| 43 | 88.5 | 1.2 | 96.50 |
| 44 | 103.5 | 1.2 | 105.50 |
| 45 | 99.5 | 1.1 | 101.50 |
| 46 | 87.5 | 1.4 | 96.50 |
| 47 | 89.5 | 1.0 | 97.50 |
| 48 | 89.5 | 1.0 | 98.50 |
| 49 | 88.5 | 1.0 | 102.50 |
| 50 | 88.5 | 1.2 | 97.50 |
| 51 | 88.5 | 1.0 | 146.50 |
| 52 | 90.5 | 1.0 | 190.50 |
| 53 | 89.5 | 1.1 | 182.50 |
| 54 | 87.5 | 1.8 | 90.50 |
| 55 | 88.5 | 0.9 | 158.50 |
| 56 | 88.5 | 1.0 | 103.50 |
| 57 | 87.5 | 1.0 | 98.50 |
| 58 | 88.5 | 1.2 | 97.50 |
| 59 | 88.5 | 1.8 | 98.50 |
| 60 | 87.5 | 1.0 | 96.50 |
| 61 | 89.5 | 1.1 | 98.50 |
| 62 | 89.5 | 1.0 | 98.50 |
| 63 | 90.5 | 1.1 | 98.50 |
On peut voir les courbes de cet ASIC sur le plot AllStripR1273_D8_A22.pdf:
Et l'on remarque les pistes très bruyantes ainsi que celles dont le piédestal est déplacé.
Malheureusement on ne peut pas ajuster les piedestaux dans l'asic HardRoc mais on peut ajuster le gain par canal.
On note que la majorité des pistes ne présente aucun bruit au delà de B0 130. On peut donc essayer de modifier le gain de tous les canaux pour que le maximum vu n'excède pas 130.
Analyse des GainCurves
Par défaut le gain de tous les canaux était fixé à 128 pour l'étude des piédestaux. On va dans cette étude fixer le seuil à B0=130 et faire varier le gain entre 0 et 255 par pas de 2 et acummuler les hits pendant plusieurs fenêtres. On obtient pour chaque canal un histogramme du type /Reco/hr2/D#dif/A#asic/GCURVE/Padc#canal i dont le premier bin touché définit le gain maximal applicable (<255) pour un seuil B0 à 130.
Par exemple le canal 19 de l'asic 22 nous donne:
on voit que le gain sur ce canal peut être augmenter jusqu'à 140. Par contre sur le canal 53 qui était un des canaux bruyant identifié sur cet asic on a:
et on devrait réduire le gain à 50 pour ne pas avoir de signaux avec un seuil à 130.
En appelant dans python la fonction suivante:
import fitpmr as fr
fr.fitgainasu(1274,8,24,"MRPC_G128",1,"MRPC-3gap-may2025 ajustement en gain B0 130")
On obtient un résumé par ASIC des gains à appliquer dans les fichiers du type
output/run1274/pmr8/asic22/summary_gain.txt mais surtout le fichier summary_gain1274.py des corrections de gains applicables pour modifier le state de base de données initial:
import MongoHR2 as mg
s=mg.HR2Instance()
s.download("MRPC_G128",1)
ga1=[205, 205, 201, 213, 169, 221, 181, 205, 209, 213, 209, 145, 128, 128, 177, 149, 153, 128, 169, 181, 128, 177, 149, 137, 169, 181, 217, 128, 221, 169, 201, 169, 255, 221, 169, 229, 221, 169, 213, 233, 229, 217, 255, 255, 169, 237, 169, 221, 128, 209, 237, 128, 229, 209, 128, 233, 128, 233, 255, 128, 255, 169, 225, 169]
s.setAsicPAGain(8,1,ga1)
ga2=[205, 213, 128, 233, 221, 128, 255, 255, 255, 255, 255, 221, 128, 169, 165, 157, 157, 255, 255, 153, 177, 161, 177, 169, 169, 241, 225, 128, 128, 169, 233, 169, 255, 128, 169, 128, 233, 169, 255, 255, 128, 255, 169, 128, 237, 255, 233, 217, 255, 255, 233, 255, 255, 229, 255, 255, 233, 128, 128, 233, 255, 128, 225, 255]
s.setAsicPAGain(8,2,ga2)
ga3=[137, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 173, 205, 165, 181, 255, 255, 157, 173, 233, 209, 229, 233, 255, 255, 255, 255, 173, 181, 173, 255, 141, 173, 255, 255, 173, 255, 229, 233, 255, 255, 255, 165, 157, 255, 255, 128, 128, 221, 229, 128, 128, 128, 128, 128, 128, 128, 128, 255, 255, 128, 157]
s.setAsicPAGain(8,3,ga3)
ga4=[255, 128, 255, 255, 255, 255, 255, 255, 255, 255, 255, 128, 255, 255, 145, 185, 185, 128, 255, 105, 201, 157, 157, 129, 205, 209, 225, 221, 217, 169, 221, 169, 233, 193, 169, 185, 255, 173, 217, 213, 181, 205, 217, 217, 201, 157, 225, 217, 221, 209, 217, 185, 201, 217, 205, 209, 197, 205, 213, 128, 217, 217, 217, 141]
s.setAsicPAGain(8,4,ga4)
ga5=[157, 169, 153, 173, 157, 181, 157, 205, 177, 157, 185, 153, 153, 141, 185, 165, 185, 217, 201, 153, 157, 185, 181, 145, 137, 153, 157, 157, 165, 153, 161, 169, 177, 89, 161, 169, 181, 153, 165, 141, 153, 157, 165, 185, 105, 109, 173, 157, 205, 157, 177, 149, 153, 165, 173, 133, 153, 157, 161, 181, 157, 153, 201, 113]
s.setAsicPAGain(8,5,ga5)
ga6=[205, 217, 205, 233, 217, 201, 221, 205, 209, 217, 255, 233, 255, 193, 193, 205, 209, 229, 221, 133, 209, 205, 205, 229, 221, 217, 221, 213, 229, 173, 217, 173, 229, 121, 173, 233, 209, 173, 197, 213, 177, 213, 221, 255, 109, 149, 128, 209, 217, 229, 213, 217, 205, 205, 233, 128, 128, 221, 233, 229, 221, 255, 255, 141]
s.setAsicPAGain(8,6,ga6)
## ...
ga22=[161, 205, 209, 217, 217, 217, 201, 181, 229, 217, 229, 209, 237, 205, 255, 221, 255, 255, 128, 129, 128, 209, 128, 229, 128, 241, 217, 128, 255, 169, 169, 169, 255, 129, 128, 255, 233, 255, 128, 201, 229, 225, 255, 255, 141, 189, 255, 255, 233, 157, 128, 97, 57, 49, 255, 73, 153, 229, 229, 128, 255, 255, 128, 225]
s.setAsicPAGain(8,22,ga22)
ga23=[221, 128, 225, 128, 255, 255, 128, 128, 221, 128, 221, 217, 128, 229, 255, 128, 255, 255, 255, 255, 128, 233, 221, 233, 128, 128, 128, 255, 255, 169, 255, 169, 255, 255, 255, 255, 255, 255, 229, 128, 128, 255, 255, 255, 255, 221, 157, 255, 255, 255, 255, 255, 229, 233, 217, 225, 225, 255, 128, 255, 128, 255, 255, 255]
s.setAsicPAGain(8,23,ga23)
ga24=[255, 141, 255, 255, 255, 255, 255, 255, 255, 255, 255, 128, 255, 255, 255, 255, 255, 128, 225, 255, 128, 255, 255, 255, 255, 255, 255, 255, 255, 128, 255, 128, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 157, 255, 133, 213, 113, 255, 149, 255, 255, 255, 255, 255]
s.setAsicPAGain(8,24,ga24)
s.uploadChanges("MRPC_G128","MRPC-3gap-may2025 ajustement en gain B0 130")
Evidemment on exécute le fichier ainsi créé:
python summary_gain1274.py
Remarque
Il se peut que l'ecriture sur /dev/shm/mgroc ne soit pas autorisée, dans ce cas faites:
sudo chmod o+w /dev/shm/mgroc
sudo rm /dev/shm/mgroc/*.json
Analyse des runs de bruits
L'ensemble des procédures précédemment décrites sont réalisées avec une tension faible (< 2 kV) sur la chambre RPC. Néanmoins à plus haute tension des points chauds peuvent apparaitre et s'ils sont peu nombreux, peuvent être masqués.
En processant un run en mode normal avec le plugins hr2Reco on crée les histogrammes /Reco/hr2/ASIC/D#dif/XY qui est une carte du bruit de la DIF:
On note 2 pads bruyants que l'on peut visualiser sur /Reco/hr2/ASIC/D#dif/Pads, une projection de tous les pads avec des bins contenant les hits
On voit que ces pads sont dans l'ASIC 21 et l´histogramme /Reco/hr2/ASIC/D#dif/List/A#asic/Pad1 contient la même distribution pour l'asic 21:
En analysant ces histogrammes pour les 24 ASIC et en fixant un seuil on peut masquer les canaux bruyants:
Python 3.10.12 (main, Feb 4 2025, 14:57:36) [GCC 11.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import fitpmr as fr
>>> for i in range(1,25):
... fr.findnoisy(1276,8,i,100000)
...
db.setChannelMask(8,21,4,0)
db.setChannelMask(8,21,5,0)
Il suffit de recopier ces lignes dans le fichier masknoise1276.py:
import MongoHR2 as mg
db=mg.HR2Instance()
db.download("MRPC_G128",14)
db.setChannelMask(8,21,4,0)
db.setChannelMask(8,21,5,0)
db.uploadChanges("MRPC_G128","MRPC-3gaps-May2025 2 Canaux bruyants vers la HV ")
et l'on crée la version 15 où ces 2 canaux sont masqués avec:
python masknoise1276.py
Analyse des runs de physique
Pour l'analyse des runs de physique, on utilise 2 scintillateurs+PM en coincidence comme déclenchement. Ce déclenchement ferme la fenêtre d'acquisition et les évenements physiques se situe dans une période étroite, à latence fixe (cable+processing), près de la fin de fenêtre.
Le plugin hr2Reco permet de créer des frameCluster pour tous les frames adjacent en temps se trouvant dans la période définie par wmin et wmax dans le fichier template:
"plugins":[
"proc_hr2Reco","proc_pmrReco"
],
"reco":{
"hr2":{"histos":3,"nplans":1,"wmin":6,"wmax":7},
"pmr":{"clusters":1,"tracks":0,"histos":1,"store":0,"display":0,
"trees":0,
"track_algo":{
"minpoint":1,
"dcut":2.75,
"pcut":0.03
}
}
},
A partir de ces frameCluster le plugin pmrReco reconstruits des PmrHit et des clusters (hits adjacent)