High multiplicity event: in which order are they written?

[bolaizol]

If I have an event with a lot of detector hits (let's say several GRIFFIN hits in coincidence), in which order are they written into the AnalysisTree? Is it time based (clock, cfd)? Or is it channel or address based?

[r3dunlop]

They are LED timestamp based. They may not be truly time ordered after the cfd is applied.

[bolaizol]

Ok, thank you.

[pcbend]

one small bit of confusion here. (maybe just for me)

If you have many gammas rays built into a single event (i.e - more than one crystal in coincidence or already grouped by a time window), I believe they are still written in order of there energy into the built event (TGriffin). What this means, if you loop over the TGriffinHits in a TGriffin event the highest energy gamma should be first, followed by the second, etc...

This is done to make it easier to construct addback events later. The actual led time of an individual gamma-ray can fluctuate by ~100 ns (to clock ticks) easily due to walk effects which are common to all large volume coaxial ge detectors.

Just out of my own curiosity; is there some effect you are trying to account for?

On Tue, Feb 14, 2017 at 2:57 PM, bolaizol notifications@github.com wrote:

Ok, thank you.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/GRIFFINCollaboration/GRSISort/issues/858#issuecomment-279817955, or mute the thread https://github.com/notifications/unsubscribe-auth/AAacI8-WIhvBVx8W2AMF-Wh5-yr1hwxOks5rcgc-gaJpZM4MA6gr .

[r3dunlop]

Was this changed to be like this at some point?

[bolaizol]

I was loooking on optimized ways to correlate TAC and LaBr (or any other detector) events. If they were ordered by addresses it would be much better for this case.

If there is such a large fluctuation (~100 ns), I don't really see the point of ordering them based on timeclock or cfd. But I see the point of ordering the hits by energy if it is useful for the addback.

[VinzenzBildstein]

I don't think we sort the hits by energy. That wouldn't help much in the addback either since you would now shuffle gamma-rays out of their time-order and the time is something we consider for the addback. As far as I can see in the code, we just use AddFragment to add the current hit (which was sorted by LED timestamp) to the vectors of hits. That is why we check the energy of the (second) hit in the TGriffinHit::Add routine to decide whether we use the position of the first or the second hit as position of the addback. If the hits were sorted by energy we wouldn't need this check.

[VinzenzBildstein]

The only energy sorting that is happening is actually due to the walk. Gamma rays that are hitting the detectors at practically the same time will have a later timestamp if their energy is lower.

[r3dunlop]

I really think LED is the way to do this, at least with GRIFFIN. Breaking up the ordering will make it a pain to deal with pileups in the future.

[pcbend]

I haven't looked at the latest incarnation of the griffin addback - however at one point I wrote a compare function (and < operator overload) which allowed us to use std::sort on the vector of hits before writing to the tree, this is still being done in tigress. I thought was still being done in griffin as well.

It is true the fragments going into the hit building are sorted, as they should be, however once the event is built - I think there is a lot more information to be gain from the energy of a gamma hit than its time - especially if the time is an led value. This stems from the idea that the energy defines a main interaction point in addback event or from which hit an addback hit will inherit its timing and position properties from when it is constructed from a sum of two or more hits. Knowing who gets copied where just makes the coding a bit cleaner.

On that same note, I am not sure what is gained from keeping the order of the led time in the hits. Based on the pileup argument - this hits should either be removed completely from the event or become there own event as they are not time ordered, right?

Also; "The only energy sorting that is happening is actually due to the walk. Gamma rays that are hitting the detectors at practically the same time will have a later timestamp if their energy is lower." and interaction location within the crystal (just for completeness sake and future readers).

On Wed, Feb 15, 2017 at 11:53 AM, Ryan Dunlop notifications@github.com wrote:

I really think LED is the way to do this, at least with GRIFFIN. Breaking up the ordering will make it a pain to deal with pileups in the future.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/GRIFFINCollaboration/GRSISort/issues/858#issuecomment-280068181, or mute the thread https://github.com/notifications/unsubscribe-auth/AAacI9uSjnRtoTxlDAlaz0XdHRs6YKKmks5rcy2XgaJpZM4MA6gr .

[r3dunlop]

In the end, it is the ordering based on CFD timing in GRIFFIN that will be best if you are looking for efficiency. I’m not sure why energy ordering makes add back better. That just means you have to loop over every single hit to find out what to add back, which you would have to do anyway if they weren’t ordered. Ordering on a time parameter allows for the quick knowledge of which hit came first. It also allows one to be more efficiency if they desire by cutting off the looping over hits when a tight time difference is exceeded. This will be very important for high rate experiments where everything is in coincidence with everything.

[VinzenzBildstein]

We do use that compare in Griffin as well, but only to determine which hits time and position we use for the addback. I agree with Ryan in that I don't see the advantage of energy-ordered hits for building addback (you need to loop over all hits anyways) compared to time-ordered hits (where you might stop after a hit is outside the addback time window).

And I think we need to change the whole time sorting as some point to use the cfd corrected time anyways (if we didn't already do that?), to correctly build events using pile-up.

[jsmallcombe]

Can I have some clarification of what the current ordering is. I can see Ryan's logic of time sorting allowing speed by continuing the loop and avoiding unneeded comparisons for addback. But this isn't done in TIGRESS. TIGRESS addback logic is heavily based on energy arguments the Peter explained, (I recently added a whole load of comments to the code) and assumes energy of hits and segments have been pre-sorted.

[pcbend]

Simply put - if two gammas are really in coincidence with each other and not a special case (i.e. isomer, which is never the case for two individual hits which need to be added together), than there energy is deposited in the detectors with a time difference we can not measure.

Currently, we do a single pass through of the hits to decide which hits to add together. What this implies is we are slightly weighting the probability of which hits get added based on their order in the list. Now the time measurements we actually measure for gammas, especially the ones that should be added back, are there due to detector effects where as the charge deposited in the detector more closely related to information carried by the actual gamma. Thus the energy making slight weighting in terms of the energy should give better results. This is a very hand wavy argument of one reason, as my time is ridiculously short right now, of why the energy is a better ordering then the time. Next week I can look at getting my hands on a large 60Co data set and see if I can make some definite plots.

Also I should mention, the addback requirements for tigress and griffin are slightly different. Tigress is a single trigger low rate counter, it is not currently used in a gamma singles mode - and like all in-beam facilities, it is not clear it can be effectively used with out an external tag to look at the event. Such an external tag already greatly cleans up a gamma-gamma spectrum. For griffin, there is a worry about high rates. However my gut feeling tells me this doesn't become a really concern until the expected rate in a single element plus neighbors approaches our addback time window, for 200ns window, that is 500,000 Hz over 5 crystals. That is still 100,000Hz in our detector which is a factor of two higher than the desired goal of 50,000 Hz, right?

I am not sure I buy the argument about after a certain time cut off, we can never have more than 64 gamma hits in a single event, and even at extremely high rate - we should still have far fewer than that.

On Wed, Feb 15, 2017 at 5:17 PM, jsmallcombe notifications@github.com wrote:

Can I have some clarification of what the current ordering is. I can see Ryan's logic of time sorting allowing speed by continuing the loop and avoiding unneeded comparisons for addback. But this isn't done in TIGRESS. TIGRESS addback logic is heavily based on energy arguments the Peter explained, (I recently added a whole load of comments to the code) and assumes energy of hits and segments have been pre-sorted.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/GRIFFINCollaboration/GRSISort/issues/858#issuecomment-280158324, or mute the thread https://github.com/notifications/unsubscribe-auth/AAacI70iTqDoE5JF6rQGXDjByCDKT_kkks5rc3mKgaJpZM4MA6gr .

[r3dunlop]

We also have descant, and sceptar, and LaBr, etc…. The ordering method I am talking about makes looping through all events more efficient. I can still find the highest energy hits and use them appropriately for addback. My thinking goes beyond addback into correlating events across detection systems and between clovers. In the GRIFFIN 2 us event window, you can easily have 3 distinct events based on CFD, but as soon as you sort by energy you mix them all up. If the first 3 of 10 hits should be added back because the other 7 are distinct, why should I have to loop through the highest energy hits of the other 7 as well? If it works for TIGRESS I think that’s fine, but I would strongly recommend against doing this in GRIFFIN.

[pcbend]

The time sorting vs energy sorting i was referring to is only relevant internally to the hpge detector. When trying to compare different subsystems, of course we must compare by time.

As far as addback goes, this may just be getting down to preference. But the logic to me goes position, energy, time in terms of importance to check. I have no proof one is faster or one gives a better sum peak to addback ratio. For tigress, we clearly do not have a rate issue and any hence no effect of sorting by time. For griffin, I am interested as to what if any effect this actually has - but we need data and plots to take this much further :)

On Wed, Feb 15, 2017 at 7:38 PM, Ryan Dunlop notifications@github.com wrote:

We also have descant, and sceptar, and LaBr, etc…. The ordering method I am talking about makes looping through all events more efficient. I can still find the highest energy hits and use them appropriately for addback. My thinking goes beyond addback into correlating events across detection systems and between clovers. In the GRIFFIN 2 us event window, you can easily have 3 distinct events based on CFD, but as soon as you sort by energy you mix them all up. If the first 3 of 10 hits should be added back because the other 7 are distinct, why should I have to loop through the highest energy hits of the other 7 as well? If it works for TIGRESS I think that’s fine, but I would strongly recommend against doing this in GRIFFIN.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/GRIFFINCollaboration/GRSISort/issues/858#issuecomment-280190591, or mute the thread https://github.com/notifications/unsubscribe-auth/AAacI2s-qrrxT2nSV1hXseFFi6squHlNks5rc5pogaJpZM4MA6gr .

[r3dunlop]

I just think someone has been working with GRETINA too much… :P

[pcbend]

I won't lie. Tracking everything makes me think about addback waaay too much.

On Feb 15, 2017 7:59 PM, "Ryan Dunlop" notifications@github.com wrote:

I just think someone has been working with GRETINA too much… :P

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/GRIFFINCollaboration/GRSISort/issues/858#issuecomment-280194769, or mute the thread https://github.com/notifications/unsubscribe-auth/AAacI-ZxIl9U4cJpSZINuXlg4ZHYN6Tbks5rc59ogaJpZM4MA6gr .

[jsmallcombe]

I agree with Peter advocating energy ordered for the physics motivation. Currently within the TTigress class there is an assumption of energy ordered hits. The potential time saving you are advocating Ryan (by skipping ahead when coincidence searching) is a matter for a subsequent stage of sorting and the benefit of doing so is only gained if the end user doesn't use their own sorting scripts or knows this particular trick of the frag->analysis tree sorting. Two things: 1) Currently how are we ordered, does tigress now need to energy sort before doing addback? 2) Producing the best physics results to ignorant end users should the priority over high end computing.

[pcbend]

Tigress hits are order by energy before they are saved to the analysis tree, thus when they are read back, they are still ordered.

This provides the default addback scheme to work as intended for an user with out having to know to much of the underlying details.

On Feb 15, 2017 10:23 PM, "jsmallcombe" notifications@github.com wrote:

I agree with Peter advocating energy ordered for the physics motivation. Currently within the TTigress class there is an assumption of energy ordered hits. The potential time saving you are advocating Ryan (by skipping ahead when coincidence searching) is a matter for a subsequent stage of sorting and the benefit of doing so is only gained if the end user doesn't use their own sorting scripts or knows this particular trick of the frag->analysis tree sorting. Two things:

1. Currently how are we ordered, does tigress now need to energy sort before doing addback?
2. Producing the best physics results to ignorant end users should the priority over high end computing.

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/GRIFFINCollaboration/GRSISort/issues/858#issuecomment-280220168, or mute the thread https://github.com/notifications/unsubscribe-auth/AAacI1fvgF-aJ_jex4GrwCmOIZ8aAtlTks5rc8FAgaJpZM4MA6gr .