mnvnearline{1,2,3,4} Kernel Updates

  • Ed Simmonds completed Kernel Updates on mnvnearline{1,2,3,4}.
  • Used beam downtime to our advantage and stopped runcontrol during the updates.
  • All subruns right before downtime have all gates processed:
    • 16566/19
    • 16566/20
    • 16566/21
    • 16566/22 –> 24 Gates only (I stopped run on that subrun)
  • There was no failed jobs and no need for manual job submission.
  • I checked the next subrun(16567/1) via e-Checklist and it was OK

Documentation Update

  • Added two new documentation under Minerva OPS wiki
  • Update Nearline Software
  • Install a NEW Frameowk Version on Nearline System


Background Classification

Background Types

  1. QE Like
    • Events with proton, neutron, muon or anti-muon only
    • If event has another particle, it is NOT QE Like
  2. Single PiPlus
    • Events with 1 PiPlus, 0 PiMinus + other(PiZero, proton, neutron, etc…)
  3. Single PiMinus
    • Events with 0 PiPlus, 1 PiMinus + other(PiZero, proton, neutron, etc…)
  4. Multi Pion
    • Multiple Charged Pion: [N(piplus) + N(piminus)] > 1
  5. Multi PiZero
    • IF there are no charged pions [N(piplus) + N(piminus)] == 0
    • Check for Multiple Primary PiZero in the Event
  6. Other
    • If NOT any of the above

Background Branchings

  • All Background Types have the following Branches
  1. with AntiMuon
  2. with Michel
    • Check Event for the decay: (piplus to muplus) in any part of the event
  3. with Primary Pi0
    • There is a Pi0 coming from the interaction
  4. with Secondary Pi0
    • There is a Pi0 as a daughter of one of the primary particles
    • Mostly due to Charge Exchange of pions (piplus and piminus)

JobSubmission Problem – /afs/ area


  • I was having the following ERROR on the LOG file after a job submission over grid
./python: can't open file '/afs/': [Errno 2] No such file or directory


  • “/afs/” is not accesible to grid computers. Need to use “/minerva/app” instead.
  • The problem arises if I use the symbolic link User_Area to acces to “/minerva/app/users/oaltinok/cmtuser”

    oaltinok@minervagpvm01:~$ cd User_Area/
    oaltinok@minervagpvm01:User_Area$ pwd

  • Use cd $User_release_area
oaltinok@minervagpvm01:~$ cd $User_release_area 
oaltinok@minervagpvm01:cmtuser$ pwd


e-Checklist nusoft works again

  • Backup e-Checklist: 
  • Modified scripts 
  • nusoft uses NEARLINE_BLUEARC_GMPLOTTER_AREA, which needs to be under “/minerva/app” NOT under “/minerva/data”
    • NEARLINE_BLUEARC_GMPLOTTER_AREA=/minerva/app/users/nearonline/gmbrowser
  • Changes committed to CVS.
  • Manually synchronized nearline1 with the mnvonlinelogger

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


  • 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”


  • 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


  • I connected to the “” 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.


  • 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 “” 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


  • 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

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.