Skip to content
Snippets Groups Projects

Vertex functor silently fails and reject all subsequent events

    • Open Issue created by Laurent Dufour @ldufour

    When using functors related to the vertex position in the MCParticleFilter on all MCParticles, none of the events pass the cut, even when wrapped inside an F.VALUE_OR @ clause which should cause the events to pass in the case of no vertex. The filter, however, does work when it is restricted to those candidates which have a decay.

    A 'minimal' reproducer can be found here: https://gitlab.cern.ch/-/snippets/3350

    If there is some common behaviour that makes functors always return false when there is a single failure, this might need reconsideration - it could mean that one single failed vertex fit for particles can result in rejections for subsequent 'good' candidates.

    Designs

      Child items ...

      2. Activity

      • Laurent Dufour added Functors bug labels

        added Functors bug labels

        • G
          Gerhard Raven @graven ·
          Developer

          If there is some common behaviour that makes functors always return false when there is a single failure

          given that the functors involved are stateless I cannot even imagine a scenario where (what happens during) one invocation could affect another invocation... ie. from first principles, this seems to be utterly ruled out. But the observed behaviour seems to disagree. So I suspect the cause must be somewhere 'upstream'...

        • L
          Laurent Dufour @ldufour ·
          Author Developer

          Yes, from looking at the functor code itself I also could not find where this behaviour would possibly creep in. I wonder if it's related to a call within the filter, which might do something special for exception handling?

        • L
          Laurent Dufour @ldufour ·
          Author Developer

          A side-note: I say here that no further events are selected, but that might be not entirely correct. Because of the high production rate of KS in any event, it is not excluded that it's rather within the same event that candidates are no longer accepted, as it is well possible that the multiplicity is more than 1 in basically every event I looked at.

          Edited by Laurent Dufour
        • G
          Gerhard Raven @graven ·
          Developer

          I have to admit I'm a bit confused. Starting from master, and then adding !4175 (merged), and then modifying your reproducer to read:

              # REMOVE the "F.OBJECT_KEY" clause below to reproduce the bug
    cut = F.require_all(F.PARTICLE_ID == 310, F.PT>500, F.ETA>2.0, F.ETA < 5.0,
                    F.ALL @ F.LOGGER('pred ({arg_type}): {arg}') @ ( ( F.LOGGER('end_vz ({arg_type}): {arg}') @ F.END_VZ ) < 300 ),
                    F.END_VZ < 300,
                    F.ALL @ F.LOGGER('passed'))
    filtered_mc_particles = MCParticleFilter(all_mc_particles, F.FILTER(cut))

          I see the following as example output:

          MCParticleRangeFilter_22fbb2b1      SUCCESS end_vz (SIMDWrapper::scalar::float_v): 38.7798
