lucabaldini / hexsample Goto Github PK

We just realized that, at this moment, a typo in a kwarg gets happily ignored.

We are starting with a fairly simple NN clustering implementation, where the two basic handles that we have are the zero-suppression threshold and the number of neighbors.

(Note that pixels added to the cluster can be on opposite sides of the seed, which probably does not make much sense.)

I think the first information that we need here is understanding how the charge is shared between adjacent pixels without the noise.

We should keep track of all the simulation settings in the simulation output, and carry this over to the recon files, adding the configuration used for the reconstruction.

Here is a link at a repo that we might be able to use for inspiration
https://github.com/lmassach/tj-monopix2-daq

See
https://lmfit.github.io/lmfit-py/
https://github.com/lmfit/lmfit-py

It seems that we're going a long way to re-implement most of the stuff that is already available in LMFIT.

We should take a deep look at the package and see if it makes sense to drop our modeling Python module.

This is already started on the analysis branch, and we can use this issue to discuss the path forward.

This would be useful in order to be able to have reproducible results across different runs.

We do have errors when the ROI hits the physical bounds of the readout.

2023-10-06 12:35:28.238 | ERROR    | hexsample.digi:__post_init__:86 - Error in DigiEvent post-initializaion.
RegionOfInterest(min_col=160, max_col=304, min_row=0, max_row=189, padding=Padding(top=2, right=2, bottom=2, left=2))
ROI size: 27550
pha size: 27360

Now that we have all the necessary metadata we can simulate with a generic geometry and pick it back automatically at the recon stage.

Note that the generation of the pixel noise in PHA space is now performed at the end of the digitization and therefore, if we need to simulate the noise at the trigger level, this must be done separately.

See the discussion at #12

https://numpy.org/doc/stable/reference/random/new-or-different.html#new-or-different

At this point hxsim runs at something between 200 and 1000 events per seconds depending of the machine and on the particular setup. This implies roughly O(1 hour) for 1 M events, which is not outrageous, but still kind of annoying. It would be nice to speed things up by at least a factor of a few. A few lines of action might be:

• check if we're doing something wrong with the generation of the noise on the matrix---it looks like adding the noise per se slows things down by a factor of ~2;
• check if I/O is a bottleneck at all;
• check what's the smallest sensible padding that we can use, in order to reduce the event size;
• check if there's something that we can vectorize without complicating the logic flow too much.

I am sure there are others.

Knowing whether a given event file is, e.g., a digi or a recon file would be extremely useful downstream in order to be able to tell what one can do with the file itself.