Intermediate ParticleCombiner being used while waiting for the full ThOr implementation having issues in two body decays involving a neutral object

added bug label

mentioned in merge request Moore!964 (merged)

changed title from ParticleVertexFitter not properly initialize when using ThOr combiners for neutrals to ParticleVertexFitter not properly initialize when using ParticleCombiner for neutrals

changed the description

@cmarinbe are you aware of any other lines with neutrals that have seen this error running Moore?

Hi @agilman @cmarinbe (cc @abertoli ) let me add some investigations by myself here:

From a test on 1k Hlt1 filtered Bs2DsK events with the latest b2oc_upgrade branch in this MR Moore!1071 (merged) (all commits from master are included), I saw this error again, but not all lines with neutrals produce zero rate.

Currently lines with neutrals in B2OC can be categorized into 3 types:

neutrals come from B, and the B hadron is combined by the new ParticleCombiner
neutrals come from D, and the D hadron is combined by the new ParticleCombiner
neutrals come from D, and the D hadron is combined by the old ParticleCombiner (Loki-based)

We keep type 3 because this error was already found last time, so our excited_d_with_neutral builder doesn't use the new one, but some new builders added by proponents are new ones.

The results show that type 1 does not produce any error, and gives non-zero rates.

For type 2, I take one example line: Hlt2B2OC_BuToD0Pi_D0ToKsDDPi0Resolved_Line

The error was produced at D0ToKsPi0 stage:

B2OCD02KSPi0Combiner#2.ParticleV...   ERROR ParticleVertexFitter didn't properly initialize:  #tracks with velo: ^@ #tracks without velo: ^@ #composites: ^A #resonances: ^@

and this step cuts off all events at vertex fit:

B2OCD02KSPi0Combiner#2                 INFO Number of counters : 5
 |    Counter                                      |     #     |    sum     | mean/eff^* | rms/err^*  |     min     |     max     |
 |*"# passed"                                      |      1000 |          0 |(  0.000000 +-  0.000000)% |
 |*"# passed CombinationCut"                       |    171762 |       5179 |( 3.015219 +- 0.04126175)% |
 |*"# passed vertex fit"                           |      5179 |          0 |(  0.000000 +-  0.000000)% |
 | "Input1 size"                                   |      1000 |        647 |    0.64700 |
 | "Input2 size"                                   |      1000 |     218830 |     218.83 |
B2OCD02KSPi0Combiner#2.LoKi::Dis...    INFO Number of counters : 1
 |    Counter                                      |     #     |    sum     | mean/eff^* | rms/err^*  |     min     |     max     |
 | "DOCA->(DI)GAMMA"                               |      5179 |

and in BuToD0Pi step no error is produced since the input event is zero:

B2OCB2XCombiner#194                    INFO Number of counters : 3                                                                                                                                                                    
 |    Counter                                      |     #     |    sum     | mean/eff^* | rms/err^*  |     min     |     max     |
 |*"# passed"                                      |      1000 |          0 |(  0.000000 +-  0.000000)% |
 | "Input1 size"                                   |      1000 |          0 |      0.0000 |
 | "Input2 size"                                   |      1000 |       9505 |     9.5050 |

For type 3, the example line is Hlt2B2OC_BuToDst0K_Dst0ToD0Pi0Resolved_D0ToHH_Line

The Dst0ToD0Pi0 step seems fine (because it uses LoKi ParticleCombiner):