MCParticleRangeFilter_22fbb2b1      SUCCESS pred (SIMDWrapper::scalar::mask_v): scalar{1}
MCParticleRangeFilter_22fbb2b1      SUCCESS passed
MCParticleRangeFilter_22fbb2b1      SUCCESS end_vz (SIMDWrapper::scalar::float_v): nan
MCParticleRangeFilter_22fbb2b1      SUCCESS pred (SIMDWrapper::scalar::mask_v): scalar{0}
MCParticleRangeFilter_22fbb2b1      SUCCESS end_vz (SIMDWrapper::scalar::float_v): 279.776
MCParticleRangeFilter_22fbb2b1      SUCCESS pred (SIMDWrapper::scalar::mask_v): scalar{1}
MCParticleRangeFilter_22fbb2b1      SUCCESS passed
MCParticleRangeFilter_22fbb2b1      SUCCESS end_vz (SIMDWrapper::scalar::float_v): 332.525
MCParticleRangeFilter_22fbb2b1      SUCCESS pred (SIMDWrapper::scalar::mask_v): scalar{0}
MCParticleRangeFilter_22fbb2b1      SUCCESS end_vz (SIMDWrapper::scalar::float_v): 341.081
MCParticleRangeFilter_22fbb2b1      SUCCESS pred (SIMDWrapper::scalar::mask_v): scalar{0}
MCParticleRangeFilter_22fbb2b1      SUCCESS end_vz (SIMDWrapper::scalar::float_v): 1779.63
MCParticleRangeFilter_22fbb2b1      SUCCESS pred (SIMDWrapper::scalar::mask_v): scalar{0}
MCParticleRangeFilter_22fbb2b1      SUCCESS end_vz (SIMDWrapper::scalar::float_v): -2003.75
MCParticleRangeFilter_22fbb2b1      SUCCESS pred (SIMDWrapper::scalar::mask_v): scalar{1}
MCParticleRangeFilter_22fbb2b1      SUCCESS passed
MCParticleRangeFilter_22fbb2b1      SUCCESS end_vz (SIMDWrapper::scalar::float_v): -5116.64
MCParticleRangeFilter_22fbb2b1      SUCCESS pred (SIMDWrapper::scalar::mask_v): scalar{1}
MCParticleRangeFilter_22fbb2b1      SUCCESS passed
MCParticleRangeFilter_22fbb2b1      SUCCESS end_vz (SIMDWrapper::scalar::float_v): 11249
MCParticleRangeFilter_22fbb2b1      SUCCESS pred (SIMDWrapper::scalar::mask_v): scalar{0}
MCParticleRangeFilter_22fbb2b1      SUCCESS end_vz (SIMDWrapper::scalar::float_v): 544.783
MCParticleRangeFilter_22fbb2b1      SUCCESS pred (SIMDWrapper::scalar::mask_v): scalar{0}
MCParticleRangeFilter_22fbb2b1      SUCCESS end_vz (SIMDWrapper::scalar::float_v): 507.285
MCParticleRangeFilter_22fbb2b1      SUCCESS pred (SIMDWrapper::scalar::mask_v): scalar{0}
MCParticleRangeFilter_22fbb2b1      SUCCESS end_vz (SIMDWrapper::scalar::float_v): 62.1883
MCParticleRangeFilter_22fbb2b1      SUCCESS pred (SIMDWrapper::scalar::mask_v): scalar{1}
MCParticleRangeFilter_22fbb2b1      SUCCESS passed
MCParticleRangeFilter_22fbb2b1      SUCCESS end_vz (SIMDWrapper::scalar::float_v): -450.596
MCParticleRangeFilter_22fbb2b1      SUCCESS pred (SIMDWrapper::scalar::mask_v): scalar{1}
MCParticleRangeFilter_22fbb2b1      SUCCESS passed
MCParticleRangeFilter_22fbb2b1      SUCCESS end_vz (SIMDWrapper::scalar::float_v): -1009.93
MCParticleRangeFilter_22fbb2b1      SUCCESS pred (SIMDWrapper::scalar::mask_v): scalar{1}
MCParticleRangeFilter_22fbb2b1      SUCCESS passed
MCParticleRangeFilter_22fbb2b1      SUCCESS end_vz (SIMDWrapper::scalar::float_v): -1212.36
MCParticleRangeFilter_22fbb2b1      SUCCESS pred (SIMDWrapper::scalar::mask_v): scalar{1}
MCParticleRangeFilter_22fbb2b1      SUCCESS passed
MCParticleRangeFilter_22fbb2b1      SUCCESS end_vz (SIMDWrapper::scalar::float_v): 456.65
MCParticleRangeFilter_22fbb2b1      SUCCESS pred (SIMDWrapper::scalar::mask_v): scalar{0}
MCParticleRangeFilter_22fbb2b1      SUCCESS end_vz (SIMDWrapper::scalar::float_v): -255.927
MCParticleRangeFilter_22fbb2b1      SUCCESS pred (SIMDWrapper::scalar::mask_v): scalar{1}
MCParticleRangeFilter_22fbb2b1      SUCCESS passed

          i.e. I see that in all cases there is an end_vz, and the comparisons to 300 result in a 'passed' in the right cases. Now, there is a 'nan' in there, and it originates from here, i.e. these are the cases that there is no MCVertex present, i.e. when EndVertex return a nullptr (which also matches your observation that there is no optional here!). Now, one could debate the choice of nan here (as opposed to using optional), but regardless, those correctly fail the filter (as the behavior of Functional::Optional was actually modelled after the IEEE754 specified behavior of nan, namely 'all comparisons fail', so in that sense, the choice of nan here is a consistent one). So as far as I can tell, it seems to work as expected, i.e. there does not seem to be any 'hysteresis', so I think I am not able to reproduce what you're seeing. So could you try to add !4175 (merged) to your setup, and see what kind of output you get?

          Edited by Gerhard Raven
        • L
          Laurent Dufour @ldufour ·
          Author Developer

          That indeed seems to be fine - although it would be nice if we could also describe some behaviour for those cases more explicitly. As a 'workaround' one could always use something silly like a double comparison to capture the nan cases.

          While the printout indicate the functors all pass, it's not the behaviour I'm seeing from the filter. I'm using DaVinci v64r7 and after the functors, and this is what I see in my log there:

          MCParticleRangeFilter_46c75b9f         INFO Number of counters : 2
 |    Counter                                      |     #     |    sum     | mean/eff^* | rms/err^*  |     min     |     max     |
 |*"#passed"                                       |      1000 |          0 |( 0.000000 +- 0.000000)% |
 |*"Cut selection efficiency"                      |   7450159 |          0 |( 0.000000 +- 0.000000)% |

          (here just for evt_max=1000, but this should capture the jist of it)

          Are you seeing events passing the filter, and entries being passed to the tuple?

          (I believe that, with your debug work, right now things are pointing to an issue in the PrFilter rather than the functors)

          Edited by Laurent Dufour
        • L
          Laurent Dufour @ldufour ·
          Author Developer

          OK, I tested with the latest version of DaVinci, and it seems that in v64r13 this behaviour is fixed, while it's still broken in v64r12. In principle this is great news - and I have to apologize for "wasting" time writing extra debugging tools (which I think are still very useful for next bugs).

          ... But what change could've fixed this?

          Edited by Laurent Dufour
        • Please register or sign in to reply
      • Gerhard Raven mentioned in merge request !4175 (merged)

        mentioned in merge request !4175 (merged)

      Please register or sign in to reply