Sorting taking too long

[beaerran]

I am trying to sort a .mid file from a 56Co (200 KBq) source with the command:

grsisort --recommended run19993_000.mid

and the sorting is taking too long e.g. barely 25% in one hour, whereas .mid from other sources (e.g. 152Eu, 39.41 kBq, run20011_000.mid) take 10 mins at most.

Do you think this issue could be related to sort depth or pile-up?

Root version: 6.26/10 Built for linuxx8664gcc

GRSISort version: 4.0.0.3

[VinzenzBildstein]

You are right, it shouldn't take this long. It could be an issue of the build window size and/or using a moving build window. This was observed before with high rate data (like the 100Zr data).

What does running top in another terminal on the same machine say about CPU and memory usage of grsisort?

You can try and stop the sorting using Ctrl-C once or twice (but not thrice). This should stop the sorting within a few minutes and you would still get an output fragment and analysis file (not the whole statistics of course) and take a look at the GRIFFIN multiplicities in the analysis tree (AnalysisTree->Draw("TGriffin.@fHits.size()>>m(100,-0.5,99.5)")).

[beaerran]

The GRIFFIN multiplicities don't look very high (see pdf attached) however by making the build window smaller (--build-window 50) the sorting finished successfully in less than 10 minutes.

GRIFFIN_HITS.SIZE.pdf

Thanks for the help!

[VinzenzBildstein]

That is a 50 ns build window, meaning any hits that aren't within 50 ns of each other will be put in separate events. This is way too short for our detectors, especially if you want to correct for time-random coincidences. You should have a build window of at least 500 ns, but 1000 would be better (to get a good idea of the time-random background).

[AdamGarnsworthy]

I agree with Vinzenz here. The build window in GRSISort should be thought of like a hardware coincidence master trigger condition in analogue electronics. 500ns would be a minimum. You can then set narrower coincidence conditions (30ns a min for HPGe) when filling histograms and matrices.

[beaerran]

According to the command grsisort --help, the command --build-window takes an argument in timestamp units, that's why I used 50 (meaning 500 ns). When using this window size these are the GRIFFIN-GRIFFIN timing histograms created (run19992_w50_tsu.pdf created in timestamp units using the function GetTimeStamp() and run19992_w50_ns.pdf created in ns using the function GetTime()): run19992_w50_tsu.pdf run19992_w50_ns.pdf

Also by varying the window size in the same calibration source but filtered by a time calibration, the GRIFFIN gamma energy histogram changes by appearing some weird spikes when using the --build-window 200 command: run20016_000_w50_gE.pdf run20016_000_w200_gE.pdf

The same thing happens for the source unfiltered but when using the --build-window 50 command: run19992_w50_gE.pdf

[VinzenzBildstein]

Looks like the help command hasn't been updated in a long time, it's actually taking the time in ns.

The spikes you are seeing are related to issue #1189, checks the tips given in there (using checkSort to test the analysis files, and sorting with --write-clients 1).