coresoftware icon indicating copy to clipboard operation
coresoftware copied to clipboard

Update PHGhostRejection:

Open david-stewart opened this issue 1 year ago • 13 comments

  • Fix error in "is same track": it now compares clusters correctly
  • Fix error in comparing the delta_phi between tracks -- take into account periodic boundary
  • Change logic: for is-same track backs on shared clusters, the number of shared clusters must be simply more than 1/2 the number of clusters in the shorter track
  • Add default minimum track parameters (week out tracks, even if not otherwise duplicate/"ghost" tracks):
    • minimum pT of 0.2 GeV/c
    • minimum number of clusters of 6 - must have clusters crossing at least one sector boundary (i.e. crossing layer 22-23 or 39-40)

Types of changes

  • [ ] Bug fix (non-breaking change which fixes an issue)
  • [ ] New feature (non-breaking change which adds functionality)
  • [ ] Breaking change (fix or feature that would cause existing functionality to not work for users)
  • [ ] Requiring change in macros repository (Please provide links to the macros pull request in the last section)
  • [x] I am a member of GitHub organization of sPHENIX Collaboration, EIC, or ECCE (contact Chris Pinkenburg to join)

What kind of change does this PR introduce? (Bug fix, feature, ...)

TODOs (if applicable)

Links to other PRs in macros and calibration repositories (if applicable)

david-stewart avatar Jun 21 '24 06:06 david-stewart

Build & test report

Report for commit 048361a502aed04ea614bd83ae94ecddd3999012: Jenkins on fire


Automatically generated by sPHENIX Jenkins continuous integration sPHENIX             jenkins.io

sphenix-jenkins-ci[bot] avatar Jun 21 '24 11:06 sphenix-jenkins-ci[bot]

Looking at the code it isn't clear to me why this causes a seg fault in the low occupancy QA. I would suggest just checking out the branch yourself locally and running gdb on it with your local build

osbornjd avatar Jun 21 '24 13:06 osbornjd

ok. There are a few more things to do. I realized that it isn't hard to avoid publishing all the rejected tracks, so things will shake up a little first.

david-stewart avatar Jun 21 '24 13:06 david-stewart

Build & test report

Report for commit 6f101a3499ede2881f5a565f5af4ec1b41750743: Jenkins on fire


Automatically generated by sPHENIX Jenkins continuous integration sPHENIX             jenkins.io

sphenix-jenkins-ci[bot] avatar Jun 21 '24 19:06 sphenix-jenkins-ci[bot]

Build & test report

Report for commit 088aa07e9f7a10d3d5845c75812944e018249d0b: Jenkins passed


Automatically generated by sPHENIX Jenkins continuous integration sPHENIX             jenkins.io

sphenix-jenkins-ci[bot] avatar Jun 22 '24 04:06 sphenix-jenkins-ci[bot]

OK, fixed the leak -- error in the looping variable when refactoring the code. The cuts remove quite a few tracks. For one random example: 36 total seeds: 13 rejected for pT < 200 MeV (10 of which < 100 MeV, one as low at 9 MeV) 1 more rejected for only having clustering in the middle layer (23-39) 6 more tracks removed because they were ghosts. In this case, every ghost had exactly the same clusters. (Looking over many runs, it is actually a smallish portion that deviate, and then only by a cluster or two). Specifically:

Found match for tracks 0 and 21 and 31 and 35
Found match for tracks 1 and 12
Found match for tracks 2 and 16 and 23

So a total of 14 tracks out of the 36 tracks reconstructed were pushed to the output TrackSeedContainer. This update doesn't tracks that are rejected to the container. (So, the track number outgoing isn't the same as the track number of the seed incoming, but I don't think that makes any different in our code). This is a change, as the old code number published every seed going in to the PHSimpleKFProp to the outgoing track container by the same track id index, even if some were deleted and only point to a nullptr.

I am curious was Marzia's 30000 track event would result in. It would also be better perhaps to not reconstruct each track 4 times in the Kalman filter. Maybe it would be better to add some logic that if a seed's clusters have already been reconstructed in another track, then to not reconstruct that seed. (For instance, the 0-21-31-35 track was reconstructed 4 times from four different seeds).

david-stewart avatar Jun 22 '24 06:06 david-stewart

This change really hurts the efficiency at low pT, presumably because we are rejecting real tracks in addition to all of the ghost tracks that it removes. Have you studied why these also get rejected?

osbornjd avatar Jun 22 '24 11:06 osbornjd

