GENIE: Event Record

  • I have updated the package to access GENIE Event Record
  • GENIE Event Record gives very detailed information about the neutrino interaction
  • Using Event Record, I am able to do the following things
    • Access particles inside nucleus
    • Saving information for
      • Pi0
      • Pi0 Mother
      • Pi0 GrandMother
    • Creating a Final State Particle Table to see what is really going on
  • However, I am NOT using GENIE: Event Record to tag my signal.
  • Signal is defined on Final State Particles as out of Nucleus.

 

Kinematics Calculations

Event Kinematics Calculations

  • Equations Used

ss

  • Kinematics Calculations Requires:
    • Muon 4-Momentum
    • Proton Kinetic Energy
    • Pi0  Total Energy
  • Two Different Signal Categories
    • Gold: Long Proton
    • Silver1: Short Proton

Task: Select Leading Proton

Different scenarios for Proton Candidates in the Event

  • No Proton Candidate:
    • Leading Proton = Proton at Rest
  • Single Proton Candidate:
    • Leading Proton
  • Multiple Proton Candidate:
    • Leading Proton = Highest Proton Scored Candidate
  • PROBLEM: In case of 1 or more Proton Candidates
    • We can have a proton candidate with a very low score
    • I think we need a selection for selecting Leading Proton

truthIsPlausible() Update

  • truthIsPlausible() is one of the mandatory functions for MINERvA Framework
  • Recently it was updated. Here is the summary of the update:

truthIsPlausible() is now a pure virtual function of MinervaAnalysisTool, so you must implement it. It is called automatically by PhysicsEventAnalysisAlg AFTER reconstructEvent() and interpretEvent() are run. If it returns false, the event is not included in the analysis ntuple

  • I am using muonIsPlausible() which checks whether the muon prong consist of MC Hits
  • In my package, truthIsPlausible() is NOT doing anything for now
  • In future I may implement truthIsPlausible() to check proton or pi0 hits in addition to muon
  • There is no longer “Cut_Event_Not_Plausible”

Pontificia MINOS: “Permission Denied”

Problem

  • Pontificia UROC having “Permission Denied” Error when they run the commands
    • ~/opt/rms/rms service rc near
    • ~/opt/rms/rms service om near

Attempt 1

  • I suggested them to use the  “kinit” command
    • ~/opt/rms/rms kinit
  • They were already tried kinit and did not worked

Solution

  • I connected to the “minos@minos-gateway-nd.fnal.gov” and checked the “.k5login” file.
  • Their principal listed in the list but in the wrong format
    • Listed as: “Principal”
    • Correct Format: “Principal@FNAL.GOV”
  • e-mailed Stefano and other MINOS people. Stefano modified the file.

v1_06

  • Modularity Improved
  • New Analysis Parameter nProngs
    • min_nProngs = 2
    • max_nProngs = 2,3, etc… (Can be varied)
  • Options File Modified for the nProngs Parameters
  • Signal Definition is Changed!
    • Signal_Gold
      • Long Proton (KE > 120 MeV)
      • 1 Pi0 or 2x Gamma
      • No Other
    • Signal_Silver1
      • Short Proton (KE < 120 MeV)
      • 1 Pi0 or 2x Gamma
      • No Other
  • Documentation Removed: ProcessAna_Scripts.txt

Signal Definition Revised

  • tagTruth() Function uses truth information to tag an event as Signal or not
  • Information for Signal Selection
    • All information is coming from truth
    • All Final State particles are the particles coming out of nucleus.
      • 2x Gamma = 1Pi0 Decayed inside Nucleus
  • Requirements for Signal
    • Vertex in Fiducial Volume
    • CC – Neutrino Interaction
  • After the requirements we have 2 Branches
    • Signal: Gold
      • 1 Pi0 or 2xGamma
      • Long Proton (KE > 120MeV)
      • No Other Particle (neutrons and muon does not counted)
    • Signal: Silver1
      • 1 Pi0 or 2x Gamma
      • Short Proton (KE < 120 MeV)
      • No Other Particle (neutrons and muon does not counted)
  • If either of the Gold or Silver1 is TRUE, event marked as SIGNAL

