Project

General

Profile

Bug #1065

A single tracker geometry module must use "PropertyInt Tracker 0"

Added by Lane, Peter about 10 years ago. Updated over 9 years ago.

Status:
Open
Priority:
Normal
Category:
Tracker
Target version:
-
Start date:
27 July 2012
Due date:
% Done:

0%

Estimated time:
Workflow:
New Issue

Description

There is an assumption in the tracker code somewhere that assumes that for a single tracker geometry module the tracker number should be 0. That is, "PropertyInt Tracker" should have a value of 0. Issue #1063 is an example of what can happen at the moment if this value is not 0. It's likely this would cause other problems once #1063 gets fixed.


Related issues

Related to MAUS - Bug #1063: Tracker1.dat geometry brokenClosedHeidt, Christopher25 July 2012

Actions
#1

Updated by Rogers, Chris about 10 years ago

Are you looking at this Chris?

#2

Updated by Heidt, Christopher almost 10 years ago

This is by intention, not a bug. Tracker 0 is the forward facing tracker while Tracker 1 is the reverse. If you label a forward facing tracker as tracker 1 (and remove the part of the code that keeps you from doing this) then your x and y values will be reversed from the true positions.

#3

Updated by Lane, Peter almost 10 years ago

I'm not saying that you should eliminate the requirement that a single tracker module must use "Tracker 0". I'm disagreeing that if you don't do this that there is code that "keeps you from doing this". The Tracker parameter is not being checked for validity explicitly. It is being left up to other parts of the code to fail in ways that have no obvious relationship to the fact that an invalid parameter value was specified in the configuration.

In general, if there are constraints on configuration parameters that are beyond simply syntax (which is already checked for automatically in the data file parsing code), there ought to be additional validity checks in the code that understands how those parameters are used. If you don't do this then the software is unpredictable and very difficult to debug.

#4

Updated by Rogers, Chris almost 10 years ago

In general, if there are constraints on configuration parameters that are beyond simply syntax (which is already checked for automatically in the data file
parsing code), there ought to be additional validity checks in the code that understands how those parameters are used. If you don't do this then the software
is unpredictable and very difficult to debug.

Right - in general, if there is a problem the relevant error message should advise where to look to fix it.

#5

Updated by Rogers, Chris over 9 years ago

Bump - is this closed? Just needs a bit more error checking I think.

Also available in: Atom PDF