From ReDecay flag for MCParticle

Adds setter/getter to flag a particle that was produced in the ReDecay part of an event. Uses bit 5 of the already existing bit-field. See LHCBGAUSS-1357

Should go to 2018-patches and master, not sure yet about older versions. Modifications to Gauss and a TupleTool to extract the information will follow. Unless I am mistaken, this only modifies the value of the unsigned integer storing the flags and thus no updates for Run1+Run2 Boole, Moore and Brunel should be necessary to propagate the information.

@dmuller could you please rebase this request to 2018-patches? Once merged there I will propagate it to master and any other branches where it is needed

changed the description

changed target branch from master to 2018-patches

added 9 commits

• 4597ac5a...801f6f95 - 8 commits from branch 2018-patches
• 20036347 - MCParticle: added from ReDecay flag

Compare with previous version

As the rebase itself started producing merge conflicts, I have locally reset the branch to point to the head of 2018-patches, cherry-picked my commit on top and force pushed it to remote.

I hope that it is correct now.

changed the description

We did not have the time to implement it and the flag is now used for the signal and what what come from the signal, but we discussed in the past having a separate bit for

• signal itself
• decay of signal
• from signal but from detector interaction
• ancestor of signal

I think it would be better to have the bit for these close to each other so I would suggest to use bit 5 instead

From my understanding, the flags unsigned integer is not supposed to be accessed by the user which instead should use the setter and getter functions, in which case the underlying order in the bitfield should not matter. But anyway, how would one add tell the bitfield in the xml to leave a few bits empty?

I guess you could define a "reserved" bitfield of length 3... (and explain in the comment what it's reserved for...)

Okay, seems I'll make those changes and add a lot of comments to avoid any misuse in the future.

• [2018-03-23 00:08] Validation started with lhcb-2018-patches#154
• [2018-03-23 00:12] Validation started with lhcb-moore-test#3
• [2018-03-24 00:05] Validation started with lhcb-moore-test#4
• [2018-03-24 00:08] Validation started with lhcb-2018-patches#155
• [2018-03-24 08:40] Validation started with lhcb-2018-patches#156
• [2018-03-25 00:05] Validation started with lhcb-moore-test#5
• [2018-03-25 00:07] Validation started with lhcb-2018-patches#157
• [2018-03-26 00:05] Validation started with lhcb-moore-test#6
• [2018-03-26 00:12] Validation started with lhcb-2018-patches#158
• [2018-03-27 00:07] Validation started with lhcb-moore-test#7
• [2018-03-27 00:10] Validation started with lhcb-2018-patches#159

@dmuller so I'll wait for your changes before merging this

added 1 commit

• 6e243ae4 - Added 3bit long reserved space between fromSignal and fromRedecay flag.

Compare with previous version

resolved all discussions

@dmuller @gcorti are you happy with this? Shall I go ahead and merge? I will then cherry-pick to master. Any other branches this needs to go to (in particular which branch is Gauss for Sim09 using)?

I am happy with this. Gauss/Sim09 is using LHCb v39r1, that is pre-git so I am not sure. reco14 or stripping24 patches maybe?

@dmuller concerning Sim09 Gauss, everything is now in Git, including old SVN tags and branches. What I need to know is the version of LHCb this should be merged into for it to be picked up by the next Sim09 release of Gauss (assuming you want to do that)

merged

mentioned in commit 4ee3c214

mentioned in commit b2bf140d

mentioned in merge request !1193 (merged)

@dmuller @gcorti - I looked a bit more into this. For Sim09, I suggest that we make a new sim09-patches branch of LHCb, starting from v39r1. What do you think?

@cattanem Thank you. Sorry, I meant I had a look at the graph for the v39r1 tag to see what branch would make sense but that is not very useful for the things we imported from svn. I agree, creating a sim09-patches based on v39r1 seems sensible and straight forward to do to then release a v39r1p1.

Sorry I am in the middle of writing slides... I agree that a sim09-patches for lhcb is a good idea. Then I can move there the patch for Det/DDDB (and GaudiPolicy?) I needed to put in the Sim09 branch of Gauss :)

mentioned in commit 2856d5f9

mentioned in merge request !1194 (merged)

changed the description

mentioned in merge request Gauss!285 (merged)

mentioned in commit 24ddc596

mentioned in merge request !1250 (merged)