More on CA tickets


Talk time : 16:00, Duration : 00:20

Summary from Irakli

https://drupal.star.bnl.gov/STAR/system/files/2016-11-03-Irakli_0.pdf

Summary of our discussions

___________________________________________________________________________________________
Victor identified a new issue with CA causing floating point exceptions.  See ticket 3261
https://www.star.bnl.gov/rt3/Ticket/Display.html?id=3261

___________________________________________________________________________________________
Trouble Ticket 3231 https://www.star.bnl.gov/rt3/Ticket/Display.html?id=3231

CA utilizes a private version of the STAR TPC geometry.  This version incorrectly
uses the layer radius (aka "sorting" radius) from the Sti geometry to specify the
position of the sensitive elements, instead of the normal radius.  These differ at
the level of a few mm.

Discussion

CA uses the wrong radius for the detector planes, however it finds tracks based on the
hit positions themselves.  The impact on track finding should be minimal.  Track fitting
is performed by Sti, using the full Sti geometry model  The refit parameters will be correct.
So we believe the impact from this bug on performance to be negligible.

CA utilizes a private geometry model.  This is a design flaw, but perhaps not serious.
It is a concern moving forward with the iTPC... CA team will need to address support
for new hardware, and backwards compatibility with existing hardware.

Recommendation

Trouble ticket 3231 should be moved to the low priority queue or closed.

___________________________________________________________________________________________
Trouble Ticket 3232 https://www.star.bnl.gov/rt3/Ticket/Display.html?id=3232

CA provides a list of track candidates which can share hits between them.  Sti assumes that
no tracks share hits.  Therefore, to match up with the Sti interface, the StiCA layer cleans
up track candidates before sending them to be refit by Sti.

1) Tracks which have more than 10% of their hits shared are dropped
2) In the remaining tracks, shared hits are uniquely assigned to the longer track
3) Shared hits are stripped off of the shorter track

This issue was identified by Victor's code analysis.  It did not show up as a misfeature,
per se.

When the first  hit on the track is stripped from it, the Sti track's first track node
will be initialized with incorrect parameters.  They will correspond to the hit which was
stripped off.

The integrated version of StiCA works around this by recalculating the parameters of the
first node when the hit was stripped.

Discussion

Initially, wasn't clear that CA team understood the issue.  Irakli tried to address the bug
by removing our workaround in StiCA, and allowing tracks to share hits.  This violates the
Sti interface.  We discussed with Irakli, and he understands the issues.

Our discussion revolved around two questions:  1) what is the correct thing to do in this
situations, and 2) is it possible?

The correct thing is to use the fit parameters of the "new" first hit on the track.  When
hits are stripped off, we need an interface to obtain the fit parameters corresponding to
any of the hits provided by CA.

After brief discussion, we concluded that the best thing to do is not possible.  It is a
limitation of the Kalman filter, that the information is no longer available to us.  So even
if CA provides an interface, the information would be wrong.

Then the question becomes what are the reasonable workarounds.  Option 1 was the initial code
provided by the CA team -- use the fit params from the first hit provided by CA.  Option 2
was to update the fit parameters for the first track node.  This is what we integrated into
the framework.  Both options are reasonable workarounds.  The latter one has the advantage of
being better when several hits have been stripped.  In both cases, refit is expected to be
correct.

Recommendation

We can close the ticket.

___________________________________________________________________________________________
Trouble Ticket 3233 https://www.star.bnl.gov/rt3/Ticket/Display.html?id=3233

There is a class of CA track which is invalid.  The same hit appears on the list of hits
twice.  Typically, there are 1-2 other hits which separate the repeated hit in the list.
StiCA has a workaround for this bug in place -- repeated hits are stripped from the
track before passing into Sti for refit.  Origin of this bug is not known.

Discussion

We have discussed with Irakli, and the feeling is the workaround is reasonable.  We have
not gotten a reply that indicates the CA team is concerned about this misbehavior.

In the course of our discussion, we realized that this bug may be occurring because of
track merging.  CA works in sectors, then merges tracks across sector boundaries.  It
could be that hits near sector boundaries have a small chance to be accepted by tracklets
in both sectors.  When they get merged, they would be repeated.

An easy check of this idea is to plot Y vs X for repeated hits.

Recommendation

Update ticket with this discussion if plot described above supports the hypothesis.  Otherwise
we should raise this ticket again with the CA team.

Note:  further investigation to be discussed.