Rename "DAQ" to "online"

Since of course the official naming of the DAQ data is "online" data, we should rename all the corresponding classes.

I am not happy with the naming since there is also a "real" online format (binary streams), but I guess we follow the naming convention.

What do you think?

added discussion label

I am not sure I know which naming convention you are talking about? Was it agreed for the other software to always consider that files created by Jpp are named online files?

I think DAQ is rather descriptive of the content of the files, but if all software developers in km3net want to refer to DAQ files as online files, then I guess we need to follow (for consistency)....

Side note: when we run a full reconstruction chain in data_processing, data files are created by both aanet and Jpp. wouldn't it be misleading if such a (reco) root file (created by Jpp) is named an online file? Just wondering ...

Yeah indeed, online is really a bad name. It is however the convention in the km3net dataformat so I am a bit puzzled...

I think the best idea is to go one level higher and solve the issue by providing km3io.open(). This should return an instance which is hiding these implementation details.

We can then map online.events to events (because they are real) and offline.events to .mc_events or so.

changed milestone to %v1.0

@zaly what do you think about a km3io.open? we can combine the readout into a single function then, which loads the file both in OfflineReader and DAQReader?

@tgal sorry, I somehow missed this!

In principle, this can be great! However, the only problem I see here is the fact that OfflineReader and DAQReader are expecting different files with different structures! So I am not sure I see the benefits of loading, for example, a DAQ file with OfflineReader if OfflineReader is not capable of reading the content of the DAQ file. Similarly, the content of an aanet/offline file wouldn't be accessible with DAQReader. So maybe you could please clarify further the benefits of combining both readers in km3io.open?

Additionally, keeping both readers separate makes it clear that there are truly two files structures in KM3NeT that contain a different type of data. One might argue that there is some data in common in both files, yes it is true! However, from my understanding, these offline files are meant for high-level analysis, while DAQ files are very low level (please correct me if I am wrong).

Maybe I misunderstood what you mean?

OK let me add some details and comments.

However, the only problem I see here is the fact that OfflineReader and DAQReader are expecting different files with different structures!

That should be not a problem since everything is in it's own namespace (branch/tree). We just need to make sure that the OfflineReader doesn't crash if there is no E branch for example and the same for the DAQReader.

Additionally, keeping both readers separate makes it clear that there are truly two files structures in KM3NeT that contain a different type of data.

I was thinking of such a user API:

import km3io

f = km3io.open("path/to/file.root")

f.offine.events   # obviously the offline events
f.online.events  # the online events ;)
f.online.header
f.online.timeslices
f.offline.events.tracks

etc.

Alright! Understood ;)

then let's do it! I like it!

kool :)

added todo usability labels and removed discussion label

created merge request !28 (merged) to address this issue

mentioned in merge request !28 (merged)

closed via merge request !28 (merged)

mentioned in commit da1b1374