[Olympus] Changes to the MWPC Geometry Representation

Brian S. Henderson bhender1 at MIT.EDU
Mon Apr 7 17:32:36 EDT 2014


Hello all,

As requested by Stan in the meeting today, I have prepared a brief =

write-up describing the problem that was present in the MWPC geometry =

representation and what has been done to fix it.  Since were are still =

confirming a few details regarding the problems with the GEM geometry =

that I mentioned, I will address those fixes in a separate write-up once =

everything is confirmed.

The fixes that are described below are currently only available in =

olympus_WC, but I will work on finalizing them and cleaning things up =

for olympus_release as soon as possible.  If you would like to access =

them now, you can simply ask Jan for read access to olympus_WC if you do =

not already have it.

Let me first stress that the problem that was found with the MWPCs is =

not a "survey error", but is instead related to the way in which hits =

produced from MWPC data are interpreted within the framework of the =

OLYMPUS geometry.  That is, as far as I can tell, the MWPC detectors =

were placed at the right position within the OLYMPUS geometry, but the =

positions of the hits were misplaced within the detector boxes.  =

Specifically, the wrong plane within the MWPC was used as the =

hit/tracking plane, as I will discuss.

To facilitate the following explanation, I have attached a sketch of a =

single MWPC detector (as I understand it from the geometry =

implementation).  This can be taken as a "side view", and the spacing of =

the planes (which are represented by vertical lines) is to scale.  The =

outermost vertical lines are the window planes, and the three sets of =

three lines marked U, X, and V are the sets of anode/cathode wire =

planes.  In the GDML, the space between the windows is filled with the =

MWPC gas mix (currently implemented as (by mass fraction) Ar: 0.595973, =

O: 0.220388, C: 0.0964174, F: 0.0872212).

Additionally included in the MWPC geometry (and currently left in for =

compatibility), was a fictitious "Drift" volume that simply occupied a =

10 mm thick region of the gas between the target-side window and the U =

planes of each MWPC.  It seems that this was modeled on the GEM =

geometry, but does not make sense since the MWPCs do not function in the =

same way as the GEMs.  While GEM hits correspond to a point of primary =

ionization between the HV and first GEM foils, MWPC hits from each of =

the wire planes should be interpreted as being located in the wire =

planes.  As Jan mentioned in the meeting, the use of 1D hits from each =

plane would be best (and should be implemented soon), but when 2D hits =

are constructed the most correct plane in which to consider the hits =

should be the center plane of the three wire planes.

When passing hits to LumiFit, MWPC hits were considered to be along the =

central plane of the drift volume rather than the center of the =

detector, which effectively shifted all MWPC hits 20 mm from their true =

plane toward the target along the "axis of the telescope". With the =

fixes that have been implemented, LumiFit now considers the hit position =

to be in the central plane of each MWPC detector (which corresponds to =

the X anode plane).  Especially when combined with GEM data (and the =

errors in the GEM geometry), the shift in the position of the hit along =

the telescope can change the apparent bending of the track as =

reconstructed by LumiFit, giving rise to many of the issues we have =

seen.   While this shift is along the "least sensitive" axis of the lumi =

telescopes, my early tests show that this changes the acceptance of the =

telescopes and the momentum reconstruction in significant (and so far =

quite positive) ways even when only MWPC hits are used for tracking, =

likely due to the significant size of the offset.

In the old system, the "Drift" volume was interpreted as the sensitive =

volume in each MWPC for the purposes of the MC.  Thus, MC hits from a =

simulated track were placed in the plane of the center of the "Drift" =

volume rather than in the actual detector planes, as represented by the =

geometry.  Because of this MC hits were reconstructed "properly" by =

LumiFit, since hits were produced and then reconstructed from the same =

planes of the geometry.  The MC has now been altered such that the =

sensitive volumes are now the anode planes (U, X, and V).  I have =

implemented a temporary change to the MWPC digitization so that =

digitized hits are generated from the center anode plane rather than =

from the fictitious "Drift" volume. This is a completely naive approach =

and should be replaced with a real digitization scheme!

In upcoming meetings, I will present some results regarding how these =

changes have affected track reconstruction.  As I noted, so far the =

changes have had a positive effect, but I need a bit more time to =

continue to study the left/right issue (which is complicated by the fact =

that the GEM geometry error is slightly different left/right and small =

differences in the field left/right).  In the meantime, I ask all =

detector groups to review the implementation of their detectors in the =

OLYMPUS geometry by using Colton's GDML internal note (which will soon =

be updated to account for the changes we have made in the past few days) =

and the human-readable GDML files available in the repository.

If you have questions regarding the GDML or anything discussed above, =

just let me know.  Hopefully everything above makes reasonable sense, =

but if not

Brian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: MWPCsketch.png
Type: image/png
Size: 414489 bytes
Desc: not available
Url : http://mailman.mit.edu/pipermail/olympus/attachments/20140407/1ee4f8f=
8/attachment.png


More information about the Olympus mailing list