km3io issueshttps://git.km3net.de/km3py/km3io/-/issues2023-10-17T13:18:52Zhttps://git.km3net.de/km3py/km3io/-/issues/104New KM3NeT Dataformat Release v3.3.02023-10-17T13:18:52ZMr. BotNew KM3NeT Dataformat Release v3.3.0There is a new version of the KM3NeT Dataformat available, please update!
https://git.km3net.de/common/km3net-dataformat/-/tagsThere is a new version of the KM3NeT Dataformat available, please update!
https://git.km3net.de/common/km3net-dataformat/-/tagshttps://git.km3net.de/km3py/km3io/-/issues/84Add support for DST summary trees2023-05-23T21:26:37ZValentin PestelAdd support for DST summary trees[UNDER CONSTRUCTION]
### Overview
In the oscillation analysis context, I'm trying to provide a workflow that only depends on official KM3NeT packages and data-format.
The dst trees (reduced offline files + additional variables) provid...[UNDER CONSTRUCTION]
### Overview
In the oscillation analysis context, I'm trying to provide a workflow that only depends on official KM3NeT packages and data-format.
The dst trees (reduced offline files + additional variables) provide a good solution, however none of the additional variables are currently available inside km3io, limiting the usage of this data format.
### DST format
DST files are basically offline files in which you've removed all tracks excepts the best, remove all the hits etc ...
In this sense, all the information available in the offline file in the `E` tree and contained in the `Evt` container are available.
In addition to that, a friend tree `T` is produced while creating the dst file. It has the same shape, and contains multiple custom struct branches, like one containing the summary information for the tracks, another for the hits etc ...
An example of such a file can be found here : `/sps/km3net/users/heijboer/dstprod/v6_data/datav5.40.ALL.dst.root`
In the context of the oscillation analysis, I would like add one or multiple additional structures to handle the additional variables required for the oscillation neutrino selection.
### Thoughts & Open questions
- The second tree, `T`, is directly accessible from `E`, as it is append to E with the `TTree::AddFriend()` method. Is the friend Tree concept something that translate through uproot ?
- The DST also used some aliasing features from `TTree`, with for example these two definitions :
```
deepAlias(E, ROOT.Trk, "trackfit", "trks[0]")
deepAlias(E, ROOT.Trk, "showerfit", "trks[1]")
```
(deepAlias is basically looping over all the sub member of the class, e.g. `trks[0].E` becomes `trackfit.E`. I don't know if this behavior is something also translatable in uproot.https://git.km3net.de/km3py/km3io/-/issues/74Rewrite the online-reader with uproot42022-11-03T08:48:08ZTamas Galtgal@km3net.deRewrite the online-reader with uproot4A complete rewrite of the `online.py` is required to support the new `uproot4` and `awkward1` packages which were recently renamed to `uproot` and `awkward` so that those are the standard versions when `pip install`-ing them.
As of km3io...A complete rewrite of the `online.py` is required to support the new `uproot4` and `awkward1` packages which were recently renamed to `uproot` and `awkward` so that those are the standard versions when `pip install`-ing them.
As of km3io v0.19.1, the `online.py` uses the `uproot3` package which was created for backwards-compatibility.
This is also a follow-up for https://git.km3net.de/km3py/km3io/-/issues/42v1.0