GMBrowser Update – Uses all gates now

  • Previously GMBrowser that shifters look at only uses a fraction of the gates, because the early processing stages (particularly DecodeRawEvent) were slow.
  • Now that we have a faster version of DecodeRawEvent, and we modified GMBrowser to use all gates
  • Modified following parameters in NearlineCurrent.opts in Tools/DaqRecv/options on mnvonlinelogger, to be 100 percent:
    • PdstlPrescaler.PercentPass          = 25;
    • LinjcPrescaler.PercentPass          = 25;
    • NumibPrescaler.PercentPass       = 20;
  • Ran the “nearline_software_sync.sh” script in all Nearline Machines to get the update
    • mnvnearline1
    • mnvnearline2
    • mnvnearline3
    • mnvnearline4
  • Informed Current Shifter about the update and started GMBrowser at Tufts UROC
    • Will investigate the behavior for some time, until we make this change permanent.

nProngs Study

Sample 1

  • Data Folder: CCProtonPi0/MC/v1_06
  • min_nProngs = 2
  • max_nProngs = 2
  • Efficiency wrt Fiducial Events = 1.89
  • Purity = 21.88

Sample 2

  • Data Folder: CCProtonPi0/MC/v1_06/nProngs3
  • min_nProngs = 2
  • max_nProngs = 3
  • Efficiency wrt Fiducial Events = 2.46
  • Purity = 18.59

Comments:

  • Purity is very low in both cases – I was expecting an increase in Purity especially in nProngs = 2 Case
  • Signal Definition, needs to be investigated

Nearline File Management Problems

We still have problems for nearline file management and I listed the ones I found. Here is the list of folders need to be managed.

  1. Synchronize /scratch/nearonline/var/job_dump/ with /minerva/data/online_processing/swap_area/
  2. Synchronize /scratch/nearonline/var/gmplotter/plotter/ with /minerva/data/users/nearonline/gmbrowser/plotter/
  3. Synchronize /scratch/nearonline/var/gmplotter/www/ with /minerva/data/users/nearonline/gmbrowser/www/
  4. Copy Files from /scratch/nearonline/var/gmplotter/www to minerva@minerva-wbm.fnal.gov:/opt/if-wbm/htdoc/minerva/echecklist/gmb_hists

Here is the status of each section

1) I modified the script to use rsync command to sync between /scratch/nearonline/var/job_dump/ with /minerva/data/online_processing/swap_area/ For now, we have a stable synchronization between two folders however,this method copies the .log files also, which is unnecessary.

2,3) No USER “nearonline” under /minerva/data/users Setup script assigns the following export NEARLINE_BLUEARC_GMPLOTTER_AREA=/minerva/data/users/nearonline/gmbrowser There is a “nearonline” user under /minerva/app, however we should not copy any data file to the /minerva/app.

4) e-Checklist works, I conclude this section works. I did not checked the details.

We should organize a plan to solve all the problems in nearline file management. I propose the following,

  • Lets use rsync command for 1,2,3
  • We need to create a folder “/minerva/data/users/nearonline” and let other systems know where we are copying the files.
  • If there is a folder I forgot to sync between nearline and bluearc, that folder also needs to be added to the script.

Delta Resonance Study

  • Average Momentum Required to get out of Iron Nucleus  = 263 MeV
  • Q2 Distribution for All protons and Protons with Momentum  higher than 263 MeV
  •  q_sq_Imposed
  • MINERvA Threshold for successful identification of a proton is 480 MeV 
  • See Presentation in Group Meeting: 2014_10_24_DeltaResonance

v10r9p1 Job Submission

  • Job Submission uses SL6 Machines
  • Use minervagpvm01 and build every package on there
  • ./ProcessAna.py --mc --run 13200 --subrun 5 --usecat --ana_tool CCProtonPi0 --os=SL6 --inv resurrection --outdir /minerva/data/users/oaltinok/CCProtonPi0/MC/v1_06/test --opts /minerva/app/users/oaltinok/cmtuser/Minerva_v10r9p1/Tools/SystemTests/options/MCFullChain/MCAna_CCProtonPi0_Debug.opts
  • Using minervagpvm02 DOES NOT WORK

