GRIFFIN Dead Layers

[evan012345]

OK, big project here that I will be working on. My worry is that it will make the code less "computer science sexy" and will make Bill want to rip his hair out. So let me explain...

As the GRIFFIN detectors roll in people at SFU are measuring the efficiency of every crystal (core) in every clover (GRIFFIN detector). The goal is to have every GRIFFIN clover in simulation match its measured efficiency in reality. Every detector's efficiency is slightly different. The shape and size of the Ge should be nearly identical (within fraction of millimetres), since they use the same cleaving process on each core. I am told that the process of inserting the inner contact can introduce varying (inner) dead layers that result in the varying efficiencies. Currently in the Geant4 code an inner dead layer of 1mm is used, this is an average based on TIGRESS measurements.

I've done some Geant4 simulation varying the inner dead layer. The core efficiency varies linearly with this inner dead layer. Awesome. Now knowing the measured core efficiency, I can find what its simulated dead layer should be. Good! So what's the problem?

This breaks the "symmetry" of the Geant4 code. Right now we make either GriffinFoward or GriffinBack and "paste" in the world 16 times if we want 16 detectors. We make one GRIFFIN object and paste it 16 times. Now we'll have to have the dead layers modular in the GRIFFIN constructor and make the object 16 times. eg.

DetectionSystemGriffin* pGriffinForwardClover1 = new DetectionSystemGriffin(0, deadlayer_core1, deadlayer_core2, deadlayer_core3, deadlayer_core4);

Does this make sense. I believe this is the only way to do it. Thoughts?

[bkatiemills]

Apologies if I'm just restating what you said, but it sounds like the GRIFFIN detectors are still identical up to a parameter or two; this shouldn't cause any real architecture drama. The constructor for them should just accept an argument for this, which can be packed in an array and iterated over; pseudocode:

G4float deadLayers[16] = {number, number,... number};
for(i=0; i<16; i++){
    makeGRIFFINdetector(deadLayers[i])
}

No hair ripping required, we're still just deploying (basically) the same thing 16 times :) - Does this make sense?

[evan012345]

I think we are saying the same thing. I'm talking about building the GRIFFIN detectors in DetectorConstruction::Construct().

Right now we have: DetectionSystemGriffin* pGriffinForward = new DetectionSystemGriffin(0); // Select Forward (0) or Back (1) this->myGriffinForward = pGriffinForward; this->myGriffinForward->Build(mySDman);

DetectionSystemGriffin* pGriffinBack = new DetectionSystemGriffin(1); // Select Forward (0) or Back (1) this->myGriffinBack = pGriffinBack; this->myGriffinBack->Build(mySDman);

we will have to loop over this 16 times. And each detector becomes its own object. Unlike right now where every detector is the same object.

[bkatiemills]

Okay, so all you're saying is we have to declare 16 objects and inject each one into the simulation once, instead of the same one 16 times? No, that's not a problem at all, as long as the objects all come from the same constructor which just accepts a parameter that contains whatever is unique about the clover being instantiated. If there were 16 different classes in the code identical except for a single parameter, then I'd be 'upset' - but instantiating a bunch of things in memory is no problem.

I know I make a big deal out of not spamming the developers with unnecessary code - but spam the computer with tons of objects all you want, particularly when 'tons' == 16 :) If I've understood you correctly then I think your plan is excellent, I look forward to the result!

[carlu]

Hi @BillMills @evan012345

Just thought I'd weigh in here with my two-pence worth.

I think you guys have the implementation basics already sorted out so I won't add anything there.

As far as the actual physics goes I have a couple of questions for Evan:

• If the outer dead layer (the Boron implanted one) is responsible for the differences in efficiency we should see the effect more at low energy than high. Is this the case?
• In my experience with acceptance testing of AGATA crystals, I found that the crystal size DID vary by enough to see it in the efficiency measurements. The reason was that in the manufacturing process the application of contacts is the most common point of failure. Canberra would make the crystal slightly larger than required, apply contacts, then test it. If it worked then we got a crystal with way higher efficiency than required by the spec. If the crystal had poor performance they would grind off the contacts, polish, then apply more contacts. If this one passed we would get a crystal that was closer to the spec efficiency. If it didn't work that time they would either repeat or melt the crystal down and start over. Are you sure that this isn't the case with GRIFFIN?
• What about the inner contact thickness? This is the Li drifted one in n-type detectors. The dead layer is usually ~300um when the crystal is produced but there's lots of anecdotal evidence out there that this layer permeates into the crystal as a result of repeated warming/cooling cycles. Should we also be accounting for this in case it needs adjusting in future.

