Draft: CbmTrdModuleRecR cleanup discussions.

@a.bercuci @p.kaehler

With this draft MR, I wanted to bring my current personal version of CbmTrdModuleRecR::BuildCluster() to your attention. It reproduces the original version but is a bit more concise in my opinion. Unfortunately, it is still too slow. I takes up to two seconds to process one timeslice of data from the 2457 run. Suggestions for additional improvements are appreciated.

Again, this is not meant to be merged into the offline version of the code. It is precursor work for a new class.

requested review from @a.bercuci

assigned to @d.smith

I observed the following: The while(true) loop only executes a single iteration in the vast majority of cases, meaning the inner loop over all digis is only done once, but on occasion it gets stuck and produces 20+ inner loops, which is probably what is slowing down the code. I guess this is what is called "monster events"?

Interstingly, this is not caused by the row merging. In fact, the same effect is observed with rowmerge=false and the runtime isn't even that much shorter.

I'm wondering whether it might be advantageous to separate kSelf and kNeighbor digis prior to running the algorithm.

added 1 commit

• 3d310ffd - Cleaned up starting position computation.

Compare with previous version

Updated loop starting point computation among other things.

To me it increasingly looks like sorting by channel will be necessary to do this algorithm efficiently.

You mean to separate between self and neighbor triggers ? If yes this looks like a major development which probably should be coupled with the cluster shape that we have discussed here !1605 (comment 39289)

@p.kaehler maybe we should discuss it during our TRD meeting ? I know @d.smith is not a fun of meetings :) but maybe he can also join !?

@a.bercuci I can perhaps attend your meeting next week. I have one other idea that I wanted to try, that might speed up this code.

Ok.

@a.bercuci A short question: is the return value of digi->GetAddressChannel() always a number in the range [0,nRows*nCols)? I.e. is the channel drawn from a consequtive set of numbers?

Yes, This should be the case !

And also: Are there in general no gaps, i.e. all numbers in the range are possible?

Yes, this is the case in general. BUT there are missing FEB channels which makes channel addresses vanish from the digi array.

Ok, thanks.

Closing. About to overhaul this again.

closed