Control Room Computer Update to v10r9p1

  • Updated minerva-cr-01 and minerva-cr-02 to v10r9p1
  • Modified setupFiles for initiating setup with v10r9p1
    • tempSetup.sh
    • .bashrc
  • Modified setup.min.soft.sh for v10r9p1
    • Python was a problem for v10r9p1 setup script
    • Created an alias to use the local version python instead of Framework Version
      • alias python=”/usr/bin/python”
  • Tested and Tagged ControlRoomTools under v10r9p1 as “stable_v10r9p1″
  • Updated the .bashrc for using the setup file under v10r9p1
  • Linked .k5login with “cmtuser/Minerva_v10r9p1/Tools/ControlRoomTools/authenticate/k5login-master”
  • Updated the documentation on wiki: “Control_Room_Setup_Manual”

Software Update

  • mnvonlinelogger updated
  • Slave Nodes will receive update automatically
    • Updated Packages under cmtuser area
      • Tools/DaqRecv [croce_v3]
        • cvs co -r croce_v3 Tools/DaqRecv
    • Installed Packages under cmtuser area
      • Event/MinervaKernel [croce_v3]
        • This package required for Event/MinervaEvent
        • getpack -u Event/MinervaKernel
      • Event/MinervaEvent [croce_v3]
        • cvs co -r croce_v3 Event/MinervaEvent
    • Built All Packages in the following order
      1. Tools/DaqRecv
      2. Event/MinervaKernel
      3. Event/MinervaEvent
    • Building Commands:
      • cmt config
      • cmt make
      • source setup.sh

Problem after restarting Nearline Machines

Problem:

The automated “nearline_bluearc_copy.sh” script on mnvnearline1 fails to copy necessary files from local_dump_area to online_processing/swap_area
(from /scratch/nearonline/var/job_dump to /minerva/data/online_processing/swap_area)

Investigations:

  • Investigating mnvnearline1:scripts/nearline_bluearc_copy.sh
  • Script runs automatically every 5 minutes.
  • Log file for the script: /scratch/var/nearonline/logs
  • Local copy from HEAD to following folders WORKS
    • NEARLINE_DUMP_AREA /scratch/nearonline/var/job_dump
    • NEARLINE_LOCAL_GMPLOTTER_LOCATION /scratch/nearonline/var/gmplotter
  • The problem is with the python script “filechecklist.py”
  • It does not generate the file list for files from the following folders:
    • $NEARLINE_DUMP_AREA
    • $NEARLINE_LOCAL_GMPLOTTER_LOCATION/plotter
  • It works for the following folder
    • $NEARLINE_LOCAL_GMPLOTTER_LOCATION/www
  • Since there is no file list generated by the python script “filechecklist.py”, NO files copied to the swap_area

Temporary Solution:

  • I modified the script to use rsync command.
    • Now it synchronizes the local_dump_area and online_processing/swap_area
  • Inside the script Jeremy notes that, “using rsync for this stage incurs a lot of overhead on the BlueArc disk”, therefor,  he writes a more efficient script “filechecklist.py” for this task

 Permanent Solution:

  • The Problem is confirmed.
    •  .fileindex under /scratch/nearonline/var/job_dump got corrupted and causing “file checklist.py” to crash for that folder
  • Using rsync manually fixed the .fileindex
  • Software sync between mnvonlinelogger and mnvnearline1 updates the nearline_bluearc_copy.sh script to the original version
  • Now everything works as before. The near ine_bluearc_copy.sh script copies the changed files to bluearc area using “file checklist.py”

 

GMBrowser Problem

  • GMBrowser Live works but shifter can not access to the previous runs and subruns
    • GMBrowser -r xx -s xxx does not work
  • The files are not copied automatically to the /minerva/data/online_processing/swap_area
  • I copied the files manually:
    • Connect to the mnvnearline1 – it has the BlueArc /minerva/ mount
    • Necessary files located: /scratch/nearonline/var/job_dumb
  • This solved the issue for non copied files.
  • I checked the log file for nearline_bluearc_copy.sh script under /scratch/nearonline/var/logs
    • After sometime the auto-script seems to be working.
  • Currently, we are not running any runs, I will check the status again tomorrow