Bug #1813

BTFieldConstructor fails to reset properly

Added by Rogers, Chris about 8 years ago. Updated about 7 years ago.

Target version:
Start date:
26 January 2016
Due date:
% Done:


Estimated time:
New Issue


Say I have an Electromagnetic field. I try to reinitialise a magnetic-only field using Globals::SetMonteCarloMiceModules(). MAUS does not update the field maps correctly.

Geant4 likes to have a magnetic field map for doing magnetic field stepping integrators, and an electromagnetic field map for doing electromagnetic field stepping integrators. When MAUS updates from an electromagnetic field map to a magnetic field map, only the magnetic field map is reinitialised. This is because the electromagnetic field map never gets reopened because no new fields are added.


Updated by Rogers, Chris about 8 years ago

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


Updated by Rogers, Chris about 8 years ago

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

Committed to the trunk r1014


Updated by Greis, Jan about 8 years ago

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

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/", 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/", 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/", line 550, in assertAlmostEqual
if round(abs(second-first), places) 0:
TypeError: 'float' object cannot be interpreted as an index

FAIL: test maus_cpp.simulation.track_particles - good json
Traceback (most recent call last):
File "/home/jan/MICE/MAUS/maus-globalrecon/build/test_maus_cpp/", line 94, in test_track_particles_good
self.assertGreater(len(mc_out[i]["tracks"]), 0)
AssertionError: 0 not greater than 0

Updated by Rogers, Chris about 8 years ago

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


Updated by Greis, Jan about 8 years ago

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.


Updated by Greis, Jan about 8 years ago

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 and see if you can tell what might be the cause for the geometry remaining set?


Updated by Greis, Jan about 8 years ago

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, following revisions have the offending test commented out in order to get it into the trunk


Updated by Greis, Jan about 7 years ago

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/ ${MAUS_ROOT_DIR}/src/map/MapCppSimulation/ --with-coverage --cover-html --cover-html-dir=${MAUS_ROOT_DIR}/doc/python_coverage --cover-inclusive

I suppose part of the question is, whether a test should always guarantee that it leaves the environment as it found it (which I unsuccessfully tried a year ago, and as it turns out it's not just my tests that are affected) or whether it should make sure to be able to run regardless of the state it is presented with is something that has to be decided.

Also available in: Atom PDF