Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Replace SeedingLayersESProducer with an EDProducer #2286

Closed
wants to merge 48 commits into from

Conversation

makortel
Copy link
Contributor

@makortel makortel commented Feb 4, 2014

SeedingLayers being constructed by an ESProducer is incompatible with the consumes() interface (they read pixel and strip RecHits from the event thus needing edm::ConsumesCollector). Replacing the ESProducer with an EDProducer has smaller impact on the configuration side than alternatives, and allows some reduction of repeated construction of TransientTrackingRecHits from same clusters. In addition to what was presented in the RECO meeting on Jan 16th (https://indico.cern.ch/conferenceDisplay.py?confId=293827), this PR contains further optimization based on comments by Chris and Liz.

All configuration files found with git grep SeedingLayersESProducer were migrated, except the ones that looked like dumps from ConfDB (under HLTrigger and DQM/DataScouting). Because of the configuration changes, all workflows containing HLT will be broken until the changes are migrated to ConfDB and to the dumps.

Rebased on top of 7_0_0_pre12 + #2269 (=first two commits).

MultiTrackValidator with 40 events of 13 TeV TTBar + 40 PU (25 ns) gives identical results. With 100 TTbar+40 PU events, overall RECO timing decreases by ~0.5 % and heap size increases by ~10 MB. With 15000 events from run 207515 and menu /online/collisions/2012/8e33/v2.3/HLT/V28 (including prescales), overall HLT timing decreases by ~0.8 % and heap size decreases slightly (~100 kB).

FYI: @Martin-Grunewald, @VinInn

…s unused

This simplifies further development of SeedingLayerSetsBuilder.
…nterface

The old interface needs to be kept, because some classes use it with
ctfseeding:SeedingLayer's constructed without SeedingLayersESProducer.
I used templates in CosmicTrackingRegion and
RectangularEtaPhiTrackingRegion to avoid copy-pasting.
In QuadrupletSeedMerger SeedingLayerSets are used only to iterate over
layer-quadruplets. Therefore SeedingLayersEDProducer would mean
unnecessary work by creating the TTRHs. Therefore I decided to just
deliver the SeedingLayerSetsBuilder PSet to QuadrupletSeedMerger, and
construct SeedingLayerSetsBuilder in the constructor.
Will need to deliver edm::ConsumesCollector to OrderedHitsGenerator in
SeedFilter (to be added in a later commit).

As a knock-on effect, move SeedFilter construction from beginRun() to
constructor in ElectronSeedProducer. Also, use std::unique_ptr for
SeedFilter.
Will be needed to deliver edm::ConsumesCollector to
- CombinedHitPairGenerator
- CombinedMultiHitGenerator
- CombinedHitTripletGenerator
- CombinedHitPairGeneratorForPhotonConversion
- CombinedHitQuadrupletGeneratorForPhotonConversion

Following concrete classes inherit from OrderedHitsGenerator
- BeamHaloPairGenerator
- GenericPairGenerator
- GenericTripletGenerator
- CombinedHitPairGenerator
- CombinedMultiHitGenerator
- CombinedHitTripletGenerator
- CombinedHitPairGeneratorForPhotonConversion
- CombinedHitQuadrupletGeneratorForPhotonConversion

Knock-on effects:

Pass ConsumesCollector to OrderedHitsFactory
- TSGSmart

+ move construction of OrderedHitsGenerator to constructor
- TSGFromL1Muon (from beginRun)
- PixelTrackReconstruction (from beginRun)
- HitTripletProducer (from init)
- CtfSpecialSeedGenerator (from beginRun)
- PhotonConversionTrajectorySeedProducerFromSingleLegAlgo (from init)
- ConversionSeedGenerators/src/PhotonConversionTrajectorySeedProducerFromQuadrupletsAlgo (from init)

+ move construction of SeedGeneratorFromRegionHits to constructor
- TSGFromOrderedHits
- EgammaHLTRegionalPixelSeedGeneratorProducers

+ move construction of SeedComparitor and SeedCreator to constructor
- SeedGeneratorFromRegionHitsEDProducer
Needed for edm::ConsumesCollector (in later commit).
@makortel
Copy link
Contributor Author

makortel commented Feb 6, 2014

Hi David,

On 05/02/14 15:59, dmoon wrote:

I’m not sure how I got on this email distribution but, can someone
please remove me?

Apologies from my part for the spam. I guess you got included because
our script included your GitHub name (@dmoon) to an automated
notification message for some reason
#2286 (comment)
(@ktf Giulio, could you take a look why this happened?)

I think you can remove yourself by clicking "Unsubscribe" on the right
of the first message near the top of
#2286
(the button is under "Notifications")

Cheers,
Matti

@ktf
Copy link
Contributor

ktf commented Feb 6, 2014

@dmoon, I think I added you by accident, sorry about that. Should be fixed now.

@ghost
Copy link

ghost commented Feb 6, 2014

Thanks Matti,

I’ll try that.

Thanks,

David Moon
Solutions Architect
OnAsset Intelligence, Inc.
O) 972-659-1619
C) 214-236-2121
dmoon@onasset.commailto:dmoon@onasset.com
[cid:image001.jpg@01CF2312.2C771960]

