Difference between revisions of "MOLLER Analysis Software, 1 December 2017"
From Hall A Wiki
| Line 21: | Line 21: | ||
| − | Participants: | + | === Notes === |
| + | '''Participants:''' KK, Wouter, Kent, Seamus, D. Armstrong, P. K., M. Pitt, Rakitha, Dustin, Paul S. | ||
| + | |||
| + | * KK brought up two points on capabilities we'd want | ||
| + | ** We should have software alarms on various quantities | ||
| + | ** Some of the result outputs we want would be checks on the dithering responses, and checks on data quality | ||
| + | * Wouter made the point that one issue Qweak had was the partitioning of responsibility of who was to figure out how to implement different analysis tasks; was it the group of experts on a detector or subsystem or was it the software integration group | ||
| + | * We should set up a wiki page or something to collect brainstorming ideas of analysis tasks or analysis outputs we'd want | ||
| + | ** Should we just have a wiki, or use some kind of issue tracker? Seamus suggests using the JLab Redmine server as an option for issue tracking. Or use the issue tracker in github | ||
| + | * KK points out that we need to have the capability to do the analysis on both the yields and asymmetries | ||
| + | ** This raises the point of how we might implement blinding. Do we want to expose single-helicity-window quantities in a way that goes around the blinding? How do we want to handle blinding for MOLLER? Blind only ring 5, or blind everything uniformly, or... | ||
| + | * D. Armstrong asks if we wanted to use a MySQL DB as an output format. Qweak used one, but ended up making a ROOT tree from the DB for the bulk of the final analysis. A DB server may be able to handle a larger number of interleaved connections as we are filling the data into it. | ||
| + | * Some additional brainstorming suggestions | ||
| + | ** What timescales do we want to think about, and what analysis tasks/results make sense at different scales. See [https://hallaweb.jlab.org/doc-private/ShowDocument?docid=284 MOLLER DocDB 284] for some first thoughts on timescales in the experiment | ||
| + | ** Should we look at helicity-pairs in addition to the helicity multiplets? | ||
| + | ** Should we do some sort of "burst" analysis? This was a capability within the Qweak software, but it went largely unused; it may be more useful for MOLLER though. | ||
Latest revision as of 16:11, 20 January 2018
Back to MOLLER wiki main page >> MOLLER Teleconferences >> MOLLER Analysis Software Meetings
previous meeting << >> following meeting
Call-in Instructions:
BlueJeans calling instructions: Toll-Free Number (U.S.& Canada): 888-240-2560 (See https://www.bluejeans.com/numbers for alternate phone numbers) Meeting ID: 902 682 526# Meeting URL: https://bluejeans.com/902682526
Agenda:
- Summary of expected data sizes
- Discussion of needed capabilities
- Regression, dithering, feedback
- Result outputs
- Initial mockdata development
- QwAnalysis as a baseline analysis
- Possible avenues for future work
Notes
Participants: KK, Wouter, Kent, Seamus, D. Armstrong, P. K., M. Pitt, Rakitha, Dustin, Paul S.
- KK brought up two points on capabilities we'd want
- We should have software alarms on various quantities
- Some of the result outputs we want would be checks on the dithering responses, and checks on data quality
- Wouter made the point that one issue Qweak had was the partitioning of responsibility of who was to figure out how to implement different analysis tasks; was it the group of experts on a detector or subsystem or was it the software integration group
- We should set up a wiki page or something to collect brainstorming ideas of analysis tasks or analysis outputs we'd want
- Should we just have a wiki, or use some kind of issue tracker? Seamus suggests using the JLab Redmine server as an option for issue tracking. Or use the issue tracker in github
- KK points out that we need to have the capability to do the analysis on both the yields and asymmetries
- This raises the point of how we might implement blinding. Do we want to expose single-helicity-window quantities in a way that goes around the blinding? How do we want to handle blinding for MOLLER? Blind only ring 5, or blind everything uniformly, or...
- D. Armstrong asks if we wanted to use a MySQL DB as an output format. Qweak used one, but ended up making a ROOT tree from the DB for the bulk of the final analysis. A DB server may be able to handle a larger number of interleaved connections as we are filling the data into it.
- Some additional brainstorming suggestions
- What timescales do we want to think about, and what analysis tasks/results make sense at different scales. See MOLLER DocDB 284 for some first thoughts on timescales in the experiment
- Should we look at helicity-pairs in addition to the helicity multiplets?
- Should we do some sort of "burst" analysis? This was a capability within the Qweak software, but it went largely unused; it may be more useful for MOLLER though.
