Bug #1060
Something fishy in MC simulation
100%
Description
Here's a funny thing - compare the test output from install_log_std (run in tracker_devel branch on test server) and test.log.
test.log is generated by running tracker_devel branch on rogers machine, note that I added some std::cerr output to print the steps.
Configuration Test
{
Dimensions 1. 1. 1. m
PropertyString Material Galactic
PropertyDouble G4StepMax 100.0 mm
Module Box
{
PropertyHep3Vector Position 0. 0. 0. mm
PropertyHep3Vector Rotation 0. 0. 0. mm
PropertyString Volume Box
PropertyHep3Vector Dimensions 10. 10. 10. cm
PropertyString Material lH2
PropertyString SensitiveDetector SpecialVirtual
}
}
The point is, in test.log, the particle starts in the liquid Hydrogen volume and steps through OK. In install_log_std the particle doesn't see the lH2 box at all and never steps through it. Must be some memory problem I guess?
Files
Related issues
Updated by Rogers, Chris over 11 years ago
I should add, the thing to look at is MAUSGeant4ManagerTest in cpp unit tests
Updated by Rogers, Chris over 11 years ago
- File valgrind.log valgrind.log added
Valgrind log attached. The only thing valgrind reports as fishy (apart from python) is the materials initialisation.
Humm, this needs sorting out anyway.
Updated by Rogers, Chris over 11 years ago
New branch submitted lp:~chris-rogers/maus/tracker_devel_g4_bug_1060
Updated by Rogers, Chris over 11 years ago
Humm, test build passed okay
http://test.mice.rl.ac.uk/job/MAUS_bug_1060/3/
Only thing I can do is fix the material bug... if it isn't within Geant4...
Updated by Rogers, Chris over 11 years ago
The valgrind error is associated with src/legacy/Simluation/fillMaterials.cc:217
a1_mt->AddProperty("RAYLEIGH", RayleighPhotE, RayleighSL,63);
(Sets Rayleigh scattering in aerogel)
Updated by Rogers, Chris over 11 years ago
Patch is to initialise RayleighPhotE[0] and RayleighSL[0] to 0.
Updated by Rogers, Chris over 11 years ago
Another feature - when I run the full tests (not using gtest_filter option) I get
==6404== Conditional jump or move depends on uninitialised value(s) ==6404== at 0xD12568C: PyObject_Free (obmalloc.c:969) ==6404== by 0xD0F4C35: code_dealloc (codeobject.c:317) ==6404== by 0xD1A91DA: PyRun_StringFlags (pythonrun.c:1347) ==6404== by 0xD17D0FD: builtin_eval (bltinmodule.c:687) ==6404== by 0xD18551C: PyEval_EvalFrameEx (ceval.c:4013) ==6404== by 0xD186CE4: PyEval_EvalCodeEx (ceval.c:3253) ==6404== by 0xD10A5EB: function_call (funcobject.c:526) ==6404== by 0xD0E27F2: PyObject_Call (abstract.c:2529) ==6404== by 0xD0EFF4E: instancemethod_call (classobject.c:2578) ==6404== by 0xD0E27F2: PyObject_Call (abstract.c:2529) ==6404== by 0xD17F666: PyEval_CallObjectWithKeywords (ceval.c:3882) ==6404== by 0xC2763E8: MAUS::MAUSEvaluator::evaluate(std::string) (MAUSEvaluator.cc:77) ==6404== ==6404== Use of uninitialised value of size 8 ==6404== at 0xD1256A4: PyObject_Free (obmalloc.c:969) ==6404== by 0xD0F4C35: code_dealloc (codeobject.c:317) ==6404== by 0xD1A91DA: PyRun_StringFlags (pythonrun.c:1347) ==6404== by 0xD17D0FD: builtin_eval (bltinmodule.c:687) ==6404== by 0xD18551C: PyEval_EvalFrameEx (ceval.c:4013) ==6404== by 0xD186CE4: PyEval_EvalCodeEx (ceval.c:3253) ==6404== by 0xD10A5EB: function_call (funcobject.c:526) ==6404== by 0xD0E27F2: PyObject_Call (abstract.c:2529) ==6404== by 0xD0EFF4E: instancemethod_call (classobject.c:2578) ==6404== by 0xD0E27F2: PyObject_Call (abstract.c:2529) ==6404== by 0xD17F666: PyEval_CallObjectWithKeywords (ceval.c:3882) ==6404== by 0xC2763E8: MAUS::MAUSEvaluator::evaluate(std::string) (MAUSEvaluator.cc:77) ==6404==
Updated by Rogers, Chris over 11 years ago
- File valgrind_2.log valgrind_2.log added
I think the things associated with evaluator are regular python valgrind hiccups (i.e. python has its own malloc functions that bypass the regular stuff and fail against valgrind). There also appears to be a problem with the way ROOT calls zlib (compression library) but I don't think there's anything we can do about that.
New valgrind log attached. There is a problem with BTSolenoid still...
Updated by Rogers, Chris over 11 years ago
- File valgrind_3.log valgrind_3.log added
Updated by Rogers, Chris over 11 years ago
I'm pretty sure that MAUSEvaluator is okay - python and valgrind are incompatible so it's hard to say (MAUSEvaluator uses python library to evaluate an expression from e.g. MiceModules).
So I cleared all of the memory issues that I could find. This is the only thing that I can imagine that could cause MAUS to behave differently on two builds with the same code on the same machine. (Note I didn't check for e.g. memory leaks). If it turns up again, I will have to dig further, but it's rather difficult to debug these transient errors. Note that we may change to Geant4.9.5 in the coming months - which will hopefully result in better behaviour from Geant4.
Updated by Rogers, Chris over 11 years ago
- Status changed from Open to Closed
- % Done changed from 0 to 100
Updated by Santos, Edward over 11 years ago
Have your changes been pushed anywhere? If they don't solve the problem, can we consider skipping this test case?
Updated by Rogers, Chris over 11 years ago
Committed to the trunk. Does it turn up a lot in the tracker branch? This is the first time I've seen this. It's a serious issue if it turns up a lot (means G4 sometimes steps in the wrong volume).
Updated by Santos, Edward over 11 years ago
Since it first happened last week, most builds in the server failed because of it. However, it rarely fails on my desktop.
Updated by Rogers, Chris over 11 years ago
- Target version changed from Future MAUS release to MAUS-v0.3.2