Project

General

Profile

Task #18483

Changes to disambiguation cheater

Added by Tingjun Yang almost 3 years ago. Updated almost 3 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Start date:
12/06/2017
Due date:
% Done:

100%

Estimated time:
Duration:

Description

CI test reported the changes to the 35t reconstructed data products:
http://dbweb5.fnal.gov:8080/LarCI/app/ns:dune/storage/docs/2017/11/30/stdout_k3i10fG.log

Tom pointed out the following change may be the cause of downstream changes:
8902: < Reco | dcheat | | art::Assns<recob::Wire,recob::Hit,void> | 603
8903: ---
8904: > Reco | dcheat | | art::Assns<recob::Wire,recob::Hit,void> | 551

This is after the changes to backtracker.

evd.twq-proj.10000001.1ref.png (16.8 KB) evd.twq-proj.10000001.1ref.png Tingjun Yang, 12/06/2017 11:15 AM
evd.twq-proj.10000001.1new.png (16.7 KB) evd.twq-proj.10000001.1new.png Tingjun Yang, 12/06/2017 11:15 AM
evd.twq-proj.10000001.1fixed.png (17 KB) evd.twq-proj.10000001.1fixed.png Tingjun Yang, 12/06/2017 03:38 PM

History

#1 Updated by Tingjun Yang almost 3 years ago

From Christoph:
@Jason:

- you can find the reference reco file here: /pnfs/dune/persistent/users/vito/ci_tests_inputfiles/DUNE35T/reco/AntiMuonCutEvents_LSU_v2_dune35t_reco_Reference.root

I don't think the output files for the CI tests are stored (please correct me if I am wrong), but you should be able to generate your own:
- the .fcl used for the CI test: https://cdcvs.fnal.gov/redmine/projects/dunetpc/repository/revisions/develop/entry/test/ci/ci_test_reco_dune35t.fcl
- reference detsim input file: /pnfs/dune/persistent/users/vito/ci_tests_inputfiles/DUNE35T/detsim/AntiMuonCutEvents_LSU_v2_dune35t_detsim_Reference.root

#2 Updated by Tingjun Yang almost 3 years ago

There are definitely hits missing in disambiguation cheater.

Note the middle plane has missing hits.

#3 Updated by Christoph Alt almost 3 years ago

I have created new reference files for DUNE 35T that include the above mentioned changes.

A copy of the old reference file can be found here: /dune/app/users/calt/AntiMuonCutEvents_LSU_v2_dune35t_reco_Reference.root

Christoph

#4 Updated by Tingjun Yang almost 3 years ago

Problem is caused by the following function in BackTracker.cxx:

  //-----------------------------------------------------------------------
  art::Ptr<sim::SimChannel> BackTracker::FindSimChannel(raw::ChannelID_t channel) const{
    art::Ptr<sim::SimChannel> chan;
    auto ilb = std::lower_bound(fSimChannels.begin(),fSimChannels.end(),channel,[](art::Ptr<sim::SimChannel> a, raw::    ChannelID_t channel) {return(a->Channel()<channel);});
    if (ilb != fSimChannels.end())
      if ( (*ilb)->Channel() == channel) {chan = *ilb;}
    if(!chan)
      throw cet::exception("BackTracker") << "No sim::SimChannel corresponding " 
        << "to channel: " << channel << "\n";
    return chan;
  }

It could not find sim::SimChannel for channel 1215. But there is signal on that channel.

#5 Updated by Tingjun Yang almost 3 years ago

The issue seems to be that the vector fSimChannels is not sorted by the channel ID.

#6 Updated by Jason Stock almost 3 years ago

Hi Tingjun,
I have one possible issue.

FindSimChannels uses a std::lower_bound to search the sim channels. I did not write a check in PrepSimChannels to make sure they are sorted when they are loaded. This is a bug, and I can put a check in this afternoon.

Another question is, do we expect the SimChannels to be sorted on retrieval (is it a bug if they make it into the event unsorted to begin with?) If so, I can make it throw whenever the SimChannels are not sorted. If that is not a bug, then I will make it sort them instead.

Edit: I see you updated the issue while I was writing this.

#7 Updated by Tingjun Yang almost 3 years ago

This is from the previous version of BackTrack_service.cc:

    // sort them by channel number.  There's a good chance they're already sorted, so check that first. 

    auto comparesclambda = [](const sim::SimChannel *a, const sim::SimChannel *b) {return(a->Channel()<b->Channel());};
    if (!std::is_sorted(fSimChannels.begin(),fSimChannels.end(),comparesclambda)) std::sort(fSimChannels.begin(),fSimChannels.end(),comparesclambda);

Yes, they should definitely be sorted.

#8 Updated by Jason Stock almost 3 years ago

  • Status changed from New to Resolved

I have updated BackTracker.tcc BackTracker::PrepSimChannels to sort the SimChannels when they are loaded into the BackTracker. This should address the bug.

#10 Updated by Tingjun Yang almost 3 years ago

  • % Done changed from 0 to 100

#11 Updated by Christoph Alt almost 3 years ago

The reference files for DUNE35T are up to date now (including Jason's fix).

#12 Updated by Tingjun Yang almost 3 years ago

  • Status changed from Resolved to Closed

Fixed in larsoft v06_59_00.



Also available in: Atom PDF