Project

General

Profile

Bug #1913

No tracks with default v2.8.0

Added by Rajaram, Durga over 4 years ago. Updated over 4 years ago.

Status:
Closed
Priority:
Urgent
Assignee:
Category:
-
Target version:
-
Start date:
21 February 2017
Due date:
% Done:

100%

Estimated time:
Workflow:
New Issue

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

check_scifi.py (1.35 KB) check_scifi.py Rajaram, Durga, 21 February 2017 12:50
analyze_data_offline.py (1.67 KB) analyze_data_offline.py Rajaram, Durga, 21 February 2017 15:47
reco-280.log (449 KB) reco-280.log Rajaram, Durga, 21 February 2017 15:50
#1

Updated by Rajaram, Durga over 4 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?

#2

Updated by Rajaram, Durga over 4 years ago

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

#3

Updated by Dobbs, Adam over 4 years ago

Hi Durga,
Just had a chat with Chris Hunt, your surmise is correct,

bin/analyze_data_offline.py
needs 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

#4

Updated by Rajaram, Durga over 4 years ago

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
#5

Updated by Rajaram, Durga over 4 years ago

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

#6

Updated by Dobbs, Adam over 4 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.

#7

Updated by Dobbs, Adam over 4 years ago

  • Status changed from Open to Closed
  • % Done changed from 0 to 100

Also available in: Atom PDF