This e-mail and any attachments thereto are the property of OnAsset Intelligence, Inc and may contain confidential material. Its use is solely for the intended recipient(s). Any review, use, distribution, disclosure or copying of this e-mail or attachments by others is strictly prohibited. If you received this e-mail in error, please contact the sender and permanently delete the original message.

From: Matti Kortelainen [mailto:notifications@github.com]
Sent: Thursday, February 06, 2014 4:33 AM
To: cms-sw/cmssw
Cc: David Moon
Subject: Re: [cmssw] Replace SeedingLayersESProducer with an EDProducer (#2286)

Hi David,

On 05/02/14 15:59, dmoon wrote:

I’m not sure how I got on this email distribution but, can someone
please remove me?

Apologies from my part for the spam. I guess you got included because
our script included your GitHub name (@dmoon) to an automated
notification message for some reason
#2286 (comment)
(@ktf Giulio, could you take a look why this happened?)

I think you can remove yourself by clicking "Unsubscribe" on the right
of the first message near the top of
#2286
(the button is under "Notifications")

Cheers,
Matti


Reply to this email directly or view it on GitHubhttps://github.com//pull/2286#issuecomment-34310419.

@Martin-Grunewald
Copy link
Contributor

Trying to generate HIon workflows with cmsDriver, I get the following problem:
(see below for more discussion).

Creating RECO+DQM HIon_DATA
RAW2DIGI,L1Reco,RECO,DQM,ENDJOB
magnetic field option forced to: AutoFromDBCurrent
entry file:RelVal_HLT_HIon_DATA.root
Step: RAW2DIGI Spec:
Step: L1Reco Spec:
Step: RECO Spec:
Traceback (most recent call last):
File "/afs/cern.ch/cms/sw/ReleaseCandidates/vol0/slc5_amd64_gcc481/cms/cmssw/CMSSW_7_0_X_2014-02-06-0200/bin/slc5_amd64_gcc481/cmsDriver.py", line 43, in
run()
File "/afs/cern.ch/cms/sw/ReleaseCandidates/vol0/slc5_amd64_gcc481/cms/cmssw/CMSSW_7_0_X_2014-02-06-0200/bin/slc5_amd64_gcc481/cmsDriver.py", line 15, in run
configBuilder.prepare()
File "/afs/cern.ch/cms/sw/ReleaseCandidates/vol0/slc5_amd64_gcc481/cms/cmssw/CMSSW_7_0_X_2014-02-06-0200/python/Configuration/Applications/ConfigBuilder.py", line 1952, in prepare
self.addStandardSequences()
File "/afs/cern.ch/cms/sw/ReleaseCandidates/vol0/slc5_amd64_gcc481/cms/cmssw/CMSSW_7_0_X_2014-02-06-0200/python/Configuration/Applications/ConfigBuilder.py", line 669, in addStandardSequences
getattr(self,"prepare_"+stepName)(sequence = getattr(self,stepName+"DefaultSeq"))
File "/afs/cern.ch/cms/sw/ReleaseCandidates/vol0/slc5_amd64_gcc481/cms/cmssw/CMSSW_7_0_X_2014-02-06-0200/python/Configuration/Applications/ConfigBuilder.py", line 1543, in prepare_RECO
self.loadDefaultOrSpecifiedCFF(sequence,self.RECODefaultCFF)
File "/afs/cern.ch/cms/sw/ReleaseCandidates/vol0/slc5_amd64_gcc481/cms/cmssw/CMSSW_7_0_X_2014-02-06-0200/python/Configuration/Applications/ConfigBuilder.py", line 1120, in loadDefaultOrSpecifiedCFF
l=self.loadAndRemember(defaultCFF)
File "/afs/cern.ch/cms/sw/ReleaseCandidates/vol0/slc5_amd64_gcc481/cms/cmssw/CMSSW_7_0_X_2014-02-06-0200/python/Configuration/Applications/ConfigBuilder.py", line 282, in loadAndRemember
self.process.load(includeFile)
File "/afs/cern.ch/cms/sw/ReleaseCandidates/vol0/slc5_amd64_gcc481/cms/cmssw/CMSSW_7_0_X_2014-02-06-0200/python/FWCore/ParameterSet/Config.py", line 508, in load
module = import(moduleName)
File "/scratch/CMS3/CMSSW_7_0_X_2014-02-06-0200/python/Configuration/StandardSequences/ReconstructionHeavyIons_cff.py", line 30, in
from RecoHI.Configuration.Reconstruction_HI_cff import *
File "/afs/cern.ch/cms/sw/ReleaseCandidates/vol0/slc5_amd64_gcc481/cms/cmssw/CMSSW_7_0_X_2014-02-06-0200/python/RecoHI/Configuration/Reconstruction_HI_cff.py", line 20, in
from RecoHI.HiMuonAlgos.HiReRecoMuon_cff import *
File "/scratch/CMS3/CMSSW_7_0_X_2014-02-06-0200/python/RecoHI/HiMuonAlgos/HiReRecoMuon_cff.py", line 4, in
from RecoHI.HiMuonAlgos.hiMuonIterativeTk_cff import *
File "/scratch/CMS3/CMSSW_7_0_X_2014-02-06-0200/python/RecoHI/HiMuonAlgos/hiMuonIterativeTk_cff.py", line 5, in
from RecoHI.HiMuonAlgos.HiRegitMuonPixelPairStep_cff import *
File "/scratch/CMS3/CMSSW_7_0_X_2014-02-06-0200/python/RecoHI/HiMuonAlgos/HiRegitMuonPixelPairStep_cff.py", line 19, in
from RecoHI.HiTracking.hiRegitPixelPairStep_cff import *
File "/scratch/CMS3/CMSSW_7_0_X_2014-02-06-0200/python/RecoHI/HiTracking/hiRegitPixelPairStep_cff.py", line 34, in
ComponentName = 'hiRegitPixelPairStepSeedLayers'
File "/afs/cern.ch/cms/sw/ReleaseCandidates/vol0/slc5_amd64_gcc481/cms/cmssw/CMSSW_7_0_X_2014-02-06-0200/python/FWCore/ParameterSet/Mixins.py", line 306, in clone
self._Parameterizable__raiseBadSetAttr(key)
File "/afs/cern.ch/cms/sw/ReleaseCandidates/vol0/slc5_amd64_gcc481/cms/cmssw/CMSSW_7_0_X_2014-02-06-0200/python/FWCore/ParameterSet/Mixins.py", line 230, in __raiseBadSetAttr
raise TypeError(name+" does not already exist, so it can only be set to a CMS python configuration type")
TypeError: ComponentName does not already exist, so it can only be set to a CMS python configuration type

The line 34 creating the problem contains the py code:

SEEDING LAYERS

hiRegitPixelPairStepSeedLayers = RecoTracker.IterativeTracking.PixelPairStep_cff.pixelPairStepSeedLayers.clone(
ComponentName = 'hiRegitPixelPairStepSeedLayers'
)

Since with the move from ESP to EDP the parameter ComponentName no longer exists
in the SeedingLayersEDProducer, so it can't be set directly - (I guess ComponentName = cms.string/InputTag(stuff) would formally work). If the ComponentName value is always
as EDP module label, then one should just remove the assignment. Note that there
are still several py files in the corresponding py directory which have several such
ComponentName assignments in them. Presumably all need to be fixed!

@makortel
Copy link
Contributor Author

makortel commented Feb 6, 2014

Hi Martin,

Whoops, apparently I missed these ones while git greping. I'll migrate those too (by removing ComponentName) and try to test more extensively. Thanks for the report, and sorry for the trouble.

Cheers,
Matti

@makortel
Copy link
Contributor Author

makortel commented Feb 7, 2014

Here are first the fixes to PhotonConversionTrajectorySeedProducerFromSingleLegAlgo and
PhotonConversionTrajectorySeedProducerFromQuadrupletsAlgo that I discussed with Vincenzo above, followed with further fixes to configuration files. I tested generating various job configurations with

runTheMatrix.py -i all -j 0
runTheMatrix.py -i all -j 0 --what upgrade

and none failed because of this migration (some upgrade configurations did fail for other reasons, and hence might hide failures relevant to this PR).

Again, no need to re-run the tests yet as the ones containing HLT will still fail.

@cmsbuild
Copy link
Contributor

cmsbuild commented Feb 7, 2014

Pull request #2286 was updated. @perrotta, @cmsbuild, @civanch, @diguida, @lveldere, @fwyzard, @ianna, @mdhildreth, @Martin-Grunewald, @anton-a, @Dr15Jones, @rcastello, @giamman, @slava77, @Degano, @ktf, @thspeer, @nclopezo can you please check and sign again.

@Martin-Grunewald
Copy link
Contributor

Hi,

GRun and PIon seem to work. FastSim and HIon do not work.

In case of HIon the error is:

----- Begin Fatal Exception 07-Feb-2014 15:34:19 CET-----------------------
An exception of category 'ProductNotFound' occurred while
[0] Processing run: 1 lumi: 666672 event: 32
[1] Running path 'HLT_HIL3Mu3_v8'
[2] Calling event method for module SeedingLayersEDProducer/'hltPixelLayerTriplets'
Exception Message:
Principal::getByToken: Found zero products matching all criteria
Looking for type: edmNew::DetSetVector
Looking for module label: hltSiPixelRecHits
Looking for productInstanceName:

Additional Info:
[a] If you wish to continue processing events after a ProductNotFound exception,
add "SkipEvent = cms.untracked.vstring('ProductNotFound')" to the "options" PSet in the configuration.

This is weird: the original HIon config (HLTrigger/Configuration/python/HLT_HIon_cff.py)
contained the old SeedingLayersESProducer hltESPPixelLayerTriplets which did contain
HitProducer = cms.string( "hltSiPixelRecHits" ), even though the whole HIon config
does not contain the module hltSiPixelRecHits - but it did not lead to an error.

Now with the new SeedingLayerEDProducer, here named hltPixelLayerTriplets (having dropped the "ESP" from the label), and same configuration as the old hltESPPixelLayerTriplets, it know
actually wnats to access the non-existing hltSiPixelRecHits and/or no longer fails silently.

What is going on here?

@cmsbuild
Copy link
Contributor

cmsbuild commented Feb 7, 2014

-1
When I ran the RelVals I found an error in the following worklfows:
4.53 step2

runTheMatrix-results/4.53_RunPhoton2012B+RunPhoton2012B+HLTD+RECODreHLT+HARVESTDreHLT/step2_RunPhoton2012B+RunPhoton2012B+HLTD+RECODreHLT+HARVESTDreHLT.log
----- Begin Fatal Exception 07-Feb-2014 16:21:15 CET-----------------------
An exception of category 'Configuration' occurred while
   [0] Constructing the EventProcessor
   [1] Validating configuration of module: class=EgammaHLTRegionalPixelSeedGeneratorProducers label='hltL1SeededEgammaRegionalPixelSeedGenerator'
Exception Message:
Parameter "SeedingLayers" should be defined as a tracked InputTag.
The type in the configuration is incorrect.
----- End Fatal Exception -------------------------------------------------

5.1 step1

runTheMatrix-results/5.1_TTbar+TTbarFS+HARVESTFS/step1_TTbar+TTbarFS+HARVESTFS.log

401.0 step1

runTheMatrix-results/401.0_TTbarNewMix+TTbarFSPU2+HARVESTFS/step1_TTbarNewMix+TTbarFSPU2+HARVESTFS.log

8.0 step2

runTheMatrix-results/8.0_BeamHalo+BeamHalo+DIGICOS+RECOCOS+ALCABH+HARVESTCOS/step2_BeamHalo+BeamHalo+DIGICOS+RECOCOS+ALCABH+HARVESTCOS.log
----- Begin Fatal Exception 07-Feb-2014 16:24:21 CET-----------------------
An exception of category 'Configuration' occurred while
   [0] Constructing the EventProcessor
   [1] Validating configuration of module: class=EgammaHLTRegionalPixelSeedGeneratorProducers label='hltL1SeededEgammaRegionalPixelSeedGenerator'
Exception Message:
Parameter "SeedingLayers" should be defined as a tracked InputTag.
The type in the configuration is incorrect.
----- End Fatal Exception -------------------------------------------------

1306.0 step2

runTheMatrix-results/1306.0_SingleMuPt1_UP15+SingleMuPt1_UP15+DIGIUP15+RECOUP15+HARVESTUP15/step2_SingleMuPt1_UP15+SingleMuPt1_UP15+DIGIUP15+RECOUP15+HARVESTUP15.log
----- Begin Fatal Exception 07-Feb-2014 16:25:06 CET-----------------------
An exception of category 'Configuration' occurred while
   [0] Constructing the EventProcessor
   [1] Validating configuration of module: class=EgammaHLTRegionalPixelSeedGeneratorProducers label='hltL1SeededEgammaRegionalPixelSeedGenerator'
Exception Message:
Parameter "SeedingLayers" should be defined as a tracked InputTag.
The type in the configuration is incorrect.
----- End Fatal Exception -------------------------------------------------

50101.0 step2

runTheMatrix-results/50101.0_SingleMuPt10+SingleMuPt10FSIdINPUT+SingleMuPt10FS_ID/step2_SingleMuPt10+SingleMuPt10FSIdINPUT+SingleMuPt10FS_ID.log

25.0 step2

runTheMatrix-results/25.0_TTbar+TTbar+DIGI+RECO+HARVEST+ALCATT/step2_TTbar+TTbar+DIGI+RECO+HARVEST+ALCATT.log
----- Begin Fatal Exception 07-Feb-2014 16:38:32 CET-----------------------
An exception of category 'Configuration' occurred while
   [0] Constructing the EventProcessor
   [1] Validating configuration of module: class=EgammaHLTRegionalPixelSeedGeneratorProducers label='hltL1SeededEgammaRegionalPixelSeedGenerator'
Exception Message:
Parameter "SeedingLayers" should be defined as a tracked InputTag.
The type in the configuration is incorrect.
----- End Fatal Exception -------------------------------------------------

you can see the results of the tests here:
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-2286/70/summary.html

@Martin-Grunewald
Copy link
Contributor

OK, I fixed up the HIon problem.

What is still failing is FastSim.... Any fastsim expert who knows what fastsim does special
with the SeedingLayerESProducers? Are they ignored and/or their output faked up?
The error message from IntegrationTestWithHLT is:

----- Begin Fatal Exception 07-Feb-2014 17:27:48 CET-----------------------
An exception of category 'ConfigFileReadError' occurred while
[0] Processing the python configuration file named IntegrationTestWithHLT_cfg.py
Exception Message:
python encountered the error: <type 'exceptions.NameError'>
name 'hltPixelLayerTriplets' is not defined
----- End Fatal Exception -------------------------------------------------

but maybe this means these modules should be removed for fastsim???

@makortel
Copy link
Contributor Author

makortel commented Feb 7, 2014

It looks to me (based on the current, V28, HLT_8E33v2_Famos_cff.py) that there are many SeedingLayersESProducers defined, but only one used (by ElectronSeedProducer). When doing the configuration migration for RECO I got the impression that fastsim would not use SeedingLayersESProducer. I'd say they could be just removed (except the one used by ElectronSeedProducer). Of course a confirmation from a fastsim expert wouldn't hurt.

@perrotta
Copy link
Contributor

perrotta commented Feb 8, 2014

A possible fix for the fastsim issue is in
perrotta@42cef32
I am not sure of the fully correctness of the implementation of the hltMixedLayerPairs in FastSimulation/Tracking/python/HLTPixelTracksProducer_cfi.py (in particular the use of a 'MixedTriplet' seeding algo with the requirement of just two hits). But it works and avoids fastsim crashing; (low stat) tests give different but compatible results with respect to the corresponding ones run in a plain IB.
You could merge that fix in this pull request, if you agree, and possibly fine tune later on with the help of some tracking expert.
Andrea

@makortel
Copy link
Contributor Author

@perrotta Andrea, thanks for the suggestion. However, I would like to understand the issue a bit better before including your commit.

I took a deeper look on ElectronSeedProducer (again in the context of HLT_8E33v2_Famos_cff.py), and it turns out that all instances of it have preFilteredSeeds=False set implying that the OrderedHitsFactoryPSet PSet (including SeedingLayers) is not used (I'll point out the relevant point in code). Therefore it seems that SeedingLayersESProducer is not used in fastsim at all.

If hltMixedLayerPairs would be removed too, would it mean, using Andrea's fix as a base, that hltMixedLayerPairs should be treated just like all other hltPixelLayer* (i.e. dummymodule.clone() in HLTPixelTracksProducer_cfi.py, and append("-hltMixedLayerPairs") in confdb.py)? By the way, is there a(n easy) way for me to test this issue myself?

@@ -128,14 +126,20 @@ void ElectronSeedProducer::beginRun(edm::Run const&, edm::EventSetup const&) {
SeedFilter::Tokens sf_tokens;
sf_tokens.token_bs = beamSpotTag_;
sf_tokens.token_vtx = filterVtxTag_;
seedFilter_ = new SeedFilter(conf_,sf_tokens) ;
edm::ConsumesCollector iC = consumesCollector();
seedFilter_.reset(new SeedFilter(conf_, sf_tokens, iC));
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

SeedFilter is constructed only if preFilteredSeeds==True.

@Martin-Grunewald
Copy link
Contributor

Hi Andrea,

This indeed works!

Thanks and best regards

Martin

On Sat, 8 Feb 2014, perrotta wrote:

A possible fix for the fastsim issue is in
perrotta@42cef32
I am not sure of the fully correctness of the implementation of the hltMixedLayerPairs in FastSimulation/Tracking/python/HLTPixelTracksProducer_cfi.py (in particular the use of a 'MixedTriplet' seeding algo with the requirement of just two hits). But it works and avoids fastsim crashing; (low stat) tests give different but compatible results with respect to the corresponding ones run in a plain IB.
You could merge that fix in this pull request, if you agree, and possibly fine tune later on with the help of some tracking expert.
Andrea


Reply to this email directly or view it on GitHub:
#2286 (comment)

Martin

Martin W. Gruenewald e-mail: Martin.Grunewald@cern.ch
http://cern.ch/Martin.Grunewald

@perrotta
Copy link
Contributor

Hi Martin and Matti.
Indeed, @makortel observation is also true (thanks for checking).
The result is the same, but I agree with Matti that we can/should replace the previous definition of hltMixedLayerPairs inside FastSimulation/Tracking/python/HLTPixelTracksProducer_cfi.py with the cleaner
hltMixedLayerPairs = FastSimulation.HighLevelTrigger.DummyModule_cfi.dummyModule.clone()

This also avoids me to check why that HLTPixelTracksProducer worked the same with either two or three layers, great :-)

Andrea

@lveldere
Copy link
Contributor

Hi All

At present I am not at all familiar with this part of the FastSim code.
I'll ask Matthias Komm to have a look at this thread.
He is working on updating the FastSim track seeding atm so he might know.

Cheers

Lukas

On Mon, Feb 10, 2014 at 9:35 AM, perrotta notifications@github.com wrote:

Hi Martin and Matti.
Indeed, @makortel https://github.com/makortel observation is also true
(thanks for checking).
The result is the same, but I agree with Matti that we can/should replace
the previous definition of hltMixedLayerPairs inside
FastSimulation/Tracking/python/HLTPixelTracksProducer_cfi.py with the
cleaner
hltMixedLayerPairs =
FastSimulation.HighLevelTrigger.DummyModule_cfi.dummyModule.clone()

This also avoids me to check why that HLTPixelTracksProducer worked the
same with either two or three layers, great :-)

Andrea

Reply to this email directly or view it on GitHubhttps://github.com//pull/2286#issuecomment-34609306
.

@Martin-Grunewald
Copy link
Contributor

Hi,

Great - I'll make the changes/simplifications/ and test again...

Best regards

Martin

On Mon, 10 Feb 2014, perrotta wrote:

Hi Martin and Matti.
Indeed, @makortel observation is also true (thanks for checking).
The result is the same, but I agree with Matti that we can/should replace the previous definition of hltMixedLayerPairs inside FastSimulation/Tracking/python/HLTPixelTracksProducer_cfi.py with the cleaner
hltMixedLayerPairs = FastSimulation.HighLevelTrigger.DummyModule_cfi.dummyModule.clone()

This also avoids me to check why that HLTPixelTracksProducer worked the same with either two or three layers, great :-)

Andrea


Reply to this email directly or view it on GitHub:
#2286 (comment)

Martin

Martin W. Gruenewald e-mail: Martin.Grunewald@cern.ch
http://cern.ch/Martin.Grunewald

@makortel
Copy link
Contributor Author

Superseded by #2378.

@makortel makortel closed this Feb 10, 2014
@nclopezo nclopezo modified the milestones: CMSSW_7_1_0_pre4, CMSSW_7_1_0_pre3 Feb 24, 2014
@nclopezo nclopezo modified the milestones: CMSSW_7_1_0_pre5, CMSSW_7_1_0_pre4 Mar 10, 2014
ggovi pushed a commit to ggovi/cmssw that referenced this pull request Jan 11, 2017
Fix data files for SLHCUpgradeSimulations/Geometry
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants