parametrized magnetic field availability in tracking modules #2410

mtosi · 2014-02-11T19:48:32Z

this is the follow up of the pull request 2394
the code and the default configuration should be back-compatible
and make the new parameters (for handling the parametrized magnetic field) available as well

this is needed for testing and possibly integrating new developments @HLT

…et(ESInputTag const& iTag, HolderT& iHolder)]. Next step update cfis in order to make them back-compatible

…ters available (above all for confDB)

mtosi · 2014-02-11T19:50:00Z

@perrotta @Martin-Grunewald @fwyzard @rovere @cerati @Dr15Jones

cmsbuild · 2014-02-11T19:52:55Z

A new Pull Request was created by @mtosi (mia tosi) for CMSSW_7_0_X.

parametrized magnetic field availability in tracking modules

It involves the following packages:

Configuration/StandardSequences
MagneticField/ParametrizedEngine
RecoTracker/CkfPattern
RecoTracker/IterativeTracking
RecoTracker/TkNavigation
RecoTracker/TkSeedGenerator
RecoTracker/TrackProducer
TrackingTools/GeomPropagators
TrackingTools/KalmanUpdators
TrackingTools/MaterialEffects
TrackingTools/Producers

@nclopezo, @vlimant, @franzoni, @cmsbuild, @anton-a, @thspeer, @slava77, @Degano, @davidlange6 can you please review it and eventually sign? Thanks.
@ghellwig, @cerati, @gpetruc, @GiacomoSguazzoni, @rovere this is something you requested to watch as well.
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.
@nclopezo, @ktf you are the release manager for this.
You can merge this pull request by typing 'merge' in the first line of your comment.

slava77 · 2014-02-13T13:58:59Z

Hi Mia,

Is there an exact copy of this in 71X?
We should follow the backport steps: a feature is introduced in 71X, gets integrated there and passes IB tests there, then gets applied to 70X.
Since in this case for 70X we want the RECO to remain unchanges, I'd like to see this step done in 71X (~one IB will be enough in this case; if RECO changes I'd need a full relval cycle)

perrotta · 2014-02-13T14:09:55Z

Hi Slava.

No, it is not an exact copy: the config files are different in 71X and
70X. While in 71X the new parabolic magnetic field is taken, the
configurations for 70X are so that the very same VolumeBased MF is
still used. (The advantage of having it already in 70X is that you can
apply it in HLT development without touching reco).

Therefore, we expect some (hopefully small) regression in 71X, but
none in 70X.
Of course, we agree that you test it yourself before signing it!

Andrea

slava77 [email protected] ha scritto:

Hi Mia,

Is there an exact copy of this in 71X?
We should follow the backport steps: a feature is introduced in 71X,
gets integrated there and passes IB tests there, then gets applied
to 70X.
Since in this case for 70X we want the RECO to remain unchanges, I'd
like to see this step done in 71X (~one IB will be enough in this
case; if RECO changes I'd need a full relval cycle)

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

This message was sent using IMP, the Internet Messaging Program.

perrotta · 2014-02-13T14:14:50Z

Ah, and by the way Mia (who can comment) says that she wants to update further this PR in order to synchronize with 71x (the modules, not the configs!).
Therefore, we should better keep this PR in standby until Mia finishes her adjustments and gives a green light to it

slava77 · 2014-02-13T14:41:00Z

Hi Andrea

Is it still possible to have changes of this PR applied in 71X?
Assuming this PR really has not changes in RECO, I'd like it to get merged to 71X first and pass the full IB matrix and other tests there and be merged to 70X only after that (I can't be sure I catch every technical problem in my own tests)

mtosi · 2014-02-13T15:15:57Z

ciao,

sorry the confusion

2 days ago I updated the 71x pull request 2392
and I also created this new one in 70x ... because the previous one was
rejected for back-compatibily issues

PR 2392 updates were mainly related to

initialization of some parameters
instead of using an "if-then-else", a unique call to get the magnetic
field [ EventSetupRecord::get(edm::ESInputTag& iTag, HolderT& iHolder),
instead of EventSetupRecord::get(HolderT& iHolder) ]
instead of using std::string as input parameter for specifying the label
of the magnetic field, use the edm::ESInputTag

