Project

General

Profile

Bug #1752

Geometry issues

Added by Rajaram, Durga almost 7 years ago. Updated about 5 years ago.

Status:
Closed
Priority:
High
Assignee:
Start date:
21 September 2015
Due date:
% Done:

100%

Estimated time:

Description

Issues arising from geometry discussion related to #1751:

Upstream tracker rotation not propagated to ParentGeometryFile.dat

Download by run_number does not retrieve the correct geometry for the run-date


Files

TOF2.gdml (30.6 KB) TOF2.gdml Rajaram, Durga, 22 September 2015 20:50
TrackerStationSchematic.pdf (36.7 KB) TrackerStationSchematic.pdf Dobbs, Adam, 24 September 2015 18:29
TOF0.gdml (27.9 KB) TOF0.gdml Corrected TOF0 gdml Rajaram, Durga, 06 October 2015 13:50
TOF0.gdml.diff (3.69 KB) TOF0.gdml.diff Diff of TOF0 against ID 70 Rajaram, Durga, 06 October 2015 13:50
TOF1.gdml (23.8 KB) TOF1.gdml TOF1 no change Rajaram, Durga, 06 October 2015 13:50
TOF2.gdml (30.6 KB) TOF2.gdml TOF2 no change Rajaram, Durga, 06 October 2015 13:50
TOF0-correct.gdml (27.9 KB) TOF0-correct.gdml Rajaram, Durga, 06 October 2015 15:01
TOF1-correct.gdml (23.8 KB) TOF1-correct.gdml Rajaram, Durga, 06 October 2015 15:01
TOF2-correct.gdml (30.6 KB) TOF2-correct.gdml Rajaram, Durga, 06 October 2015 15:01

Related issues

Related to Analysis - Bug #1751: Detector AlignmentOpenHunt, Christopher21 September 2015

Actions
#1

Updated by Rajaram, Durga almost 7 years ago

Notes from the phone discussion on Sep 21, 2015:

  • Ryan found the bug (in the XSLT translation) which was causing the rotations not propagating from GDML to the ParentGeometry file
  • Ryan to investigate why download by run_number does not retrieve the correct geometry from that time period
    • e.g. downloaded geometry for Run# 7157 does not correspond to ID 69 though 69 is supposed to be the geometry for the June 2015 period
    • If this is a bug in the CDB, raise as an issue for Janusz to fix
  • Chris Hunt to check with Chris Heidt on whether the Tracker GDML descriptions are accurate. He will make fixes, if necessary, and pass the GDML files to Ryan
  • download_fit_geometry is no longer necessary and has been retired. This should be deleted from MAUS to avoid confusion.
#2

Updated by Bogomilov, Mariyan almost 7 years ago

I add also a bug in KL geometry to this issue:

Chris Hunt pointed out that KL cell ids are only 0,1,2 instead of 0 to 20. It is indeed in KL.gdml file that cell id numbering is incorrect. I'll provide a new file.

#3

Updated by Dobbs, Adam almost 7 years ago

Mariyan, if you let me have a branch when the fix is ready I will merge it in.

#4

Updated by Bayes, Ryan almost 7 years ago

Also send me the corrected GDML as soon as possible (both Chris and Mariyan).

#5

Updated by Hunt, Christopher almost 7 years ago

Talking with Chris Heidt over emails:

Heidt: Currently looking through CDB versions of tracker geometry to verify.
It looks as though we never officially transferred one over to GDML.

One of Heidt or Hunt to generate new CDB file with precise tracker details in it.

We will post the file with any queries as soon as possible.

#6

Updated by Bayes, Ryan almost 7 years ago

I am now confused.

What needs to be done with the Tracker geometry? Is this the addition of a file or is it a correction to the existing GDML files?

#7

Updated by Hunt, Christopher almost 7 years ago

The only tracker geometries I have are either updated legacy MiceModules or the CDB GDML geometries. I'm not sure who created the original Tracker GDML geometries but I think they were translated from the wrong MiceModules file - I haven't seen the station corrections in a GDML geometry yet.

I think it may be easiest if either myself or Chris Heidt just provides a new GDML file (updated from an old one) where we are confident that it is correct.

#8

Updated by Heidt, Christopher almost 7 years ago

