Suggestions

[SmithJK]

Question:

• Is the idea to parse a single GRIFFIN event? Or a single MIDAS event?

Suggestions:

• Allow selective display of events based on digitizer, channel number, type of event (scaler, PPG, event, etc.), pileup type, filters passed.
• Print both the hex event and parsed event.
• Allow display of corrupted events (probably reasonable only in hex). In the case of a corrupted event in GRSISort, it print the entire MIDAS event. Practically, we would probably only need to print from the beginning of a previous non-corrupted GRIFFIN event to the end of the next non-corrupted GRIFFIN event.

[bkatiemills]

These are all pretty doable, but (with the exception of printing both hex and parsed events, which is for sure happening), are contingent on how the raw data is getting served. If there's an API endpoint somewhere that will supply events specific to detectors, trigger conditions, or whatever else, then it's no problem to do as you suggest.

For corrupted events, our plan was to always include the unparsed event, so that the raw data would be available when things looked suspicious. But, if we fetch one event at a time (which is how I envisioned it, but not necessarily true), printing adjacent incorruptible events will rely on being able to fetch those events as well.

So - TLDR this is all contingent on whatever is serving the raw data; do we have an idea yet of where that's coming from?

[SmithJK]

Could the selective display of events be implemented by continuously fetching events and parsing them, but only displaying events that fit the criteria?

Is the plan to display many events at once, or a single event at a time?

[AdamGarnsworthy]

The initial idea was that Chris makes the frontend code place a single GRIFFIN event in the ODB and updates it every few seconds. The webpage display would then only need to talk to the ODB (easy). Thinking about it more though, we might want a full network packet put into the odb. That way we could skim through many events and display them either as single events or multiple. We might want to grab the infrequent PPG and scalar events separately and put them separately into the odb so we can display them by choice.

[bkatiemills]

@SmithJK querying the server until we get what we want is one way we could do it, but that's a lot of network traffic just to get one event. To your second question, the idea is to display the minute details of one single event.

@AdamGarnsworthy posting to the ODB makes a lot of sense - that's super easy to grab from. In order to fit that together with @SmithJK's suggestions of being able to see events of different varieties, each of those varieties needs to be posted to a separate key in the ODB, so I can just grab whatever is there.