Analysis Mtg 240304

From Moller Wiki
Jump to: navigation, search

Back to Main Page >> Analysis Software overview >> Analysis Meetings

previous meeting << >> following meeting

Meeting information

Agenda

  • General discussion

Minutes

Participants: R. Conaway, P. King, A. Sen, K. Paschke, Prakash, E. King, M. Gericke, J. Mammei


  • Ryan has modifying the standard JAPAN to use a new evio which allows us to analyze either CODA2 or CODA3 data files.
    • He and Paul are reviewing his changes, and the changes ought to be transportable into japan-MOLLER
  • Paul was still working on merging the fixes for the macOS compiliation from the standard JAPAN repo
    • Still not quite done with this
  • Discussion of Pull Request #11.
    • We should follow up with Ole about if we should try to fix the missing overload operator for ourselves as was mentioned in the discussion of the PR.
    • Maybe the best choice is Ole's suggestion to disable the TMapFile functionality if the CXX standard is >= 17. That would allow the use of development machines with newer ROOT versions, but still allow us to use the TMapFile with specially compiled ROOT versions to be able to test real-time displays.
  • Discussion of possible displays and analysis scripts
    • The idea is that we can use the mock-data generator and analysis to create ROOT files with the detector and monitor channels and use that data to start making plots to see what kinds of analysis and scripts we might want. This may motivate changes in the anlaysis engine that make those plots easier.
    • We should try to look back at what we looked at for Qweak, or for PREX/CREX. Paul, Ryan, and Arindam will try to look at the outputs from Qweak for next time
  • A prior question was if we thought we would need to combine helicity window and waveform-level data
    • Michael thinks it would be useful to have this
      • Michael and Bryerton had discussed that there would be some waveform samples taken in parallel with the helicity windows; such as having a few samples surrounding the spin flip
      • Kent asks how much data we might be talking about. Recall that we planned to have ~1% of the data set in the "diagnostic mode"
      • Michael thinks that from the firmware perspective it should be possible to have this data available on a per channel basis
      • Would we need to calculate asymmetries on the sample-by-sample basis?
      • Kent would want to be able to tag the waveforms to know if the plus-to-minus or minus-to-plus transitions show different intensity variations.
      • How baked-in does that need to be in the main analysis?
  • We will not have a meeting next week, but will plan to have one on the 18th