Cheers,

Carl

[evan012345]

@carlu You raise some very good points!

• If the outer dead layer (the Boron implanted one) is responsible for the differences in efficiency we should see the effect more at low energy than high. Is this the case?

Probably. The small amount of dead layer on the outside of the crystal would absorb low-energy gammas / x-rays and lower the observed efficiency at low energies. However the energy we are talking about is most certainly in the x-ray range, a millimeter or less of additional dead layer wouldn't absorb higher energy gammas. I suspect the aluminium can the crystal sits in has a much larger effect.

• In my experience with acceptance testing of AGATA crystals, I found that the crystal size DID vary by enough to see it in the efficiency measurements. The reason was that in the manufacturing process the application of contacts is the most common point of failure. Canberra would make the crystal slightly larger than required, apply contacts, then test it. If it worked then we got a crystal with way higher efficiency than required by the spec. If the crystal had poor performance they would grind off the contacts, polish, then apply more contacts. If this one passed we would get a crystal that was closer to the spec efficiency. If it didn't work that time they would either repeat or melt the crystal down and start over. Are you sure that this isn't the case with GRIFFIN?

This could very well be the case for GRIFFIN. I am by no means a crystal manufacturing expert. You definitely have more experience here than me. I was told by Carl Svensson that the crystal cleaving process results in nearly identical crystal shape. Obviously if a detector has a larger crystal than the rest we would expect a higher efficiency. I wonder if Canberra has exact measurements for every crystal? Would they tell us if they did?

• What about the inner contact thickness? This is the Li drifted one in n-type detectors. The dead layer is usually ~300um when the crystal is produced but there's lots of anecdotal evidence out there that this layer permeates into the crystal as a result of repeated warming/cooling cycles. Should we also be accounting for this in case it needs adjusting in future.

We could adjust this in the future. I am basing the inner dead layer thickness on the acceptance test measurements.

Thanks for raising these points Carl. Perhaps we can chat more about this in the upcoming GRIFFIN collaboration meeting. In the time being I will incorporate specific inner dead layers for each crystal. This will make every crystal its own specific geometry and if in the future we decide change the crystal shape it will be much easier to do so.

Thanks!

[evan012345]

OK, detector specific dead layers are added! Take a look at the images below. Since each crystal in the clover is a different geometry, I can now colour them differently. I've followed the TIGRESS colouring scheme. On TIGRESS we number the colours in alphabetical order: 1 Blue, 2 Green, 3 Red, 4 White. These are in the anti-clockwise direction when looking at the face of the detector.

fig 1

fig 2

Figure 2 shows the view from the back. To demonstrate the unique dead layers I gave crystals 1 to 4 increasing dead layers, 0.01, 2.0, 4.0, 6.0 mm respectively. The dead layers are coloured slightly darker than the crystals so you can see them.

I kept all the original code in DetectionSystemGriffin.cc and .hh, so old simulations with non-unique dead layers will still work. I simply copied the functions I needed to modify and made a second "dead layer specific" version. In the future we will probably want to only keep the "dead layer specific" version, but since others are working on the code I didn't want to go ahead and kill code people are using.

Specifically the two versions differ in the "build" and "place" functions. Before "build" would make one detector and place would paste it into the world "x" number of times. Now we build every time we want to place a detector in the world. I've made the following command in the messenger to run the dead layer specific code:

/DetSys/det/addGriffinPositionConfig 1 1 0

The first integer is the detector number (1-16), second is the position number in the array (1-16), and the last is forward (0) or back (1) configurations.

I know Tyler is working on better GRIFFIN messenger commands. My command above does not replace his efforts. I just needed a simple command to try out the new code.

I need to work on the data output now. Since each crystal is now a different volume, I need to sort out the detector and crystal numbers in the SteppingAction.

[bkatiemills]

Hi Evan,

Sounds great - but where's the pull request? Please merge this back to master before we diverge too far, I promise it'll be easier for you in the long run rather than trying to merge months of work all at once! You're right that people are working with this code, but I know @carlu for example mentioned being keen to see results with independent dead layers, so we all want to stay on the same page (ie version) here. This looks like great work - let us get our hands on it!

