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

Valuemaps for E/gamma GED Integration #1032

Merged
merged 19 commits into from
Oct 14, 2013

Conversation

lgray
Copy link
Contributor

@lgray lgray commented Oct 9, 2013

Machinery to produce PFEG <-> GEDPhoton/GsfElement valuemaps needed for the final step of particle flow reconstruction.

Electron energy/resolution will change since we have dropped the old electron energy corrections for the new GEDGsfElectrons.

Preliminary tests on ttbar indicate the electron reconstruction takes a rather large chunk of time, will investigate further with igprof.
The photon reco doesn't add much.

@beaudett Would like to run a few more tests on his end and possibly change some configurations, but it would be useful to go ahead and start the process since the pieces are in place.

Short matrix results:
7 6 5 5 3 tests passed, 0 1 0 0 0 failed
The one failure is from an empty DBS query result for 8.0.

@cmsbuild
Copy link
Contributor

cmsbuild commented Oct 9, 2013

A new Pull Request was created by @lgray (Lindsey Gray) for CMSSW_7_0_X.

Valuemaps for E/gamma GED Integration

It involves the following packages:

DataFormats/EgammaCandidates
RecoEgamma/Examples
RecoEgamma/EgammaPhotonProducers
RecoEgamma/EgammaElectronAlgos
RecoEgamma/EgammaElectronProducers

@nclopezo, @smuzaffar, @thspeer, @slava77 can you please review it and eventually sign? Thanks.
You can sign-off by replying to this message having '+1' in the first line of your reply.
You can reject by replying to this message having '-1' in the first line of your reply.
@ktf you are the release manager for this.

@nclopezo
Copy link
Contributor

nclopezo commented Oct 9, 2013

// Read the collection of PFCandidates
edm::Handle<reco::PFCandidateCollection> pfCandidates;

bool found = event.getByLabel(egmPFCandidateCollection_, pfCandidates);
Copy link
Contributor

Choose a reason for hiding this comment

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

I think that all new code should come in with getByToken

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Agreed, will add.

Copy link
Contributor

Choose a reason for hiding this comment

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

Lindsey,

Since getByToken will require changes in the base class, that may deserve a separate update in this case.

What's your schedule to complete the "consumes" migration?

Slava

Copy link
Contributor Author

Choose a reason for hiding this comment

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

For some of these classes I'll need to call consumes in the parent producer and use getByLabel in the class that does the work since the daughter class doesn't inherit from EDConsumerBase.
At a later time we should do it correctly with the tokens, otherwise there needs to be some rather substantial work done to rewrite some classes.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Than being said, I think those classes that inherit from producer pose no problem for the migration.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ok, I found a reasonably non-invasive way to provide the Tokens down to the owned classes.
I'll do this.

Copy link
Contributor

Choose a reason for hiding this comment

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

Why not provide a consumesCollector to the helper, the class that does the work, as explained on
https://twiki.cern.ch/twiki/bin/view/CMSPublic/SWGuideEDMGetDataFromEvent#Consumes_and_Helpers ?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Neat trick, thanks, I'll keep it around for the future. For now, everything is changed to either use tokens directly or use consumes + getByLabel (only one case of this).

@slava77
Copy link
Contributor

slava77 commented Oct 9, 2013

@slava77 working on it

@@ -1,3 +1,7 @@
<use name="FWCore/Framework"/>
Copy link
Contributor

Choose a reason for hiding this comment

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

these are duplicates, please cleanup

Here are scram warnings
**WARNING: Multiple usage of "FWCore/Framework". Please cleanup "use" in "non-export" section of "src/RecoEgamma/Examples/BuildFile".
*
*WARNING: Multiple usage of "FWCore/ParameterSet". Please cleanup "use" in "non-export" section of "src/RecoEgamma/Examples/BuildFile".

@slava77
Copy link
Contributor

slava77 commented Oct 10, 2013

Hi Lindsey,

I see quite a few differences, in an apparent contradiction to "Don't expect much if any change in the physics output."

Here are a couple of plots from the electron pt=35 sample.

all_sign259vsorig_singleelectron35wf17p0c_recogsfelectrons_gedgsfelectrons__reco_obj_pt

all_sign259vsorig_singleelectron35wf17p0c_recogsfelectrons_gedgsfelectrons__reco_obj_ecalenergyerror

