Project

General

Profile

Task #21221

Add time of flight information to the event display

Added by Tingjun Yang 11 months ago. Updated 11 months ago.

Status:
New
Priority:
Normal
Assignee:
Start date:
10/23/2018
Due date:
% Done:

0%

Estimated time:
Duration:

Description

Hi David,

Would it be OK to add time of light information to the event display to help pi/p separation?

In the develop version of dunetpc, after running RunRawDecoder.fcl, beam information is saved. The following code should get time of flight:

  art::Handle< std::vector<beam::ProtoDUNEBeamEvent> > pdbeamHandle;
  std::vector< art::Ptr<beam::ProtoDUNEBeamEvent> > beaminfo;
  if (evt.getByLabel("beamevent", pdbeamHandle))
    art::fill_ptr_vector(beaminfo, pdbeamHandle);
  else{
    std::cout<<"No beam information from "<<fBeamModuleLabel<<std::endl;
  }

  double tof = -1;
  if (beaminfo.size()){
    if (beaminfo[0]->GetTimingTrigger() == 12){
      if (beaminfo[0]->CheckIsMatched()){
        //Get TOF info
        if (beaminfo[0]->GetTOFChan() != -1){//if TOFChan == -1, then there was not a successful match, if it's 0, 1, 2, or 3, then there was a good match corresponding to the different pair-wise combinations of the upstream and downstream channels
          tof = beaminfo[0]->GetTOF();
        }
      }
    }
  }

History

#1 Updated by Tingjun Yang 11 months ago

  • Assignee set to David Adams

#2 Updated by David Adams 11 months ago

Sounds like something we can add. Will require 0.5-1 day of my time.

What units does the TOF have (ns?) and what values do we expect?

#3 Updated by David Adams 11 months ago

From the talk today, I suppose we can also use the beam info to get horizontal position of the beam at the front of the TPC. That would also be very interesting to put on plots. Do you have code for that? I understand there may now have offsets.

#4 Updated by David Adams 11 months ago

I added a beam event producer with

#include "BeamEvent.fcl" 
.
.
.
  beamevent: @local::proto_beamevent
.
.
.

and now get this error:
     DeviceTypes: ERROR: Unknown data type for sequence key DeviceTypes
terminate called after throwing an instance of 'cet::coded_exception<fhicl::error, &fhicl::detail::translate[abi:cxx11]>'
  what():  ---- Type mismatch BEGIN

  Unsuccessful attempt to convert FHiCL parameter 'DeviceTypes' to type 'std::vector<fhicl::ParameterSet, std::allocator<fhicl::ParameterSet> >'.

It looks like the fcl is an array of arrays but the code expects an array of parameter sets.

I am using the head of dunetpc.

#5 Updated by David Adams 11 months ago

I see the problem is in my fcl dumper and that art can parse the file. Sorry about that.

However, I now get this error:

%MSG-s ArtException:  BeamEvent:beamevent@Construction 24-Oct-2018 13:01:49 EDT  ModuleConstruction
cet::exception caught in art
---- ServiceNotFound BEGIN
  Unable to create ServiceHandle.
  Perhaps the FHiCL configuration does not specify the necessary service?
  The class of the service is noted below...
  ---- ServiceNotFound BEGIN
    art::ServicesManager unable to find the service of type 'ifbeam_ns::IFBeam'.
  ---- ServiceNotFound END
---- ServiceNotFound END
%MSG
Art has completed and will exit with status 30.

even though I have included services_dune.fcl. From where should I take that service?

#6 Updated by David Adams 11 months ago

I followed Jake's suggestion to add "IFBeam: {}" to services. I now get this error:

%MSG-s ArtException:  PostEndJob 24-Oct-2018 13:17:19 EDT ModuleEndJob
cet::exception caught in art
---- OtherArt BEGIN
  ---- EventProcessorFailure BEGIN
    EventProcessor: an exception occurred during current event processing
    ---- ScheduleExecutionFailure BEGIN
      Path: ProcessingStopped.
      ---- ProductNotFound BEGIN
        getByLabel: Found zero products matching all criteria
        Looking for type: std::vector<raw::ctb::pdspctb>
        Looking for module label: ctbrawdecoder
        Looking for productInstanceName: daq
        cet::exception going through module BeamEvent/beamevent run: 5308 subRun: 1 event: 76
      ---- ProductNotFound END
      Exception going through path freco
    ---- ScheduleExecutionFailure END
  ---- EventProcessorFailure END
