Put the 11.1 cm shift in the default position not as an alignment. No change...

Put the 11.1 cm shift in the default position not as an alignment. No change in overall position. Affects BEE1,BEE2 stations only.

Background:

@todorova discovered recently a mismatch between the SQLite position of the BEE chambers and their position in Athena. This was finally traced to a very strange use of alignment constants to fix an apparent bug in positioning of the BEE detectors which sit on the cogs of the endocap toroids. Maybe someone mentioned here knows why or when this was done. It is not specifically related to the SQLite scenario, though it will make the transition easier and more transparent.

Looking in the Geometry database, one fines the table below. The "TRAZ" column is an 11.1 cm shift that affects all of the BEE chambers and nothing else. The entry is the same for all of the BEE chambers (apart from the A Side/C Side minus sign) and it is the same in the last 31 versions of this database table in the Oracle database.

This quantity is currently being injected as a shift in the BEE positions as an alignment correction. It should be obvious that this is improper.

This MR is meant to move the 11.1 cm shift from an alignment correction into the default position of the chambers. The changes produced an identical final position of the chambers, as was tested using a program from @jojungge .

The history of repeated attempts to get this right comes from the following issue. Since the large shift was implemented as an alignment correction, the alignment constants in the conditions database are numbers like (11.1+delta) cm where "delta" is an actual alignment. These alignment constants are applied in data, not in Monte Carlo. So if one adds 11.1 cm into the default position of the chamber, then when alignment corrections are applied (in the reconstruction of data), one gets approximately a 22.2 cm shift rather than an 11.1 cm shift. To fix that, the default position is only adjusted in MC, not in data.

I think in the future we can completely resolve this, because @jojungge plans anyway to migrate information in the conditions database to a friendlier format, and in so doing can remove the 11.1 mm shift from conditions data leaving only the actual "delta".

So that is the story.