[evan012345]

Hi Bill @BillMills ,

Don't you worry, I wasn't going to make you wait too long. After making my post I thought I would check the crystal orientation in space (since the symmetry of the crystals is now broken). Sure enough I needed to rotate everything. I made sure to rotate all the suppressors too, so everything lines up now, and the simulated world should match the real one.

fig 1

fig2 (bottom left detector incorrectly positioned in this photo)

I'll send a pull request shortly.

[evan012345]

Pull request done. I emailed @BillMills the suppressed GRIFFIN file as I modified it too.

I haven't modified the SteppingAction to correctly identify the crystal and detector number yet, so don't expect the crystal and detector numbering in the histograms to work. Of course the old code will work, but not the dead layer specific code.

[bkatiemills]

Suppressed files checked in at rev 14. @evan012345 @carlu @tballast I'm going to call this feature implemented and close this thread once everyone tries it out and doesn't have any critical problems, please let me know. Good work Evan et al.

[evan012345]

With the new command (addGriffinPositionConfig) it asks for the position number in the array. This is how the positions are currently labelled in the Array, I'm not labelling detector numbers in the figures below, but rather the position number in the array. So we can put detector 4 in position 1 for example. Totally arbitrary numbers. If there are actually numbered spots in the array I can change these values to match real life, but until then, this is how they are numbered.

fig 1 DOWNSTREAM

fig 2 UPSTREAM

[bkatiemills]

@AdamGarnsworthy is there an established numbering scheme for GRIFFIN's detectors we can use here, or are the pictures @evan012345 posted above good as is?

[carlu]

Hi Evan. There is an established scheme for both GRIFFIN and TIGRESS. I am writing it up now in a longer message.

Carl

On 10 October 2013 13:23, Bill Mills notifications@github.com wrote:

@AdamGarnsworthy https://github.com/AdamGarnsworthy is there an established numbering scheme for GRIFFIN's detectors we can use here, or are the pictures @evan012345 https://github.com/evan012345 posted above good as is?

— Reply to this email directly or view it on GitHubhttps://github.com/GRIFFINCollaboration/detectorSimulations/issues/20#issuecomment-26087937 .

[carlu]

@evan012345 @BillMills @tballast

There is an established scheme for numbering and naming TIGRESS clovers which was devised by Greg and has been documented here:

http://www.triumf.info/wiki/tigwiki/index.php/Coordinates

and here:

http://www.triumf.info/wiki/tigwiki/index.php/Detector_Nomenclature

This has been extended to include GRIFFIN and it is my understanding that this has been accepted and will be the "official" GRIFFIN scheme, but @AdamGarnsworthy will have to confirm this.

I will write again in a moment with a brief summary of the scheme and how it differs from what @evan012345 has just posted.

[carlu]

First off, the axes.

• z is defined as being the beam direction i.e. downstream, so this is the opposite of what is shown in @evan012345 's images above.
• y is defined as being the vertical axis, with the +ve direction being up.
• Finally, the axis system is defined as being right-handed, which fixes the x direction. In the case of TIGRESS x is towards the north wall of the lab.

Secondly, numbering the clovers/positions.

• Numbering is based on spherical polar coordinates. 0 <= theta <= 180, 0 <= phi <= 360.
• Theta = 0 is the z axis, i.e. beam direction.
• Phi = 0, Theta = 90, points along the x axis. Increasing phi moves into the +ve y zone so Phi = 90, theta = 90 points along the y axis i.e. up.
• Positions in ANY of our HPGe or ancillary arrays (TIGRESS, SHARC, etc) are numbered with theta being the major index and phi being the minor. So:

Downstream lampshade: Smallest theta so these are positions 1-4. Position 1 lies just above the x axis, so +ve x and y. Pos 2 is 90 degs around phi from there so +ve y, -ve x. And so on until Pos4 is just below the x axis. Corona: The central 8 detectors are 5-12 and they are numbered from the x axis around phi. In the case of TIGRESS this means 5 and 6 are above the beam in the north hemisphere of the array, 7 and 8 are above the beamline in the south hemi, 9 and 10 are below the beamline in the south hemi, and 11 and 12 are below the beamline in the north hemi. Upstream lampshade: Same pattern. Position 13 is above the x axis and 14-16 are numbered around phi.