---- OtherArt END
%MSG
Art has completed and will exit with status 1.

Should I need to decode ctb info to get the beam TOF?

#7 Updated by Tingjun Yang 11 months ago

David Adams wrote:

I followed Jake's suggestion to add "IFBeam: {}" to services. I now get this error:

[...]

Should I need to decode ctb info to get the beam TOF?

Technically you don't as the time is from RDTimeStamp, but Jake's module also retrieves Cherenkov information from ctb. The module can be modified to skip it if ctb information is not available.

#8 Updated by Tingjun Yang 11 months ago

David Adams wrote:

From the talk today, I suppose we can also use the beam info to get horizontal position of the beam at the front of the TPC. That would also be very interesting to put on plots. Do you have code for that? I understand there may now have offsets.

You can find example code near the end of the wiki page:
https://wiki.dunescience.org/wiki/Look_at_ProtoDUNE_SP_data#Parsing_Beamline_Information

#9 Updated by David Adams 11 months ago

I added the CTB decoder and am now able to run. I processed 100 events in run 5308. About 40 have the beam trigger and those all have a beaminfo vector of length one but all return false for

beaminfo[0]->CheckIsMatched()

Is this what I should expect?

Above you indicate I should require this to be true.

#10 Updated by Tingjun Yang 11 months ago

David Adams wrote:

I added the CTB decoder and am now able to run. I processed 100 events in run 5308. About 40 have the beam trigger and those all have a beaminfo vector of length one but all return false for
[...]
Is this what I should expect?

Above you indicate I should require this to be true.

xroot://fndca1.fnal.gov:1094/pnfs/fnal.gov/usr/dune/tape_backed/dunepro/protodune/np04/beam/detector/None/raw/06/92/81/04/np04_raw_run005308_0001_dl1.root

#11 Updated by Jacob Calcutt 11 months ago

Tingjun Yang wrote:

David Adams wrote:

I added the CTB decoder and am now able to run. I processed 100 events in run 5308. About 40 have the beam trigger and those all have a beaminfo vector of length one but all return false for
[...]
Is this what I should expect?

Above you indicate I should require this to be true.

xroot://fndca1.fnal.gov:1094/pnfs/fnal.gov/usr/dune/tape_backed/dunepro/protodune/np04/beam/detector/None/raw/06/92/81/04/np04_raw_run005308_0001_dl1.root

[dunetpc - Task #21221] Add time of flight information to the event display
Calcutt, Jacob Michael
Hi all,

the issue is that the Spill Start stored in the decoded 'ProtoDUNETimeStamp' was invalid:

-------------------------------
Version: 3
Run: 1539611972.6997931
Spill Start: 368934881474.19104
Spill End: 368934881474.19104

Within a spill

Invalid Spill Start time! Skipping Event
-------------------------------

You can see the Spill Start and End are at some default values. See this message from Phil Rodrigues:

"the timing board reader gets the spill start and end times by reading "events" from the timing board buffer, so if the events weren't in that buffer, the board reader will use 0xff.."

We caught this happening at the beginning of the run, again from Phil:

"ok, the board reader log for that run is only showing fake triggers, and no spill start/end commands"

What's weird is that we're seeing beam triggers here, so I'm not sure what the problem is. Anyways I've asked Phil to look into it.

As to why this is a problem: The SpillStart time is used when I match between the TPC and the Beamline. I use the SpillStart timestamp recorded by the PD timing system to essentially calibrate the time difference between 'Good Particle' triggers received at the PD timing system and the Good Particle trigger timestamps recorded in the Beamline database.

However, it poses a problem when the SpillStart times are invalid for some reason (like now). The current implementation is to skip collecting the info from the database, as I wouldn't be able to match anyways. That's why you see unmatched events, but with a TimingTrigger of 12.

What I'll do now: I won't skip the event, but instead, I'll give a default spill offset. Again, this will be a problem in the case that the timing system is reset, but should be fine until then.

I'll get to work on fixing this

#12 Updated by David Adams 11 months ago

Let me know when you commit a fix. In the meantime, I may try another run. --da

#13 Updated by Jacob Calcutt 11 months ago

David Adams wrote:

Let me know when you commit a fix. In the meantime, I may try another run. --da

Hi all, Upon investigating some more, the SpillOffsets aren't exactly constant. So I don't think we can reliably try using a fixed offset to try to recover from the Spill timing issue. However, looking into this revealed some other bugs, for which I've pushed fixes to develop, so be sure to get those

- Jake



Also available in: Atom PDF