Hi all,
I was wondering if there is a way to reconfigure [DetectorHistogrammer] to output the hits in global coordinates instead of local ones. Thanks in advance for any advice you can provide.
Cheers,
Pietro
Dear @pietrodelta7 ,
which output are you referring to? The hitmap (graph) is available in both local and global coordinates. Or are you talking about the log output?
Thanks and cheers
Paul
Hi @pschutze ,
thanks for your reply. Exactly, I mean the hitmap, but in the root file I only get the ones in local coordinates (see picture).
Is there a way to extract the histogram in global coordinates from the root file or do I have to re-run them with a special option?
Thanks again.
Hi!
Oh, this is a funny bug, thanks for pointing it out! It turns out that we’re doing it wrong (old copy-paste error) when we merge histograms that may have been filled in parallel.
Due to this, we get two copies of the local hitmap;
auto hit_map_global_histogram = hit_map_local->Merge();
auto hit_map_local_histogram = hit_map_local->Merge();
It’s fixed in merge request !1054
Turns out the title and axis labels were also wrong, but all good now.
You can extract it from the local histogram by shifting the axes according to the global positions of your sensors (local coordinate (0,0) is in the centre of the bottom-left pixel of the sensor), but I’m afraid there’s no easier way.
If you have saved the PixelHit objects using [ROOTObjectWriter], you can get the global positions by using the GetPixel() function, and then getGlobalCenter() on the Pixel objects.
Kind regards,
Håkan
Hi @hwennlof ,
thank you very much for the clarification! Is there an ETA on when the fix is going to be released?
And another (maybe trivial) question: how can I update my Allpix install? (I’m using Ubuntu) Do I have to build everything again from scratch?
Cheers,
Pietro
Hi @pietrodelta7,
The ETA is tricky to know, I will try to poke a merge request reviewer to get it done quickly. If you have Allpix Squared installed locally though, it will be faster to fix this particular issue by hand on your local copy.
There are two lines of code that need changing, in DetectorHistogrammerModule.cpp:
The right hand side of this image is the corrected code.
After it has been changed, you can just go to your build directory for Allpix Squared and do make install, and it will be sorted! No need to rebuild from scratch, and with a change as uncomplicated as this, recompilation should only take a few seconds.
Kind regards,
Håkan
Hi again @hwennlof and @pschutze ,
sadly I am still having dificulties with the DetectorHistogrammer module. It reports the same bin centers for all the chips on a 2x5 grid. It seems it is taking only the coordinates from one silicon chip (the one in the middle) placing the coordinate origin at the center of it and copying them for the rest of chips.
As a consequence, the histogramms are not propoerly shown (see pictures).
For context: the chips are almost 1cmx1cm and are separated by 0.6mm gaps.
Hi @pietrodelta7 ,
I see! That makes sense with how the histogram is currently defined. I didn’t notice because all my detectors were relatively neatly in a row in my test case (this example, slightly modified to shift one of the sensors by 400 µm in the y direction).
Would you mind sharing your geometry file, just so we get a good idea of the positioning of the sensors, so that we can build a good test case for this issue?
We are working on a solution, and I think we will have it sorted soon so that the histogram ranges are defined by the global position of the individual sensors.
Kind regards,
Håkan
Hi @hwennlof ,
I tested the latest proposal for modification on GitLab. The global histograms are now shown, but the matrix with the counts has now 90x90 entries although my pixel grid has 48x48 pixels. Is that on purpose?
Thanks again for the help.
Dear @pietrodelta7 ,
what do you mean by “matrix with the counts”. Do you mean the number of bins?
In global coordinates, the hitmap of a sensor projected onto an x-y surface (that’s what is shown here) does not necessarily benefit from having a number of bins equal to the number of pixels. For a non-rotated sensor, this might be helpful, but imagine a sensor that is rotated, maybe even around more than just one axis. In this case the bins of the histogram would not overlap with the pixels anymore.
Hence, the answer is that it is not on purpose, but also there’s no strong reason for changing this in my eyes.
Cheers
Paul
Hi @pschutze ,
I meant the matrix with the counts per histogram bin (the “color” on the hitmap).
I understand what you mean. I guess the functionality of a histogram does not align fully with my application in this case, thanks for helping me realize it. What I hoped to extract from the histogramm was a tuple with three coordinates: (pixelcenter_x, pixelcenter_y, pixel_hits). For my application it is very important to have only one entry per pixel, since sometimes I need to manipulate the information collected by each pixel.
This won’t be possible taking the information of the histogramm since, as you pointed out, the bins have to be resized to account for the rotation.
Dear @pietrodelta7 ,
I understand, yes. For your use case I would recommend using either the ROOTObjectWriter (ROOTObjectWriter | Allpix Squared) or the TextWriter (TextWriter | Allpix Squared) module to write the raw data to file and perform a quick analysis on the data. You will find objects called PixelHit (Object Types | Allpix Squared) that contain all the information you need.
You can find an example on how to read the data files in our repository - you can e.g. write python scripts or ROOT macros.
Cheers
Paul
Thanks for all the support!