domenica 23 dicembre 2007

cambio di sub-package

Abbiamo spostato InvMatrixLooper e InvRingCalib da Calibration/EcalAlCaRecoProducers ad Calibration/EcalCalibAlgos; BlockSover, IMASelector, PhiRangeSelector in Calibration/Tools.
Il tutto e' taggato "afterMigration".

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

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.

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

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



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.

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.



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.

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.



confronto: calib x recalib in EB

Ecco gli analoghi per il barrel.


confronto: calib x recalib in EE con le fette

Ecco il plot di confronto calibrazione x scalibrazione, dopo l'unione dei risultati delle singole 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!

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.



una grezza idea della statistica


questa e' le dimensione di ogni singolo file processato in funzione dell'eta di partenza (sono fette da 0.2 in eta).

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.

il DB file e' committato

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.

breve tutorial per LSF

link

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.

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.

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.

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

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

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.

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" }
}
}

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.

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

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

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.

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.

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

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.

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 -"

monitor della CAF

lemonweb

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'.

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.

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

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.

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.

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'?)
da fare:
  • la composizione dei file XML
  • catturare l'output e ritornarlo per non perdere le efficienze (questo anche in genera.pl)
che cosa ne dite? che cosa manca da fare subito, ancora?

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.

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

domenica 21 ottobre 2007

update

modificato leggermente InvMatrixLooper per accettare anche il caso in cui il maxnumpercrystal sia -1, cioe' tutti.
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.

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.

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.

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

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

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
}

AlcaElectronsTest

sistemato un bug, c'e' un nuovo commit, funziona.
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

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ù!

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.

Correlazioni


Due plot della correlazione tra ESCOpin e EseedOpout.
Nel primo è stata tolta la brehmstrallung con tagli su PminMpoutOpin tra -0,9 e 0,15
Nel secondo tutti i parametri sono stati lasciati larghi praticamente su tutto lo spettro.

relazione fra eta ed R nell'endcap

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

sabato 6 ottobre 2007