Where are the OnMon files?

  • The OnMon files that have been processed through the nearline can be found in:
  • The directory structure is similar to the production directory structure (i.e. - large groups of runs together in one folder with sub-folders for each individual run.)
  • Each OnMon file contains the information from all events for every cosmic and numi trigger within one subrun.
  • We are currently processing FarDet OnMon files under the S14-02-05 release, and NearDet OnMon files under the S14-06-20 release. Note that the file name convention has changed between the S13-09-17 and the S14-02-05 release.
  • We are currently NOT processing NDOS files through OnMon.

How do I open a file with the OnMon viewer?

The BEST way to browser through an OnMon file is with the OnMon viewer (which is run as an executable from the command line.) With an offline environment setup (for best results, use the offline release that the file was produced with) execute:

onmon_viewer -f {filename} -d {detector: fardet, ndos, nd}

How are the OnMon files processed?

The OnMon files are generated as part of the nearline processing and each file represents the data from one subrun. Ten minutes after a subrun is complete (and the raw files for each trigger stream are written to disk) OnMon is run over all of the raw files for this subrun. This means that OnMon processes all events from all trigger streams together in one job. This processing is done on a dedicated machine up at Ash River and new OnMon files are transferred to FNAL every ten minutes, so the time elapsed between a subrun finishing and the OnMon files showing up at FNAL is ~20-30 minutes. For more details, see the following wiki:

How do I process my own OnMon file (or files) as the nearline does?

You shouldn't have to do this since all of the OnMon files processed through the nearline exist on disk. But in case you want to use an old release or process all subruns from a given run together or something like that, here's how you do it:

nova -c job/fdnearlineonmonjob.fcl {files}

This should give you one root file at the end that contains the OnMon histos from all the data in {files}. For NDOS or NearDet, obviously you should replace "fd" with ndos or nd in the name of the job file.

What is in an OnMon file?

The Header Object

Each OnMon file contains a header object that has useful information about the subrun processed. This header object is a TTree with the following leaves:
  • Run - meaning is obvious
  • Subrun - meaning is obvious
  • Partition - meaning is obvious (this variable is only in the OnMon files processed in releases after S13-09-17)
  • FirstEvent - the smallest event number in this subrun (not necessarily the first event)
  • LastEvent - the largest event number in this subrun (not necessarily the last event)
  • Nevents - number of events in the subrun (not necessarily equal to [LastEvent-FirstEvent+1])
  • StartYear - the year for the event with the earliest time stamp (in the S13-09-17 release, this is in ctime format i.e. 113 = 2013 A.D., in releases after S13-09-17, this will be in human readable format i.e. 2013 = 2013 A.D.)
  • StartMonth - the month for the event with the earliest time stamp (in the S13-09-17 release, this is in ctime format i.e. 0 = January, in releases after S13-09-17, this will be in human readable format i.e. 1 = January.)
  • StartDay - the day of the month for the event with the earliest time stamp (always a number between 1 and 31.)
  • StartHour - the UTC hour of the day for the event with the earliest time stamp (this is a double and is accurate to a few decimal places beyond seconds.)
  • EndYear/Month/Day/Hour - this is what you would expect, the times for the event with the largest time stamp.

Major Histograms


  • HitMaps (ADC ranges, errors/alerts, hit counts/rates, by plane and cell)
  • Trigger histos
  • counts of number of DCMs/FEBs/pixels hit vs. time

How do I convert from hitmap coordinates to DB/DCM/FEB/PIX or plane/cell?

The following link will take you to an explanation of how to read and interpret the DAQ coordinate system. Please read this section before proceeding.

If you are using the OnMon HitMaps to extract information about specific hardware, then you will need to be able to determine for a given bin in a histogram which DB/DCM/FEB/pixel the bin contents correspond to (and possibly vice versa.) But FEAR NOT! You need not reinvent the wheel as there is already a C++ object in the DAQChannelMap package that will do these conversions for you. The object is called "HardwareDisplay{.cpp,.h}" and contains functions to convert from the bin number for either a detector level or DCM level OnMon HitMap to DAQ coordinates and vice versa.

For an example of how to properly use this object, see OnlineMonitoring/producer/HitMaps.cxx Look for all the places in the code where the "fHwMap" object is used to make sure that you know how to properly initialize and setup this object.

CAUTION: To ensure that you are using the HardwareDisplay object correctly, I strongly encourage printing conversions to the screen to make sure that you are not suffering from any kind of "off-by-one" assumptions that you may not be aware of.

Why are the plots vs. UTC hour binned from -1 to 24 instead of from 0 to 24?

Any of the plots that have "VsHour" in the title are designed to be viewed in the control room zoomed in so that the most recent data is always on the far right side of the plot with only the data from the last hour being displayed. This will work fine for any time between 01:00 and 24:00 but to display the last hours worth of data for times between 00:00 and 01:00, we have to repeat the data from 23:00 to 24:00 in the bins representing -01:00 to 00:00. So to be clear, the data between -1 and 0 is a repeat of the data between 23 and 24 so that this zoom in on one hours worth of data can occur.

So if you are using the data from any of these plots, YOU MUST IGNORE THE DATA BETWEEN -1 AND 0 OR ELSE YOU WILL POTENTIALLY DOUBLE COUNT.

For example, let's say that you were trying to count how many cosmic triggers were recorded in a given subrun. You could do something like the following:

TFile file("some_onmon_file.root");
TH2F *hTriggers = (TH2F*)file.FindObjectAny("TriggerVsHourGeneral");
if( hTriggers != 0 )
     int NumberOfCosmicTriggers = hTriggers->Integral(61,1500,3,3);

This will properly count all cosmic triggers (the 3rd bin along the Y-axis) from T=0 (the 61st bin on the X-axis) to T=24 (the 1500th bin on the X-axis.)