Project

General

Profile

Bug #1060

Something fishy in MC simulation

Added by Rogers, Chris almost 11 years ago. Updated almost 11 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Simulation
Target version:
Start date:
25 July 2012
Due date:
% Done:

100%

Estimated time:
Workflow:
New Issue

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

install_log_std_4_ (5.17 MB) install_log_std_4_ Rogers, Chris, 25 July 2012 11:51
test.log (49.9 KB) test.log Rogers, Chris, 25 July 2012 11:51
valgrind.log (123 KB) valgrind.log Rogers, Chris, 25 July 2012 12:24
valgrind_2.log (179 KB) valgrind_2.log Rogers, Chris, 25 July 2012 16:29
valgrind_3.log (125 KB) valgrind_3.log Rogers, Chris, 26 July 2012 08:48

Related issues

Related to MAUS - Bug #1061: aerogel materialClosedRogers, Chris25 July 2012

Actions
Related to MAUS - Bug #1062: Solenoid field map possibly writes uninitialised dataClosedRogers, Chris25 July 2012

Actions
Related to MAUS - Bug #1088: Tracker branch error messagesClosedSantos, Edward03 August 2012

Actions
#1

Updated by Rogers, Chris almost 11 years ago

I should add, the thing to look at is MAUSGeant4ManagerTest in cpp unit tests

#2

Updated by Rogers, Chris almost 11 years ago

Valgrind log attached. The only thing valgrind reports as fishy (apart from python) is the materials initialisation.

Humm, this needs sorting out anyway.

#3

Updated by Rogers, Chris almost 11 years ago

New branch submitted lp:~chris-rogers/maus/tracker_devel_g4_bug_1060

#4

Updated by Rogers, Chris almost 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...

#5

Updated by Rogers, Chris almost 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)

#6

Updated by Rogers, Chris almost 11 years ago

Patch is to initialise RayleighPhotE[0] and RayleighSL[0] to 0.

#7

Updated by Rogers, Chris almost 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== 
#8

Updated by Rogers, Chris almost 11 years ago

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...

#9

Updated by Rogers, Chris almost 11 years ago

see also #1061, #1062. I did some clean up... I just want to check the MAUSEvaluator stuff now

#10

Updated by Rogers, Chris almost 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.

#11

Updated by Rogers, Chris almost 11 years ago

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

Updated by Santos, Edward almost 11 years ago

Have your changes been pushed anywhere? If they don't solve the problem, can we consider skipping this test case?

#13

Updated by Rogers, Chris almost 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).

#14

Updated by Santos, Edward almost 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.

#15

Updated by Rogers, Chris almost 11 years ago

  • Target version changed from Future MAUS release to MAUS-v0.3.2

Also available in: Atom PDF