Bug #13306

Clarify range for ROI in recob::Wire

Added by David Adams about 3 years ago. Updated about 3 years ago.

Start date:
Due date:
% Done:


Estimated time:


Code to build ROIs for for recob::Wire can be found in dunetpc/dune/CalData/ Here is that code:

      // work out the ROI 
      recob::Wire::RegionsOfInterest_t ROIVec;
      std::vector<std::pair<unsigned int, unsigned int>> holderInfo;
      std::vector<std::pair<unsigned int, unsigned int>> rois;

      double max = 0;
      double deconNoise = sss->GetDeconNoise(channel);
      // find out all ROI
      unsigned int roiStart = 0;
      for(bin = 0; bin < dataSize; ++bin) {
        double SigVal = holder[bin];
        if (SigVal > max) max = SigVal;
        if(roiStart == 0) {
          if (SigVal > fSigThrFact*deconNoise) roiStart = bin; // n sigma above noise
          if (SigVal < deconNoise){
            rois.push_back(std::make_pair(roiStart, bin));
            roiStart = 0;
      if (roiStart!=0){
        rois.push_back(std::make_pair(roiStart, dataSize-1));
        roiStart = 0;

The range of ROI roi is (roi.first, roi.second). In the first block, the last tick with signal above threshold is roi.second-1 while in the second block, the last tick above threshold is roi.second. Is this intentional? I am making a new service to build wires and would like to effectively replace the line
            rois.push_back(std::make_pair(roiStart, bin));

            rois.push_back(std::make_pair(roiStart, bin-1));

so that all ticks in the range (roi.first, roi.second) are all above threshold.

Any objections?

Note that the ROS are later padded and merged and so we can recover my behavior by decrementing the upper pad by one. But this will look funny for no padding--one muse use a pad value of -1 to get what I expect if we don't make the above code change.

I ask this to Tinjun and Xin. Please add any other watchers you feel appropriate.

Thank you.

Related issues

Blocks dunetpc - Feature #12701: New module and services for raw data preparationClosed05/18/2016


#1 Updated by David Adams about 3 years ago

  • Blocks Feature #12701: New module and services for raw data preparation added

#2 Updated by David Adams about 3 years ago

  • Status changed from New to Closed

The problem described here presumably arises because Root deletes its list of functions (see TROOT) during cleanup (i.e. when C++ exits) and the Root cleanup is being called before the cleanup of art services. I have added a call to ArtServiceHelper::close() at the end of my main program so the ServiceRegistry is deleted before C++ cleanup. The crash no longer occurs.

I close this issue.

#3 Updated by David Adams about 3 years ago

The last comment was intended for a different Redmine issue and is not relevant here. Sorry for that.

I didn't get any comment here and so I will assume my proposal for ROI convention is accepted and leave this closed. Please reopen if not.

Also available in: Atom PDF