Abbiamo spostato InvMatrixLooper e InvRingCalib da Calibration/EcalAlCaRecoProducers ad Calibration/EcalCalibAlgos; BlockSover, IMASelector, PhiRangeSelector in Calibration/Tools.
Il tutto e' taggato "afterMigration".
domenica 23 dicembre 2007
mercoledì 19 dicembre 2007
tag della versione odierna
prima di modificare la posizione dei vari file in vista della fusione con il codice ufficiale, abbiamo taggato la versione odierna con il tag "beforeMoving".
Martina, Pietro
Martina, Pietro
lunedì 10 dicembre 2007
Calibrazione ad anelli
Preliminarmente arriva il primo test sulla calibrazione ad anelli con gli eventi Wenu.
Girata nell'endcap con un po' di eventi.
Ci si aspettano i coefficienti intorno a 1.
Più o meno ci siamo anche se si vede chiaramente la dipendenza dei coefficienti da eta.
In x c'è un'indice dell'anello(dal più esterno al più interno) e in y il coefficiente.
Adesso rimangono da produrre i coefficienti di scalibrazione per anelli e poi si possono fare i test delle performance.
Girata nell'endcap con un po' di eventi.
Ci si aspettano i coefficienti intorno a 1.
Più o meno ci siamo anche se si vede chiaramente la dipendenza dei coefficienti da eta.
In x c'è un'indice dell'anello(dal più esterno al più interno) e in y il coefficiente.
Adesso rimangono da produrre i coefficienti di scalibrazione per anelli e poi si possono fare i test delle performance.
mercoledì 21 novembre 2007
nuovo repository del codice
ciao,
ho spostato il codice in un repository ufficiale, anche se ancora privato:
http://cmssw.cvs.cern.ch/cgi-bin/cmssw.cgi/UserCode/Bicocca/
si prendono i pacchetti similmente a CMSSW, facendo
project CMSSW
per impostare il CVS (coerente con il resto di CMSSW), mentre per scaricare il pacchetto si fa:
cvs co -d Calibration UserCode/Bicocca/Calibration
pietro
ho spostato il codice in un repository ufficiale, anche se ancora privato:
http://cmssw.cvs.cern.ch/cgi-bin/cmssw.cgi/UserCode/Bicocca/
si prendono i pacchetti similmente a CMSSW, facendo
project CMSSW
per impostare il CVS (coerente con il resto di CMSSW), mentre per scaricare il pacchetto si fa:
cvs co -d Calibration UserCode/Bicocca/Calibration
pietro
domenica 4 novembre 2007
lo stesso per l'endcap
# ESC/Pin (min,max) Eseed/Pout (min,max) (pin - pout)/pin (min,max)
# -----------------------------------------------------------------
# R1, R3
0.95 1.05 0.9 1.15 -0.05 0.2
# R2
0.95 1.10 0.9 1.25 -0.05 0.2
# R4
0.95 1.10 0.9 1.15 -0.05 0.15
# R5
0.95 1.05 0.9 1.15 -0.05 0.15
la divisione in anelli e' la seguente, con anche le precisioni ottenute (la geometria non e' chiara come in EB, quindi questa infittendo la divisione si capisce meglio):
R1 = [22,27) 0.49
R2 = [27,32) 0.55
R3 = [32,37) 0.55
R4 = [37,42) 0.94
R5 = [42,45) 1.01
# -----------------------------------------------------------------
# R1, R3
0.95 1.05 0.9 1.15 -0.05 0.2
# R2
0.95 1.10 0.9 1.25 -0.05 0.2
# R4
0.95 1.10 0.9 1.15 -0.05 0.15
# R5
0.95 1.05 0.9 1.15 -0.05 0.15
la divisione in anelli e' la seguente, con anche le precisioni ottenute (la geometria non e' chiara come in EB, quindi questa infittendo la divisione si capisce meglio):
R1 = [22,27) 0.49
R2 = [27,32) 0.55
R3 = [32,37) 0.55
R4 = [37,42) 0.94
R5 = [42,45) 1.01
risultati di ottimizzazione tagli
con questi tagli:
# ESC/Pin (min,max) Eseed/Pout (min,max) (pin - pout)/pin (min,max)
# -----------------------------------------------------------------
# M1
0.95 1.05 0.9 1.40 -0.05 0.2
# M2
0.95 1.05 0.9 1.25 -0.05 0.2
# M3, M4
0.95 1.05 0.9 1.15 -0.05 0.15
si ottengoo le seguenti distribuzioni. mi sembra di capire che, mentre nel modulo uno tagli duri funzionano e non e' necessari controllare la forma dello sciame rispetto al momento che esce dal calorimentro (il secondo taglio), piu' si avanza in eta piu' questo e' importante.
Mi mancano ancora le stime di efficienza di questi tagli.
Riassumendo, si ha una risoluzione del:
M1 0.41 %
M2 0.47 %
M3 0.81 %
M4 1.1 %
rispettivamente per ogni modulo.
# ESC/Pin (min,max) Eseed/Pout (min,max) (pin - pout)/pin (min,max)
# -----------------------------------------------------------------
# M1
0.95 1.05 0.9 1.40 -0.05 0.2
# M2
0.95 1.05 0.9 1.25 -0.05 0.2
# M3, M4
0.95 1.05 0.9 1.15 -0.05 0.15
si ottengoo le seguenti distribuzioni. mi sembra di capire che, mentre nel modulo uno tagli duri funzionano e non e' necessari controllare la forma dello sciame rispetto al momento che esce dal calorimentro (il secondo taglio), piu' si avanza in eta piu' questo e' importante.
Mi mancano ancora le stime di efficienza di questi tagli.
Riassumendo, si ha una risoluzione del:
M1 0.41 %
M2 0.47 %
M3 0.81 %
M4 1.1 %
rispettivamente per ogni modulo.
singolo loop
se si considera tutta la regione da calibrare, non serve fare piu' di un loop sugli eventi per avere il risultato.
Scelte le seguenti regioni:
[1,86) x [20,60) in EB
[20,45) x [15,45) in EE
si calibra con u ngiro solo. Con i tagli non ottimizzati, ecco i plot. L'ultimo riporta sovrapposto al plot i punti che derivano dal TProfile della distribuzione.
Scelte le seguenti regioni:
[1,86) x [20,60) in EB
[20,45) x [15,45) in EE
si calibra con u ngiro solo. Con i tagli non ottimizzati, ecco i plot. L'ultimo riporta sovrapposto al plot i punti che derivano dal TProfile della distribuzione.
per fare studi sistematici dei tagli
ho aggiunto lo script:
Calibration/EcalAlCaRecoProducers/script/scanSelections.pl, con relativo esempio di CFG file e di txt file (che contiene i diversi tagli da provare, uno per riga.
Inoltre, una volta disponibili i risultati c'e' il seguente script perl per produrre in barreria i root file con i plot di confronto e due macro di root che fatto i fit degli istogrammi e trovano la configurazione migliore, per ciascun modulo nel barrel e per un po' di fette dell'endcap (dove e' meno chiaro come suddividere le regioni):
makeRootFiles.pl
makeTableEB.C
makeTableEE.C
Ci sono un po' di nomi e numeri da sistemare a mano in questi ultimi script.
Calibration/EcalAlCaRecoProducers/script/scanSelections.pl, con relativo esempio di CFG file e di txt file (che contiene i diversi tagli da provare, uno per riga.
Inoltre, una volta disponibili i risultati c'e' il seguente script perl per produrre in barreria i root file con i plot di confronto e due macro di root che fatto i fit degli istogrammi e trovano la configurazione migliore, per ciascun modulo nel barrel e per un po' di fette dell'endcap (dove e' meno chiaro come suddividere le regioni):
makeRootFiles.pl
makeTableEB.C
makeTableEE.C
Ci sono un po' di nomi e numeri da sistemare a mano in questi ultimi script.
giovedì 1 novembre 2007
mercoledì 31 ottobre 2007
trend dei coefficienti in EB
Come si vede dai plot seguenti, nel modulo uno dopo aver assunto il primo valore dei coefficienti a partire da una scalibrazione che non ho associato all'istogramma (a meno che i coeff0.root non siamo PRIMA del primo loop, devo ctrl), di vede che al secondo c'e' un salto ulteriore del 0.5% e poi piu' o meno il risultato e stabile.
Questo e' il plot che sale.
Il plot che scende, invece, e' fatto con numeri dell'ultima fetta, eta index 83, credo, e si vede come l'algoritmo sembri piu' lento ad assestare il valore dei coefficienti.
Il terzo plot e' relativo all'endcap, 37,27 credo.
Questo e' il plot che sale.
Il plot che scende, invece, e' fatto con numeri dell'ultima fetta, eta index 83, credo, e si vede come l'algoritmo sembri piu' lento ad assestare il valore dei coefficienti.
Il terzo plot e' relativo all'endcap, 37,27 credo.
confronto: calib x recalib in EE con le fette
Studi sulla statistica e sui tagli.
ho lanciato 4 set di lavori con 4 tipi di tagli diversi.
EseedOpout non è stato toccato ed è rimasto largo.
ESCOpin largo era 0,85-1,15, stretto 0,94-1,06
PinMPout/pin stretto -0,1-0,1 largo -0,1-0,2
per la combinazione stretto-stretto il risultato del fit è
4%/sqrt(N) +0,8%
Per la combinazione largo-stretto
7,5%/sqrt(N)+0.8
Per la combinazione stretto-largo
5,6%/SQRT(N) +0,8%
Per la combinazione largo-largo
12%/SQRT(N)+0,5%
Da questo non saprei che conclusioni trarci.
Stanotte ho girato anche altri job che analizzerò in seguito.
Direi che altri lavori da lanciare non ce ne sono e potremmo dire che a noi la caf non serve più.
Ora devo andare a sentire una laurea,
buona giornata!
EseedOpout non è stato toccato ed è rimasto largo.
ESCOpin largo era 0,85-1,15, stretto 0,94-1,06
PinMPout/pin stretto -0,1-0,1 largo -0,1-0,2
per la combinazione stretto-stretto il risultato del fit è
4%/sqrt(N) +0,8%
Per la combinazione largo-stretto
7,5%/sqrt(N)+0.8
Per la combinazione stretto-largo
5,6%/SQRT(N) +0,8%
Per la combinazione largo-largo
12%/SQRT(N)+0,5%
Da questo non saprei che conclusioni trarci.
Stanotte ho girato anche altri job che analizzerò in seguito.
Direi che altri lavori da lanciare non ce ne sono e potremmo dire che a noi la caf non serve più.
Ora devo andare a sentire una laurea,
buona giornata!
martedì 30 ottobre 2007
primi plot: endcap calibrato
A partire dall'endcap calibrato, la distribuzione dei coefficienti trovata e' la seguente, fittata con una gaussiana e mostrata nella mappa.
Questi plot sono ottenuti dopo aver combinato diversi XML file prodotti da loop di calibrazione indipendenti in sotto-regioni dell'endcap.
Vorrei aspettare i risultati del run globale e del run sui dati scalibrati prima di diffonderli.
Questi plot sono ottenuti dopo aver combinato diversi XML file prodotti da loop di calibrazione indipendenti in sotto-regioni dell'endcap.
Vorrei aspettare i risultati del run globale e del run sui dati scalibrati prima di diffonderli.
una grezza idea della statistica
lanciare calib e scalib insieme
per lanciare in parallelo calib e scalib, ho modificato a mano lanciaBarrel.pl e lanciaEndcap.pl perche' creino cfg file e sh file con nome diverso.
andra' sistematizzato, per ora bisogna fare attenzione.
andra' sistematizzato, per ora bisogna fare attenzione.
cfg file modificati
ho committato i cfg file per il lancio singolo con un bugfix.
lo stesso bugfix e' applicato ai template per la calibrazione, con inoltre i seguenti parametri cambiati:
double minCoeff = 0.5
double maxCoeff = 1.5
int32 loops = 4
il numero di loop e' minore per fare piu' velocemente, i coeff min e max piu' larghi per contemplare problemi legati alla scalibrazione negli endcap.
lo stesso bugfix e' applicato ai template per la calibrazione, con inoltre i seguenti parametri cambiati:
double minCoeff = 0.5
double maxCoeff = 1.5
int32 loops = 4
il numero di loop e' minore per fare piu' velocemente, i coeff min e max piu' larghi per contemplare problemi legati alla scalibrazione negli endcap.
output deviato per genera.pl
il log file di genera.pl viene mandato su castor in una cartella dedicata.
ho modificato solo i cfg file della CSA07 in questo senso.
c'e' il nuovo tag CSA07_1_0_2.
ho modificato solo i cfg file della CSA07 in questo senso.
c'e' il nuovo tag CSA07_1_0_2.
lunedì 29 ottobre 2007
nuovo coeffCompare
ho committato una nuova versione di coeffcompare.
tiene conto correttamente delle regioni di confronto, tuttavia i parametri sono hardcoded ancora.
non plotta piu' distribuzioni di coeffcienti.
i set di coeff (calib, miscalib) sono moltiplicati fra loro.
la nuova versione e' taggata CSA07_1_0_1.
tiene conto correttamente delle regioni di confronto, tuttavia i parametri sono hardcoded ancora.
non plotta piu' distribuzioni di coeffcienti.
i set di coeff (calib, miscalib) sono moltiplicati fra loro.
la nuova versione e' taggata CSA07_1_0_1.
bin anomalo
facendo girare il looper sui file EEElectrons*.root di Luca con 0< phi <0.5 ed 1.6< eta <1.8 e filtri IMA
double ESCOPinMin = 0.7
double ESCOPinMax = 1.4
double ESeedOPoutMin = 0.85
double ESeedOPoutMax = 100
double PinMPoutOPinMin = -100
double PinMPoutOPinMax = 0.4
compare sempre un coefficiente completamente fuori scala sull'endcap+ alle coordinate:
cell x_index="86" y_index="77" z_index="1" scale_factor="297.438629"
Luca hai mai visto qualcosa del genere?
ciao.
double ESCOPinMin = 0.7
double ESCOPinMax = 1.4
double ESeedOPoutMin = 0.85
double ESeedOPoutMax = 100
double PinMPoutOPinMin = -100
double PinMPoutOPinMax = 0.4
compare sempre un coefficiente completamente fuori scala sull'endcap+ alle coordinate:
cell x_index="86" y_index="77" z_index="1" scale_factor="297.438629"
Luca hai mai visto qualcosa del genere?
ciao.
preparazione alla CSA07
ciao,
la cartella Calibration/EcalAlCaRecoProducers/test/CSA07 contiene script e cfg file per lanciare l'esercizio di CSA07.
Contiene:
CMSSW CFG FILES:
filtering_CSA07.cfg # template per il filtraggio dei dati
IMAcalib_CSA07.cfg # template per la calibrazione di dati calibati
IMAcalib_CSA07_miscalib.cfg # template per la calibrazione di dati scalibrati
IMAcalib_CSA07_ALL.cfg # per lanciare la calibrazione su tutta la porzione di calorimetro calibrato
IMAcalib_CSA07_ALL_miscalib.cfg # per lanciare la calibrazione su tutta la porzione di calorimetro scalibrato
IMAcalib_CSA07_EB.cfg # per lanciare la calibrazione su tutta la porzione di barrel calibrato
IMAcalib_CSA07_EB_miscalib.cfg # per lanciare la calibrazione su tutta la porzione di barrel scalibrato
IMAcalib_CSA07_EE.cfg # per lanciare la calibrazione su tutta la porzione di endcap calibrato
IMAcalib_CSA07_EE_miscalib.cfg # per lanciare la calibrazione su tutta la porzione di endcap scalibrato
CONFIG FILE PER I NOSTRI SCRIPT:
genera_CSA07.CFG # per smistare la produzione di sottofile e lanciare la calibrazione su dati calibrati in sottoregioni
genera_CSA07_miscalib.CFG # per smistare la produzione di sottofile e lanciare la calibrazione su dati scalibrati in sottoregioni
SCRIPT DI SHELL:
lancia_CSA07_ALL.sh # per lanciare al batchsystem IMAcalib_CSA07_ALL.cfg
lancia_CSA07_ALL_miscalib.sh # per lanciare al batchsystem IMAcalib_CSA07_ALL_miscalib.cfg
lancia_CSA07_EB.sh # per lanciare al batchsystem IMAcalib_CSA07_EB.cfg
lancia_CSA07_EB_miscalib.sh # per lanciare al batchsystem IMAcalib_CSA07_EB_miscalib.cfg
lancia_CSA07_EE.sh # per lanciare al batchsystem IMAcalib_CSA07_EE.cfg
lancia_CSA07_EE_miscalib.sh # per lanciare al batchsystem MAcalib_CSA07_EE_miscalib.cfg
CARTELLE PER I RISULTATI:
coeff/
coeff_miscalib/
L'ELENCO DEI DATAFILE ALCARECO DISPONIBILI:
originalDataset.cff
Le selezioni utilizzate per la preselezione sono:
double ESCOPinMin = 0.7
double ESCOPinMax = 1.4
double ESeedOPoutMin = 0.8
double ESeedOPoutMax = 10
double PinMPoutOPinMin = -1.
double PinMPoutOPinMax = 0.6
mentre quelle utilizzate per la calibrazione effettiva sono:
double ESCOPinMin = 0.85
double ESCOPinMax = 1.20
double ESeedOPoutMin = 0.8
double ESeedOPoutMax = 1.4
double PinMPoutOPinMin = -0.1
double PinMPoutOPinMax = 0.2
con il blocksolver spento
la cartella Calibration/EcalAlCaRecoProducers/test/CSA07 contiene script e cfg file per lanciare l'esercizio di CSA07.
Contiene:
CMSSW CFG FILES:
filtering_CSA07.cfg # template per il filtraggio dei dati
IMAcalib_CSA07.cfg # template per la calibrazione di dati calibati
IMAcalib_CSA07_miscalib.cfg # template per la calibrazione di dati scalibrati
IMAcalib_CSA07_ALL.cfg # per lanciare la calibrazione su tutta la porzione di calorimetro calibrato
IMAcalib_CSA07_ALL_miscalib.cfg # per lanciare la calibrazione su tutta la porzione di calorimetro scalibrato
IMAcalib_CSA07_EB.cfg # per lanciare la calibrazione su tutta la porzione di barrel calibrato
IMAcalib_CSA07_EB_miscalib.cfg # per lanciare la calibrazione su tutta la porzione di barrel scalibrato
IMAcalib_CSA07_EE.cfg # per lanciare la calibrazione su tutta la porzione di endcap calibrato
IMAcalib_CSA07_EE_miscalib.cfg # per lanciare la calibrazione su tutta la porzione di endcap scalibrato
CONFIG FILE PER I NOSTRI SCRIPT:
genera_CSA07.CFG # per smistare la produzione di sottofile e lanciare la calibrazione su dati calibrati in sottoregioni
genera_CSA07_miscalib.CFG # per smistare la produzione di sottofile e lanciare la calibrazione su dati scalibrati in sottoregioni
SCRIPT DI SHELL:
lancia_CSA07_ALL.sh # per lanciare al batchsystem IMAcalib_CSA07_ALL.cfg
lancia_CSA07_ALL_miscalib.sh # per lanciare al batchsystem IMAcalib_CSA07_ALL_miscalib.cfg
lancia_CSA07_EB.sh # per lanciare al batchsystem IMAcalib_CSA07_EB.cfg
lancia_CSA07_EB_miscalib.sh # per lanciare al batchsystem IMAcalib_CSA07_EB_miscalib.cfg
lancia_CSA07_EE.sh # per lanciare al batchsystem IMAcalib_CSA07_EE.cfg
lancia_CSA07_EE_miscalib.sh # per lanciare al batchsystem MAcalib_CSA07_EE_miscalib.cfg
CARTELLE PER I RISULTATI:
coeff/
coeff_miscalib/
L'ELENCO DEI DATAFILE ALCARECO DISPONIBILI:
originalDataset.cff
Le selezioni utilizzate per la preselezione sono:
double ESCOPinMin = 0.7
double ESCOPinMax = 1.4
double ESeedOPoutMin = 0.8
double ESeedOPoutMax = 10
double PinMPoutOPinMin = -1.
double PinMPoutOPinMax = 0.6
mentre quelle utilizzate per la calibrazione effettiva sono:
double ESCOPinMin = 0.85
double ESCOPinMax = 1.20
double ESeedOPoutMin = 0.8
double ESeedOPoutMax = 1.4
double PinMPoutOPinMin = -0.1
double PinMPoutOPinMax = 0.2
con il blocksolver spento
come fare il nuovo file DB
rfdir $CASTOR_HOME/ECALCalib/AlCa/test3 | tr "_" " " |
awk '{print $11" "$12" /castor/cern.ch/user/g/govoni/ECALCalib/AlCa/test/"$9"_"$10"_"$11"_"$12"_"$13}' > db3.txt
awk '{print $11" "$12" /castor/cern.ch/user/g/govoni/ECALCalib/AlCa/test/"$9"_"$10"_"$11"_"$12"_"$13}' > db3.txt
CSA07 config files
ho aggiunto al repository la catella Calibration/EcalAlCaRecoProducers/test/CSA07 dove mettere tutti i cfg file e gli script da usare per l'esercizio CSA07
LSF e' giu' per un po'
An LSF upgrade is in progress. See
http://it-support-servicestatus.web.cern.ch/it-support-servicestatus/ScheduledInterventionsArchive/070829-LSF.htm
On Monday, 29 Oct, CERN will migrate the batch system from the current version 6.1 of LSF to 7.0 and new master node hardware. The main benefit will be better scalability.
The intervention will start at 8:00 am and is scheduled until 11:00.
During that period short service interruptions will be likely, and job submission and scheduling will be disabled for about one hour.
Please consult
https://twiki.cern.ch/twiki/bin/view/FIOgroup/FsLSF7Changes
for a list of the most important changes.
Please note that after the migration the bpeek command will not work properly on individual worker nodes, until old jobs have finished and LSF has been restarted on them.
http://it-support-servicestatus.web.cern.ch/it-support-servicestatus/ScheduledInterventionsArchive/070829-LSF.htm
On Monday, 29 Oct, CERN will migrate the batch system from the current version 6.1 of LSF to 7.0 and new master node hardware. The main benefit will be better scalability.
The intervention will start at 8:00 am and is scheduled until 11:00.
During that period short service interruptions will be likely, and job submission and scheduling will be disabled for about one hour.
Please consult
https://twiki.cern.ch/twiki/bin/view/FIOgroup/FsLSF7Changes
for a list of the most important changes.
Please note that after the migration the bpeek command will not work properly on individual worker nodes, until old jobs have finished and LSF has been restarted on them.
domenica 28 ottobre 2007
filtrare gli eventi
con la seguente configurazione dei path e del PoolOutputModule, gli eventi che vengono effettivamente salvati nel root file sembrano essere solamente quelli selezionati, con una notevole riduzione di spazio.
La novita' rispetto a prima e' che la sequenza di selezione sta in un path separato dal testing e il nome del path viene usato come "trigger" dal PoolOutputModule.
Facendo un test veloce su pochi dati, con e senza il trigger le distribuzioni rilette sono identiche.
Stando ai job girati sui frontier, si arriva anche ad una riduzione del 94% dello spazio occupato, sono ancora da testare.
# --- percorsi di analisi ------------------------------------------------
path filter = {secondFilter , phiFiltering , IMAFiltering}
#path withFilter = {secondFilter , phiFiltering , IMAFiltering , alcatesting}
endpath write = {alcatesting,out}
# --- results testing ------------------------------------------------
module out = PoolOutputModule
{
untracked string fileName = "preSelected_pietro_nofiler.root"
untracked vstring outputCommands =
{
# "keep *"
"drop *",
"keep *_IMAFiltering_*_*",
"keep *_alCaIsolatedElectrons_*_*"
}
untracked PSet SelectEvents =
{
vstring SelectEvents = { "filter" }
}
}
La novita' rispetto a prima e' che la sequenza di selezione sta in un path separato dal testing e il nome del path viene usato come "trigger" dal PoolOutputModule.
Facendo un test veloce su pochi dati, con e senza il trigger le distribuzioni rilette sono identiche.
Stando ai job girati sui frontier, si arriva anche ad una riduzione del 94% dello spazio occupato, sono ancora da testare.
# --- percorsi di analisi ------------------------------------------------
path filter = {secondFilter , phiFiltering , IMAFiltering}
#path withFilter = {secondFilter , phiFiltering , IMAFiltering , alcatesting}
endpath write = {alcatesting,out}
# --- results testing ------------------------------------------------
module out = PoolOutputModule
{
untracked string fileName = "preSelected_pietro_nofiler.root"
untracked vstring outputCommands =
{
# "keep *"
"drop *",
"keep *_IMAFiltering_*_*",
"keep *_alCaIsolatedElectrons_*_*"
}
untracked PSet SelectEvents =
{
vstring SelectEvents = { "filter" }
}
}
nuova versione di splitting dei dat
splitSource.pl e genera.pl prevedono di girare su sotto-insiemi dei file di dati iniziali per accelerare il processo di splitting geometrico.
un test e' in corso.
un test e' in corso.
i cfg per la CSA07
per ottenere i cfg file per scalibrare nella csa07, bisogna pigliare la seguente cartella dalla head:
cvs co -r HEAD CalibCalorimetry/CaloMiscalibTools/data
cvs co -r HEAD CalibCalorimetry/CaloMiscalibTools/data
possbile modo di selezionare solo gli eventi...
... che passano l'IMAFiltering: mettere nel PoolOutputModule le seguenti righe:
untracked PSet SelectEvents =
{
vstring SelectEvents = { "IMAFiltering" }
}
continuo von gli script poi provo
untracked PSet SelectEvents =
{
vstring SelectEvents = { "IMAFiltering" }
}
continuo von gli script poi provo
Filtro funzionante!
Con un magico include nel SealModule dal funzionamento non chiaro ora i filtri funzionano correttamente salvando tutto quel che serve.
Le istruzioni per il poolOutputModule sono:
"drop *",
"keep *_IMAFiltering_*_*",
"keep *_alCaIsolatedElectrons_*_*"
Le dimensioni del file vengono diminuite ragionevolmente.
Il numero di eventi letti no perchè i recHit non vengono toccati.
Poi si legge efficacemente gli eventi filtrati con le stesse inputTag per le recHit e IMAFiltering per gli elettroni.
Le istruzioni per il poolOutputModule sono:
"drop *",
"keep *_IMAFiltering_*_*",
"keep *_alCaIsolatedElectrons_*_*"
Le dimensioni del file vengono diminuite ragionevolmente.
Il numero di eventi letti no perchè i recHit non vengono toccati.
Poi si legge efficacemente gli eventi filtrati con le stesse inputTag per le recHit e IMAFiltering per gli elettroni.
Considerazioni sui dati splittati
Venerdì notte ho fatto splittare i dati famos nostri dell'endcap in 5 zone.
Da 2GB circa di dati iniziali ho ottenuto 5 file da 2 GB l'uno!
Ho notato il problema sopratutto leggendo i dati mettendo l'inputTag sbagliato(electronFilter al posto di IMAFiltering). In quel modo stava processando il 600Kesimo dato e non aveva ancora finito nonostante i dati in totale fossero 200k.
Il keep * insomma non funziona bene.
Il punto è che se imafilter, ma anche phifilter, non hanno associati il supercluster, come invece hanno electronFilter e secondFilter.
E senza il supercluster la matrice inversa non funziona.
Tralaltro facendo leggere così i dati con l'inputTag IMAFiltering ogni volta che trova un evento che non ha passato il filtro lancia una exception, che comunque non lo blocca, però sarebbe meglio che quegli eventi non li leggesse per niente, se no i dati filtrati non velocizzano per niente.
Una prima idea per fare i dati filtrati è quella di filtrare solo col secondFilter e fare un
drop *
keep *_alcaIsolatedElectrons_*_*
keep *_secondFilter_*_*
che così almeno il filtraggio su eta funziona.
Da 2GB circa di dati iniziali ho ottenuto 5 file da 2 GB l'uno!
Ho notato il problema sopratutto leggendo i dati mettendo l'inputTag sbagliato(electronFilter al posto di IMAFiltering). In quel modo stava processando il 600Kesimo dato e non aveva ancora finito nonostante i dati in totale fossero 200k.
Il keep * insomma non funziona bene.
Il punto è che se imafilter, ma anche phifilter, non hanno associati il supercluster, come invece hanno electronFilter e secondFilter.
E senza il supercluster la matrice inversa non funziona.
Tralaltro facendo leggere così i dati con l'inputTag IMAFiltering ogni volta che trova un evento che non ha passato il filtro lancia una exception, che comunque non lo blocca, però sarebbe meglio che quegli eventi non li leggesse per niente, se no i dati filtrati non velocizzano per niente.
Una prima idea per fare i dati filtrati è quella di filtrare solo col secondFilter e fare un
drop *
keep *_alcaIsolatedElectrons_*_*
keep *_secondFilter_*_*
che così almeno il filtraggio su eta funziona.
sabato 27 ottobre 2007
dividere un PoolSource un tanti poolsource
lo script splitSource.pl aggiunto al repository legge dallo stesso CFG file degli altri script, produce N cmssw-cfg files con all'interno i root-file di un source inziale sparsi uniformemente.
controllare la memoria occupata
da questo link:
http://blog.webfaction.com/memory-usage
ps -u govoni -o pid,rss,command
la seconda colonna e' la RAM usata, in KB
http://blog.webfaction.com/memory-usage
ps -u govoni -o pid,rss,command
la seconda colonna e' la RAM usata, in KB
spazio su castor caf
con Luca abbiamo creato le cartelle:
/castor/cern.ch/cms/store/cmscaf/alca/calibration/IMA
e
/castor/cern.ch/cms/store/cmscaf/alca/calibration/IMA/test
con permessi di scrittura e lettura per tutti, per i nostri risultati.
/castor/cern.ch/cms/store/cmscaf/alca/calibration/IMA
e
/castor/cern.ch/cms/store/cmscaf/alca/calibration/IMA/test
con permessi di scrittura e lettura per tutti, per i nostri risultati.
Varie ed eventuali
Filtraggio degli eventi:
Per leggere e filtrare 300K eventi sulla caf sono servite 2 ore. Probabilmente un po' di tempo è stato fregato da castor, ma è bene considerare questo tempo per fare stime di quanto tempo ci vuole per filtrare tutti gli eventi.
La maggior parte del tempo serve per scrivere l'output su file, se no è molto più veloce.
AlcaElectronTest:
Per leggere 326Keventi servono: 17 minuti. Tempo simile alla matrice inversa.
Non so quanto di questo tempo sia perso per scrivere (su file) l'output del messagge logger che è enorme.
Matrice Inversa:
Su cmsmi3:
Per girare su una sola regione da 400 cristalli usa il 14% della ram.
Per fare un loop su 160Keventi servono 5 minuti.
Se il messagge logger funziona bene una matrice da 400 cristalli viene invertita istantaneamente.
Test sui dati della csa.
Si leggono perfettamente. Sono nella stessa regione dei relval usati finora. In pratica nel barrel eta da 0 a 85 e phi da 20 a 60
In endcap phi dovrebbe essere la stessa e il raggio da 17 circa (da 20 si è sicuri) circa in su.
Questi dati sono scritti nel dbs nel formato /store/mc etc...
Perchè cmssw sappia risolvere il path bisogna settare la variabile d'ambiente SVCCLASS=cmscaf
Scratch su cui girare:
Si è scoperto che a volte girare in /tmp/nomeuser/ mica funziona perchè lo riempie. E' stato consigliato di lavorare nella directory in cui si viene buttati facendo "cd -"
Per leggere e filtrare 300K eventi sulla caf sono servite 2 ore. Probabilmente un po' di tempo è stato fregato da castor, ma è bene considerare questo tempo per fare stime di quanto tempo ci vuole per filtrare tutti gli eventi.
La maggior parte del tempo serve per scrivere l'output su file, se no è molto più veloce.
AlcaElectronTest:
Per leggere 326Keventi servono: 17 minuti. Tempo simile alla matrice inversa.
Non so quanto di questo tempo sia perso per scrivere (su file) l'output del messagge logger che è enorme.
Matrice Inversa:
Su cmsmi3:
Per girare su una sola regione da 400 cristalli usa il 14% della ram.
Per fare un loop su 160Keventi servono 5 minuti.
Se il messagge logger funziona bene una matrice da 400 cristalli viene invertita istantaneamente.
Test sui dati della csa.
Si leggono perfettamente. Sono nella stessa regione dei relval usati finora. In pratica nel barrel eta da 0 a 85 e phi da 20 a 60
In endcap phi dovrebbe essere la stessa e il raggio da 17 circa (da 20 si è sicuri) circa in su.
Questi dati sono scritti nel dbs nel formato /store/mc etc...
Perchè cmssw sappia risolvere il path bisogna settare la variabile d'ambiente SVCCLASS=cmscaf
Scratch su cui girare:
Si è scoperto che a volte girare in /tmp/nomeuser/ mica funziona perchè lo riempie. E' stato consigliato di lavorare nella directory in cui si viene buttati facendo "cd -"
quanti dati abbiamo
per la CSA07 abbiamo 6M dati, con eta positivo e phi fra 20 e 60.
6M di elettroni si accumulano in questa regione se tu tutto CMS cascano:
6M * 2 (anceh eta negativi) * 40/360 (tutto phi) = 180M eventi = 10.8E7 eventi
Un anno e' composto da 10E7 secondi di presa dati (con efficienza di 1/3) e gli elettroni attesi da Wenu avranno una frequenza di trigger HLT di 10 Hz a bassa luminosita' (2E33 cm-2 s-1) e 35Hz ad alta luminosita' (E34 cm-2 s-1).
Quindi, per acquisire gli eventi che avremo dalla CSA07, ci vorra' circa un anno a bassa luminosita' e da 3 a 4 mesi ad alta luminosita'.
6M di elettroni si accumulano in questa regione se tu tutto CMS cascano:
6M * 2 (anceh eta negativi) * 40/360 (tutto phi) = 180M eventi = 10.8E7 eventi
Un anno e' composto da 10E7 secondi di presa dati (con efficienza di 1/3) e gli elettroni attesi da Wenu avranno una frequenza di trigger HLT di 10 Hz a bassa luminosita' (2E33 cm-2 s-1) e 35Hz ad alta luminosita' (E34 cm-2 s-1).
Quindi, per acquisire gli eventi che avremo dalla CSA07, ci vorra' circa un anno a bassa luminosita' e da 3 a 4 mesi ad alta luminosita'.
venerdì 26 ottobre 2007
Prove sui frontier
Ho fatto girare l'invMatrixLooper sui Frontier.
Un solo processo su tutti i dati su tutta la zona coperta)
Come memoria è fattibilissimo.(usa circa 200MB)
su cmsmi3 ha bisogno di 20 minuti per fare un loop(sono circa 325Keventi)
Direi insomma che è fattibile fare un processo solo su una sola cpu, il problema è il tempo che ci mette(proporzionale al numero di eventi)
Per 6M di eventi su una macchina veloce possiamo aspettarci un paio d'ore abbondanti per un loop. Quindi...Meglio dividere in un po' di zone, anche se non è necessario che siano tantissime, così il primo filtro anche se largo dimezza gli elettroni e accelera ulteriormente il tempo di esecuzione.(da vedere con l'alcaelectronTest quanto fitte farle)
P.s.: Gli elettroni sono piuttosto pochi nei frontier e non i tutti i punti si riesce a calibrare bene.
In certe regioni proprio non ce la fa.
Un solo processo su tutti i dati su tutta la zona coperta)
Come memoria è fattibilissimo.(usa circa 200MB)
su cmsmi3 ha bisogno di 20 minuti per fare un loop(sono circa 325Keventi)
Direi insomma che è fattibile fare un processo solo su una sola cpu, il problema è il tempo che ci mette(proporzionale al numero di eventi)
Per 6M di eventi su una macchina veloce possiamo aspettarci un paio d'ore abbondanti per un loop. Quindi...Meglio dividere in un po' di zone, anche se non è necessario che siano tantissime, così il primo filtro anche se largo dimezza gli elettroni e accelera ulteriormente il tempo di esecuzione.(da vedere con l'alcaelectronTest quanto fitte farle)
P.s.: Gli elettroni sono piuttosto pochi nei frontier e non i tutti i punti si riesce a calibrare bene.
In certe regioni proprio non ce la fa.
dove sono i dati della csa07
http://cmsdbs.cern.ch/DBS2_discovery/getData?ajax=0&phedex=off&userMode=user&dbsInst=cms_dbs_prod_global&group=Any&tier=Any&app=Any&primType=Any&primD=Wenu_Calibration&site=Any
CAF: sottomissione e castor
In order to access files at the CAF castor pool you must set:
export STAGE_SVCCLASS=cmscaf
In one of the Emails from computing yesterday, there was a nasty typo
specifying the t0 pool rather than the CAF pool.
NEVER EVER use the t0 castor pool for anything!!!!!!!!!!!
Below you will find a few important instructions for CAF usage:
CAF Usage:
-----------------
CAF Usage is restricted to dedicated users. Only if you are registered
in a special list you are able to access the CAF.
CAF disk pool:
--------------------
You need to set the environment variable:
export STAGE_SVCCLASS=cmscaf
to get access to the CAF disk space (see also warning above)
CAF job submission:
-----------------------------
bsub -q dedicated -R cmscaf cmsrun.job
export STAGE_SVCCLASS=cmscaf
In one of the Emails from computing yesterday, there was a nasty typo
specifying the t0 pool rather than the CAF pool.
NEVER EVER use the t0 castor pool for anything!!!!!!!!!!!
Below you will find a few important instructions for CAF usage:
CAF Usage:
-----------------
CAF Usage is restricted to dedicated users. Only if you are registered
in a special list you are able to access the CAF.
CAF disk pool:
--------------------
You need to set the environment variable:
export STAGE_SVCCLASS=cmscaf
to get access to the CAF disk space (see also warning above)
CAF job submission:
-----------------------------
bsub -q dedicated -R cmscaf cmsrun.job
Domande sui nuovi dati dell'endcap
Ciao Luca,
mi sembra un'ottima cosa avere quei dati sull'encap, ottimo lavoro :)
Hai gia' provato a girare su tutti loro? Il limite in phi e' lo stesso della produzione CSA07?
Se hai gia' provato a girarci, che etawidth e phiwidth hai scelto?
Ti sembra che funzioni? Cioe' hai guardato i coefficienti prodotti su un dataset calibrato?
Per caso hai provato con diverse statistiche per cristallo, tipo TOT, TOT/2, TOT/4, TOT/8?
Queste informazioni sono utili per sapere quanto siamo gia' pronti per girare con la CSA07.
Io proseguo con la struttura di script ed eseguibili che sto facendo per sminuzzare i dataset, ora termino il barrel e passo all'endcap.
Mi piacerebbe che provassi poi a lanciare gli script su questo nouvo dataset a partire da genera.pl.
Riorganizzazione e nuovi dati
Sono stati generati 165K nuovi elettroni per l'endcap fino al limite di dove il traker ricostruisce.
Sommando ai precedenti abbiamo in totale un 295K elettroni buoni in totale circa.
Inoltre visto che stava nascendo troppo casino ho riorganizzato i nomi dei file su cmsmi3
Si chiamano EEElectrons1.root e così via fino al 6.
I primi due sono i vecchi a basso eta, il 3 è ad alto eta, dal 4 al 6 sono quelli di stanotte in tutto il range. La cosa più furba è chiaramente usarli tutti insieme, anche se diventa lentina la cosa, ma prima la statistica era bassa.
Per poter girare anche su macchine che non siano cmsmi3 ho anche messo tutti i file su castor in /castor/cern.ch/user/p/presotto/Famos/
Nei punti più scuri ci sono più di 200 elettroni.
I file alcaElectrons_test e InvMatrixCalibration_test in cvs sono già stati aggiornati coi nuovi nomi dei file.
giovedì 25 ottobre 2007
merge dei cfg file
Ho aggiunto al repository:
Calibration/EcalAlCaRecoProducers/bin/viewCoeffEB.cpp
per velocemente vedere che cosa c'e' in un file XML di calibrazione, e:
Calibration/EcalAlCaRecoProducers/bin/mergeXML.cpp
per unire file XML diversi a partire dallo stesso CFG file di genera e lanciaBarrel.
mergeXML ha un baco da sistemare.
Calibration/EcalAlCaRecoProducers/bin/viewCoeffEB.cpp
per velocemente vedere che cosa c'e' in un file XML di calibrazione, e:
Calibration/EcalAlCaRecoProducers/bin/mergeXML.cpp
per unire file XML diversi a partire dallo stesso CFG file di genera e lanciaBarrel.
mergeXML ha un baco da sistemare.
trivial parser
ho agggiunto un parser banale che legge in c++ il cfg file scritto per gli script di calibrazione.
(per ora) e' in grado solamente di associare stringhe e double. gli interi diventano double, le stringhe diventano zeri e non hanno senso, anche se lui se le tiene a memoria.
e' molto fragile, quindi bisogna fare attenzione a non scrivere CFG file troppo impegnativi.
il codice sta in:
Calibration/EcalAlCaRecoProducers/bin/trivialParser.h
Calibration/EcalAlCaRecoProducers/bin/trivialParser.cc
L'ho testato , funziona.
(per ora) e' in grado solamente di associare stringhe e double. gli interi diventano double, le stringhe diventano zeri e non hanno senso, anche se lui se le tiene a memoria.
e' molto fragile, quindi bisogna fare attenzione a non scrivere CFG file troppo impegnativi.
il codice sta in:
Calibration/EcalAlCaRecoProducers/bin/trivialParser.h
Calibration/EcalAlCaRecoProducers/bin/trivialParser.cc
L'ho testato , funziona.
martedì 23 ottobre 2007
update e test di lanciaBarrel.pl
lo script lanciaBarrel.pl ora:
- tiene conto del buco ad eta=0
- allarga la zona di calibrazione per creare sovrapposizioni e minimizzare gli effetti ai bordi delle sottoregioni, poi andranno uniti coerentemente gli XML
- ritorna i root file in una cartella diversa per ogni job
- ritorna i coeff nella stessa cartella ed in un'altra dove si raccolgono tutti i coeff (i nomi sono diversi da un caso all'altro, ci va bene cosi'?)
- la composizione dei file XML
- catturare l'output e ritornarlo per non perdere le efficienze (questo anche in genera.pl)
script per database di testo: modifica:
rfdir $CASTOR_HOME/ECALCalib/AlCa/test | tr "_" " " | awk '{print $10" "$11" /castor/cern.ch/user/g/govoni/ECALCalib/AlCa/test/"$9"_"$10"_"$11"_"$12}' > db1.txt
mette gia' il path corretto.
mette gia' il path corretto.
lunedì 22 ottobre 2007
test di genera.pl
Il primo test del nuovo genera.pl e' andato bene, i problemi con castor sono stati solo transienti e si trovano qui:
rfdir /castor/cern.ch/user/g/govoni/ECALCalib/AlCa/test
i root file prodotti con il seguente CFG e cfg:
revision 1.5 di Calibration/EcalAlCaRecoProducers/script/genera.pl
revision 1.3 di Calibration/EcalAlCaRecoProducers/script/genera_example.CFG
revision 1.3 di Calibration/EcalAlCaRecoProducers/test/filtering_template.cfg
rimane da finire il test con lanciaBarrel elanciaEndcap, tener traccia degl output e dei job che non vanno in porto.
Ecco il file di DB con i root file:
0.1 0.2 preSelected_0.1_0.2_.root
0.2 0.3 preSelected_0.2_0.3_.root
0.3 0.4 preSelected_0.3_0.4_.root
0.4 0.5 preSelected_0.4_0.5_.root
0.5 0.6 preSelected_0.5_0.6_.root
0.6 0.7 preSelected_0.6_0.7_.root
0.7 0.8 preSelected_0.7_0.8_.root
0.8 0.9 preSelected_0.8_0.9_.root
0.9 1 preSelected_0.9_1_.root
0 0.1 preSelected_0_0.1_.root
1.1 1.2 preSelected_1.1_1.2_.root
1.2 1.3 preSelected_1.2_1.3_.root
1.3 1.4 preSelected_1.3_1.4_.root
1.4 1.5 preSelected_1.4_1.5_.root
1.5 1.6 preSelected_1.5_1.6_.root
1.6 1.7 preSelected_1.6_1.7_.root
1.7 1.8 preSelected_1.7_1.8_.root
1.8 1.9 preSelected_1.8_1.9_.root
1.9 2 preSelected_1.9_2_.root
1 1.1 preSelected_1_1.1_.root
2.1 2.2 preSelected_2.1_2.2_.root
2.2 2.3 preSelected_2.2_2.3_.root
2.3 2.4 preSelected_2.3_2.4_.root
2.4 2.5 preSelected_2.4_2.5_.root
2.5 2.6 preSelected_2.5_2.6_.root
2.6 2.7 preSelected_2.6_2.7_.root
2.7 2.8 preSelected_2.7_2.8_.root
2.8 2.9 preSelected_2.8_2.9_.root
2.9 3 preSelected_2.9_3_.root
2 2.1 preSelected_2_2.1_.root
rfdir /castor/cern.ch/user/g/govoni/ECALCalib/AlCa/test
i root file prodotti con il seguente CFG e cfg:
revision 1.5 di Calibration/EcalAlCaRecoProducers/script/genera.pl
revision 1.3 di Calibration/EcalAlCaRecoProducers/script/genera_example.CFG
revision 1.3 di Calibration/EcalAlCaRecoProducers/test/filtering_template.cfg
rimane da finire il test con lanciaBarrel elanciaEndcap, tener traccia degl output e dei job che non vanno in porto.
Ecco il file di DB con i root file:
0.1 0.2 preSelected_0.1_0.2_.root
0.2 0.3 preSelected_0.2_0.3_.root
0.3 0.4 preSelected_0.3_0.4_.root
0.4 0.5 preSelected_0.4_0.5_.root
0.5 0.6 preSelected_0.5_0.6_.root
0.6 0.7 preSelected_0.6_0.7_.root
0.7 0.8 preSelected_0.7_0.8_.root
0.8 0.9 preSelected_0.8_0.9_.root
0.9 1 preSelected_0.9_1_.root
0 0.1 preSelected_0_0.1_.root
1.1 1.2 preSelected_1.1_1.2_.root
1.2 1.3 preSelected_1.2_1.3_.root
1.3 1.4 preSelected_1.3_1.4_.root
1.4 1.5 preSelected_1.4_1.5_.root
1.5 1.6 preSelected_1.5_1.6_.root
1.6 1.7 preSelected_1.6_1.7_.root
1.7 1.8 preSelected_1.7_1.8_.root
1.8 1.9 preSelected_1.8_1.9_.root
1.9 2 preSelected_1.9_2_.root
1 1.1 preSelected_1_1.1_.root
2.1 2.2 preSelected_2.1_2.2_.root
2.2 2.3 preSelected_2.2_2.3_.root
2.3 2.4 preSelected_2.3_2.4_.root
2.4 2.5 preSelected_2.4_2.5_.root
2.5 2.6 preSelected_2.5_2.6_.root
2.6 2.7 preSelected_2.6_2.7_.root
2.7 2.8 preSelected_2.7_2.8_.root
2.8 2.9 preSelected_2.8_2.9_.root
2.9 3 preSelected_2.9_3_.root
2 2.1 preSelected_2_2.1_.root
domenica 21 ottobre 2007
update
modificato leggermente InvMatrixLooper per accettare anche il caso in cui il maxnumpercrystal sia -1, cioe' tutti.
lanciaBarrel.pl updatato.
lanciaBarrel.pl updatato.
sabato 20 ottobre 2007
genera.pl usa un cfg file
lo script per il filtro geografico del dataset, genera.pl, e' stato modificato per leggere da un CFG file, analogamente a come fa cmsRun.
genera.pl e' committato, come un esempio di config file: genera_example.CFG in Calibration/EcalAlCaRecoProducers/script
ci sono un po' di note su come si puo' migliorarlo inserite nello script stesso.
Suggerirei di usare l'estensione CFG maiuscola per i cfg file di genera.pl, lasciarla minuscola per quelli di cmsRun (e non mettere mai il resto uguale).
Inoltre, sugggerisco anche che i nomi dei parametri del CFG file siano relativi a genera: quando ci sara' il cfg file anche per lanciaBarrel e lanciaEndcap, vorrei che i nomi dei parametri non si sovrapponessero, in modo da non creare ambiguita' - ed eventualmente usare lo stesso cfg file per entrambi i processi, di generazione e sottomissione.
genera.pl e' committato, come un esempio di config file: genera_example.CFG in Calibration/EcalAlCaRecoProducers/script
ci sono un po' di note su come si puo' migliorarlo inserite nello script stesso.
Suggerirei di usare l'estensione CFG maiuscola per i cfg file di genera.pl, lasciarla minuscola per quelli di cmsRun (e non mettere mai il resto uguale).
Inoltre, sugggerisco anche che i nomi dei parametri del CFG file siano relativi a genera: quando ci sara' il cfg file anche per lanciaBarrel e lanciaEndcap, vorrei che i nomi dei parametri non si sovrapponessero, in modo da non creare ambiguita' - ed eventualmente usare lo stesso cfg file per entrambi i processi, di generazione e sottomissione.
script per fare il file di testo DB
l'output di rfdir di una cartella castor e' il seguente:
-rw-r--r-- 1 govoni zh 7547831 Oct 13 19:51 preSelected_0.3_0.4_.root
-rw-r--r-- 1 govoni zh 7578728 Oct 13 19:46 preSelected_0.6_0.7_.root
-rw-r--r-- 1 govoni zh 7469746 Oct 13 19:46 preSelected_2.3_2.4_.root
-rw-r--r-- 1 govoni zh 7269604 Oct 13 19:46 preSelected_2.9_3_.root
sostituendo gli "_" con spazi si ottiene:
-rw-r--r-- 1 govoni zh 7547831 Oct 13 19:51 preSelected 0.3 0.4 .root
-rw-r--r-- 1 govoni zh 7578728 Oct 13 19:46 preSelected 0.6 0.7 .root
-rw-r--r-- 1 govoni zh 7469746 Oct 13 19:46 preSelected 2.3 2.4 .root
-rw-r--r-- 1 govoni zh 7269604 Oct 13 19:46 preSelected 2.9 3 .root
dove la nona colonna e' "preSelected", la decima e' etaStart, la undicesima e' etaEnd, la dodicesima e' "_.root". (Attenzione all'ultimo "_", e' messo apposta per facilitare questo script).
Quindi, scrivo:
rfdir $CASTOR_HOME/ECALCalib/AlCa/test | tr "_" " " | awk '{print $10" "$11" "$9"_"$10"_"$11"_"$12}' > db.txt
dove il comando "tr" sostituisce un singolo carattere, mentre awk stampa a schermo per ogni riga le colonne ed il ">" alla fine serve per deviare l'output su u file, che risulta essere:
0.3 0.4 preSelected_0.3_0.4_.root
0.6 0.7 preSelected_0.6_0.7_.root
2.3 2.4 preSelected_2.3_2.4_.root
2.9 3 preSelected_2.9_3_.root
PS : i file che adesso sono nel mio castor non sono esattamente come dico, perche' ho modificato lo script che li genera per cambiarne il formato del nome.
-rw-r--r-- 1 govoni zh 7547831 Oct 13 19:51 preSelected_0.3_0.4_.root
-rw-r--r-- 1 govoni zh 7578728 Oct 13 19:46 preSelected_0.6_0.7_.root
-rw-r--r-- 1 govoni zh 7469746 Oct 13 19:46 preSelected_2.3_2.4_.root
-rw-r--r-- 1 govoni zh 7269604 Oct 13 19:46 preSelected_2.9_3_.root
sostituendo gli "_" con spazi si ottiene:
-rw-r--r-- 1 govoni zh 7547831 Oct 13 19:51 preSelected 0.3 0.4 .root
-rw-r--r-- 1 govoni zh 7578728 Oct 13 19:46 preSelected 0.6 0.7 .root
-rw-r--r-- 1 govoni zh 7469746 Oct 13 19:46 preSelected 2.3 2.4 .root
-rw-r--r-- 1 govoni zh 7269604 Oct 13 19:46 preSelected 2.9 3 .root
dove la nona colonna e' "preSelected", la decima e' etaStart, la undicesima e' etaEnd, la dodicesima e' "_.root". (Attenzione all'ultimo "_", e' messo apposta per facilitare questo script).
Quindi, scrivo:
rfdir $CASTOR_HOME/ECALCalib/AlCa/test | tr "_" " " | awk '{print $10" "$11" "$9"_"$10"_"$11"_"$12}' > db.txt
dove il comando "tr" sostituisce un singolo carattere, mentre awk stampa a schermo per ogni riga le colonne ed il ">" alla fine serve per deviare l'output su u file, che risulta essere:
0.3 0.4 preSelected_0.3_0.4_.root
0.6 0.7 preSelected_0.6_0.7_.root
2.3 2.4 preSelected_2.3_2.4_.root
2.9 3 preSelected_2.9_3_.root
PS : i file che adesso sono nel mio castor non sono esattamente come dico, perche' ho modificato lo script che li genera per cambiarne il formato del nome.
Un paio di note
Anzitutto ho finalmente aggiunto il "maxSelectedEventPerCrystal"
Non usa un evento se il cristallo su cui si ha la hit più energetica è stato il più energetico per più del numero selezionato di volte.
Permette di fare facilmente studi di risoluzione in funzione del numero di eventi.
è committato.
Quando faccio girare l'alcatesting insieme al looper per un qualche motivo mi legge più elettroni di quanti ce ne sono....esattamente il doppio di quanti sarebbero non filtrati...da investigare....
Per i file xml direi che la cosa migliore rimane quella di cambiare con gli script i nomi...
Non so altrimenti come fare(se non modificando il codice dei calibXMLwriter per far prendere loro qualcosa dal .cfg)
Non ho idea di come fare il file di testo coi file di root...
Di scripting non ho proprio idea.
Non usa un evento se il cristallo su cui si ha la hit più energetica è stato il più energetico per più del numero selezionato di volte.
Permette di fare facilmente studi di risoluzione in funzione del numero di eventi.
è committato.
Quando faccio girare l'alcatesting insieme al looper per un qualche motivo mi legge più elettroni di quanti ce ne sono....esattamente il doppio di quanti sarebbero non filtrati...da investigare....
Per i file xml direi che la cosa migliore rimane quella di cambiare con gli script i nomi...
Non so altrimenti come fare(se non modificando il codice dei calibXMLwriter per far prendere loro qualcosa dal .cfg)
Non ho idea di come fare il file di testo coi file di root...
Di scripting non ho proprio idea.
venerdì 19 ottobre 2007
lanciare i job di calibrazione sui dati sminuzzati
ho committato in:
Calibration/EcalAlCaRecoProducers/script
lanciaBarrel.pl, che serve per lanciare i job di calibrazione scegliendo i root file sui quali girare a seconda del delta eta. Ha bisogno di un file di testo come database dei root file, ad esempio del tipo (etaStart, etaEnd, nomeFile):
0.0 0.1 primo.root
0.1 0.2 secondo.root
0.2 0.3 terzo.root
0.3 0.4 quarto.root
0.4 0.5 quinto.root
da creare dalla lista di root file generati, o in sede di generazione dentro a genera.pl.
Non e' ancora completo, l'equivalente per l'endcap e' committato, ma e' molto piu' indietro.
Per sicurezza c'e' un margine intorno alla regione da calibrare.
Nessuno dei due script e' stato testato.
Che cosa ne dite? Come e' meglio generare il file di testo secondo voi?
ciao,
p
Calibration/EcalAlCaRecoProducers/script
lanciaBarrel.pl, che serve per lanciare i job di calibrazione scegliendo i root file sui quali girare a seconda del delta eta. Ha bisogno di un file di testo come database dei root file, ad esempio del tipo (etaStart, etaEnd, nomeFile):
0.0 0.1 primo.root
0.1 0.2 secondo.root
0.2 0.3 terzo.root
0.3 0.4 quarto.root
0.4 0.5 quinto.root
da creare dalla lista di root file generati, o in sede di generazione dentro a genera.pl.
Non e' ancora completo, l'equivalente per l'endcap e' committato, ma e' molto piu' indietro.
Per sicurezza c'e' un margine intorno alla regione da calibrare.
Nessuno dei due script e' stato testato.
Che cosa ne dite? Come e' meglio generare il file di testo secondo voi?
ciao,
p
nomi dei file XML
ciao,
sembra che non sia possibile cambiare da dentro il codice il nome ai file XML, come si capisce dal codice al link:
http://cmssw.cvs.cern.ch/cgi-bin/cmssw.cgi/CMSSW/Calibration/Tools/src/calibXMLwriter.cc?revision=1.2&view=markup
Questo per noi e' un po' fastidioso perche' vogliamo salvare sotto-porzioni di file XML con nomi differenti.
O lo facciamo con gli script al batch, di rinominare i file, oppure cambiamo il codice di salvataggio. Per ora direi di farlo con gli script al batch, poi si vedra'.
Che ne pensate?
p
sembra che non sia possibile cambiare da dentro il codice il nome ai file XML, come si capisce dal codice al link:
http://cmssw.cvs.cern.ch/cgi-bin/cmssw.cgi/CMSSW/Calibration/Tools/src/calibXMLwriter.cc?revision=1.2&view=markup
Questo per noi e' un po' fastidioso perche' vogliamo salvare sotto-porzioni di file XML con nomi differenti.
O lo facciamo con gli script al batch, di rinominare i file, oppure cambiamo il codice di salvataggio. Per ora direi di farlo con gli script al batch, poi si vedra'.
Che ne pensate?
p
mercoledì 17 ottobre 2007
miscalibrazione
le varie miscalibrazioni sono salvate qui:
CalibCalorimetry/CaloMiscalibTools/data
Con i seguenti file d XML a seconda degli scenari:
100pb-1 scenario:
miscalibcsa07_barrel.xm,l
miscalibcsa07_endcap.xml
10pb-1 scenario:
ecal_barrel_10pb.xml
ecal_endcap_10pb.xml
#startup scenario:
ecal_barrel_startup.xml
ecal_endcap_startup.xml
Il file committato miscalib.cfg aggiunge all'evento i rechit miscalibrati, SENZA fare ri-ricostruzione degli oggetti fisici.
La rilettura del file e' stata testata con l'alcaElectron_test.cfg committato.
gli InputTag utilizzati, nel modulo, sono:
module alCaIsolatedElectrons = AlCaElectronsProducer
{
#PG miscalibrated input (prod. by Miscalib.cfg)
InputTag ebRecHitsLabel = miscalrechit:alcaBarrelHitsMiscalib
InputTag eeRecHitsLabel = miscalrechit:alcaEndcapHitsMiscalib
InputTag electronLabel = electronFilter
string alcaBarrelHitCollection = "alcaBarrelHits"
string alcaEndcapHitCollection = "alcaEndcapHits"
int32 etaSize = 5
int32 phiSize = 11
}
CalibCalorimetry/CaloMiscalibTools/data
Con i seguenti file d XML a seconda degli scenari:
100pb-1 scenario:
miscalibcsa07_barrel.xm,l
miscalibcsa07_endcap.xml
10pb-1 scenario:
ecal_barrel_10pb.xml
ecal_endcap_10pb.xml
#startup scenario:
ecal_barrel_startup.xml
ecal_endcap_startup.xml
Il file committato miscalib.cfg aggiunge all'evento i rechit miscalibrati, SENZA fare ri-ricostruzione degli oggetti fisici.
La rilettura del file e' stata testata con l'alcaElectron_test.cfg committato.
gli InputTag utilizzati, nel modulo, sono:
module alCaIsolatedElectrons = AlCaElectronsProducer
{
#PG miscalibrated input (prod. by Miscalib.cfg)
InputTag ebRecHitsLabel = miscalrechit:alcaBarrelHitsMiscalib
InputTag eeRecHitsLabel = miscalrechit:alcaEndcapHitsMiscalib
InputTag electronLabel = electronFilter
string alcaBarrelHitCollection = "alcaBarrelHits"
string alcaEndcapHitCollection = "alcaEndcapHits"
int32 etaSize = 5
int32 phiSize = 11
}
AlcaElectronsTest
sistemato un bug, c'e' un nuovo commit, funziona.
visti i plot sulle regioni ristrette in eta.
visti i plot sulle regioni ristrette in eta.
domenica 14 ottobre 2007
AlcaElectronsTest duplicato
ciao,
ho duplicato AlcaElectronsTest in AlcaElectronsTestCalib, con l'idea di togliere da AlcaElectronsTest tutto quello che riguardi dla ricalibrazione, in modo da avere un tester per fare plot vemoci senza stare a preoccuparsi della ricalibrazione.
Ora riduco AlcaElectronsTest, per fare test con la ricalibrazione quindi l'ora in poi usiamo Alca...Calib, ed eventualmente modifichiamo quello.
ciao,
p
ho duplicato AlcaElectronsTest in AlcaElectronsTestCalib, con l'idea di togliere da AlcaElectronsTest tutto quello che riguardi dla ricalibrazione, in modo da avere un tester per fare plot vemoci senza stare a preoccuparsi della ricalibrazione.
Ora riduco AlcaElectronsTest, per fare test con la ricalibrazione quindi l'ora in poi usiamo Alca...Calib, ed eventualmente modifichiamo quello.
ciao,
p
mercoledì 10 ottobre 2007
Considerazioni varie nonchè eventuali sui tagli
Sta girando l'alcaElectronTest su dei relVal di Wenu che vanno con eta da 0 al massimo.
Ora facciamo 3 tipi di tagli:
Energia del supercluster vs. pIn: Si suppone che se un superCluster è stato ricostruito bene e pIn ricostruito bene anche questo valore stia intorno a 1 più o meno un errore.
Nel range di eta tra 0 e 0.2 la media di questo parametro è 1.06 mentre la moda(il bin più pieno è a 0.6)
Questo parametro è abbastanza correlato linearmenteo al rapporto E25/pIn. Se non c'è brehmstrallung è quello che ci aspettiamo.
Si può fare un taglio tra 0,9 e 1,1 prendendo ben due terzi degli elettroni nel range tra 0 e 0,2.
Energia del cluster seed vs. pout. Ci aspettiamo pure qua che il rapporto sia uno se il seed è identificato bene e se pout è misuragio giusto.
Nel range tra 0 e 0.2 si vede una traccia correlata col rapporto E25/pIn, come ci aspettiamo, e un picco scorrelato a E/p = 1. Questo avviene quando pIn è misurato giusto ma pOut è sbagliato. Se tagliamo su questo parametro perdiamo un certo numero di elettroni "buoni", ma per i quali non possiamo fare tagli sulla brehmstrallung.
Sempre in questo range la media di questo parametro è addirittura a 1,23, indicando che la coda che sale è molto alta. La moda sta a 1,04 abbastanza alta comunque...
Tagliando tra 0,9 e 1,15 si perde un elettrone ogni 2, molti dei quali hanno un rapporto ESCOpin buono.
combinando i due tagli si arriva a perdere il 60% degli elettroni.
PminOput se i due sono stati misurati bene toglie la brehmstrallung. Dovrebbe essere correlato a E25/pIn(meno ha radiato più l'energia dovrebbe essere confinata)...ma non lo è tanto... Un buon taglio sembra tra 0,15 e -0,02..il limite inferiore conta poco una volta che è inferiore di zero perchè una volta fatti i primi 2 tagli non ne rimane praticamente nessuno. Si perdono un'altro 20% circa di elettroni in eta tra 0 e 0,2.
Ora provo a guardare in tutte le altre zone e vedo quanti elettroni si salvano facendo due tagli: 0,9-1,1 per il primo parametro e 0,9 - 1,15 per il secondo.
A seconda della zona vengono tenuti più o meno elettroni.
In eta tra 0,2 e 0,4 è tutto uguale.
In eta tra 0,4 e 0,6 tra i due tagli si salva meno del 30% degli elettroni.
Senza il taglio sul Eseed o Pout si salvano il 57% degli elettroni.
Tra 0,6 e 0,8 ancora il 55% degli elettroni si mantiene al taglio EscoOpin.
EseedOput aumenta parecchio. Ha come moda 1,06. Non ci sono praticamente eventi sotto 1. A tagliare tra 0,9 e 1,15 si perdono praticamente il 30% degli elettroni.
Con i due tagli combinati si tengono il 22% degli elettroni.
Tra 0,8 e 1 la situazione è ancora più critica. Il primo taglio funziona ugualmente, il secondo mantiene solo il 20% degli elettroni e combinandoli si tiene neanche un 18% del totale. (uno ogni 5,5)
Tra 1 e 1,2 il primo taglio mantiene il 50% degli elettroni. Il secondo ha una media che sale ancora e se si taglia tra 0,9 e 1,15 si salvano un 13 % scarso di elettroni.
Combinando i 2 tagli salviamo un elettrone ogni 10.
Tra 1,2 e 1,4 il primo taglio permette di salvare il 40% degli elettroni solamente.
il secondo di nuovo solo un 12% degli elettroni. Combinati il 9%.
Tra 1,4 e1,6 è la zona più critica. Il primo taglio salva il 30% degli elettroni.
il secondo taglio il 16%. Combinati il 9%
tra 1,6 e 1,8 il primo taglio ancora salva un 30% degli elettroni. Il secondo il 15.
Combinati il 10%.
Tra 1,8 e 2 il primo taglio salva il 30% degli elettroni Moda e media si abbassano. Il secondo ancora il 15.
I due combinati il 10%.
(mi sa ad occhio che ho saltato 2-2,2?? ma è tardi e ci vuole mezz'ora perchè sia pronto)
Tra 2,2 e 2,4 si salvano dal primo taglio il 37% degli elettroni. Recuperiamo un po'.
19% al secondo. Si risale pure qua!
Il 12,5% combinato.
CONSIDERAZIONI FINALI:
Solo a basso eta sembra praticabile il secondo taglio "strettamente". Conviene lasciarlo molto largo e tagliare sul primo e sulla brehmstrallung.
Bisogna capire inoltre perchè ha media e moda incompatibili con 1.
Domani provo a calibrare escludendo questo secondo taglio.
Nota a margine:
TAgliando in eta vengono smangiati un po' di elettroni ai bordi della zona. Quando tagliamo meglio includere un anello in più!
Ora facciamo 3 tipi di tagli:
Energia del supercluster vs. pIn: Si suppone che se un superCluster è stato ricostruito bene e pIn ricostruito bene anche questo valore stia intorno a 1 più o meno un errore.
Nel range di eta tra 0 e 0.2 la media di questo parametro è 1.06 mentre la moda(il bin più pieno è a 0.6)
Questo parametro è abbastanza correlato linearmenteo al rapporto E25/pIn. Se non c'è brehmstrallung è quello che ci aspettiamo.
Si può fare un taglio tra 0,9 e 1,1 prendendo ben due terzi degli elettroni nel range tra 0 e 0,2.
Energia del cluster seed vs. pout. Ci aspettiamo pure qua che il rapporto sia uno se il seed è identificato bene e se pout è misuragio giusto.
Nel range tra 0 e 0.2 si vede una traccia correlata col rapporto E25/pIn, come ci aspettiamo, e un picco scorrelato a E/p = 1. Questo avviene quando pIn è misurato giusto ma pOut è sbagliato. Se tagliamo su questo parametro perdiamo un certo numero di elettroni "buoni", ma per i quali non possiamo fare tagli sulla brehmstrallung.
Sempre in questo range la media di questo parametro è addirittura a 1,23, indicando che la coda che sale è molto alta. La moda sta a 1,04 abbastanza alta comunque...
Tagliando tra 0,9 e 1,15 si perde un elettrone ogni 2, molti dei quali hanno un rapporto ESCOpin buono.
combinando i due tagli si arriva a perdere il 60% degli elettroni.
PminOput se i due sono stati misurati bene toglie la brehmstrallung. Dovrebbe essere correlato a E25/pIn(meno ha radiato più l'energia dovrebbe essere confinata)...ma non lo è tanto... Un buon taglio sembra tra 0,15 e -0,02..il limite inferiore conta poco una volta che è inferiore di zero perchè una volta fatti i primi 2 tagli non ne rimane praticamente nessuno. Si perdono un'altro 20% circa di elettroni in eta tra 0 e 0,2.
Ora provo a guardare in tutte le altre zone e vedo quanti elettroni si salvano facendo due tagli: 0,9-1,1 per il primo parametro e 0,9 - 1,15 per il secondo.
A seconda della zona vengono tenuti più o meno elettroni.
In eta tra 0,2 e 0,4 è tutto uguale.
In eta tra 0,4 e 0,6 tra i due tagli si salva meno del 30% degli elettroni.
Senza il taglio sul Eseed o Pout si salvano il 57% degli elettroni.
Tra 0,6 e 0,8 ancora il 55% degli elettroni si mantiene al taglio EscoOpin.
EseedOput aumenta parecchio. Ha come moda 1,06. Non ci sono praticamente eventi sotto 1. A tagliare tra 0,9 e 1,15 si perdono praticamente il 30% degli elettroni.
Con i due tagli combinati si tengono il 22% degli elettroni.
Tra 0,8 e 1 la situazione è ancora più critica. Il primo taglio funziona ugualmente, il secondo mantiene solo il 20% degli elettroni e combinandoli si tiene neanche un 18% del totale. (uno ogni 5,5)
Tra 1 e 1,2 il primo taglio mantiene il 50% degli elettroni. Il secondo ha una media che sale ancora e se si taglia tra 0,9 e 1,15 si salvano un 13 % scarso di elettroni.
Combinando i 2 tagli salviamo un elettrone ogni 10.
Tra 1,2 e 1,4 il primo taglio permette di salvare il 40% degli elettroni solamente.
il secondo di nuovo solo un 12% degli elettroni. Combinati il 9%.
Tra 1,4 e1,6 è la zona più critica. Il primo taglio salva il 30% degli elettroni.
il secondo taglio il 16%. Combinati il 9%
tra 1,6 e 1,8 il primo taglio ancora salva un 30% degli elettroni. Il secondo il 15.
Combinati il 10%.
Tra 1,8 e 2 il primo taglio salva il 30% degli elettroni Moda e media si abbassano. Il secondo ancora il 15.
I due combinati il 10%.
(mi sa ad occhio che ho saltato 2-2,2?? ma è tardi e ci vuole mezz'ora perchè sia pronto)
Tra 2,2 e 2,4 si salvano dal primo taglio il 37% degli elettroni. Recuperiamo un po'.
19% al secondo. Si risale pure qua!
Il 12,5% combinato.
CONSIDERAZIONI FINALI:
Solo a basso eta sembra praticabile il secondo taglio "strettamente". Conviene lasciarlo molto largo e tagliare sul primo e sulla brehmstrallung.
Bisogna capire inoltre perchè ha media e moda incompatibili con 1.
Domani provo a calibrare escludendo questo secondo taglio.
Nota a margine:
TAgliando in eta vengono smangiati un po' di elettroni ai bordi della zona. Quando tagliamo meglio includere un anello in più!
lunedì 8 ottobre 2007
Stime di tempo (per futura memoria)
Servono circa 1,5 millisecondi ad evento per processare un dato su cmsm3.Circa 1 su un lxplus.
Per processare 8Meventi della csa su una cpu di un computer della caf servono di conseguenza 2 ore e qualcosina per un loop.
Per girare su più cpu contemporaneamente bisogna mettere dei filtri per splittare gli eventi in regioni.
Rimane da investigare quanto tempo porta via filtrare un singolo evento per vedere quanto tempo fa perdere per vedere quante cpu ci servono.
Ad ogni modo con 4cpu e un giorno a disposizione se non facciamo vaccate perchè abbiamo già testato tutto (script vari, config files, che tagli fare, inputTags....)ci stiamo dentro largamente.
Se abbiamo qualcosa in più, soprattuto di tempo più che di cpu, tanto meglio.
Per processare 8Meventi della csa su una cpu di un computer della caf servono di conseguenza 2 ore e qualcosina per un loop.
Per girare su più cpu contemporaneamente bisogna mettere dei filtri per splittare gli eventi in regioni.
Rimane da investigare quanto tempo porta via filtrare un singolo evento per vedere quanto tempo fa perdere per vedere quante cpu ci servono.
Ad ogni modo con 4cpu e un giorno a disposizione se non facciamo vaccate perchè abbiamo già testato tutto (script vari, config files, che tagli fare, inputTags....)ci stiamo dentro largamente.
Se abbiamo qualcosa in più, soprattuto di tempo più che di cpu, tanto meglio.
Correlazioni
domenica 7 ottobre 2007
per futura memoria
questo magari significa che il try and catch puo' essere sostituito da un if ....isValid, accettiamo di non avere altri crash.
p
Begin forwarded message:
From: "Chris Jones"
Date: October 7, 2007 2:08:33 AM GMT+02:00
To: hn-cms-edmFramework@cern.ch
Subject: change to edm::Event single product 'get' routines in 1_7_X
*** Discussion title: Framework and Edm Development
Dear collaborators,
As requested, I have changed the behavior of all the edm::Event
single product 'get' methods (e.g. getByLabel and getByType) so that
in the case where the data requested is not available in the
edm::Event the method will return a value of 'false' and the
edm::Handle<> which was passed to the method will return false from
its 'isValid()' method. However, if the edm::Handle<> is later
dereferenced, the edm::Handle<> will throw the same exception which
the 'get' methods formerly threw. In this way, modules which never
tried to 'catch' a thrown exception should not even notice the change
in behavior. Modules which did try to catch exceptions (which under
almost all conditions is a bad idea) may have to be modified to
behave the intended way after this change. Also, the 'get' methods
still do throw exceptions for other reasons (e.g. more than one
product matches the request or if an error occurs why trying to read
the data from disk]).
This change is scheduled to be included with the
CMSSW_1_7_X_2007-10-07-0200 integration build. Given the minimal
change to the interfaces (the get methods now return a bool and some
additional functions were added to edm::Handle<>) it is unlikely that
any compilation error will occur. However, for modules which were
trying to catch the exception it is likely that they no longer
function as intended.
Sincerely,
Chris
p
Begin forwarded message:
From: "Chris Jones"
Date: October 7, 2007 2:08:33 AM GMT+02:00
To: hn-cms-edmFramework@cern.ch
Subject: change to edm::Event single product 'get' routines in 1_7_X
*** Discussion title: Framework and Edm Development
Dear collaborators,
As requested, I have changed the behavior of all the edm::Event
single product 'get' methods (e.g. getByLabel and getByType) so that
in the case where the data requested is not available in the
edm::Event the method will return a value of 'false' and the
edm::Handle<> which was passed to the method will return false from
its 'isValid()' method. However, if the edm::Handle<> is later
dereferenced, the edm::Handle<> will throw the same exception which
the 'get' methods formerly threw. In this way, modules which never
tried to 'catch' a thrown exception should not even notice the change
in behavior. Modules which did try to catch exceptions (which under
almost all conditions is a bad idea) may have to be modified to
behave the intended way after this change. Also, the 'get' methods
still do throw exceptions for other reasons (e.g. more than one
product matches the request or if an error occurs why trying to read
the data from disk]).
This change is scheduled to be included with the
CMSSW_1_7_X_2007-10-07-0200 integration build. Given the minimal
change to the interfaces (the get methods now return a bool and some
additional functions were added to edm::Handle<>) it is unlikely that
any compilation error will occur. However, for modules which were
trying to catch the exception it is likely that they no longer
function as intended.
Sincerely,
Chris
sabato 6 ottobre 2007
Iscriviti a:
Post (Atom)