DataMixer

Introduction

We have done some work on the datamixer for Ecal. It was basically along the following two lines:

1. Modify the code in order to add correct handling of the gain switch
2. Validate the code by producing the following samples

• Minbias with noise
• Minbias no noise mixed with nu gun with noise
• Nu gun with noise mixed with minbias no noise

The idea is that all three samples should give the same results

Gain switch code

The idea is that in mixing two digis, the gain of the highest energy sample should be retained. The lower energy sample should be scaled to the lower (higher energy) gain taking into account that the pedestals are different for different gains. The formula we use is therefore:

float ratio = gainRatios[gain_new-1]/gainRatios[gain_old-1];
adc_old = (int) round ((adc_old - pedeStals[gain_old-1]) * ratio + pedeStals[gain_new-1] );
adc_sum = adc_new + adc_old;

when the sample to be mixed has lower energy and similar for the opposite situation. If adc_sum is then higher than 4096, the gain is switched again if we are not already in gain 1.
The code is committed at the HEAD as
SimGeneral/DataMixingModule/plugins/DataMixingEMDigiWorker.cc
SimGeneral/DataMixingModule/plugins/DataMixingEMDigiWorker.h

Gain switch validation

We "validated" by looking at the resulting FADC traces after mixing
an electron gun of 1000 GeV without noise with nu gun events. We used a trivial module called PlotEcalDigis (see section Test Code below). Here are examples of FADC traces after mix. One is for a channel that switches to gain 1 (g3), one switches to gain 2 (g2) and one stays in g1 and shows noise (proving that the digis do mix).

Todo: check that without mixing the trace is flat

Known issue

There are cases in which the datamixer produces empty traces with gainId=0 (which is a non valid gainId). Under investigation.


Test Code

The code used can be checked out from UserCode/Torino/Ecal/datamixerstuff
The package UserCode/PlotEcalDigis contains the analyzer to plot FADC traces. The procedure used was the following:

cmsRun sim-singlee1000-nonoise.py
cmsRun reco-egun.py
cmsRun mm_deb_overlay_egunonnugun_cff.py
cmsRun src/User/PlotEcalDigis/python/runplotdigis_cfg.py

Note that mixOne_data_on_data_secEqNu_cfi.py has to be copied to SimGeneral/DataMixingModule/python and compiled. The last step produces a file called histo.root that with FADC traces

MinBias with Nu mixes

I generated the samples that I report here :

• Minbias with noise
• Minbias no noise mixed with nu gun with noise
• Nu gun with noise mixed with minbias no noise

Using the following commands:

#generation cmsRun sim-minbias-noise.py >& log1.log
cmsRun sim-minbias-nonoise.py >& log2.log
cmsRun sim-nugun-noise.py >& log3.log
#get reco digi cmsRun reco-minbias-noise.py >& log4.log
cmsRun reco-minbias-nonoise.py >& log5.log
cmsRun reco-nugun.py >& log6.log #mix
cmsRun src/SimGeneral/DataMixingModule/test/mm_deb_overlay_minbiasonnu_cff.py >& log7.log
cmsRun src/SimGeneral/DataMixingModule/test/mm_deb_overlay_nuonminbias_cff.py >& log8.log
#get rechits from mixed digis
cmsRun rereco-mix-MinbiasNoNoiseonNu.py >& log9.log
cmsRun rereco-mix-NuonMinBiasNoNoise.py >& log10.log

In this complicated procedure we generate and save raw data, reconstruct and generate digis, mix from reconstructed digis (note that it is possible to mix from simulated digis or rechits). Indeed we could have taken a shorter path. Then we reconstruct again to look at rechits after mixing.

Here we show the distribution of rechit energies in five cases:

Nu gun (pure noise)





Minimum bias without noise

Minimum bias with noise



Minimum bias no noise mixed on nu gun :




Nu gun mixed with minimum bias no noise




The last three distribution seem compatible, proving that the mixing works


Electrons of 250 GeV on top of electrons of 1000 GeV

We have generated electrons of different energies in the same eta/phi region to check that samples with different gains are added consistently.
Note : in the following "e100" is reported where it should be "e1000", as the configuration file
sim-singlee100-noise-small.py actually contains settings for e1000. This is why there are switches to gainId=3.

#test gain switch e250 on e100 in a small region
cmsRun sim-singlee100-noise-small.py
cmsRun sim-singlee250-noise-small.py cmsRun reco-egun-100-small.py
cmsRun reco-egun-250-small.py
cmsRun src/SimGeneral/DataMixingModule/test/mm_deb_overlay_egunonegun_cff.py
cmsRun src/User/PlotEcalDigis/python/runplotdigis_cfg.py

Here are a couple examples

Summing

Adding signals -2 191
1 199[1] 201[1] 200[1] 293[1] 3147[2] 4071[2] 3637[2] 2805[2] 2033[2] 1435[2]
2 201[1] 200[1] 199[1] 203[1] 532[1] 638[1] 591[1] 496[1] 409[1] 341[1]