B2OCD0Pi0Combiner#8                    INFO Number of counters : 11
 |    Counter                                      |     #     |    sum     | mean/eff^* | rms/err^*  |     min     |     max     |     
 | "# B2OCD02HHCombiner#1/OutputContainer"         |      1000 |        753 |    0.75300 |     1.2853 |       0.0000 |      12.000 |
 | "# D*(2007)0 -> D0  pi0 "                       |      1000 |       3734 |     3.7340 |     8.8830 |       0.0000 |      65.000 |
 | "# D0"                                          |      1000 |        753 |    0.75300 |     1.2853 |       0.0000 |      12.000 |
 | "# D~0"                                         |      1000 |          0 |      0.0000 |      0.0000 |       0.0000 |       0.0000 |
 |*"# ParticleRangeFilter#33/Output"               |      1000 |       1000 |( 100.0000 +-  0.000000)% |
 | "# input particles"                             |      1000 |     219583 |     219.58 |     117.96 |      3.0000 |      614.00 |
 | "# pi0"                                         |      1000 |     218830 |     218.83 |     117.63 |      3.0000 |      614.00 |
 | "# selected"                                    |      1000 |       3734 |     3.7340 |
 |*"#accept"                                       |      1000 |        298 |( 29.80000 +- 1.446361)% |
 | "#pass combcut"                                 |    202158 |     202158 |     1.0000 |
 | "#pass mother cut"                              |    202158 |       3734 |   0.018471 |

and no error produced by this step, but in the BuToDst0K step:

B2OCB2XCombiner#247                    INFO Number of counters : 5                                                                                                                                                                    
 |    Counter                                      |     #     |    sum     | mean/eff^* | rms/err^*  |     min     |     max     |
 |*"# passed"                                      |      1000 |          0 |(  0.000000 +-  0.000000)% |
 |*"# passed CombinationCut"                       |     23149 |        947 |( 4.090889 +- 0.1301885)% |
 |*"# passed vertex fit"                           |       947 |          0 |(  0.000000 +-  0.000000)% |
 | "Input1 size"                                   |      1000 |       3734 |     3.7340 |
 | "Input2 size"                                   |      1000 |       9005 |     9.0050 |

so all combinations are also cut off in vertex fit step, and this combiner produces the following in the run:

B2OCB2XCombiner#247.ParticleVert...   ERROR ParticleVertexFitter didn't properly initialize:  #tracks with velo: ^A #tracks without velo: ^@ #composites: ^@ #resonances: ^@

Currently what confuses me most is type 1 works well. I attached the full log below, but I need to warn you that ~40k lines in the log are those error messages, hope these info are useful for you to identify the problem.

log_hlt2_b2oc.txt

mentioned in merge request Moore!1071 (merged)

Hi, I am obtaining a similar error when I try to combine a track and a jet, i.e. with decay descriptor 'H_10 -> mu+ CELLjet'

TwoBodyCombiner#3.ParticleVertex... ERROR ParticleVertexFitter didn't properly initialize: #tracks with velo: #tracks without velo: #composites: #resonances:

And then candidates are discarded. It is possible that the same error affects CELLjet, and not only neutral objects. We foresee many jet lines in QEE, it would be fundamental for us to have this fixed.

mentioned in commit Moore@af38e425

mentioned in merge request Moore!1134 (merged)

changed title from ParticleVertexFitter not properly initialize when using ParticleCombiner for neutrals to Intermediate ParticleCombiner being used while waiting for the full ThOr implementation having issues in two body decays involving a neutral object

@agilman (cc @shunan) reported that the same error is found when using as input the K0s Pi0 pair of particles

This looks to me like an issue when trying to make a combination from a long-lived particle + a neutral, where the common origin vertex cannot be found due to the lack of knowledge of the neutral direction. In the past, we would use the option ParticleCombiners = {'' : 'MomentumCombiner:PUBLIC'} to tell the LoKi CombineParticles not to do a vertex fit but just add the momenta instead, see eg here. Does the new CombineParticles provide a similar option @agilman ? Or what does it do in such a case?

\cc @pgironel who was looking into using this option also for the Lb -> Lambda Gamma HLT2 lines

mentioned in merge request Moore!1199 (merged)

mentioned in merge request Moore!1271 (merged)

In ThoR, there is the option of using the argument ParticleCombiner="ParticleAdder" in the ParticleCombiner function (that does the same thing?). Like Tom does in Moore!1271 (merged). However, note the issue that I just created concerning the ParticleAdder functionality and vertexing. #269.

mentioned in merge request Moore!1294 (merged)

mentioned in merge request Moore!1293 (merged)

mentioned in merge request Moore!1229 (merged)

Intermediate ParticleCombiner being used while waiting for the full ThOr implementation having issues in two body decays involving a neutral object

Designs

Child items ...

Activity