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!

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

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

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.

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.

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.

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!)