Is this an expected outcome of a new implementation/configuration of the gedGsfElectrons ?

@beaudett
Copy link
Contributor

Hi Slava,

it is normal. It corresponds to the deactivation of the "old" corrections which are not adequate for ged electrons.
Cheers,
Florian

@lgray
Copy link
Contributor Author

lgray commented Oct 10, 2013

Thanks Florian! I had forgotten that.

@slava77
Copy link
Contributor

slava77 commented Oct 10, 2013

Lindsey,
could you please edit the pull request message to reflect this expected change.
(it's easier to follow than going through the full thread here)

@beaudett
Copy link
Contributor

Slava,

I am curious, can I know which tool you have used to spot the two plots which have changed with the new code ?
Thanks
Florian

@slava77
Copy link
Contributor

slava77 commented Oct 10, 2013

@beaudett
Hi Florian,
this is using the FWLite-based script (the original came from Jean-Roch)
http://cmssw.cvs.cern.ch/cgi-bin/cmssw.cgi/UserCode/slava77/RecoTools/validate.C?view=log

@lgray
Copy link
Contributor Author

lgray commented Oct 10, 2013

@slava77 consumes migration passes short matrix.

@cmsbuild
Copy link
Contributor

Pull request #1032 was updated. @perrotta, @smuzaffar, @nclopezo, @fwyzard, @Martin-Grunewald, @thspeer, @slava77 can you please check and sign again.

@nclopezo
Copy link
Contributor

@slava77
Copy link
Contributor

slava77 commented Oct 11, 2013

@nancymarinelli @beaudett @lgray
Hi Nancy, Florian and Lindsey,

Is this pull request complete now, or should we expect some more last minute changes?

Lindsey confirmed that the "consumes migration" is done here

Please clarify

Thanks

Slava

@fwyzard
Copy link
Contributor

fwyzard commented Oct 11, 2013

My two cents: for the producers running inside the HLT, I would strongly
advocate getting rid completely of "getBylabel" in favour of "getByToken"
and friends.

For reco-only producers I don't mind ;-)

Ciao,
.Andrea

On 11 October 2013 11:20, slava77 notifications@github.com wrote:

@nancymarinelli https://github.com/nancymarinelli @beaudetthttps://github.com/beaudett
@lgray https://github.com/lgray
Hi Nancy, Florian and Lindsey,

Is this pull request complete now, or should we expect some more last
minute changes?

Lindsey confirmed that the "consumes migration" is done here

Please clarify

Thanks

Slava


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

@Martin-Grunewald
Copy link
Contributor

+1

@cmsbuild
Copy link
Contributor

Pull request #1032 was updated. @perrotta, @smuzaffar, @nclopezo, @fwyzard, @Martin-Grunewald, @thspeer, @slava77 can you please check and sign again.

@lgray
Copy link
Contributor Author

lgray commented Oct 12, 2013

@nancymarinelli @beaudett
Could you please let us know if you are ok with this pull request to be approved?

@slava77
The above additional commit passed the short matrix.

@slava77
Copy link
Contributor

slava77 commented Oct 12, 2013

Just FYI: I started testing preemptively.

@beaudett
Copy link
Contributor

Hi

it is ok for me.

F.

@nancymarinelli
Copy link
Contributor

Ok for me as well.


Nancy Marinelli

Research Associate Professor
University of Notre Dame, IN, US

CERN, Bdg 40/3-A01, 1211 Geneva,

SWITZERLAND

Phone +41-22-76-70809, fax +41-22-76-78940

From: Lindsey Gray <notifications@github.commailto:notifications@github.com>
Reply-To: cms-sw/cmssw <reply@reply.github.commailto:reply@reply.github.com>
Date: Sat, 12 Oct 2013 02:22:43 -0700
To: cms-sw/cmssw <cmssw@noreply.github.commailto:cmssw@noreply.github.com>
Cc: Nancy Marinelli <nancy.marinelli@cern.chmailto:nancy.marinelli@cern.ch>
Subject: Re: [cmssw] Valuemaps for E/gamma GED Integration (#1032)

@nancymarinellihttps://github.com/nancymarinelli @beaudetthttps://github.com/beaudett
Could you please let us know if you are ok with this pull request to be approved?

@slava77https://github.com/slava77
The above additional commit passed the short matrix.


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

@slava77
Copy link
Contributor

slava77 commented Oct 13, 2013

Hi Lindsey,

This doesn't merge into 70X anymore.
I'm using CMSSW_7_0_X_2013-10-13-0200

CONFLICT (content): Merge conflict in RecoEgamma/EgammaElectronAlgos/src/SiStripElectronSeedGenerator.cc
CONFLICT (content): Merge conflict in RecoEgamma/EgammaElectronAlgos/src/SeedFilter.cc

I suspect this is because of interference with #1063 which was just added to 70X

Please take a look

Thanks

Slava

@lgray
Copy link
Contributor Author

lgray commented Oct 13, 2013

@slava77 hopefully that doesn't clobber anything else... This was made on top of CMSSW_7_0_X_2013-10-13-0200

@cmsbuild
Copy link
Contributor

@slava77
Copy link
Contributor

slava77 commented Oct 13, 2013

Hi Lindsey

Diff stats don't agree with you.
There are now 283 changed files, with changes not relevant to #1032

@Dr15Jones
Copy link
Contributor

I think this needs to be rebased onto 'CMSSW_7_0_X' branch

@lgray
Copy link
Contributor Author

lgray commented Oct 13, 2013

Ok, tried that at first, gave some odd output. I'll rewind and try again.

@lgray
Copy link
Contributor Author

lgray commented Oct 13, 2013

@slava77 rebased, passes short matrix

@cmsbuild
Copy link
Contributor

Pull request #1032 was updated. @perrotta, @smuzaffar, @nclopezo, @fwyzard, @Martin-Grunewald, @thspeer, @slava77 can you please check and sign again.

@Martin-Grunewald
Copy link
Contributor

+1

@nclopezo
Copy link
Contributor

@slava77
Copy link
Contributor

slava77 commented Oct 14, 2013

+1

tested 29539e1 in CMSSW_7_0_X_2013-10-13-0200

There are no new differences in physics outputs from the consumes migration.
See above for changes in the ged electrons.
There are no plots for these collections in regular DQM, one needs to look at these collections separately, e.g., using http://cmssw.cvs.cern.ch/cgi-bin/cmssw.cgi/UserCode/slava77/RecoTools/validate.C?view=log

On the timing side there is some odd vacillation in ecalDrivenElectronSeeds (using total time in the module in wflow 202.0, TTBar+PU, 200 events ):

Considering that the final physics output doesn't change, I just leave this noted; maybe someone bothers to check.

@cmsbuild
Copy link
Contributor

This pull request is fully signed and it will be integrated in one of the next IBs unless changes or unless it breaks tests. @ktf can you please take care of it?

@ktf
Copy link
Contributor

ktf commented Oct 14, 2013

@nclopezo can you look at http://cmssw.cvs.cern.ch/cgi-bin/cmssw.cgi/UserCode/slava77/RecoTools/validate.C?view=log and add it to the jenkins stuff?

ktf added a commit that referenced this pull request Oct 14, 2013
Reco improvement -- Valuemaps for E/gamma GED Integration
@ktf ktf merged commit f390b6e into cms-sw:CMSSW_7_0_X Oct 14, 2013
@nclopezo
Copy link
Contributor

@slava77

Hi Slava, you run validate.C using the file validateJR.sh?

http://cmssw.cvs.cern.ch/cgi-bin/cmssw.cgi/UserCode/slava77/RecoTools/validateJR.sh?view=log

Could you give me an example of the command that you run?

Thanks

@slava77
Copy link
Contributor

slava77 commented Oct 15, 2013

Hi David,

bd=commonPartOfDirecotryName
rA=newReleaseNameExtension
rB=referenceReleaseNameExtension
source ~/tools/validateJR.sh ${bd}-${rA} ${bd}-${rB} ${rA}VS${rB} ~/tools/matrix_62X.txt

the matrix*.txt file is a map for the input files
This needs to match the names in the tested workflow.
Feel free to modify at will.

bundocka pushed a commit to bundocka/cmssw that referenced this pull request Aug 10, 2022
…_2_12_4

Add caloParamsHI_2022_v0 2 for heavy ion studies
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.