|Message: Re: composite_calorimeter Example Crashing During Decay Process, SubType 201 (out of the box, fresh install)||Not Logged In (login)|
Click on the Forum title, e.g. on the "Forums by Category" page, to read a sequence of postings to the Forum and its threads all in one page. If you are only interested in one thread or the thread following a specific posting, click the thread or the posting, which takes you to a smaller page, which contains only the part you are interested in and may be easier to navigate.
Messages are "chained" if there are only replies at the first level, i.e. 1/1.html, 1/1/1.html etc. In case of "chained" messages the message number is replaced by the icon and there is no indentation.
Inline: Display the subject line only or also the text of the posting(s); for the choice "All" the "Outline" choices are switched off.
|1||0||1||no text / full text of posting|
|2||1||All||text for level 1 only / text for All postings|
Outline: Choose the depth of the posting thread, successive toggle controls provide increasing detail.
|1||2||1||2 levels / 1 level (original posting)|
|2||3||2||3 levels / 2 levels|
|3||3||All||3 levels / all levels (all postings)|
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/energy 300 GeV
Please let me know if you have any ideas as to the cause, or a possible solution to this.