Hey everyone,I'm fairly certain the correct mice module geometry of the trackers is in the cdb somewhere, I'm having trouble downloading from the cdb right now to verify it though. That said there have been a couple of different geometries in use over the years as we worked towards the final version, I suspect one of these got propagated. Last time I talked to Ryan about this (which was a long time ago) I was certain that we agreed on using the mice module, things may have changed since then. I'll keep everyone updated as I poke around.

#9

Updated by Rajaram, Durga almost 7 years ago

Also found a problem in the TOF2 numbering [ readout/mapping bug, not a geometry one ]

I verified last night with a HV scan that the TOF2 slab numbering in the readout is the opposite of TOF0&TOF1.
cf. https://micewww.pp.rl.ac.uk/elog/MICE+Log/3442

I have added the fixed TOF2 gdml [ and also emailed you, Ryan ]

#10

Updated by Bayes, Ryan almost 7 years ago

Heidt, Christopher wrote:

Hey everyone,I'm fairly certain the correct mice module geometry of the trackers is in the cdb somewhere, I'm having trouble downloading from the cdb right now to verify it though. That said there have been a couple of different geometries in use over the years as we worked towards the final version, I suspect one of these got propagated. Last time I talked to Ryan about this (which was a long time ago) I was certain that we agreed on using the mice module, things may have changed since then. I'll keep everyone updated as I poke around.