Hmmm. The cuts are these:

  • all tracks < 200 MeV
  • all tracks with < 6 clusters
  • all tracks with clusters which don't span a radial sector boundary
  • the lower chi2 out of each pair of tracks matching in phi/eta/x/y/z if one of the pair has at least 50% matching clusters

None of those should hurt efficiency particularly badly. The removing of ghosts is important, but that was already happening (although not after the first three cuts above)

david-stewart avatar Jun 22 '24 12:06 david-stewart

The <200 MeV cut might hurt efficiency quite a bit, if lots of higher-momentum seeds are erroneously being assigned much lower momenta due to spurious clusters being added to them (which usually drastically increase the average curvature). A plot of pt vs. gpt would probably work to reveal this.

petermic avatar Jun 27 '24 18:06 petermic

Build & test report

Report for commit a1005fc4f9dd69b07e30dd0ff6c58713d7af5768: Jenkins passed


Automatically generated by sPHENIX Jenkins continuous integration sPHENIX             jenkins.io

sphenix-jenkins-ci[bot] avatar Aug 02 '24 03:08 sphenix-jenkins-ci[bot]

The efficiency curves in the QA Juypter notebook haven't changed. I have run individual tests where I didn't think that I saw this behavior. I will get a good comparison test with slightly lower statistics nail down the inconsistency.

david-stewart avatar Aug 02 '24 11:08 david-stewart

Build & test report

Report for commit 2c168ea4a9de36015cab916e96f71eb25bea21c8: Jenkins passed


Automatically generated by sPHENIX Jenkins continuous integration sPHENIX             jenkins.io

sphenix-jenkins-ci[bot] avatar Aug 03 '24 02:08 sphenix-jenkins-ci[bot]

Build & test report

Report for commit b19f411135d45b6c96e1ee554811788334955054: Jenkins passed


Automatically generated by sPHENIX Jenkins continuous integration sPHENIX             jenkins.io

sphenix-jenkins-ci[bot] avatar Aug 05 '24 20:08 sphenix-jenkins-ci[bot]

Now that Michael's changes are in, we should probably be able to push this after we see if it works. There was a clang complaint in that a line of code float dphi = fabs(...); demoted a double to float. I have modified the line and pushed so that we can get the new Jenkin's report. If all is well with that, I recommend that we merge it.

david-stewart avatar Aug 20 '24 15:08 david-stewart

Build & test report

Report for commit 396e4bb370578e5003f54d38b8de99da5c093759: Jenkins passed


Automatically generated by sPHENIX Jenkins continuous integration sPHENIX             jenkins.io

sphenix-jenkins-ci[bot] avatar Aug 20 '24 19:08 sphenix-jenkins-ci[bot]

Build & test report

Report for commit 55137d71be386fda9a308451f24c26dda3aff2ab: Jenkins passed


Automatically generated by sPHENIX Jenkins continuous integration sPHENIX             jenkins.io

sphenix-jenkins-ci[bot] avatar Aug 23 '24 04:08 sphenix-jenkins-ci[bot]

This kills the efficiency at low pT again - did that fix get removed inadvertently?

osbornjd avatar Aug 23 '24 12:08 osbornjd

Build & test report

Report for commit fa763a071a03032fc6688a47c7c0c05718fa985c: Jenkins on fire


Automatically generated by sPHENIX Jenkins continuous integration sPHENIX             jenkins.io

sphenix-jenkins-ci[bot] avatar Aug 23 '24 19:08 sphenix-jenkins-ci[bot]

I'm not sure at all what I did to upset everything; but obviously my trying to something cut with git had external consequences. I'll push a branch backup_ghost that should be fine. Let's wait and see.

david-stewart avatar Aug 23 '24 22:08 david-stewart

Build & test report

Report for commit 55cb00a9a66f6c4044c1f9b508db71799f74e4f0: Jenkins on fire


Automatically generated by sPHENIX Jenkins continuous integration sPHENIX             jenkins.io

sphenix-jenkins-ci[bot] avatar Aug 24 '24 01:08 sphenix-jenkins-ci[bot]

This is probably a result of the cvmfs issues. Hold off pushing anything

osbornjd avatar Aug 24 '24 01:08 osbornjd

This is probably a result of the cvmfs issues. Hold off pushing anything

Ah, ok. I assumed that I had royally botched a git squash and tried again, and then resubmitted under "Backup ghost". I won't push anything more.

david-stewart avatar Aug 24 '24 02:08 david-stewart

Superseded by https://github.com/sPHENIX-Collaboration/coresoftware/pull/3090

osbornjd avatar Aug 26 '24 20:08 osbornjd