Legacy vertexing issue

Analysis
1

I am currently trying to update my analysis to run in v0.9.0 (the last version compatible with winter2023 MC I believe) of the stack however it seems that the vertexing is broken.

An easy reproduction of the issue is to run the vertexing tutorial, fccanalysis run examples/FCCee/tutorials/vertexing/analysis_primary_vertex.py, for which each event results in the following output in the terminal of the form

CheckDefPos: found <= 0 eigenvalue E(2) = 0
CheckDefPos: input matrix NOT posite definite. Printing normalized matrix.

5x5 matrix is as follows

     |      0    |      1    |      2    |      3    |      4    |
----------------------------------------------------------------------
   0 |          0           0           0           0           0 
   1 |          0           0           0           0           0 
   2 |          0           0           0           0           0 
   3 |          0           0           0           0           0 
   4 |          0           0           0           0           0

sometimes accompanied by VertexMore:: Error making fCov

Is this expected behaviour? It never used to happen when I originally wrote my analysis but as it also appears in the tutorial I wonder if it’s okay or if the tutorial is also broken. If I limit my analysis script to just make some truth branches, vertex objects and then use those to make a branch for decay candidate mass I get these warnings in the log but the mass distribution looks as expected.

Thanks for any help,

Aidan

2

Hi @jsmiesko,

Do you know if this behaviour is safe or not, and expected in the tutorial job? For now I’m carrying on updating my analysis assuming things are fine and will try to see if my tuples make sense later on. One issue is the log output is pretty large which is a bit annoying, is there a way to at least suppress this?

Thanks,

Aidan

3

This issue is also being discussed in a GH issue: #378.

The large printout has been suppressed, however question remains about the correctness of the result…

4

Hi @jsmiesko,

Just cross posting here to say that as far as I can tell this vertexing issue causes an extreme slow down in the event processing to the point where it now takes hours to process a single file which makes it almost impossible to develop the analysis at a reasonable pace. This is quite disruptive now.

If this cannot be resolved easily is there at least a simple way to use the MC vertex info to spoof the vertexing for now for use in BDTs etc… at least so we have some form of data to set up our code around and then when this is resolved properly we can revert back to using the proper vertexing?

Thanks,

Aidan

6

Very late reply:

Two problems found:

  • Delphes’ VertexFit silently returns a NaN vertex for tracks with a non-positive-definite covariance matrix, which also broke get_PrimaryTracks()'s outlier rejection.
  • the slowdown culprit is that VertexFitter_Tk always builds a Delphes VertexMore object for per-track momenta at the vertex, which scales ~O(ntracks³) regardless of whether that’s used.

Added a flag ComputeMomentaAtVertex (defaults to true) to skip the expensive part when you don’t need it, i.e. pass false to get_VertexObject()/VertexFitter()/VertexFitter_Tk() if you don’t read updated_track_momentum_at_vertex.

Merged to pre-edm4hep1 : #525. Cherry picked to master: #537.

Overall I think the vertexing utilities need a major overhaul and those are to be considered only as a hot-fixes.

Best,
Juraj