Bug #1898
Merge files script
100%
Description
Jan can't get the merge files script to work. Works for me. I do:
cr67@cr67-VirtualBox ~/MAUS/work/2016-11-25_root-join $ rm combined.root cr67@cr67-VirtualBox ~/MAUS/work/2016-11-25_root-join $ ./root_join maus_output_0.root maus_output_1.root Found 2 Files Combining, Please Wait... Combined 18 Events in Total. Found 4 Non-Data Events cr67@cr67-VirtualBox ~/MAUS/work/2016-11-25_root-join $ python check_emr_scripts/main.py Loading ROOT file combined.root Setting up data tree Getting some data... 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 ...loaded 17 spills Found 6 emr orig Info in <TCanvas::Print>: file emr_orig_x_vs_y.png has been created Found 5 tof12 space points Info in <TCanvas::Print>: file tof12.png has been created N EMR POSITRONS 0 OUT OF 6 MUONS AND 6 EVENTS TH2::TH2:0: RuntimeWarning: nbinsy is <=0 - set to nbinsy = 1 Info in <TCanvas::Print>: file emr_edep.png has been created TH2::TH2:0: RuntimeWarning: nbinsy is <=0 - set to nbinsy = 1 Info in <TCanvas::Print>: file emr_delta_time.png has been created TH2::TH2:0: RuntimeWarning: nbinsy is <=0 - set to nbinsy = 1 Info in <TCanvas::Print>: file emr_time.png has been created TH2::TH2:0: RuntimeWarning: nbinsy is <=0 - set to nbinsy = 1 Info in <TCanvas::Print>: file emr_nhits.png has been created Found 1800 primary time Info in <TCanvas::Print>: file primary_time.png has been created Finsihed
Files
Updated by Greis, Jan almost 7 years ago
With the root files you have attached it works for me. With http://gfe02.grid.hep.ph.ic.ac.uk:8301/Simulation/MCproduction/000000/000000/000019/ it doesn't. Could you check that?
Updated by Rogers, Chris almost 7 years ago
- Status changed from Closed to Open
- % Done changed from 100 to 0
What have you tried to check?
Updated by Greis, Jan almost 7 years ago
Rogers, Chris wrote:
What have you tried to check?
If I output the event types, I only get end_of_spill. I've looked into the root files with the TBrowser and the physics events appear to be there, they're just not read in by the script. I have been unable to figure out what it is that causes them to apparently be skipped by the script. I've looked into the streamer code but have not found anything that by my understanding could cause the issue.
Updated by Rogers, Chris almost 7 years ago
Look through the code and insert print statements at each branch point (say inside and just outside each if ...
statement, in the for
loops, etc). Run the code. Does it reach the outfile << fillEvent
statement? If not, where does it give up?
Updated by Greis, Jan almost 7 years ago
As I said, the issue is in this line:
if ( spill == 0 || spill->GetDaqEventType() != "physics_event" )
which evaluates to true for every spill. When spills are read in, the DaqEventType is never "physics_event", even though when looking at the ROOT file, there are events with that type in there.
Updated by Greis, Jan almost 7 years ago
- File daq_event_type.png daq_event_type.png added
See attached screencap from TBrowser
Updated by Rogers, Chris almost 7 years ago
Put a print statement in and print the spill->GetDaqEventType()
. What is the type returned here?
- Are you sure that there are no spaces or other weird characters (NULL, carriage return, ...) in the
spill->GetDaqEventType()
return value? - Are you sure that the type of
spill->GetDaqEventType()
is the same as the type of"physics_event"
? It may be better to overload them both to astd::string
. - Check that C++ std::string != operator does what you expect. You could force them to a C string and then use strcmp routine. If you aren't sure.
Updated by Greis, Jan almost 7 years ago
Output of
if (spill) {
std::cout << spill->GetDaqEventType() << "\n";
}
inserted just after line
MAUS::Spill* spill = data.GetSpill();
end_of_run
end_of_run
end_of_run
Updated by Rogers, Chris almost 7 years ago
If you print spill->GetMCEvents()->size()
and spill->GetReconEvents()->size()
what happens?
Updated by Greis, Jan almost 7 years ago
0 in every case, since the only spills registered are end_of_run spills.
Updated by Rogers, Chris almost 7 years ago
Question. What do the statements
infile >> readEvent
and
infile >> branchName( BRANCH_NAME ) >> data;
actually do?
Updated by Greis, Jan almost 7 years ago
readEvent is defined from line 102 in IRStream.cc
irstream* readEvent(irstream& irs) { if (irs.m_evtCount >= irs.m_tree->GetEntries()) { MAUS::Squeak::mout(MAUS::Squeak::info) << "Failed to find event " << irs.m_evtCount << " in file." << std::endl; return 0; } irs.m_tree->GetEntry(irs.m_evtCount); ++irs.m_evtCount; return &irs; }
branchName goes via OneArgMapic.cc:
oneArgManip<const char*>* branchName(const char* name) { return new oneArgManip<const char*>(rstream::setBranch, name); }
to line 72ff in RStream.cc:
rstream& rstream::setBranch(rstream& rs, const char* name) { strcpy(rs.m_branchName, name); return rs; }
As far as I can tell it copies a branch labelled "data" from infile into the data variable.
Updated by Rogers, Chris almost 7 years ago
Good. So the loop goes something like
readEvent
set branch name and set the data pointer
readEvent
set branch name and set the data pointer
readEvent
set branch name and set the data pointer
readEvent
set branch name and set the data pointer
until we run out of data. On the first iteration (first execution of readEvent), what is the branch name and data pointer?
Updated by Greis, Jan almost 7 years ago
BRANCH_NAME is always "data", on the first call to readEvent, data wouldn't be defined yet, because that happens two lines below. I don't understand what you're getting at, especially since the code obviously isn't fundamentally broken, otherwise it wouldn't be working with some root files...
Updated by Rogers, Chris almost 7 years ago
otherwise it wouldn't be working with some root files...
Well, let's have a think about that.
Updated by Greis, Jan almost 7 years ago
I don't see how (infile >> readEvent != 0) would depend on the state of either. Maybe I'm overlooking something obvious because I don't have a great understanding of streaming operators, but I really don't get it...
Updated by Rogers, Chris almost 7 years ago
Look up iomanip. Here you have streaming operators that manipulate the iostream (e.g. setprecision).
Now look at infile >> branchName( BRANCH_NAME ) >> data;
. It sets the branch name and data pointer.
infile >> branchName( BRANCH_NAME )
sets the branch name to BRANCH_NAME and
infile >> data
is a call to the operator
template<typename T> irstream& operator>>(T& d);
sets the pointer to data so ROOT knows what to fill. IOManipulators are one of those bits of slightly obscure C++ syntax.
Updated by Greis, Jan almost 7 years ago
- Status changed from Open to Closed
- % Done changed from 0 to 100
Right, I thought infile >> branchName( BRANCH_NAME ) >> data; was the actual operation that sends the branch to data. Placing that line above the while loop seems to work. Thank you.