Choose timezone
Your profile timezone:
Developer's meeting
→
Europe/Zurich
present: Brett, Giovanna, Enrico, Roland, Milo, Eric, Frank
EHN1 update (Enrico):
- focusing on f/w, longer transmits possible on VC709 after FELIX f/w fix
- actual long-term limitations not yet investigated (test simply stopped after ~ a minute)
- the VC709 test used all 4 links (2 WIBs) successfully
- Enrico will build (with help from Frans) an update for the BNL711 card
- cannot use most recent WIB f/w as no data are transmitted using it
- earlier version does not have this problem, even if issues with timestamp duplication are (still) observed with it
- plan for now is to continue testing as much as we can (longer-duration tests + back-end details)
- more extensive testing possible once BNL711 f/w update in place
IEEE contribution:
- open question by Enrico on the readout window (4.8 versus 5 msec): will use 5 msec
- the plan is to read the draft once more by tomorrow evening, submit on Friday
Compression (Eric, Milo):
- Eric has now generated one MC event and re-formatted it. He and Milo are discussing details (some format updates appear to be needed)
Demonstrator (Brett):
- wirecell based study into performance of trigger primitive finding
- wirecell better than larsoft in that it uses the actual channel map and includes long-range induction effects; also the code base is relatively small
- treating 39Ar decays as low-E "signal" for now (electron E endpoint 565 keV, see e.g. https://arxiv.org/pdf/1705.05726.pdf) and noise compatible w/ MicroBooNE
- algorithm:
- dynamically keep track of each individual channel's pedestal (median signal), allowing for shifts due to (low-frequency) noise
- some concern that a non-negligible signal "contamination" could affect the computation (even if the median rather than the mean is chosen)
- threshold chosen as pedestal + cut high enough to be well below 0.1% noise probability
- dynamically keep track of each individual channel's pedestal (median signal), allowing for shifts due to (low-frequency) noise
- results seem satisfactory; also CPU time appears to be reasonable (but the measurement could be biased by caching etc.)
- further study: resampling (lower frequency), refined pedestal calculation, further parallellisation
- discussion:
- Frank: can use ring buffer experience of Roland's?
- Roland: will be interesting to share experience
- Frank: would be interesting to see to what extent h/w acceleration (e.g. AVX or AVX512, when available) can help performance.
- Brett: agree but need to get more familiar with this. Perhaps some of this is already done by Eigen3? [ This may be the case; see http://www.eigen.tuxfamily.org/index.php?title=FAQ#Vectorization ]
- Giovanna: useful but would first like to see what is possible on the algorithm front
- Giovanna: how about a hackathon (with e.g. Roland, Enrico, Milo, Eric)?
- Brett: seems useful in the somewhat longer term
- Roland: think it would be interesting
- Frank: can use ring buffer experience of Roland's?
There are minutes attached to this event.
Show them.