I think we should keep this system for the simulations as converting to compare experimental and simulated data will be a real pain. Sorry I didn't notice this discrepancy earlier.

I'm sorry if that makes no sense. I will be able to answer questions and help out with making these changes.

[bkatiemills]

+1 the numbering scheme for these detectors must be consistent in all implementations, both in code and IRL. @evan012345 mentioned that this was arbitrary in simulation, I'm sure it will be no problem to adjust the code to match what @carlu has described.

[evan012345]

Not a problem, really easy to change this. If I've understood everything above I need to make the following changes.

my 9-12 should be 1-4 my 1-8 should be 5-12 13-16 are identical.

The only file that changes is DetectionSystemGriffinSuppressed, so I'll email that to @BillMills when I'm done.

Thanks for commenting on this @carlu

[carlu]

@evan012345

my 9-12 should be 1-4 my 1-8 should be 5-12 13-16 are identical.

These changes will mean the clovers are positioned correctly relative to each other but not relative to to the axes/beam. Looking at the "looking upstream" image you posted.

• It should really be "looking downstream" and the z axis should be into the page not out of it. If you change this but leave x and y where they are, then positions 13-16 are exactly correct.
• As you say 1-8 should be 5-12 and 9-12 should be 1-4.

[bkatiemills]

I just committed the suppressed file fix Evan sent me at rev 15 - @evan012345, does this account for @carlu 's comments?

[evan012345]

I realized after that my "looking" phrasing was a bit confusing. I meant "looking from ... ". If you noticed, I edited the images to remove the word "looking", and now I'll let the vectors do the talking. If z is the beam direction, the "downstream" (+ve z ) lampshade is 1-4 (starting at +ve x in phi direction), middle ring is 5-12 (start just above (+ve y) x axis), and the "upstream" (-ve z ) lampshade is 13-16 (starting at +ve x in phi direction).

I think we agree ( 1-8 should be 5-12 and 9-12 should be 1-4 ), it was just my "looking" comment that was confusing.

[carlu]

Ah. Ok yes, I think we agree. I just had to go downstairs to compare the rotation of the two lampshades but you have it correct now.

[AdamGarnsworthy]

Check the angles of your clovers against this table for GRIFFIN: http://www.triumf.info/wiki/tigwiki/index.php/HPGe_Coordinate_Table

[evan012345]

@AdamGarnsworthy @carlu @BillMills The document Adam linked to (hopefully) clears everything up. After our discussion Carl and I agree with the detector positions. However, as it states in the document Adam linked: "the GRIFFIN lampshade angles are rotated by 45 degrees with respect to those of TIGRESS". Thus detector positions in GRIFFIN do not equal TIGRESS positions (in the lampshades).

Assuming the linked document is 100% correct, Carl and I agreed on TIGRESS positions. I've modified the DetectionSystemGriffinSuppressed file again to match the detector positions of GRIFFIN. I've also included code to account for TIGRESS detector positions. At the moment this code needs to uncommented to put the GRIFFIN/TIGRESS detectors in the TIGRESS positions. In the future it will be easy to accommodate both the TIGRESS and GRIFFIN positions without needing to recompile the code, but since we are concerned with GRIFFIN right now I left the code there to be utilized later.

[AdamGarnsworthy]

What exactly has happened between TIGRESS and GRIFFIN is that we had a conflict with a beamline stand so there has been a rotation of the structure 180 degrees around the y axis. ie. Upstream is now downstream. However, following this we want to maintain the same numbering scheme as TIGRESS as was described by Carl. Net result is that the lampshade angles change by 45 degrees.

[evan012345]

ahh, I see. OK, thanks for clearing this up Adam. We are all on the same page now.

[bkatiemills]

Suppressed files checked in at rev 16.

[carlu]

Cheers @AdamGarnsworthy I'd totally missed that difference in the two designs.

@evan012345 I'm comparing the simulations with some TIGRESS data so I'll try using the commented code you included. It shouldn't make any difference to the results but I may as well do things properly.

[evan012345]

@carlu I just added some code to use TIGRESS detector positions rather than GRIFFIN positions. This should be useful for you Carl. Use the command "/DetSys/det/UseTIGRESSPositions true" in your run macro BEFORE adding the GRIFFIN detectors.