Adding signals -1 12
1 200[1] 200[1] 199[1] 205[1] 499[1] 597[1] 550[1] 465[1] 389[1] 326[1]
2 198[1] 200[1] 201[1] 256[1] 3825[1] 2589[2] 2322[2] 1809[2] 1333[2] 963[2]


Adding signals -1 11
1 202[1] 199[1] 200[1] 352[1] 941[3] 1166[3] 1054[3] 848[3] 656[3] 506[3]
2 200[1] 201[1] 198[1] 390[1] 1128[3] 1410[3] 1270[3] 1011[3] 771[3] 585[3]


Adding signals -1 190
1 200[1] 200[1] 202[1] 209[1] 767[1] 944[1] 860[1] 700[1] 554[1] 438[1]
2 200[1] 200[1] 199[1] 204[1] 476[1] 565[1] 525[1] 446[1] 373[1] 318[1]

Adding signals -1 191
1 197[1] 198[1] 202[1] 213[1] 1122[1] 1416[1] 1278[1] 1021[1] 779[1] 588[1]
2 201[1] 199[1] 202[1] 414[1] 1252[3] 1572[3] 1413[3] 1120[3] 847[3] 636[3]
The opposite overlay (electrons of 250 GeV on electrons of 1000 GeV) has been tested and gave sensible results (question: why are'nt the input traces just swapped ?)

Adding signals -2 191
1 200[1] 199[1] 202[1] 291[1] 3119[2] 4034[2] 3602[2] 2779[2] 2018[2] 1423[2]
2 201[1] 200[1] 201[1] 202[1] 517[1] 617[1] 573[1] 481[1] 399[1] 334[1]


Adding signals -1 191
1 199[1] 203[1] 198[1] 214[1] 1009[1] 1268[1] 1150[1] 922[1] 706[1] 540[1]
2 200[1] 200[1] 199[1] 411[1] 1236[3] 1554[3] 1400[3] 1108[3] 839[3] 630[3]


Adding signals -1 190
1 199[1] 200[1] 199[1] 209[1] 675[1] 821[1] 753[1] 622[1] 497[1] 401[1]
2 200[1] 199[1] 199[1] 205[1] 448[1] 534[1] 495[1] 425[1] 358[1] 306[1]


Adding signals -1 11
1 199[1] 200[1] 201[1] 325[1] 3847[2] 992[3] 900[3] 730[3] 573[3] 452[3]
2 199[1] 202[1] 201[1] 398[1] 1163[3] 1457[3] 1312[3] 1043[3] 793[3] 600[3]


Adding signals -1 12
1 199[1] 200[1] 200[1] 203[1] 440[1] 515[1] 484[1] 414[1] 351[1] 302[1]
2 200[1] 200[1] 198[1] 255[1] 3826[1] 2586[2] 2317[2] 1805[2] 1331[2] 960[2]

Work

phi symmetry. I realized that the cut applied in the alcareco stream EE is 750 not 650. This may account for the k<1 problem and high miscalibration.
Running now

phisym-eb160-ee825-up1.5-k0.1.cfg.tmpl

no differences ...

Playing with L1 trigger bits

Study L1 bias on csa08 data:


include "L1TriggerConfig/L1GtConfigProducers/data/L1GtConfig.cff"
replace l1GtTriggerMenuXml.TriggerMenuLuminosity = "lumi1030"
replace l1GtTriggerMenuXml.DefXmlFile = "L1Menu2008_2E30.xml"

module selectL1 = HLTLevel1GTSeed{

# string L1SeedsLogicalExpression = "(L1_ZeroBias OR L1_SingleJetCountsHFTow OR L1_DoubleJetCountsHFTow OR L1_SingleJetCountsHFRing0Sum3 OR L1_DoubleJetCountsHFRing0Sum3 OR L1_SingleJetCountsHFRing0Sum6 OR L1_DoubleJetCountsHFRing0Sum6) AND NOT L1_SingleEG2 AND NOT L1_DoubleEG1"
string L1SeedsLogicalExpression = "L1_ZeroBias AND NOT L1_SingleEG2 AND NOT L1_DoubleEG1"

InputTag L1GtReadoutRecordTag = "hltGtDigis"
bool L1TechTriggerSeeding = False
InputTag L1GtObjectMapTag = "hltL1GtObjectMap"
InputTag L1CollectionsTag = "hltL1extraParticles"
InputTag L1MuonCollectionTag = "hltL1extraParticles"

}


mistery: if paretheses are added to the logical expression, the filter complains about products not present in the event ...

test: try L1MinBias OR L1_EG versus MinBias alone

phisym-eb160-ee710-up1.5-noL1EG.cfg.tmpl : L1MinBias AND NOT L1_SingleEG2 AND NOT DoubleEG1


Launched high threshold job (500 Mev in barrel) algorithm did not work (nans)