Krypton analysis under way: Kryptonite scripts

[jjgomezcadenas]

Krypton analysis is under way! Branch KrNB contains a number of NBs that summarize initial results obtain by @gonzaponte. Branch KrSrc contains the /Kryptonite/kryptonite.py sript (and friends) which performs a city-like reduction of data, from PMAPS to a summary data structure (pandas data frame) with simple vectors, very fast and flexible for analysis. I call this data structure a KDST.

kryptonite runs very fast over PMAPS data, producing a very lean KDST. A notebook containing an example of use of the KDST, reproducing (part of) the analysis of @gonzaponte can be found in my own branch:

https://github.com/jjgomezcadenas/ICARO/tree/KrNB

Several interesting questions:

1. kryptonite.py is nothing but a city, which further reduces the data, from PMAPS to a KDST. Unlike IRENE, however, which processes all the data, kryptonite filters the data requiring specific conditions (e.g, a single S1, at least 1 SiPM with signal). These are, however, very general, and will be required by all the analysis downstream IRENE.

2. On the other hand, kryptonite.py assumes that the events are "krypton-like", that is, small enough to be treated as points. That means that the information in the tracking plane is integrated in the time dimension before computing a simple baricenter to produce x & y coordinates. Notice that many type of events (analysis) can work well assuming Krypton-like objects, in particular x-ray studies with Na-22, Energy resolution with Na-22 for 511 keV, and alpha analysis.

3. However, the algorithms for (x,y) are not unique, so a different script could compute (x,y) with, say, a neural network (e.g, the analysis of Josh and Alex). Here we are in a situation in which we can produce a KDST from PMAPS, but using different algorithms for (x,y). Obviously, this has to be accomodated in the software.

4. A different situation is that in which we want to do something else that we are not doing in Kryptonite (say, produce extended tracks) and therefore results in a different type of DST. In practice, this can be taken as a different city, since it consumes the same data but produces different data. As before, we need to figure out the best way to organize this.

However, it appears clear to me that the initial teething period of IC is more or less over with this first Krypton analysis.

I have open this issue to encourage some discussion concerning the best way to integrate analysis into the IC general structure. We are not in a hurry and is probably best to work in ICARO until past the May review, then devote some time to think how to organize the analysis (we will have enough examples then, not only this initial Krypton analysis).

Meanwhile, KrScr will develop the "Krypton" like analysis. Only scripts go to this branch. Notebooks can go to KrNB (but only when mature enough, otherwise keep then in your forks). Also, the best way to browse somebody else's NB is DIRECTLY IN YOUR BROWSER, NBs are not easily amenable to collaboration and are best taken as individual documents. This is why you must keep them in your forks, until they are sufficiently mature to document an analysis.