Pushed as lp:~chris-rogers/maus/1813; now in test...

Rogers, Chris wrote:

Committed to the trunk r1014

There still seems to be something strange going on. When I now run the complete set of unit tests, I get several failures which don't appear to happen if I run the tests individually.
Output is below. The first one I looked into a bit deeper and it seems that when it's run with all the other tests, the output of the process function doesn't contain any tracks.

Current version of my branch is on https://code.launchpad.net/~jan.greis/maus/global-recon-rk

======================================================================
ERROR: Check mapper runs for mc good. Check it tracks primaries by testing
----------------------------------------------------------------------
Traceback (most recent call last):
File "/home/jan/MICE/MAUS/maus-globalrecon/build/test_MapCppSimulation.py", line 109, in test_mc_good
ev_0 = doc["mc_events"][0]["tracks"][0]
IndexError: list index out of range

======================================================================
ERROR: Test maus_cpp.Field.get_field_value(...)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/home/jan/MICE/MAUS/maus-globalrecon/build/test_maus_cpp/test_field.py", line 60, in test_get_field_value
self.assertAlmostEqual(field_value[i], 0., 1e-12)
File "/home/jan/MICE/.MAUSSTABLE/maus-v1.4.0/third_party/install/lib/python2.7/unittest/case.py", line 550, in assertAlmostEqual
if round(abs(second-first), places) 0:
TypeError: 'float' object cannot be interpreted as an index

This does not occur in the trunk. Do you think this is a field map issue?

Rogers, Chris wrote:

This does not occur in the trunk. Do you think this is a field map issue?

I'm really not sure what's going on but it seems not unlikely given where the error occurs and that it again manifests itself in missing tracks. I can try to dig a little deeper to confirm. Since these are mapper tests, I don't know how I can execute only part of the tests, so I'd have to run the entire set of unit tests every time, unless you know of a way to do a filter there as you can do with test_cpp_unit which AFAIK does not include the module tests.

Ok, it seems like I have found the culprit and it looks like this time it's my fault... Somehow the geometry isn't reset after my test_MapCppGlobalTrackMatching. I've attempted to fix this by copying some code from test_MapCppTrackerRecon that seemed to be making sure the geometry is reset (see current version of my branch) but this doesn't seem to have helped. I'm not sure what else to try. Could you have a look at my test_MapCppGlobalTrackMatching.py and see if you can tell what might be the cause for the geometry remaining set?

Fixed a few issues with my last commit and tried out a bunch of things to really force it to go back to the original configuration after running test_MapCppGlobalTrackMatching (confirmed that maus_cpp.globals.get_configuration_cards() produces a config that has the geometries set back to Test.dat), but it's still not working.

Edit: Current state is http://bazaar.launchpad.net/~jan.greis/maus/global-recon-rk/revision/837, following revisions have the offending test commented out in order to get it into the trunk

Trying to get test_MapCppGlobalTrackMatching active again the problem is rearing its head again. I have determined that it's not something in my test. It seems that running a test that sets a geometry before any of the mentioned ones results in the error.
e.g. if you run

python ${MAUS_THIRD_PARTY}/third_party/install/bin/nosetests -v ${MAUS_ROOT_DIR}/src/map/MapCppTrackerClusterRecon/test_MapCppTrackerClusterRecon.py ${MAUS_ROOT_DIR}/src/map/MapCppSimulation/test_MapCppSimulation.py --with-coverage --cover-html --cover-html-dir=${MAUS_ROOT_DIR}/doc/python_coverage --cover-inclusive