Message: Re: composite_calorimeter Example Crashing During Decay Process, SubType 201 (out of the box, fresh install) Not Logged In (login)
 Next-in-Thread Next-in-Thread
 Next-in-Forum Next-in-Forum

Feedback Re: composite_calorimeter Example Crashing During Decay Process, SubType 201 (out of the box, fresh install) 

Forum: Installation and Configuration
Re: Question composite_calorimeter Example Crashing During Decay Process, SubType 201 (out of the box, fresh install) (Dylan)
Re: Note Re: composite_calorimeter Example Crashing During Decay Process, SubType 201 (out of the box, fresh install) (Dylan)
Re: Warning Re: composite_calorimeter Example Crashing During Decay Process, SubType 201 (out of the box, fresh install) (Ben Morgan)
Date: 09 Jul, 2012
From: Dylan <Dylan>

Okay, I've done a complete install of Geant 4.9.5.p01 and tested with both my old user code and the completely new 'composite_calorimeter' example packaged with 4.9.5.p01.

I can confirm that the segmentation fault described above is still present, using the unmodified 'composite_calorimeter' code packaged with Geant 4.9.5.p01.

Again, my system is an iMac running OSX 10.6.8. And the bug has occurred both on this (running 4.9.3, 4.9.3.p02, the 4.9.3.p02 binaries and now 4.9.5.p01) and on a Linux system, also described above, running Geant 4.9.4.p02. That's five different setups.

I am getting a curious message output by the built-in G4 debug statements though. Around 40 or 50 lines per particle, as follows. They were not there when I ran the program on 4.9.3 and 4.9.4, so I'm guessing they're due to a new feature, or new debug statements in the 4.9.5 release:

"
G4QCaptureAtRest: wrong product12 imax= 13 Pa226[0.0] 4-mom= (-34.4136,-110.082,31.561;210498)
G4QCaptureAtRest: wrong product16 imax= 17 Pa222[0.0] 4-mom= (-82.737,-166.913,72.433;206768)
G4QCaptureAtRest: wrong product17 imax= 18 Pa221[0.0] 4-mom= (113.399,-185.094,150.325;205835)
G4QCaptureAtRest: wrong product7 imax= 8 Th231[0.0] 4-mom= (-72.03,-103.689,-86.2623;215164)
... (And so on)
"

I don't know if this output is significant or not.

The fault tends to occur quickest with 300 GeV pions (pi-) and denser absorber materials, such as Uranium or Tungsten. It does still occur with the default copper however, it just takes longer (the absorber material can be changed towards the bottom of the file "tbhcal96hcal.geom" in the directory "composite_calorimeter/geom").

Typical input to the UI at run time to produce the fault is as follows:

/gun/particle pi-
/gun/energy 300 GeV
/run/beamOn 20000

Please let me know if you have any ideas as to the cause, or a possible solution to this.

Best regards,

Dylan

 Add Message Add Message
to: "Re: composite_calorimeter Example Crashing During Decay Process, SubType 201 (out of the box, fresh install)"

 Subscribe Subscribe

This site runs SLAC HyperNews version 1.11-slac-98, derived from the original HyperNews


[ Geant 4 Home | Geant 4 HyperNews | Search | Request New Forum | Feedback ]