6 ms·

I think the title (from JPL author) is not suitable to convey the message that this piece will talk about triggering and accusation system for nuclear physics e

I think the title (from JPL author) is not suitable to convey the message that this piece will talk about triggering and accusation system for nuclear physics experiments. And I disagree with that part > But turning data collection on and off to capture individual events requires a trigger, an expensive, complicated piece of hardware with embedded software that uses specific criteria to decide when events occur during the run of an experiment. Trigger can be easily be fully software based (LHCb from LHC have that already). And actually this is exactly what JPL, get rid of hardware triggering (like usually most of the experiments do) and move it to software based. And because the pile-up is much less than say LHC experiments (and physics of interest is much narrowly defined) they could do some real-time analysis on the data. Disclaimer: I'm part of LHCb Collaboration

peteradio 3y ago
I guess you mean "acquisition"? Is LHC L1 trigger not hardware based? That was always my understanding, or has it evolved in recent years?
- elashri 3y ago
  Yes, stupid iPhone autocorrecting words. LHC experiments (CMS,ATLAS, LHCb and Alice -others) up until run 3 (started last year) used all level one hardware based trigger (FPGAs). But LHCb with run 3 is doing all the triggering on the software side [1] And yes this allows Real time analysis (RTA) to be done. Well this is quite something that was new. But also to be honest is easier to do with LHCb than its big siblings ATLAS and CMS because of higher pile-up and instantaneous luminosity. [1] https://home.cern/news/news/experiments/lhcb-begins-using-unique-approach-process-collision-data-real-time https://home.cern/news/news/experiments/lhcb-begins-using-un...
davrosthedalek 3y ago
Software defined triggers is essentially what is meant with streaming readout. I try to avoid to use this, because it confused the heck out of people in the NP community. I prefer "software data filter", I think that's more accurate anyway, as the software trigger doesn't actually trigger anything anymore (in the sense of a QDC gate, for example), but just marks which data should be passed on and which should be dropped. HEP is a lot further along on this transition, but I can tell you that virtually all NP experiments use either a standard hardware trigger, or at least a fixed latency hardware signal to readout from a (small length) digital or often analog buffer filled from a continuously converting ADC. One of the new detectors in SBS (one of the detectors in Hall A of Jefferson Lab) for example is read out with APV25 chips -- they need a fixed latency, electronic trigger signal. (Disclaimer: I was a PI of eRD23: Streaming readout for EIC)
deleted 3y ago
[deleted]
omgJustTest 3y ago
color me skeptical on whether nuclear physics systems need software triggers. At the lhc I see the benefit to broadcasting complex data and event types across many instruments. It’s my opinion that misunderstandings of captured data lead to serious science errors and I can see why ppl want to merge into software architectures some of the front end work. Imo the best thing is that one will be able to hand this over to deep learning pipelines in an easier way, however latency becomes a real issue when flowing this much data. I suspect one will return to dense fpgas for efficiency and scalability. These signal problems have true information limits and sample rates / multichannel acq will force event driven pipelines or a new hybrid architecture. Source: I do front-end detector computing in both hardware and software front-ends professionally. Event driven paradigms are vastly superior for cutting edge high resolution and multichannel systems, “software” front ends are good for inspection but streaming data may be less useful long term. Bespoke systems might be software oriented but not for more than a few deployments, or not without substantially wide applications.

peteradio 3y ago

I guess you mean "acquisition"? Is LHC L1 trigger not hardware based? That was always my understanding, or has it evolved in recent years?

elashri 3y ago
Yes, stupid iPhone autocorrecting words. LHC experiments (CMS,ATLAS, LHCb and Alice -others) up until run 3 (started last year) used all level one hardware based trigger (FPGAs). But LHCb with run 3 is doing all the triggering on the software side [1] And yes this allows Real time analysis (RTA) to be done. Well this is quite something that was new. But also to be honest is easier to do with LHCb than its big siblings ATLAS and CMS because of higher pile-up and instantaneous luminosity. [1] https://home.cern/news/news/experiments/lhcb-begins-using-unique-approach-process-collision-data-real-time https://home.cern/news/news/experiments/lhcb-begins-using-un...

davrosthedalek 3y ago

Software defined triggers is essentially what is meant with streaming readout. I try to avoid to use this, because it confused the heck out of people in the NP community. I prefer "software data filter", I think that's more accurate anyway, as the software trigger doesn't actually trigger anything anymore (in the sense of a QDC gate, for example), but just marks which data should be passed on and which should be dropped. HEP is a lot further along on this transition, but I can tell you that virtually all NP experiments use either a standard hardware trigger, or at least a fixed latency hardware signal to readout from a (small length) digital or often analog buffer filled from a continuously converting ADC. One of the new detectors in SBS (one of the detectors in Hall A of Jefferson Lab) for example is read out with APV25 chips -- they need a fixed latency, electronic trigger signal. (Disclaimer: I was a PI of eRD23: Streaming readout for EIC)

deleted 3y ago

[deleted]

omgJustTest 3y ago

color me skeptical on whether nuclear physics systems need software triggers. At the lhc I see the benefit to broadcasting complex data and event types across many instruments. It’s my opinion that misunderstandings of captured data lead to serious science errors and I can see why ppl want to merge into software architectures some of the front end work. Imo the best thing is that one will be able to hand this over to deep learning pipelines in an easier way, however latency becomes a real issue when flowing this much data. I suspect one will return to dense fpgas for efficiency and scalability. These signal problems have true information limits and sample rates / multichannel acq will force event driven pipelines or a new hybrid architecture. Source: I do front-end detector computing in both hardware and software front-ends professionally. Event driven paradigms are vastly superior for cutting edge high resolution and multichannel systems, “software” front ends are good for inspection but streaming data may be less useful long term. Bespoke systems might be software oriented but not for more than a few deployments, or not without substantially wide applications.