Bug #335
tracker geometry issue when finding fibre number (affects physics resolutions)
0%
Description
The code for determining the fibre number in the detector model is approximate stopgap code whilst geant4 lets you know the true position of the fibres. Especially the part about figuring out when two fibres were hit and splitting the energy between them (which is not physical).
The purpose of the detector model in Geant4 is to produce energy deposited and a time for each fibre. The relevant code is in DetModel/SciFi.
When the Detector construction code encounters a volume that says it is a SciFi sensitive detector in the MiceModules, it knows to build the detailed model using the SciFiPlane class:
http://micewww.pp.rl.ac.uk/projects/maus/repository/entry/src/common/DetModel/SciFi/SciFiPlane.cc
This contains the code that finds out the details of the fibre (diameter, pitch, etc) and builds the G4 parametrized volume that places the fibres in the correct position with the correct lengths, etc, for a given plane.
The actual parametrization is performed by the DoubletFiberParam class:
This code is passed the copy number by GEANT4 and returns the position, orientation and dimensions of the fibre that is being placed with that copy number.
Finally, SciFiSD.cc is where the code that is called at the end of the simulation of every event in G4 is found:
http://micewww.pp.rl.ac.uk/projects/maus/repository/entry/src/common/DetModel/SciFi/SciFiSD.cc
The main issue is that based on the description above, the nchans == 2 stuff and splitting the energy between fibres should never happen. One should check to see if the MC hit is actually inside the fibre code (by querying the Geant4 volume name of the object that the hit is in) and throw it away if it isn't.
Then, you ask the volume it is in for its copy number, and that tells you the fibre number of the fibre the hit was in.
Then you stop. It's the job of the digitization to bundle the 7 fibres into a readout channel.
Files
Related issues
Updated by Tunnell, Christopher over 12 years ago
- Target version changed from MAUS-v0.0.1 to Future MAUS release
Updated by Tunnell, Christopher over 12 years ago
- Assignee changed from Adey, David to Santos, Edward
Updated by Belozertseva, Anastasia over 12 years ago
- File corrected.jpg corrected.jpg added
- File before.jpg before.jpg added
In the last few days, Edward and I have been trying to solve the problem of finding the relationship between the hit channel number in the tracker and the copy number of the scintillating fiber (i.e. the position of the fiber in the plane). We were expecting to find a uniform offset between the old channel number (that G4MICE gives us) and our new guess (that was calculated based on the copy number of the fiber). However, the picture attached below shows that the plots of the old channels versus our guess for all the planes and the stations were just a mess, except for one plane (plane 1), that does not have a rotation.
Eventually, we found a bug in the code in SciFiPlane.cc (maus->src->legacy->DetModel->SciFi). The rotation was not introduced properly for all the planes. As the 'corrected' plot shows, we have fixed the problem and now we understand the translation from the GEANT4 copy number to the real channel number.
Updated by Tunnell, Christopher over 12 years ago
Great work you both. Here are the sanity checks that need to be done before this modification makes it into the software trunk (ie. code for everybody).
1. You have two methods for computing the channel number (even though the SciFiSD will only store fibre number). And one was written by Malcolm Ellis who knew more about the tracker than anybody, so let's be careful. How do we know which method is correct? You are assuming that SciFiPlane is wrong and the SciFiSD tossed in code is correct. Given that there is a correct answer for this problem since the tracker is built a certain way and resides in Lab 7 at RAL, can you find a document that says the rotations are a certain way? There should be something here: http://hep04.phys.iit.edu/mice/notes/notes.html. If you can't find anything, then please talk to one of the engineers. This is not something you want to get wrong.
2. Any bug that gets fixed must come with an accompanying test. This ensures that the bug never creeps back in again; you would be surprised how much that happens. We can discuss this at the software workshop, but how would you like to test this? The test can either be a low level function that gives 'false' for the bad setup and 'true' for the good setup (this is ideal since fewer dependencies). Or we can try to think of something higher level if the first way is impossible.
3. You'll need to somehow send us a 'diff' of the work (ie. the changes you made). I don't see a branch for you at the moment (https://code.launchpad.net/maus) so we should set you up with one tomorrow. We can go through the motions of getting changes included into the main repository.
4ish. This relates to (1) but we need as Doxygen comments at the top of the file within MAUS a few paragraphs saying what SciFiSD is, what it is doing, why it is doing that, etc., since in a few years somebody else will be fishing through this code trying to figure it out.
Don't take the long list of things as criticisms. Nice work now let's get it so other people can use it!
Updated by Adey, David over 12 years ago
- File Fig03old.jpg Fig03old.jpg added
Actually this part of the code was written by Ed McKigney before the tracker was built, as far as I know. As for the "tossed in code" I really wouldn't assume it's correct. It's based on the fibre pitch diagram found in the tracker paper (I've attached it). As an additional sanity check I would recommend the sum of the channel numbers - if it's a triplet the sum of the channels should peak at 318/319 (or 321 for tracker 1 station 5) with some tails depending on how you've calculated the channel number for a two digit cluster.
Updated by Tunnell, Christopher over 12 years ago
Hi David,
Thansk for the useful input!
Do you think that the 318 sum would be a good test? Ie. a plot of it would convince you it was right? And you woudl want to know when that wasn't true?
And thanks for letting me know it was Ed McKigney who did it. My history is a little mixed up and my phrasings of things are frequently poor, sorry.
Cheers,
Chris
Updated by Adey, David over 12 years ago
You're right that Malcolm knew this better than anyone, but the problem is a lot of this code was written for the first simulations and has just stayed, and we need to be weary of it. Summing the channel numbers for a triplet (and it only works for triplets) will tell you if the rotations have worked, as well as the ordering of the channels within the plane. However, it requires you to reconstruct space points, and a cross-level test like this may not be to your liking.
The results of the real data for this sum are here (page 19):
http://www2.warwick.ac.uk/fac/sci/physics/research/epp/people/david_adey/trackercosmic.pdf
Updated by Santos, Edward over 12 years ago
Thanks, David.
The issue in Ed McKigney's code was pretty simple. The fibres were being disposed in the SD plane as they should, but the plane wasn't being rotated. The G4PVParametrized placement was always passing a ZERO degree rotation. We replaced the zero by a call to the rotation defined in the Module that plane corresponds to (view x, w or v). It follows the very same way the position of the plane is defined by a call to that same Module. I didn't hunt for errors in the geometry, but I was left with the impression that besides the detail we mentioned, everything is accurate.
As you understand, the feature we found doesn't affect the channel calculation you have written previously, because you only cared for the central fibre number and the (perpendicular) distance between it and the true position of the hit. The rotation of the plane doesn't matter in this scenario because the concept of fibre doesn't exist and the rotation doesn't affect the mc hit position in the world volume.
We will work out the 3 channel sum.
Hope we can meet and discuss this case in the following days.
Updated by Tunnell, Christopher over 12 years ago
So the fibres were in the wrong place (that affect dE/dx) but since they weren't used to figure out the channel number, it didn't matter?
I still think what I said about a reference stands but it probably relates more to job #509 than here now.
Updated by Santos, Edward over 12 years ago
Sure the dE/dx matters, but at this point we were only discussing the channel number calculation and why it hasn't been affected by the lack of rotation so far.
Updated by Tunnell, Christopher over 12 years ago
The dE/dx here was wrong! This was a big deal. It may not matter that the geometry being wrong was cancelled out by the geometry not being used when computing the energy deposited in a volume, but the amount of energy deposited in fibres was wrong since the physical volumes were constructed wrong. All this work predates us but let's not forget that we discovered something here that may not be catastrophic to previous results but caught us all by surprise and (as you both admit) is a bug.
So maybe this is only a minor bug within the SciFiSD stuff but it instead brought up a hideously major bug of the geometry that is simulated having nothing to do with deposited MeV the sensitive detector stored per channel. The fibers being in completely the wrong place and no code being able to notice is a big deal...
It's a big deal that nobody ever noticed this before.
Anyways, feature #507 being complete will close this bug since that's just making sure the sensitive volumes are fibres instead of hacking channel numbers. But #509 geometry verification is now even more important since we need to make sure the fibres we place have some bearing to reality.
(P.S. I'm not meaning to be heated at you Edward, you Anastatia, or you David. This predates all of us. This is just confusing and bad. We lost expertise and are hurting because of it. I'm excited about us being able to actually do this correctly now!)