Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in
  • Corryvreckan Corryvreckan
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 33
    • Issues 33
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
  • Merge requests 14
    • Merge requests 14
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Issue
    • Repository
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Corryvreckan
  • CorryvreckanCorryvreckan
  • Merge requests
  • !260

Merged
Created Mar 09, 2020 by Jens Kroeger@jekroegeOwner

Fix getColumn/getRow and getLocalPosition

  • Overview 15
  • Commits 5
  • Pipelines 4
  • Changes 7

@williamm discovered an inconsistency, i.e. "shift" between

  • clusterMapAssoc
  • hitMapAssoc

in the AnalysisDUT module.

I had a closer look at it and found that

cluster->column();
// and 
auto clusterLocal = m_detector->globalToLocal(cluster->global());
m_detector->getColumn(clusterLocal);

would not give the same result. The second method was the one implemented and much more complicated than necessary. However, I took this as an opportunity to understand what was going wrong.

And in fact, the getColumn()/getRow() as well as the getLocalPosition() member functions of the detectors class did not behave as expected - even though we thought about them many times.

Now it's fixed and consistent (also with what I calculated on paper). Again, the tricky bit as an integer division causing an unexpected shift by 1/2 pitch.

Anyway, I believe that it's fine now. Tested with run 742. @williamm Can you also check it with your analysis?

Assignee
Assign to
Reviewer
Request review from
Time tracking
Source branch: fix_coord_transformation