How-to reconstruct and handle TIF data
Step-by-step:
MAIN LINKSC'e' una pagina di analisi automatizzata (che carica istogrammi).
C'e' una pagina di tracking/monitoring della ricostruzione (by Subir) [in progress]
E' disponibile anche l'e-log gestito dagli shifter della TIF.
Il forum di HN di riferimento e': hn-cms-tk-datahandling@cern.ch .
NEW DATA SCANNINGI run vengono chiusi su Castor/CERN (compito di Subir).
Pagina web TIF DATA ANALYSIS -> Data Publication
TacFileList (il colore si riferisce al trsferimento al Fermilab)
Da lxplus si fa: ssh -l cmstac cmstkstorage-giga
[cmstkstorage] /home/cmstac > cd Registration
[cmstkstorage] /home/cmstac/Registration > ps -eaf | grep Scan
cmstac 2731 1 0 Mar30 ? 00:01:19 perl ScanRunFile_TIB_data2_data3.pl
cmstac 2899 1 0 Mar30 ? 00:03:06 perl ScanRunFile_TOB_data2_data3.pl
cmstac 3140 1 0 Mar30 ? 00:00:03 perl ScanRunFile_TIBTOB_data3.pl
cmstac 7383 1 0 Mar30 ? 00:00:20 perl ScanRunFile_TIF_data2_data3.pl
cmstac 21067 1 0 Apr02 ? 00:00:02 perl ScanRunFile_TEC.pl
Questi script vengono lanciati con i comandi:
nohup perl ScanRunFile_TIB_data2_data3.pl > ScanRunFileTIB_data2_data3.log &
nohup perl ScanRunFile_TOB_data2_data3.pl > ScanRunFileTOB_data2_data3.log &
nohup perl ScanRunFile_TIBTOB_data3.pl > ScanRunFileTIBTOB_data3.log &
nohup perl ScanRunFile_TEC.pl > ScanRunFileTEC.log &
nohup perl ScanRunFile_TIF_data2_data3.pl > ScanRunFileTIF_data2_data3.log &
I run sono resi disponibili per montaggio via nfs delle aree data1, data2 e data3.
Attualmente sono in uso (e quindi vengono scansionate) solo data2 e data3.
Tipicamente si hanno run del tipo "TIB","TOB","TIB_TOB"; talvolta anche "TEC" e solo in passato "TIF".
In ogni caso gli script di scansionamento (alla caccia di nuovi run) girano tutti.
I corrispondenti file di log si trovano sempre in : /home/cmstac/Registration/. Vanno di tanto in tanto monitorati. ispezionati in caso di problemi.
Se p.es. guardiamo:
[cmstkstorage] /home/cmstac/Registration > tail -n 500 -f ScanRunFileTIB_data2_data3.log
si leggono linee del tipo:
File is /data3/EDMProcessed/TIB/dbs/EDM0007427 and Run is 0007427
Skipping EDM0007427 because it is processing or already processed
...oppure del tipo:
Processing Run 0007427 and executing perl RegisterRunInDBSDLS.pl --file=/data3/EDMProcessed/TIB/dbs/EDM0007427 --dataset=/TAC-TIB-120-DAQ-EDM/RAW/CMSSW_1_2_0-RAW-Run-0007427
Nel primo caso salta il run perche' e' gia' stato processato o e' in via di processamento; nel secondo caso invece procede ad eseguire, per il run nuovo, lo script RegisterRunInDBSDLS.pl .
I log relativi a tali operazioni vengono immagazzinati nella sotto-directory logs_[parte-del-detector] (p.es. log_TIB].
Per esempio per il run 7427: [cmstkstorage] /home/cmstac/Registration/logs_TIB > ls -tlr *EDM0007427* | more
-rw-r--r-- 1 cmstac zh 0 Apr 6 01:15 processing_EDM0007427
-rw-r--r-- 1 cmstac zh 4 Apr 6 01:36 nevt_EDM0007427_000.txt
-rw-r--r-- 1 cmstac zh 37 Apr 6 01:36 guid_EDM0007427_000.txt
-rw-r--r-- 1 cmstac zh 4 Apr 6 01:36 nevt_EDM0007427_001.txt
-rw-r--r-- 1 cmstac zh 37 Apr 6 01:36 guid_EDM0007427_001.txt
[...]
-rw-r--r-- 1 cmstac zh 3 Apr 6 02:00 nevt_EDM0007427_048.txt
-rw-r--r-- 1 cmstac zh 37 Apr 6 02:01 guid_EDM0007427_048.txt
-rw-r--r-- 1 cmstac zh 5788 Apr 6 02:01 XML_for_DBS_EDM0007427.xml
-rw-r--r-- 1 cmstac zh 76939 Apr 6 02:02 dbslog_EDM0007427.txt
-rw-r--r-- 1 cmstac zh 421 Apr 6 02:02 dlslog_EDM0007427.txt
-rw-r--r-- 1 cmstac zh 0 Apr 6 02:02 processed_EDM0007427
-rw-r--r-- 1 cmstac zh 1376 Apr 6 02:03 dbsdlsmigrate_EDM0007427.txt
Per stoppare gli script basta creare un file in /home/cmstac/Registration: touch stop_TIBTOB (gli script infatti controllano che il file non esista.
Gli script di cui sopra, uno per tipologia di dati (dare il nome di uno dei file !!!!), esegue le seguenti operazioni:
1) chiude il run (???)
2) registrare nel DLS locale (MClocal4???) ??? e fa il check (???) dell'operazione
3) migra al DBS globale (???)
A questo punto bisognerebbe controllare sulla pagina web del DBS (dare l'indirizzo!!!)
Il DB relativo e' MClocal4 e i 5 dataset son sempre quelli (piu' 2 test che non ci interessano)
Per esempio si seleziona CMSSW_1_2_0/online/FUEventProcess (???); N.B.: 1_2_0 e' la release usata per trasformare il formato RAW in EDM.
L'operazione successiva e' iniettare (la sottoscrizione dei dataset e' gia' stata fatta una volta per tutte).
DATA INJECTION
L'iniezione in Phedex viene triggerata da Phedex su pccms29.ba.infn.it
Si usa l'account con login "phed".
cd /home/phed/Prodagent_v012/prodarea
Il certificato si aggiorna come facciamo di solito nella produzione MC (vedi anche file voms.sh):
voms-proxy-init -voms cms:/cms/Role=production -valid 999:59 -cert ~/.globus_nicola/usercert.pem -key ~/.globus_nicola/userkey.pem -out ~/.globus_nicola/proxy_injection
Su pccms29 runnano 5 scripts in /home/phed/prodAgent_v012/prodarea/ :
nohup perl ScanRunInjected.pl --det=TIBTOB >logs_injected__TIBTOB &
nohup perl ScanRunInjected.pl --det=TEC >logs_injected__TEC &
nohup perl ScanRunInjected.pl --det=TOB >logs_injected__TOB &
nohup perl ScanRunInjected.pl --det=TIB >logs_injected__TIB &
nohup perl ScanRunInjected.pl --det=TIF >logs_injected__TIF &
Essi fanno lo scan del DBS globale per cercare nuovi run e in caso positivo
1) chiudono il blocco nuovo (N.B.: vi e' un blocco per ogni run il quale puo' contenere piu' root file).
2) lanciano lo script che fa l'iniezione dei dati in Phedex e li sottoscrive a Bari, Pisa e FNAL.
discutere lo scriptino ????
I dati a Bari vanno a finire in /pnfs/cmsfarm1.ba.infn.it/data/cms/phedex/store/data/2007/ ; si tratta dei soli TIB e TIB_TOB.
Bisognerebbe fare una query al DBS per tenere solo i run di fisica.
Col monitoring di Subir (link???) bisogna scoprire se oltre che verso il FNAL le migrazioni vanno anche verso Bari (perche col monitoring ??? alternative?).
RECONSTRUCTION
La ricostruzione dei dati viene fatta su pccms31.ba.infn.it.
Utente (login) prodagent. La working dir e': /home1/prodagent/Prodagent_v012/prodarea dove...
... si crea na directory per la release di CMSSW (installata in /opt?exp_soft?...) per la ricostruzione (il tag va concordato con Ciulli, Noeding ed altri).
Tipicamente, p.es.,:
scramv1 project CMSSW CMSSW_1_3_0_pre6
cd CMSSW_1_3_0_pre6/src/
se non esiste tirare giu' con cvs il sottopacchetto necessario:
cvs co -r tag_da_specificare AnalysisExamples/SiStripDetectorPerformance/test/TIF
Qui vi sono i cfg per la ricostruzione; tipicamente:
TIF_reconstruction_RealData_TIB_default.cfg, TIF_reconstruction_RealData_TIBTOB_default.cfg, TIF_reconstruction_RealData_TOB_default.cfg
Bisogna cambiare il nome ai cfg???
Nel cfg va modificato il PoolOutputModule in modo che sia come:
module DIGI-RECO = PoolOutputModule {
untracked string fileName = "TIF_reconstruction_RealData_TOB_default.root"
untracked PSet datasets ={
untracked PSet dataset1 = {
untracked string dataTier = "DIGI"
}
untracked PSet dataset2 = {
untracked string dataTier = "RECO"
}
}
}
endpath e = { DIGI-RECO }
Copiare quei (quali???) file modificati in TIF_reconstruction_RealData_${det}_${release}.cfg nella stessa directory che saranno usati per l'effettiva ricostruzione con prodagent (fai esempio di path).
In proadarea giace lo script da runnare: ScanRunRecoSummary.pl; viene eseguito con i comandi:
nohup perl ScanRunRecoRunSummary.pl --det=TOB --version=CMSSW_1_3_0_pre6 --onlyphysics=NO > logs_reconstructed__TOB_CMSSW_1_3_0_pre6 &
nohup perl ScanRunRecoRunSummary.pl --det=TIBTOB --version=CMSSW_1_3_0_pre6 --onlyphysics=NO > logs_reconstructed__TIBTOB_CMSSW_1_3_0_pre6 &
nohup perl ScanRunRecoRunSummary.pl --det=TIB --version=CMSSW_1_3_0_pre6 --onlyphysics=NO > logs_reconstructed__TIB_CMSSW_1_3_0_pre6 &
Lo script cerca nuovi file di dati da ricostruire ogni mezz'ora. Crea anche un file per tener traccia di cosa e' stato gia' sottomesso.
Per far cio' (sicuro?)
Query al DBS TAC_TIBTOB_120_DAQ_EDM/DIGI o RECO
lista in proddatasetlist.txt + lista run di fisica RunSummaryPhysList.txt con query sul DB della TIF al cern
il vettore del datasetpath e' dato da prodatasetlist.txt o da matchedPhysRun.txt
@myfilelist contiene i dataset da ricostruire
adesso bisogna fare i relativi workflow, uno per ogni run.
$version e' la tag del pacchetto
il cfg viene mess/creato/spostato? nella src della release do dove verra' processato per il workflow
il suo nome e' fatto secondo lo standard di PA
se il run esiste lo "skippa"
poi crea il workflow sotto src
L'updating del workflow consiste nell'aggiornamento per i nuovi file dello stesso run, permettendo di girare SOLO sui nuovi file. Si tenga cnto che un run coincide con un dataset.
Infine avviene la sottomissione. La risottomissione e' fornita come al solito da PA e i log foniscono nelle solite directory, cioe' Successes e Failures.
Come nella produzione anche qui bisogna ogni tanto pulire i log prima che producano la saturazione di /home1
Se il comando di submit e' "piantato" e' il broker che non risponde: edg-job-submit va killato???
(da mettere anche nella pagina web della produzione)
Infine non resta che scrivere nel DBS/DLS locale.
PROCEDURA DI CHIUSURA, PUBBLICAZIONE E INIEZIONE
Si torna infine su pccms29.ba.infn.it e bisogna chiudere nel local i DIGI-RECO, migrare al global, chiudere nel global, iniettare in phedex.
C'e' un solo script che fa tutto questo (con 3 argomenti diversi: TIBTOB,TIB,TOB). Viene lanciato con questo comando:
nohup perl ScanDIGIRECOInjected.pl --det=TIBTOB --version=CMSSW_1_3_0_pre6 >logs_injected_reconstructed__TIBTOB_CMSSW_1_3_0_pre6 &
nohup perl ScanDIGIRECOInjected.pl --det=TIB --version=CMSSW_1_3_0_pre6 >logs_injected_reconstructed__TIB_CMSSW_1_3_0_pre6 &
nohup perl ScanDIGIRECOInjected.pl --det=TOB --version=CMSSW_1_3_0_pre6 > logs_injected_reconstructed__TOB_CMSSW_1_3_0_pre6 &
Lo script viene runnato con un cronjob ogni 5 ore.
Nel DBS si puo' verificare prendendo come "application" /DIGI-RECO/CmsRun, e come "primary dataset" TAC-TIBTOB ecc...
I file vengono spediti a tutti i siti (FNAL,Pisa,Bari); a Bari sono su pccms2 che e' il server dcache e finiscono in /pnfs/cmsfarm1.ba.infn.it/data/...
continua...
Last update: 27-April-2007