Bug #1913
No tracks with default v2.8.0
100%
Description
With MAUS-v2.8.0, I see no tracks, i.e. 0 tracks in either tracker in the scifi_tracks structure.
Cards, geometry, calibrations used in:
http://reco.mice.rl.ac.uk/MAUS-v2.8.0/08681_offline.tar
Files
Updated by Rajaram, Durga almost 7 years ago
The output listed above was produced by running the default driver
bin/analyze_data_offline.py
Does this have to include additional modules in 2.8.0?
Updated by Rajaram, Durga almost 7 years ago
- File check_scifi.py check_scifi.py added
The #spacepoints are the same in the 2.7.0 & the 2.8.0 outputs
So, I suspect something changed in how the reconstruction gets run now -- e.g. analyze_data_offline has to be updated -- or something is off in ConfigurationDefaults affecting the track fitting.
2.7.0: http://reco.mice.rl.ac.uk/MAUS-v2.7.0/08681_offline.tar
2.8.0: http://reco.mice.rl.ac.uk/MAUS-v2.8.0/08681_offline.tar
attached script to check #spacepoints and #tracks in the reconstructed output
Updated by Dobbs, Adam almost 7 years ago
Hi Durga,
Just had a chat with Chris Hunt, your surmise is correct,
bin/analyze_data_offline.pyneeds modifying most likely. Chris is on it, and I will do a patch release asap when the update is ready. As an aside, I have already patched 2.8 once already to account for the previous default GEANT4 download location failing.
Will keep you posted...
AD
Updated by Rajaram, Durga almost 7 years ago
- File analyze_data_offline.py analyze_data_offline.py added
From Chris Hunt:
Hi Adam, Durga, Attached is a new copy of the analyze_data_offline.py script. That should be a simple cut and paste job. I thought this was faster than going through the whole branch/merge chain. Can someone try it and let me know if that hasn't fixed the bug. Cheers Chris
Updated by Rajaram, Durga almost 7 years ago
- File reco-280.log reco-280.log added
With Chris's modified
analyze_data_offline.py, I find that reco of 8681 with v2.8.0 is ~10 times slower than with v2.7.0
This seems to be because every few events, track reco is having a hard think and eventually spits out messages like:
14:51:21.337051 TRANSFORM/MERGE/OUTPUT: Processed 678 events so far, 1 events in buffer.
Stack trace:
Traceback (most recent call last):
File "/home/mice/MAUS/.maus-v2-8-0/src/common_py/ErrorHandler.py", line 159, in HandleCppException
raise CppError(error_message)
ErrorHandler.CppError: Mass Shell condition failed at HelicalPropagator::_calculateBasePropagator()
14:51:29.650350 TRANSFORM/MERGE/OUTPUT: Processed 679 events so far, 1 events in buffer.
14:51:29.650819 TRANSFORM/MERGE/OUTPUT: Processed 680 events so far, 1 events in buffer.
14:51:29.712552 TRANSFORM/MERGE/OUTPUT: Processed 681 events so far, 1 events in buffer.
Stack trace:
Traceback (most recent call last):
File "/home/mice/MAUS/.maus-v2-8-0/src/common_py/ErrorHandler.py", line 159, in HandleCppException
raise CppError(error_message)
ErrorHandler.CppError: Mass Shell condition failed at HelicalPropagator::_calculateBasePropagator()
14:51:39.271325 TRANSFORM/MERGE/OUTPUT: Processed 682 events so far, 1 events in buffer.
14:51:39.271625 TRANSFORM/MERGE/OUTPUT: Processed 683 events so far, 1 events in buffer.
Log file of v2.8.0 reco against 8681.000 is atttached
Updated by Dobbs, Adam almost 7 years ago
Fixed it. The problem was that the exception was uncaught, so it just spiralled up the call stack, and left the programme fumbling round for how to deal with it. I now catch in the calling function, and print the exception content to the error stream. This provides more info and has fixed the speed issue. Will issue a patch release (2.8.2) asap.
Updated by Dobbs, Adam over 6 years ago
- Status changed from Open to Closed
- % Done changed from 0 to 100