unfortunately, point 3. makes crashing the code
and simply rolling back to the std::string fixes this issue

now, my plan is to wait for a green light in 71x
and I will roll back to the std::string also in 70x
in this way the only difference between 71x and 70x will be config,
allowing the back-compatibility between 70x and the PR in 70x

mia

On Thu, Feb 13, 2014 at 3:41 PM, slava77 [email protected] wrote:

Hi Andrea

Is it still possible to have changes of this PR applied in 71X?
Assuming this PR really has not changes in RECO, I'd like it to get merged
to 71X first and pass the full IB matrix and other tests there and be
merged to 70X only after that (I can't be sure I catch every technical
problem in my own tests)

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

perrotta · 2014-02-13T15:22:12Z

Also to avoid confusion:
The corresponding PR in 71X is #2291 (and not 2392...)

slava77 · 2014-02-13T22:03:55Z

Hi Andrea and Mia,
I see that #2291 introduces differences in track parameters of RECO tracks (and some downstream quantities).
I understand that that is a full PR which includes the offline tracking changes as well, right?

As I mentioned above, for a backport in to 70X I would like to see a PR in 71X which has no RECO changes at all. (I can't sign off on apples going into one release based on oranges that went to another release)

mtosi · 2014-02-13T22:18:09Z

ciao,
so, I should do a branch in 71x
w/ the configuration files untouched (as it is the case in 70x)
in this way nothing should change in 71x

=> after a comparison 1:1, I'll be able to backport in 70x ?

do I get right ?
thanks
mia

On Thu, Feb 13, 2014 at 11:03 PM, slava77 [email protected] wrote:

Hi Andrea and Mia,
I see that #2291 #2291 introduces
differences in track parameters of RECO tracks (and some downstream
quantities).
I understand that that is a full PR which includes the offline tracking
changes as well, right?

As I mentioned above, for a backport in to 70X I would like to see a PR in
71X which has no RECO changes at all. (I can't sign off on apples going
into one release based on oranges that went to another release)

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

slava77 · 2014-02-14T01:09:38Z

Hi Mia,

Yes.

mtosi · 2014-02-17T16:35:20Z

ciao,

I've just created the following branch
https://github.com/mtosi/cmssw/tree/from-CMSSW_7_1_0_pre2_hlttracking-parabolic-mf-build-fit_test700compatibility
which has the same c++ code as PR #2410
but the config files, which are the same as 70x

please, let me know if there are problems
thanks
cheers
mia

On Thu, Feb 13, 2014 at 11:18 PM, mia tosi [email protected] wrote:

ciao,
so, I should do a branch in 71x
w/ the configuration files untouched (as it is the case in 70x)
in this way nothing should change in 71x

=> after a comparison 1:1, I'll be able to backport in 70x ?

do I get right ?
thanks
mia

On Thu, Feb 13, 2014 at 11:03 PM, slava77 [email protected]:

Hi Andrea and Mia,
I see that #2291 #2291 introduces
differences in track parameters of RECO tracks (and some downstream
quantities).
I understand that that is a full PR which includes the offline tracking
changes as well, right?

As I mentioned above, for a backport in to 70X I would like to see a PR
in 71X which has no RECO changes at all. (I can't sign off on apples going
into one release based on oranges that went to another release)

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

slava77 · 2014-03-04T15:33:11Z

this is strange, it compiled well on slc5

mtosi · 2014-03-04T15:35:07Z

indeed, I tested on slc5 ... :(

slava77 · 2014-03-04T16:08:00Z

@Degano @nclopezo
David and Alessandro, please check if the IB or build area for slc6 are healthy

slava77 · 2014-03-05T00:18:22Z

+1

for #2410 2108814
tested in slc5_amd64_gcc481 CMSSW_7_0_X_2014-03-04-0200 (sign700a area)
no differences from my longer version of the short matrix. There are no differences in RECO.

I also checked that this PR compiles with slc6_amd64_gcc481 in CMSSW_7_0_X_2014-03-04-0200.

nclopezo · 2014-03-05T09:34:03Z

+1
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-2410/81/summary.html

davidlange6 · 2014-03-16T20:26:25Z

+1
for operations

…racking-parabolic-mf-build-fit Reco -- Parametrized magnetic field availability in tracking modules

cerati and others added 16 commits December 16, 2013 10:31

first commit

b7146fb

fix propagator in mixedTripletStep

5cccc4e

restore warning

d492a0d

adding missing files

35bd068

adding missing files

03da7a9

add parabolic field for track building

160ee6f

switch to LogDebug

a8ac9a4

move parabolic field to standard includes

bd9933c

add parabolic MF

18c13ca

remove parabolic MF

7e3ec42

Merged tracking-use-parabolic-mf-v2 from repository cerati

7d600ce

parabolic in fitting

b122bdf

Merged hlttracking-parabolic-mf-build-fit from repository tropiano

e2bfe59

add MagneticField_38T_PostLS1_cff

5878f09

synchronize code w/ new updates committed in 71x [EventSetupRecord::g…

efe0352

…et(ESInputTag const& iTag, HolderT& iHolder)]. Next step update cfis in order to make them back-compatible

adjust config files and make them back-compatible and make new parame…

a07252c

…ters available (above all for confDB)

ktf modified the milestones: Next CMSSW_7_0_X release, CMSSW_7_0_0 Feb 16, 2014

mtosi added orp-pending labels Mar 4, 2014

mtosi added operations-pending labels Mar 5, 2014

This was referenced Mar 13, 2014

Strip clusters back to 70X #2746

Merged

Seeding layers for70 x #2728

Merged

mtosi added fully-signed labels Mar 16, 2014

ktf added a commit that referenced this pull request Mar 24, 2014

Merge pull request #2410 from mtosi/mtosi/from-CMSSW_7_0_0_pre12_hltt…

b0669c7

…racking-parabolic-mf-build-fit Reco -- Parametrized magnetic field availability in tracking modules

ktf merged commit b0669c7 into cms-sw:CMSSW_7_0_X Mar 24, 2014

slava77 mentioned this pull request Apr 24, 2023

archaelogy: tracking code damage from automatic (or centralized manual) forward ports in 71X #41396

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

parametrized magnetic field availability in tracking modules #2410

parametrized magnetic field availability in tracking modules #2410

mtosi commented Feb 11, 2014

mtosi commented Feb 11, 2014

cmsbuild commented Feb 11, 2014

slava77 commented Feb 13, 2014

perrotta commented Feb 13, 2014

perrotta commented Feb 13, 2014

slava77 commented Feb 13, 2014

mtosi commented Feb 13, 2014

perrotta commented Feb 13, 2014

slava77 commented Feb 13, 2014

mtosi commented Feb 13, 2014

slava77 commented Feb 14, 2014

mtosi commented Feb 17, 2014

slava77 commented Mar 4, 2014

mtosi commented Mar 4, 2014

slava77 commented Mar 4, 2014

slava77 commented Mar 5, 2014

nclopezo commented Mar 5, 2014

davidlange6 commented Mar 16, 2014

parametrized magnetic field availability in tracking modules #2410

parametrized magnetic field availability in tracking modules #2410

Conversation

mtosi commented Feb 11, 2014

mtosi commented Feb 11, 2014

cmsbuild commented Feb 11, 2014

slava77 commented Feb 13, 2014

perrotta commented Feb 13, 2014

perrotta commented Feb 13, 2014

slava77 commented Feb 13, 2014

mtosi commented Feb 13, 2014

perrotta commented Feb 13, 2014

slava77 commented Feb 13, 2014

mtosi commented Feb 13, 2014

slava77 commented Feb 14, 2014

mtosi commented Feb 17, 2014

slava77 commented Mar 4, 2014

mtosi commented Mar 4, 2014

slava77 commented Mar 4, 2014

slava77 commented Mar 5, 2014

nclopezo commented Mar 5, 2014

davidlange6 commented Mar 16, 2014