Yes it was apparently uploaded last back in January (don't ask me for a CDB reference --- I am not 100% sure that it will be there), and I think fell out of service while I was in the process of updating the GDML for use with the Parser. If the following lines are correct, I can make the correction to the CDB very quickly.

For the upstream tracker

           <position name="TrackerRef0_pos" unit="mm" x="0.0" y="0.0" z="-560.0"/>
            <rotation name="TrackerRef0_rot" unit="degree" x="0.0" y="0.0" z="0.0"/>

            <position name="TrackerStation1_pos" unit="mm" x="0.0" y="0.0" z="-549.8789"/>
            <rotation name="TrackerStation1_rot" unit="degree" x="0.0" y="0.0" z="0.0"/>

            <position name="TrackerStation2_pos" unit="mm" x="-0.5709" y="-0.7375" z="-349.9143"/>
            <rotation name="TrackerStation2_rot" unit="degree" x="0.0" y="0.0" z="0.0"/>

            <position name="TrackerStation3_pos" unit="mm" x="-1.2021" y="-0.1657" z="-100.0513"/>
            <rotation name="TrackerStation3_rot" unit="degree" x="0.0" y="0.0" z="0.0"/>

            <position name="TrackerStation4_pos" unit="mm" x="-0.5694" y="-0.6040" z="199.9491"/>
            <rotation name="TrackerStation4_rot" unit="degree" x="0.0" y="0.0" z="0.0"/>

            <position name="TrackerStation5_pos" unit="mm" x="0.0" y="0.0" z="549.8789"/>
            <rotation name="TrackerStation5_rot" unit="degree" x="0.0" y="0.0" z="0.0"/>

For the downstream tracker

            <position name="TrackerRef1_pos" unit="mm" x="0.0" y="0.0" z="-560.0"/>
            <rotation name="TrackerRef1_rot" unit="degree" x="0.0" y="0.0" z="0.0"/>

            <position name="TrackerStation1_pos" unit="mm" x="0.0" y="0.0" z="-549.9513"/>
            <rotation name="TrackerStation1_rot" unit="degree" x="0.0" y="0.0" z="0.0"/>

            <position name="TrackerStation2_pos" unit="mm" x="0.0" y="0.0" z="-349.9491"/>
            <rotation name="TrackerStation2_rot" unit="degree" x="-0.4698" y="0.0052" z="0.0"/>

            <position name="TrackerStation3_pos" unit="mm" x="-0.6717" y="-0.1759" z="-100.0523"/>
            <rotation name="TrackerStation3_rot" unit="degree" x="0.0" y="0.0" z="0.0"/>

            <position name="TrackerStation4_pos" unit="mm" x="0.1722" y="-0.2912" z="199.8771"/>
            <rotation name="TrackerStation4_rot" unit="degree" x="0.0" y="0.0" z="0.0"/>

            <position name="TrackerStation5_pos" unit="mm" x="0.0" y="0.0" z="549.9513"/>
            <rotation name="TrackerStation5_rot" unit="degree" x="0.0" y="0.0" z="0.0"/>

Are there any other corrections that need to be made?

#11

Updated by Heidt, Christopher almost 7 years ago

The upstream tracker looks good, the downstream should be.

            <position name="TrackerRef1_pos" unit="mm" x="0.0" y="0.0" z="-560.0"/>
            <rotation name="TrackerRef1_rot" unit="degree" x="0.0" y="0.0" z="0.0"/>

            <position name="TrackerStation1_pos" unit="mm" x="0.0" y="0.0" z="-549.9513"/>
            <rotation name="TrackerStation1_rot" unit="degree" x="0.0" y="0.0" z="0.0"/>

            <position name="TrackerStation2_pos" unit="mm" x="-0.4698" y="0.0052" z="-349.0577"/>
            <rotation name="TrackerStation2_rot" unit="degree" x="0.0" y="0.0" z="0.0"/>

            <position name="TrackerStation3_pos" unit="mm" x="-0.6717" y="-0.1759" z="-100.0523"/>
            <rotation name="TrackerStation3_rot" unit="degree" x="0.0" y="0.0" z="0.0"/>

            <position name="TrackerStation4_pos" unit="mm" x="0.1722" y="-0.2912" z="199.8771"/>
            <rotation name="TrackerStation4_rot" unit="degree" x="0.0" y="0.0" z="0.0"/>

            <position name="TrackerStation5_pos" unit="mm" x="0.0" y="0.0" z="549.9513"/>
            <rotation name="TrackerStation5_rot" unit="degree" x="0.0" y="0.0" z="0.0"/>
#12

Updated by Bayes, Ryan almost 7 years ago

I have generated an updated set of geometry files with corrected Tracker geometry files, KL files (with cell numbers corrected), and EMR position. The files can be found at http://www.ppe.gla.ac.uk/~rbayes/MICE/StepIV_July2015_20150923/. If Chris H. and Mariyan double check the affected files (KL.gdml, Tracker0.gdml, and Tracker1.gdml) for me I would appreciate it.

#13

Updated by Rajaram, Durga almost 7 years ago

Can you also include the fixed TOF2 gdml in your update? Thanks

#14

Updated by Rajaram, Durga almost 7 years ago

Thinking about the TOF2 issue more, I think it's much easier for me to handle it in the channel map rather than in the geometry.
Apologies if this causes confusion. For completeness, I will upload the TOF0, 1, 2 gdml files which I think should be in there to go with the channel maps.

#15

Updated by Dobbs, Adam almost 7 years ago

Is the upstream tracker 180 deg rotation about the y-axis now included?

#16

Updated by Bayes, Ryan almost 7 years ago

The 180 degree rotation about the y-axis is done in the master GDML file (SolenoidUS.gdml) and the MiceModule file (ParentGeometryFile.dat). The correction to the geometry download to synchronize the two has been made to the maus merge branch (it has been there since Tuesday).

Thanks to Durga for reminding me about the TOF correction. It is now in the geometry directory at http://www.ppe.gla.ac.uk/~rbayes/MICE/StepIV_July2015_20150923/.

I am waiting on verification for the KL and the Tracker files before posting this geometry to CDB.

#17

Updated by Dobbs, Adam almost 7 years ago

Thanks Ryan. Just had a little browse of the GDML (haven't finished yet). Think I have spotted a bug:

<position name="Tracker0View1W_pos" unit="mm" x="0.0" y="0.0" z="0.00125"/>

Whereas in the legacy:

Module Tracker/TrackerViewW.dat
{
Position 0.0 0.0 0.00125 cm
Rotation 0.0 0.0 120.0 degree
}

i.e. a unit change. I think this bug is present in for all the plane W z positions. I think it should be:

<position name="Tracker0View1W_pos" unit="mm" x="0.0" y="0.0" z="0.0125"/>

but I would like someone to check me.

#18

Updated by Dobbs, Adam almost 7 years ago

Also, I notice in the CDB geo for plane numbering we have:

V -> 2
W -> 1
U -> 0

whereas in legacy:

V -> 0
W -> 1
U -> 2

#19

Updated by Dobbs, Adam almost 7 years ago

A question too, why do we have x = -90 deg in each doublet plane, is just so that the fibres run in the correct direction? I am struggling a little to interpret which way this points them (with a intuitive guess about the no rotation case, it seems right), but the final result should match up with the description shown in the attached.

#20

Updated by Bayes, Ryan almost 7 years ago

Dobbs, Adam wrote:

A question too, why do we have x = -90 deg in each doublet plane, is just so that the fibres run in the correct direction? I am struggling a little to interpret which way this points them (with a intuitive guess about the no rotation case, it seems right), but the final result should match up with the description shown in the attached.

Yes. For some reason, I could only define the fibres to be along the z-axis. I then parametrized the fibres in position along the x-axis with small offsets in y (to reflect the staggering). The 90 degree rotation about the x axis rotates the station doublet from the z-x plane into the y-x plane (so that in the no-rotation case the fibres are vertical and measure positions in x).

I think I tried to do this in a different way but GEANT didn't like it.

#21

Updated by Bayes, Ryan almost 7 years ago

Dobbs, Adam wrote:

Also, I notice in the CDB geo for plane numbering we have:

V -> 2
W -> 1
U -> 0

whereas in legacy:

V -> 0
W -> 1
U -> 2

This is likely an "old" versus "new" legacy problem associated with the tracker plane positions and likely crept in with the version confusion noted by Chris Heidt.

I also note that this change in the plane ordering is the sort of thing that I was worried about when we were discussing the plane ordering problem with the reconstruction of the data. I kind of felt that I was brushed off at that time.

#22

Updated by Bayes, Ryan almost 7 years ago

Dobbs, Adam wrote:

Thanks Ryan. Just had a little browse of the GDML (haven't finished yet). Think I have spotted a bug:

<position name="Tracker0View1W_pos" unit="mm" x="0.0" y="0.0" z="0.00125"/>

Whereas in the legacy:

Module Tracker/TrackerViewW.dat {
Position 0.0 0.0 0.00125 cm
Rotation 0.0 0.0 120.0 degree
}

i.e. a unit change. I think this bug is present in for all the plane W z positions. I think it should be:

<position name="Tracker0View1W_pos" unit="mm" x="0.0" y="0.0" z="0.0125"/>

but I would like someone to check me.

This is corroborated with Tracker1. Likely the result of a typo during development. I will fix this.

#23

Updated by Dobbs, Adam almost 7 years ago

Thanks Ryan. My feeling is we should probably stick to the old legacy numbering scheme,

V -> 0
W -> 1
U -> 2

as I think this is what the reconstruction assumes. Would that be possible please?

#24

Updated by Bayes, Ryan almost 7 years ago

Dobbs, Adam wrote:

Thanks Ryan. My feeling is we should probably stick to the old legacy numbering scheme,

V -> 0
W -> 1
U -> 2

as I think this is what the reconstruction assumes. Would that be possible please?

It has been done in my development version. I would like to upload this to production CDB (I have already checked it using the preproduction data base) assuming that I have a final okay from the KL and Tracker people.

Thank you.

#25

Updated by Rajaram, Durga almost 7 years ago

I need a day to verify that I can swap numbering in the channel map & calibration rather than in the geometry.
Once that's done, I'll submit the tof geometry which I hope will the last time we ever have to touch the tof geometry.

#26

Updated by Rajaram, Durga almost 7 years ago

TOF0 gdml was somewhow incorrect.
I have fixed & verified.
Attached the final TOF gdml files along with the diff

#27

Updated by Rajaram, Durga almost 7 years ago

I see that http://www.ppe.gla.ac.uk/~rbayes/MICE/StepIV_July2015_20150923/ is different for TOF2.

To avoid confusion, I re-attach the corrected TOF GDMLs with meaningful names.

Details of the corrections:
The slab numbering in the readout for TOF0 and TOF1 go South->North, whereas for TOF2 it goes North->South.
My proposal is to keep the numbering the same for all 3 TOFs. To accomplish this, I will swap the DAQ channel map to read out TOF2 South->North.
Thus, the geometry numbering for all three TOFs will be the same ( South->North).
The Horizontal slabs for all 3 read out bottom->top

#28

Updated by Rogers, Chris about 5 years ago

  • Status changed from Open to Closed
  • % Done changed from 0 to 100

Also available in: Atom PDF