Forum: Fast Simulation, Transportation & Others Not Logged In (login)
Show subscribers

Several topics are included in this forum: fast simulation as implemented by parameterized showers, methods of particle transport, and topics not covered by the other physics fora.

The email gateway for this forum is: fastsim-g4hn@slac.stanford.edu


Inline Depth:
 0 0
 1 1
Add message: (add)

None Multi-scattering and parallel world transportation problem?  by Sergio Losilla <Sergio Losilla>,   Apr 26, 02:48
NOTE: This issue was originally posted under "Hits, Digitization and Pileup", but after personal discussion with Makoto Asai and Vladimir Ivanchenko I am reposting it here. For reference, this is the original post:

http://hypernews.slac.stanford.edu/HyperNews/geant4/get/hitsdigits/333.html

---------------------------------------------------------------

Hi,

I have a very simple setup: Material world: a large cube of air containing a water cylinder. Parallel world: a box around the water cylinder, with a sensitive detector attached. I verified that there were no overlaps.

What I have observed, is that every now and then (1 in 1e6-1e7 events?) ProcessHits is triggered for the detector, but both PreStepPoint and PostStepPoint are outside of the parallel world box. This happens only for electrons, and the processes are always multi-scattering and ionization. The first of these steps is always a jump from inside the box to the outside.

Is this a bug? Maybe multi-scattering and parallel world transportation are not getting along?

Sergio Losilla

Question Error at boundary  by Mikhail <Mikhail>,   17 Mar, 2018
Hi!

I faced to a strange thing while simulating particle propagation through water slab (z axe is perpendicular to slab). Sometimes particle passes through the boundary in a wrong way (pre and post points are different) and on the next step it is pushed back with transportation process. The kinetic energy is around 1 MeV.

As I understand particle should reach the boundary at the first step, placed to the same point in another volume on the second step, and the then propagate in new volume on next steps.

Here is an example. Particle pass the boundary and change momentum direction along Z to opposite. By the way in backward direction it is transported in correct way(

run prepoint tName e- tID 15 stepNum 4 procName msc preVol water_slab_PV pEnergy 0.660823 x -0.880212 y 0.0969188 z 0.0402352 Mx -0.723382 My 0.613168 Mz 0.461292

run postpoint tName e- tID 15 stepNum 4 procName Transportation postVol World_PV pEnergy 0.58421 x -0.880505 y 0.0971674 z 0.0404222 Mx -0.697791 My 0.610063 Mz -0.281555

run prepoint tName e- tID 15 stepNum 5 procName Transportation preVol World_PV pEnergy 0.58421 x -0.880505 y 0.0971674 z 0.0404222 Mx -0.697791 My 0.610063 Mz -0.281555

run postpoint tName e- tID 15 stepNum 5 procName Transportation postVol water_slab_PV pEnergy 0.58421 x -0.880505 y 0.0971674 z 0.0404222 Mx -0.697791 My 0.610063 Mz -0.281555

Is my situation a bug or not and what should I do?

Is it correct to set momentum direction in next volume manually like step -> GetTrack()->SetMomentumDirection(step -> GetPreStepPoint()-> GetMomentum()); ?

Or I should apply TrackingAction and AppendStep() ? Buy the way, I appreciate if one can share an example of adding point to the track))

Hope for your suggestions! Mike

*Please correct me if I posted in wrong thread

None Missing de-excitation for *Bi210 in version 10.3.p01  by Alexis Brosssard <Alexis Brosssard>,   13 Jul, 2017
Hello,

I am simulating Pb 210 decay in copper. The decay produce Bi 210 with excited energy of 46.5 keV. The de-excitation occurs by emission of gamma or auger electron. The branching ratio for emission of one 46.5 keV gamma is 4%. These gammas were well simulated in the previous version 10.2.p03 but not in the new version 10.3.p01.

The spectrums with the two different versions are attached, 10_2.png for version 10.2.p03 and 10_3.png for version 10.3.p01. Each simulation was 10k decay of Pb 210. X axis in keV

Regards,

   Attachment:
      http://hypernews.slac.stanford.edu/HyperNews/geant4/get/AUX/2017/07/13/12.54-78732-10_3.png
      http://hypernews.slac.stanford.edu/HyperNews/geant4/get/AUX/2017/07/13/12.54-29530-10_2.png

None Re: Missing de-excitation for *Bi210 in version 10.3.p01  by michel maire <michel maire>,   25 Jul, 2017
Re: None Missing de-excitation for *Bi210 in version 10.3.p01 (Alexis Brosssard)
On Thu, 13 Jul 2017 20:00:47 GMT, Alexis Brosssard wrote:
> Hello,
> 
> I am simulating Pb 210 decay in copper. The decay produce Bi 210 with
> excited energy of 46.5 keV. The de-excitation occurs by emission of
> gamma or auger electron. The branching ratio for emission of one 46.5
> keV gamma is 4%. These gammas were well simulated in the previous
> version 10.2.p03 but not in the new version 10.3.p01.
> 
> The spectrums with the two different versions are attached, 10_2.png for
> version 10.2.p03 and 10_3.png for version 10.3.p01. Each simulation was
> 10k decay of Pb 210. X axis in keV

 Here an output of rdecay01 for Geant4 10.3-ref-06 (also 10.4-beta)
 As you can see, the 4.5% of gamma (46.54 keV) are present.

   Attachment:
      http://hypernews.slac.stanford.edu/HyperNews/geant4/get/AUX/2017/07/25/04.07-33407-Bi210.txt

Question Small energy deposition in vacuum at parallel world boundaries  by Nicholas Kinnaird <Nicholas Kinnaird>,   03 May, 2017
Hi, I'm seeing a bug in the geant simulation where occasionally (every ~20/30 events) particle steps in vacuum geometry are ended with the physics processes of ionization or bremsstrahlung, depositing a very small (~=0) amount of energy in the vacuum. This problem seems to occur at boundaries of parallel world geometry, and disappears if the parallel world is removed.

I'm not so concerned with the small number energy dep since I imagine geant probably just calculates some very small value from the vacuum material, but I am very surprised that steps are being halted by ionization or bremsstrahlung processes instead of transportation/coupled transportation/parallel world processes/step limiter, etc.

Attached are a couple of pics showing the issue, in two a histogram of post process ids which halted steps within the simulation, including processes ionization (one zoomed out and one zoomed in - 2 is ionization, the rest are transportation, etc.), and the other some output showing a single ionization event even though vacuum is the material the step is contained within.

Has anyone seen something like this before? Is this expected behavior at all?

geant version: v4_10_2_p02a

   Attachment:

      http://hypernews.slac.stanford.edu/HyperNews/geant4/get/AUX/2017/05/03/13.31-36490-vacenergydep.png
      http://hypernews.slac.stanford.edu/HyperNews/geant4/get/AUX/2017/05/03/14.04-9444-postProcessAll.png
      http://hypernews.slac.stanford.edu/HyperNews/geant4/get/AUX/2017/05/03/14.04-95252-postProcessIon.png

Question Why did my Method not Work  by Sahra <Sahra>,   10 Feb, 2017
Hi, this is mostly a question of why my particular technique in finding area cross-sections and attenuation coefficients of materials in Geant4 did not work.

I currently understand that Extended Example 'TestEm13' is the main example provided by Geant4 to enable you to find the cross-section/attenuation coefficients of different materials, which was my original project, and now understand how to use that.

However, before i came across this example, i had come up with a particular method of finding the initial and transmitted gamma photon intensities through lead, by placing a slice of lead in a envelope, a particle gun on the edge of the envelope so that it shoots perpendicular to the slice of lead, and a box_mesh/scorer on the other side of the lead.

I set my own initial intensity of gamma photons, say 10,000, and the scorer/box_mesh which i implemented via commands, would 'count' or 'score the gammas that made it through the lead, onto the scorer/box_mesh.

The scorer would only count gamma photons making it on to the scorer via. 'FlatSurfaceCurrent' which is a method to count particles injecting the surface of the scorer without taking into account the angle at which the photon hits it.

I get good values in an external text file i created like, 9064/10,000 particles were counted, but when i start building up data of thickness of lead (which i change manually in between events and then re-build the application again) against the decreasing number of photons detected, i get an attenuation coefficient value that is not equal to the actual value I am meant to get.

What have i done wrong or understood wrong? - My envelope and world volumes are both as close to vacuum as you can get. - My detector is the Geant4 default lead material of varying thickness. - My scorer is a simple box mesh, divided into 50 by 50 bins i.e. (50,50,0).

I really wish to understand how to use Geant4 to a really good level, so I would appreciate any and all feedback on this, thank you for helping.

Sahra

None Re: Why did my Method not Work  by michel maire <michel maire>,   10 Feb, 2017
Re: Question Why did my Method not Work (Sahra)
On Fri, 10 Feb 2017 10:10:38 GMT, Sahra wrote:
> Hi, this is mostly a question of why my particular technique in finding
> area cross-sections and attenuation coefficients of materials in Geant4
> did not work.
> 
> I currently understand that Extended Example 'TestEm13' is the main
> example provided by Geant4 to enable you to find the
> cross-section/attenuation coefficients of different materials, which was
> my original project, and now understand how to use that.
> 
> However, before i came across this example, i had come up with a
> particular method of finding the initial and transmitted gamma photon
> intensities through lead, by placing a slice of lead in a envelope, a
> particle gun on the edge of the envelope so that it shoots perpendicular
> to the slice of lead, and a box_mesh/scorer on the other side of the
> lead.
> 
> I set my own initial intensity of gamma photons, say 10,000, and the
> scorer/box_mesh which i implemented via commands, would 'count' or
> 'score the gammas that made it through the lead, onto the
> scorer/box_mesh.
> 
> The scorer would only count gamma photons making it on to the scorer
> via. 'FlatSurfaceCurrent' which is a method to count particles injecting
> the surface of the scorer without taking into account the angle at which
> the photon hits it.
> 
> I get good values in an external text file i created like, 9064/10,000
> particles were counted, but when i start building up data of thickness
> of lead (which i change manually in between events and then re-build the
> application again) against the decreasing number of photons detected, i
> get an attenuation coefficient value that is not equal to the actual
> value I am meant to get.
> 
> What have i done wrong or understood wrong? - My envelope and world
> volumes are both as close to vacuum as you can get. - My detector is the
> Geant4 default lead material of varying thickness. - My scorer is a
> simple box mesh, divided into 50 by 50 bins i.e. (50,50,0).
> 
> I really wish to understand how to use Geant4 to a really good level, so
> I would appreciate any and all feedback on this, thank you for helping.
> 
> Sahra
> 

 1- To compute cross sections from transmitted particles, you must count the unaltered beam, e.g. the incident particles which have not interact.
  Incident gammas which suffer a Compton interaction are scattered and can be transmitted. They must not be counted.
  To better understand what I mean, I invite you to run TestEm5 interactively with the attached macro.

 2- Another method to evaluate cross sections is illustrated TestEm14. From the computing point of view, this approach is much more efficient.

   Attachment:
      http://hypernews.slac.stanford.edu/HyperNews/geant4/get/AUX/2017/02/10/07.27-27209-sahra.mac.txt

None Re: Why did my Method not Work  by Sahra <Sahra>,   13 Feb, 2017
Re: None Re: Why did my Method not Work (michel maire)
Hi Michel,

  Thank you very much for your reply. I've had a look at TestEm5 and 14, and i was looking more specifically at how they sifted or were able to count the unaltered beam i.e number of gammas that hadn't reacted, for example any functions that has been used or lines of code in general, so i could add them to my program, and it was quiet difficult to narrow down.

Sahra

Question How to not track particles below a specified energy or of a specified particle species  by <adamrouh>,   19 Jan, 2017
I need to know a way to have my simulation not track particles below some energy threshold. I am using the physics in example Hadr03, and elastic collisions of a neutron creates many protons, and these protons are transported by a few angstroms, as shown in the attachment. I do not care about these protons and would like to somehow ignore them for computational efficiency purposes only.

I would also like to somehow ignore particles of some specified species. Sometimes a neutron at a high enough energy will produce photons somewhere in my simulation. I do not care about these photons and would like to somehow ignore them as well.

   Attachment:
      http://hypernews.slac.stanford.edu/HyperNews/geant4/get/AUX/2017/01/19/09.20-85848-65protons.png

None Re: How to not track particles below a specified energy or of a specified particle species  by Michael H. Kelsey <Michael H. Kelsey>,   19 Jan, 2017
Re: Question How to not track particles below a specified energy or of a specified particle species
On Thu, 19 Jan 2017 17:21:32 GMT, adamrouh wrote:
> I need to know a way to have my simulation not track particles below
> some energy threshold.

The most generic way to do this would be for you to implement a stepping action. In that action you can write whatever code you want to kill tracks by your desired criteria.

You may also choose to add StepLimiterPhysics to your physics list. You can then instantiate a G4UserLimits object and attach it to the world volume, setting a non-zero "ekinMin" value. This method is limited to the specific cuts available in G4UserLimits, but it does mean less coding.

> I would also like to somehow ignore particles of some specified species.
> Sometimes a neutron at a high enough energy will produce photons
> somewhere in my simulation. I do not care about these photons and would
> like to somehow ignore them as well.

You can turn off photon production by setting the photon "production cut" in your physics list to a very large value (larger than your beam energy). In that case, instead of creating photons that get tracked, Geant4 will assign their energy to the "energy deposit" value for the step.

If you want to do something more general (where you can specify other particle species than photons, for example), you should write a stacking action.

  -- Michael Kelsey

Question Re: How to not track particles below a specified energy or of a specified particle species  by Beatriz Tapia <Beatriz Tapia>,   31 Jan, 2017
Re: None Re: How to not track particles below a specified energy or of a specified particle species (Michael H. Kelsey)
Hi!

We were trying to do what you describe as a second option:

You can turn off photon production by setting the photon "production cut" in your physics list to a very large value (larger than your beam energy). In that case, instead of creating photons that get tracked, Geant4 will assign their energy to the "energy deposit" value for the step.

But it did not work out. We still get opticalphotons when we run our macro with /tracking/verbose 2. We are using the LXe example of Geant4 and added a few lines to the PhysicsList.cc file:

void LXePhysicsList::SetCuts(){
  //  " G4VUserPhysicsList::SetCutsWithDefault" method sets
  //   the default cut value for all particle types
  //SetCutsWithDefault();
  SetCutValue(1000000000000000000000000*m, "opticalphoton");
  SetCutValue(1000000000000000000000000*m, "e-");
  SetCutValue(1000000000000000000000000*m, "e+");
}

I attach the whole PhysicsList.cc file. Is there something else we would have to change to not track the opticalphotons our simulation is creating?

Thank you, Bea

   Attachment:
      http://hypernews.slac.stanford.edu/HyperNews/geant4/get/AUX/2017/01/31/15.35-31660-LXePhysicsList.cc

Disagree Re: How to not track particles below a specified energy or of a specified particle species  by Michael H. Kelsey <Michael H. Kelsey>,   31 Jan, 2017
Re: Question Re: How to not track particles below a specified energy or of a specified particle species (Beatriz Tapia)
On Tue, 31 Jan 2017 23:37:52 GMT, Beatriz Tapia wrote:
> void LXePhysicsList::SetCuts(){
>   //  " G4VUserPhysicsList::SetCutsWithDefault" method sets
>   //   the default cut value for all particle types
>   //SetCutsWithDefault();
>   SetCutValue(1000000000000000000000000*m, "opticalphoton");

This line isn't correct. The productions cuts apply to gammas, e+, e-, and protons (the "proton" cut value is also used for nuclei).

If you want to prevent the production of optical photons, then you shouldn't have optical physics enabled in your physics list. The simplest solution for your case is to just remove the if-opticalphoton block from your physics list construction.

If you were using one of the Geant4 reference physics lists (QGSP_BERT, Shielding, etc.), then you would have to add optical physics explicitly anyway, which would make it easy to remove.

  -- Micahel Kelsey

Question how to feed Geant4 with a 2D energy spectrum as input souce   by Maura E.M. <Maura E.M.>,   10 Oct, 2016
I have set up a simulation that includes only the electron source and the target. I have scored an N-Tuple collecting all gammas (Bremsstrahlung & Compton) on a spherical surface surrounding both the Target and the electron source. Using MatLab I have binned the photons by Energy and by the azimuthal angle Phi. The resulting histogram is 2D. There is a Phi dependence. My question is: How can I feed Geant4 with a 2D spectrum as input source ? If that is not possible I will have to integrate with respect to Phi. Thank you in advance for any suggestion. Regards, Mauede

   Attachment:
      http://hypernews.slac.stanford.edu/HyperNews/geant4/get/AUX/2016/10/10/13.29-60712-eV_3D_PhotonHistogram.jpg

Question documentation about multiple scattering  by Anthony LaTorre <Anthony LaTorre>,   03 Jun, 2016
In section 6.1.4 of the Physics Reference Manual it talks about how the angular distribution after multiple scattering is calculated. It introduces a model parameter \mu_0 but doesn't clearly explain what it is.

Does \mu_0 represent a hard cutoff for the functions g_1 and g_2, i.e.

g_1(u) = C_1 exp(-a*(1-u)) if u >= u_0 *otherwise* 0
g_2(u) = c_2 1/(b-u)**2    if u <= u_0 *otherwise* 0

?
Warning Memory corruption when dealing with electromagnetic fields  by Jan C. Bernauer <Jan C. Bernauer>,   05 May, 2016
It seems some function expect GetFieldValue to only write 3 doubles to the caller-provided pointer. Indeed some, for example user-defined electro-magnetic field classes write 6. This leads to memory corruption.

Attached is a patch which extends the caller provided arrays to be at least 6 entries long.

In general, the handling of that calling interface seems fishy. I haven't looked into this too carefully, but it seems that some classes only write 3 doubles. Which means the other 3 might be random, if the caller does not set them to zero.

   Attachment:
      http://hypernews.slac.stanford.edu/HyperNews/geant4/get/AUX/2016/05/05/09.56-34930-fieldpatch.patch

Question low-energy tracks incorrectly stopped  by Tom Roberts <Tom Roberts>,   28 Nov, 2015
If I shoot mu+ with momentum 0.01 MeV/c, they are stopped at the end of the first step and decay there. e+ with momentum 0.001 MeV/c are stopped at the end of the first step and annihilate there (in Vacuum!). Higher-energy particles do not do this.

I need to track such low-energy particles. How can I change this?

This is geant4-10-01-patch-01. I'm pretty sure this did not happen in 9.6 or earlier.

None Re: low-energy tracks incorrectly stopped  by Tom Roberts <Tom Roberts>,   30 Nov, 2015
Re: Question low-energy tracks incorrectly stopped (Tom Roberts)
I went back and tried this using Geant4 9.5.p01, with the same results (mu+ with KE ~ 1eV has its status set to fStopButAlive at the end of the first step, regardless of which process limited the step). I mistakenly thought I had used such slow muons with previous versions; they actually had KE ~ 100 eV or more and did not do this.

In the Geant4 code I found a test that does set track Status to fStopButAlive for KE < 10*eV, but it is in a hadronic process (G4hImpactIonization). I'm still stumped where this is happening for mu+. Does anybody know?

Note that Geant4 has no hope of simulating the generation of these very slow muons [#], so in the Geant4 simulation I have to inject them as initial "beam" particles. I now have a work-around: inject them inside a volume with material=Vacuum, and set the maxStep in that volume to be larger than its size. When the muon leaves that volume, it will be stopped right at the boundary, rather than penetrating a few nanometers into the other material -- I can live with this. The only limit is that I must not have any Vacuum/Vacuum boundaries.

[#] it is really muonium, and the beam is generated via its chemical potential in superfluid He.

Idea Re: low-energy tracks incorrectly stopped  by Vladimir Ivanchenko <Vladimir Ivanchenko>,   04 Jan, 2016
Re: None Re: low-energy tracks incorrectly stopped (Tom Roberts)
Hello all,

this situation with low-energy transport is known. In previous versions of Genat4 our recommendations were to use custom Physics Lists when ionization and elastic scattering processes should be configured with all low-energy limits significantly reduced. The reason of these low-energy limits was top provide effective tracking of low-energy particles in all circumstances (including LHC experiments). 

With Geant4 10.2 (December 2015) we change our approach. Now it is possible to use standard Physics Lists for your type of simulation. In each Physics Lists there are two parameters: lowest energy of e+- and muons/hadrons. You can change (or vanish) these parameters via UI commands:

/process/em/lowestElectronEnergy 0.001 MeV
/process/em/lowestMuHadEnergy        0 MeV

Please, try out 10.2 and report any problem.

VI

None Re: low-energy tracks incorrectly stopped  by Artem Zontikov <Artem Zontikov>,   28 Nov, 2015
Re: Question low-energy tracks incorrectly stopped (Tom Roberts)
Vacuum material ("G4_Galactic") still has non-zero density so the first step of e+ is limited with annihilation process.

None Re: low-energy tracks incorrectly stopped  by Tom Roberts <Tom Roberts>,   28 Nov, 2015
Re: None Re: low-energy tracks incorrectly stopped (Artem Zontikov)
It is true that Vacuum (=G4_Galactic) has non-zero density, but that is not the problem (if it were, high-energy tracks would also do this; they don't). The track is stopped right at the end of the first step (presumably track->status set to fStopButAlive). Stopped mu+ decay, and stopped e+ annihilate.

My code puts a StepLimiter process onto every particle, and no matter what value I give it this happens at the end of the first step. As this happens when the limiting process is either StepLimiter or Transportation (reached a boundary), I conclude this is done somewhere in the stepping code, not in any process.

My code never sets track-status to fStopButAlive, so I need to know where in the Geant4 tracking code that this has been added, and how I can avoid it. Presumably there is a test on kinetic energy or velocity, as higher-energy tracks do not do this.

I would also like to understand why this was done....

None Re: low-energy tracks incorrectly stopped  by Artem Zontikov <Artem Zontikov>,   29 Nov, 2015
Re: None Re: low-energy tracks incorrectly stopped (Tom Roberts)
I think the only active processes for e+ with given momentum (0.001 MeV/c) are transportation and annihilation, same for mu+ with 0.01 MeV/c - only transportation and decay. You can check physics list output for other processes (i.e. ionisation and multiple scattering). I bet you find that its cross sections are tabulated from ~100 eV while the kinetic energy of the particles you interested in is surely less than 1 eV.

Question Energy loss in Tranport  by Vitaliy Ziskin <Vitaliy Ziskin>,   07 Oct, 2015
Hello, I'm trying to track very (very) low energy electrons in a thing material. When doing this I'm observing that some electrons lose their energy during Transportation (see print out from tracking below). Is this because I'm going below the valid simulation range (10 eV in LivermoreIonization)? The code claims that Transportation should maintain the energy of the transported particle.

Your help is appreciated.

Thanks, Vitaliy

*********************************************************************************************************
* G4Track Information:   Particle = e-,   Track ID = 2,   Parent ID = 1
*********************************************************************************************************

Step#      X         Y         Z        KineE    dEStep   StepLeng  TrakLeng    Volume     Process
    0   37.5 nm   18.9 nm  -2.23 nm   10.6 eV      0 eV      0 fm      0 fm     Device   initStep
    1     50 nm   13.7 nm   12.5 nm   8.71 eV   1.88 eV   23.2 nm   23.2 nm     Device          msc
    2    292 nm   -147 nm   -250 nm      0 eV   8.71 eV    391 nm    414 nm     Device   Transportation

*********************************************************************************************************
* G4Track Information:   Particle = e-,   Track ID = 12,   Parent ID = 4
*********************************************************************************************************

Step#      X         Y         Z        KineE    dEStep   StepLeng  TrakLeng    Volume     Process
    0   34.3 nm     12 nm   34.8 nm   11.9 eV      0 eV      0 fm      0 fm     Device   initStep
    1   34.7 nm   10.3 nm   36.4 nm   7.52 eV   4.43 eV    3.6 nm    3.6 nm     Device        eIoni
    2   -211 nm    152 nm    250 nm      0 eV   7.52 eV    355 nm    359 nm     Device   Transportation

Idea Re: Energy loss in Tranport  by Vladimir Ivanchenko <Vladimir Ivanchenko>,   04 Jan, 2016
Re: Question Energy loss in Tranport (Vitaliy Ziskin)
Hello,

sorry for the late reply but you choose not optimal forum to make the post. This question has nothing to do with fast simulation and transportation. EM physics is responsible for energy loss, so such posts should be made in the emprocess forum. There are also answers to similar questions in this forum.

When you study "/tracking/verbose n" output you can see a name of the process, which is responsible for this step length. At this step several other processes are active (it is normal in Geant4). Ionisation process is responsible for energy loss at each step independently of what process limit the step.

VI

None G4Transportation and dynamic charge and mass  by Francois Mauger <Francois Mauger>,   27 Aug, 2015
Hi

I use G4.9.6.

I'm interesting in tracking low energy Li6(2+) ions in vacuum with 
electric RF field.
(this was done previously through SIMION but out group want to integrate 
the full MC response
within the only G4 tool, using a detailed geometry).
I have carefully read the G4 source code and what I understand is
that I can pass the effective charge (2+) from my primary generator 
typically with:

<pre>
 
_particle_gun_->GSetParticleDefinition(4ParticleTable::GetParticleTable()->GetIon(3, 
6, 0));
  _particle_gun_->SetParticleCharge(2 * CLHEP::eplus);
  _particle_gun_->SetMomentum({the proper kinematics from some Li6(1+) 
beta decay generator});
</pre>

thanks to this, the underlying G4PrimaryTransformer object should
fill some atomic shell (only the K shell, whatever the number of atomic 
electrons is!)
of the G4ElectronOccupancy instance in the G4DynamicParticle
The G4ElectronOccupancy::AddElectron also takes care of updating the 
ion's dynamic charge
and mass (well, neglecting electron binding energy, but I don't care...).

At this stage, the primary event is ready to be tracked, taking into 
account the realistic
charge state of the Li6 recoil ion.

Now I need to transport the ion in the geometry (mainly vacuum but with 
E field everywhere)
together with the beta particle emitted simultaneously from my home-made 
decay.
The G4Transportation class seems to be the responsible of this task.

In the G4Transportation::AlongStepGetPhysicalInteractionLength method, any
dynamic particle is fetched form the processed G4Track.
The dynamic charge is extracted, as well as the magnetic moment
and *rest* mass ( ParticleDef->GetPDGMass()), NOT the dynamic mass.

Following the same scheme, the fFieldPropagator is given (through 
SetChargeMomentumMass):
  - dynamic charge
  - momentum mag
  - rest mass!!!

Q1: Why not using the dynamic mass here ? should this be fixed ?

of course I guess the only possible annoying case is for ions with 
special charge state
and the correction on the realistic mass is generally tiny (~ n(e-) * 
511 keV vs ~ A(ion) * GeV)...

G4FieldTrack object is also created with rest mass and charge is even 
NOT passed!!!
Note that in the G4CoupledTransportation class, a dedicated method 
(G4FieldTrack::SetChargeAndMoments)
is used to explicitely pass the dynamic charge... strange !

however I assume the fFieldPropagator has this information so probably 
there is no problem
because the G4PropagatorInField::ComputeStep should push the Q/P/M 
triplet in the ChordFinder
which in turn passes it to the fIntgrDriver and finally to the equation 
of motion.


Q2: I'd like to know at least if the effective charge of my Li6(2+) ions 
will be properly taken into account
within the equation of motion in the electric field ? (considering taht 
the rest vs dynamic mass bias should not be a big issue)

Q3: I'm not really interested in a detailed description of the Li6(2+) 
ion material other than in
vacuum where the E field drives it. However, for my information, what 
charge is effectively used to
compute energy losses (and other EM mechanisms) if the ion enters some 
solid volume ? It there some sort
of effective ion/medium atomic recombination effect taht is taken into 
account ?

Thanks a lot for comments, hints and help.

cheers

frc
-- 
François Mauger
Unicaen/CNRS/IN2P3
Idea Re: G4Transportation and dynamic charge and mass  by Vladimir Ivanchenko <Vladimir Ivanchenko>,   04 Jan, 2016
Re: None G4Transportation and dynamic charge and mass (Francois Mauger)
Hello,

sorry for the late response but you have chosen not an optimal forum: this question has nothing to do with fast simulation. It is a pure question for EM physics of Geant4 and should be discussed in the emprocess forum.

Basically you need to switch off effective charge approach in your simulation. For that you need some customization of EM Physics. The examples demonstrating how to do this :

$G4INSTALL/examples/advanced/microbeam
$G4INSTALL/examples/extended/electromagnetic/TestEm7

VI
Question Merging data using G4MPIScorerMerger  by bilal <bilal>,   18 Apr, 2015
Hello Experts,

I am running Geant4.10.p01 on a cluster. My question is how to merge the data if i am using command based scorers. Currently i am using G4MPIScorerMerger in the same way as defined in ~/examples/extended/parallel/MPI/exMPI02. This doesn't seem to work properly.
I am scoring doses in a 3D grid. (job splitting is fine using mpi; merging takes unusually long time and the merged data doesn't seem right).

Can anyone help please.

Thank you
Bilal
Question Step Length  by Manoj Kumar Parida <Manoj Kumar Parida>,   03 Feb, 2015
Dear all,
         I am beginner in the Geant4. I am simulating the thermal neutron interaction with the Boron-10. I would like to know how to randomize the step length of neutron during the transportation process? Any help would be appreciated.

Thanks & Regards Manoj

None Re: Step Length  by Michael H. Kelsey <Michael H. Kelsey>,   03 Feb, 2015
Re: Question Step Length (Manoj Kumar Parida)
On Wed, 04 Feb 2015 04:10:41 GMT, Manoj Kumar Parida wrote: > I am beginner in the Geant4. I am simulating the thermal neutron interaction with the Boron-10. I would like to know how to randomize the step length of neutron during the transportation process? Any help would be appreciated.

The steps are already randomized. The mean free path is computed using cross-sections and material properties (e.g., density), and the step length is thrown randomly from the mean free path.

Question get Mean free path  by Artem Basalaev <Artem Basalaev>,   03 Mar, 2014
Hello!

My setup is a modification of example B2, where I replaced geometry by thin Silicon layer (250 µm) and configured the Particle Gun to shoot single Pi+ per event perpendicular to the layer.

Now I need to get the value of Mean free path calculated by Geant for my material. I'm only interested in hadronic inelastic interactions.

here http://hypernews.slac.stanford.edu/HyperNews/geant4/get/fastsim/72/1.html I found the way to do it: "You can get the mean free path of a process calling its "G4double GetCurrentInteractionLength() const (method from G4VProcess)". If "-1" is returned, the process is not a true physical one (eg: transportation)."

So, now I get this value by aStep->GetTrack()->GetCreatorProcess()->GetCurrentInteractionLength() for the last step in the Volume for secondaries born by the process type fHadronic.

And values which I get are different (sometimes even by 2 orders!) and also I get "-1" value often.

As I see it, I should get (almost) same values, because I have only one homogeneous material and the shooting direction is always perpendicular and I should never get "-1", because I call this function only if aStep->GetTrack()->GetCreatorProcess()->GetProcessType()==4 (type fHadronic) i.e. this is a physical process.

Could you please tell me what I'm doing wrong? Or maybe explain me if these values are what they should be, but my expectations are wrong.

None Re: get Mean free path  by michel maire <michel maire>,   04 Mar, 2014
Re: Question get Mean free path (Artem Basalaev)
On Mon, 03 Mar 2014 20:13:26 GMT, Artem Basalaev wrote:
> Hello!
> 
> My setup is a modification of example B2, where I replaced geometry by
> thin Silicon layer (250 &#65533;m) and configured the Particle Gun to shoot
> single Pi+ per event perpendicular to the layer.
> 
> Now I need to get the value of Mean free path calculated by Geant for my
> material. I'm only interested in hadronic inelastic interactions.
> 

  Please, have a look to extended/hadronic/Hadr03

None Re: get Mean free path  by Artem Basalaev <Artem Basalaev>,   04 Mar, 2014
Re: None Re: get Mean free path (michel maire)
Hello!

Thank you for the answer, but the method of calculating the mean free path in this example is not valid for my setup.

There is a thick ('infinite') material, thus all incident particles interact with it sooner or later, and then their track length is being averaged.

This is a simulation of a real physical experiment, where we assume that we don't know mean free path until we calculate average track length on a large sample.

The material in my setup is neither infinite, nor even thicker than the mean free path, so interactions of incident particle with it are quite rare. And what I want to do is to get calculated mean free path from intrinsic Geant functions.

Obviously, Geant calculates somehow the probability of interaction with given material: P = 1 - exp (- layerThickness/meanFreePath) So I want to get this meanFreePath value.

On Tue, 04 Mar 2014 10:22:09 GMT, michel maire wrote:

> On Mon, 03 Mar 2014 20:13:26 GMT, Artem Basalaev wrote:
> 
> > Hello!
> > 
> > My setup is a modification of example B2, where I replaced geometry by
> > thin Silicon layer (250 &#65533;m) and configured the Particle Gun to shoot
> > single Pi+ per event perpendicular to the layer.
> > 
> > Now I need to get the value of Mean free path calculated by Geant for my
> > material. I'm only interested in hadronic inelastic interactions.
> > 
> 
>   Please, have a look to extended/hadronic/Hadr03
> 

None Re: get Mean free path  by michel maire <michel maire>,   05 Mar, 2014
Re: None Re: get Mean free path (Artem Basalaev)
On Tue, 04 Mar 2014 12:55:42 GMT, Artem Basalaev wrote:
> 
> Obviously, Geant calculates somehow the probability of interaction with
> given material: P = 1 - exp (- layerThickness/meanFreePath) So I want to
> get this meanFreePath value.

  Indeed  this is what the example does, because :
  1- there is no Em processes registered
  2- event is killed at first step. So, this unique step is always governed by hadronic interaction, according the exponential law.

 Also, you will see how to extract hadronic cross sections from Geant4 data tables via G4HadronicProcessStore

 In attachement, an example of macro and output

   Attachment:
      http://hypernews.slac.stanford.edu/HyperNews/geant4/get/AUX/2014/03/05/02.28-96884-artem.mac.txt
      http://hypernews.slac.stanford.edu/HyperNews/geant4/get/AUX/2014/03/05/02.28-29853-artem.log.txt

Ok Re: get Mean free path  by Artem Basalaev <Artem Basalaev>,   06 Mar, 2014
Re: None Re: get Mean free path (michel maire)
Hello!

Yes, I see now, it does exactly what I need and even more. Thank you very much!

On Wed, 05 Mar 2014 10:33:13 GMT, michel maire wrote:

> On Tue, 04 Mar 2014 12:55:42 GMT, Artem Basalaev wrote:
> 
> > 
> > Obviously, Geant calculates somehow the probability of interaction with
> > given material: P = 1 - exp (- layerThickness/meanFreePath) So I want to
> > get this meanFreePath value.
> 
>   Indeed  this is what the example does, because :
>   1- there is no Em processes registered
>   2- event is killed at first step. So, this unique step is always governed by hadronic interaction, according the exponential law.
> 
>  Also, you will see how to extract hadronic cross sections from Geant4 data tables via G4HadronicProcessStore
> 
>  In attachement, an example of macro and output
> 
>    Attachment:
>       http://hypernews.slac.stanford.edu/HyperNews/geant4/get/AUX/2014/03/05/02.28-96884-artem.mac.txt
>       http://hypernews.slac.stanford.edu/HyperNews/geant4/get/AUX/2014/03/05/02.28-29853-artem.log.txt
> 

Question Interaction length comparison  by George Dedes <George Dedes>,   07 Feb, 2014
Hi,

I put this question here, as it is generic and doesn't seem to fit anywhere else than a category that has "& Others":

For the decision of each step size, each process proposes a step and the lowest one decides the invoked interaction and the actual step size. I guess that each process returns either a macroscopic cross section or directly a mean free path, from which then a step length is sampled according to the exponential decay law. Then all step lengths should be compared and take the lowest. I would like to know in which class(es), the sampling and the comparison of the proposed steps is done.

Thanks in advance, George

PS: I see that printing the proposed step from G4Navigator::ComputeStep(), gives already the final proposed step, which coincides with the step length that I get from my SteppingAction

None Re: Interaction length comparison  by Marc Verderi <Marc Verderi>,   07 Feb, 2014
Re: Question Interaction length comparison (George Dedes)
Hi Georges,

Indeed this forum is not much for this generic question, but anyway.

Processes return a proposed step length (and not a cross-section) and 
are themselves responsible for making the related sampling of the 
exponential law, using their own mean free path. This sampling is 
actually done in the process base class G4VProcess. You can get the mean 
free path of a process calling its "G4double 
GetCurrentInteractionLength() const (method from G4VProcess)". If "-1" 
is returned, the process is not a true physical one (eg: transportation).
I would believe that if you call these methods at the end of a step (in 
a user stepping action) you would still get the mean free paths for the 
step that just occurred.
However, there is no easy way to get the proposed step lengths 
themselves. If this just for "curiosity" purpose, a /tracking/verbose 10 
would dump everything about what processes do, but if you do not that 
information for your application, it is more complicated.

The comparison between step length proposed by processes is made in the 
G4SteppingManager : this is its responsibility of selecting the process 
that returns the smallest step length.

Cheers,
Marc

PS: message re-sent: because of web mail server change, not sure the 
first attempt will succeed...

On 02/07/2014 02:47 PM, George Dedes wrote:
> *** Discussion title: Fast Simulation, Transportation & Others
>
> Hi,
>
> I put this question here, as it is generic and doesn't seem to fit
> anywhere else than a category that has "& Others":
>
> For the decision of each step size, each process proposes a step and the
> lowest one decides the invoked interaction and the actual step size. I
> guess that each process returns either a macroscopic cross section or
> directly a mean free path, from which then a step length is sampled
> according to the exponential decay law. Then all step lengths should be
> compared and take the lowest. I would like to know in which class(es),
> the sampling and the comparison of the proposed steps is done.
>
> Thanks in advance, George
>
> PS: I see that printing the proposed step from
> G4Navigator::ComputeStep(), gives already the final proposed step, which
> coincides with the step length that I get from my SteppingAction
>
> -------------------------------------------------------------
> Visit this GEANT4 at hypernews.slac.stanford.edu message (to reply or unsubscribe) at:
> http://hypernews.slac.stanford.edu/HyperNews/geant4/get/fastsim/72.html
None geometry overlap- optical fiber inserted in glass box  by Josh Xie <Josh Xie>,   13 Aug, 2013
Hi everyone,

I created a simulation of particle detector. It is composed by multiple layers of scintillating glass with iron as inter-layer. Optical fibers are inserted in each scintillating glass layer.

When the scintillating process is triggered, the optical photons will go through glass fiber. By the wavelength shifting properties of the fiber core, I should be able to carry the light out of glass layer.

However, the problem I met is, the optical photons ignores the fibers- like they are traveling in a pure scintillating glass box. Therefore the light is not able to be carried out.

However, if I just shoot light into a single fiber, everything works fine.

I somewhat believe this is due to Geant4's bug but I'm not very sure- it can also be my problem.

My algorithm is simple- I created a glass box, and use G4placement to insert fibers. I also tried to use G4Replica to insert the fiber, and yet it does not work as well.

Can anyone give me some advise on solving this problem? Thanks so much in advance!

~Josh

Question Unwanted beam dispersion in vacuum.  by Martin McHugh <Martin McHugh>,   19 Jun, 2013
Hello fellow users,

I'm developing a simulation of a detector attached to a polarimeter however I'm facing a basic issue I can't find any other documentation of. I fire a monoenergetic from (3-8 MeV) beam of electrons from about 2' (0.6 m) away, they must pass through a circular aperture 0.38" (~0.9 cm) across. until they get to the aperture, they're passing through vacuum defined as such:

  //Vacuum
  G4Material* Air = G4NistManager::Instance()->FindOrBuildMaterial("G4_AIR");
  G4Material* Vacuum = new G4Material("Vacuum", density=1.e-5*g/cm3, 
				      nel=1, kStateGas, 
                                      temperature=STP_Temperature, 
				      pressure=2.e-2*bar);
  Vacuum->AddMaterial(Air, fractionmass=1.0);

The problem I encounter is this: At 3 MeV only ~50% of the electrons thrown actually make it through the aperature and into the detector which I believe is unphysical due to the typical beam spot size of O(1 mm) in this device. The relevant sections from the PrimaryGeneratorAction are shown below:

  G4int n_particle = 1;
  particleGun = new G4ParticleGun(n_particle);

  // Set default particle to electron

  G4ParticleTable* particleTable = G4ParticleTable::GetParticleTable();
  G4ParticleDefinition* particle = particleTable->FindParticle("e-");

  G4double energy = 5.0*MeV;
  G4double position = 0.0*cm;
  G4ThreeVector direction = G4ThreeVector(0.0, 0.0, 1.0);
  		direction.setTheta(172.7*deg);

  particleGun->SetParticleDefinition(particle);
  particleGun->SetParticlePosition(G4ThreeVector(0.*cm,0.*cm,position));
  particleGun->SetParticleMomentumDirection(direction);
  particleGun->SetParticleEnergy(energy);

And the primaries are generated in

void MottPrimaryGeneratorAction::GeneratePrimaries(G4Event* anEvent)
{   
  particleGun->GeneratePrimaryVertex(anEvent);
}

Any input at all would be welcome since I've been searching for a method of dealing with this for the last two weeks or so while doing other work on the simulation but now it's becoming a major stumbling block.

Best, Marty

Question Please, tell me any example   by Batom <Batom>,   03 May, 2013
Dear

Please, advise me any example for how to use the function ComputeSolid in the Parameterisation class?

Regards

Question G4Exception with 4.9.6 and Geant4e  by Matt Wysocki <Matt Wysocki>,   05 Dec, 2012
Since upgrading to version 4.9.6 I get this message frequently:

-------- WWWW ------- G4Exception-START -------- WWWW -------
*** G4Exception : GeomNav0003
      issued by : G4Navigator::GetLocalExitNormal()
Function called when *NOT* at a Boundary.

*** This is just a warning message. *** -------- WWWW -------- G4Exception-END --------- WWWW -------

while using the Geant4e package. It is reproducible by running the example in examples/extended/errorpropagation. This is on OS X 10.7.5. From the CVS diff it appears this exception was added after 4.9.5.

Question G4PhantomParameterisation and parallel world problem  by Mathieu Plamondon <Mathieu Plamondon>,   05 Nov, 2012
I use the latest layered mass geometry functionality with a G4PhantomParameterisation in the base mass world and some parameterised objets in the parallel-world.

Interested in the dose deposited by photons, I need at each step to extract the track lengths inside all the voxels that have been crossed, i.e. the vector G4RegularNavigationHelper::theStepLengths.

When a photon enters a parallel-world volume, this theStepLengths vector does not take into account the boundary that has been crossed and in these cases, it is filled with all the voxels in the extrapolated photon's path up to the edge of the phantom. I wonder if this behaviour is expected. Fortunately, the aStep->GetStepLength() is ok and this problem can be cured.

Feedback Re: G4PhantomParameterisation and parallel world problem  by Pedro Arce <Pedro Arce>,   06 Nov, 2012
Re: Question G4PhantomParameterisation and parallel world problem (Mathieu Plamondon)
This is indeed the expected behaviour. G4RegularNavigation fills G4RegularNavigationHelper::theStepLengths without really navigating the geometry, but instead using a fast algorithm to divide the total step length among the voxels. It it had to interrogate the parallel geometry to get intersections with parallel world volumes, all the speed gain would be lost. Anyhow, you can always set G4PhantomParameterisation::SetSkipEqualMaterials(0) and you will only get a step per volume crossed (real or parallel).

Pedro

None Re: G4PhantomParameterisation and parallel world problem  by Mathieu Plamondon <Mathieu Plamondon>,   06 Nov, 2012
Re: Feedback Re: G4PhantomParameterisation and parallel world problem (Pedro Arce)
Thank you Pedro for the detailed answer.

I was naïvely thinking that this fast algorithm could fill G4RegularNavigationHelper::theStepLengths until G4Step::fStepLength is reached and stop there. It seems that it can be done without the cost/need of interrogating the parallel geometry, but maybe I am missing an important point.

Mathieu

Question How to collect the results from MPI parrallel  by Geng <Geng>,   24 Sep, 2012
Dear experts:

First of all, I have realized the parallel of Geant4 with MPI. But when I run the application, output-files' number is the number of clusters you used.Just like the example exMPI02.

So, do you have any smart ways to collect these files in the application? And how do you process your results after parallel run?

Any advice will be appreciated. Thanks very much.

Geng.

None Re: How to collect the results from MPI parrallel  by Matthew Lund <Matthew Lund>,   06 Sep, 2014
Re: Question How to collect the results from MPI parrallel (Geng)
Check out the new beta version GEANT4.10.01.b1, there is a new function in MPI for merging data. I haven't used it yet, but I'm putting it in my code today.

None Too many materials?  by Youming Yang <Youming Yang>,   20 Jun, 2012
Hello,

I am using Nested Parameterisation and voxelized geometry using 4072 materials based off of ~18 base materials.

When I initialize the code, it will call GetMaterial for the detector construction. I have it outputting the i'th material call. When I perform run/beamon, it will call getMaterial again for some reason. Except this time it will hang at the 3947th material, and end up resulting pointing me to in mlock.c (function in question is appended as well as console output)

Does anyone have experience with what this second GetMaterial sequence is for?

thanks, Ming

   Attachment:
      http://hypernews.slac.stanford.edu/HyperNews/geant4/get/AUX/2012/06/20/11.29-78997-lockerror.txt
      http://hypernews.slac.stanford.edu/HyperNews/geant4/get/AUX/2012/06/20/11.29-32818-mlockc.txt

Question problems in geant4.9.5 on the way to parallel  by Geng <Geng>,   22 Mar, 2012
Dear sir/madam:

        Thanks in advance!
        I want to do some parallel work with geant4.9.5,but I make failed with mpi-interface.There are so many errors. Could you please give me some advice?
        This is the error in the terminal.
        Thanks very much!

geng

In file included from src/G4VMPIsession.cc:34:
include/G4VMPIsession.hh:37:28: error: G4VBasicShell.hh: No such file or directory
In file included from src/G4VMPIsession.cc:35:
include/G4MPImanager.hh:38:22: error: globals.hh: No such file or directory
src/G4VMPIsession.cc:36:26: error: G4UImanager.hh: No such file or directory
src/G4VMPIsession.cc:37:26: error: G4UIcommand.hh: No such file or directory
Making dependency for file src/G4VMPIseedGenerator.cc ...
In file included from src/G4VMPIseedGenerator.cc:33:
include/G4VMPIseedGenerator.hh:37:22: error: globals.hh: No such file or directory
Making dependency for file src/G4UImpish.cc ...
In file included from src/G4UImpish.cc:34:
include/G4UImpish.hh:38:25: error: G4VUIshell.hh: No such file or directory
Making dependency for file src/G4MPIstatus.cc ...
In file included from src/G4MPIstatus.cc:34:
include/G4MPIstatus.hh:37:22: error: globals.hh: No such file or directory
include/G4MPIstatus.hh:38:33: error: G4ApplicationState.hh: No such file or directory
include/G4MPIstatus.hh:39:22: error: G4Timer.hh: No such file or directory
src/G4MPIstatus.cc:35:33: error: G4ApplicationState.hh: No such file or directory
Making dependency for file src/G4MPIsession.cc ...
In file included from include/G4MPIsession.hh:37,
                 from src/G4MPIsession.cc:34:
include/G4VMPIsession.hh:37:28: error: G4VBasicShell.hh: No such file or directory
In file included from src/G4MPIsession.cc:35:
include/G4MPImanager.hh:38:22: error: globals.hh: No such file or directory
src/G4MPIsession.cc:36:27: error: G4RunManager.hh: No such file or directory
src/G4MPIsession.cc:37:26: error: G4UImanager.hh: No such file or directory
src/G4MPIsession.cc:38:26: error: G4UIcommand.hh: No such file or directory
src/G4MPIsession.cc:39:22: error: G4UIcsh.hh: No such file or directory
In file included from src/G4MPIsession.cc:40:
include/G4UImpish.hh:38:25: error: G4VUIshell.hh: No such file or directory
Making dependency for file src/G4MPIrandomSeedGenerator.cc ...
In file included from include/G4MPIrandomSeedGenerator.hh:37,
                 from src/G4MPIrandomSeedGenerator.cc:34:
include/G4VMPIseedGenerator.hh:37:22: error: globals.hh: No such file or directory
src/G4MPIrandomSeedGenerator.cc:36:24: error: Randomize.hh: No such file or directory
Making dependency for file src/G4MPImessenger.cc ...
In file included from src/G4MPImessenger.cc:34:
include/G4MPImessenger.hh:37:28: error: G4UImessenger.hh: No such file or directory
In file included from src/G4MPImessenger.cc:35:
include/G4MPImanager.hh:38:22: error: globals.hh: No such file or directory
src/G4MPImessenger.cc:37:28: error: G4UIdirectory.hh: No such file or directory
src/G4MPImessenger.cc:38:38: error: G4UIcmdWithoutParameter.hh: No such file or directory
src/G4MPImessenger.cc:39:35: error: G4UIcmdWithAnInteger.hh: No such file or directory
src/G4MPImessenger.cc:40:33: error: G4UIcmdWithAString.hh: No such file or directory
src/G4MPImessenger.cc:41:33: error: G4UIcmdWithADouble.hh: No such file or directory
src/G4MPImessenger.cc:42:26: error: G4UIcommand.hh: No such file or directory
src/G4MPImessenger.cc:43:28: error: G4UIparameter.hh: No such file or directory
Making dependency for file src/G4MPImanager.cc ...
In file included from src/G4MPImanager.cc:34:
include/G4MPImanager.hh:38:22: error: globals.hh: No such file or directory
In file included from src/G4MPImanager.cc:35:
include/G4MPImessenger.hh:37:28: error: G4UImessenger.hh: No such file or directory
In file included from include/G4MPIsession.hh:37,
                 from src/G4MPImanager.cc:36:
include/G4VMPIsession.hh:37:28: error: G4VBasicShell.hh: No such file or directory
In file included from src/G4MPImanager.cc:38:
include/G4MPIstatus.hh:38:33: error: G4ApplicationState.hh: No such file or directory
include/G4MPIstatus.hh:39:22: error: G4Timer.hh: No such file or directory
src/G4MPImanager.cc:40:26: error: G4UImanager.hh: No such file or directory
src/G4MPImanager.cc:41:27: error: G4RunManager.hh: No such file or directory
src/G4MPImanager.cc:42:29: error: G4StateManager.hh: No such file or directory
src/G4MPImanager.cc:43:20: error: G4Run.hh: No such file or directory
Making dependency for file src/G4MPIbatch.cc ...
In file included from include/G4MPIbatch.hh:37,
                 from src/G4MPIbatch.cc:34:
include/G4VMPIsession.hh:37:28: error: G4VBasicShell.hh: No such file or directory
In file included from src/G4MPIbatch.cc:35:
include/G4MPImanager.hh:38:22: error: globals.hh: No such file or directory
src/G4MPIbatch.cc:36:26: error: G4UImanager.hh: No such file or directory
src/G4MPIbatch.cc:37:32: error: G4UIcommandStatus.hh: No such file or directory
Compiling G4MPIbatch.cc ...
In file included from include/G4MPIbatch.hh:37,
                 from src/G4MPIbatch.cc:34:
include/G4VMPIsession.hh:37:28: error: G4VBasicShell.hh: No such file or directory
In file included from src/G4MPIbatch.cc:35:
include/G4MPImanager.hh:38:22: error: globals.hh: No such file or directory
src/G4MPIbatch.cc:36:26: error: G4UImanager.hh: No such file or directory
src/G4MPIbatch.cc:37:32: error: G4UIcommandStatus.hh: No such file or directory
include/G4VMPIsession.hh:50: error: expected class-name before ‘{’ token
include/G4VMPIsession.hh:56: error: ‘G4bool’ does not name a type
include/G4VMPIsession.hh:57: error: ‘G4bool’ does not name a type
include/G4VMPIsession.hh:58: error: ‘G4int’ does not name a type
include/G4VMPIsession.hh:60: error: ‘G4int’ does not name a type
include/G4VMPIsession.hh:61: error: ‘G4String’ does not name a type
include/G4VMPIsession.hh:62: error: ‘G4String’ does not name a type
include/G4VMPIsession.hh:65: error: ‘G4bool’ does not name a type
include/G4VMPIsession.hh:73: error: ‘G4String’ has not been declared
include/G4VMPIsession.hh:75: error: ‘G4int’ does not name a type
include/G4VMPIsession.hh:76: error: ‘G4int’ does not name a type
include/G4MPIbatch.hh:49: error: ‘G4bool’ does not name a type
include/G4MPIbatch.hh:50: error: ‘G4bool’ does not name a type
include/G4MPIbatch.hh:53: error: ‘G4String’ does not name a type
include/G4MPIbatch.hh:56: error: expected ‘,’ or ‘...’ before ‘&’ token
include/G4MPIbatch.hh:56: error: ISO C++ forbids declaration of ‘G4String’ with no type
include/G4MPIbatch.hh:60: error: ISO C++ forbids declaration of ‘G4UIsession’ with no type
include/G4MPIbatch.hh:60: error: ‘G4UIsession’ declared as a ‘virtual’ field
include/G4MPIbatch.hh:60: error: expected ‘;’ before ‘*’ token
include/G4MPImanager.hh:58: error: ‘G4int’ does not name a type
include/G4MPImanager.hh:62: error: ‘G4bool’ does not name a type
include/G4MPImanager.hh:63: error: ‘G4bool’ does not name a type
include/G4MPImanager.hh:64: error: ‘G4int’ does not name a type
include/G4MPImanager.hh:65: error: ‘G4int’ does not name a type
include/G4MPImanager.hh:71: error: ‘G4bool’ does not name a type
include/G4MPImanager.hh:75: error: ‘G4bool’ does not name a type
include/G4MPImanager.hh:76: error: ‘G4String’ does not name a type
include/G4MPImanager.hh:77: error: ‘G4bool’ does not name a type
include/G4MPImanager.hh:78: error: ‘G4String’ does not name a type
include/G4MPImanager.hh:82: error: ‘G4int’ has not been declared
include/G4MPImanager.hh:83: error: ‘G4int’ has not been declared
include/G4MPImanager.hh:93: error: ‘G4double’ does not name a type
include/G4MPImanager.hh:117: error: ‘G4int’ does not name a type
include/G4MPImanager.hh:118: error: ‘G4int’ has not been declared
include/G4MPImanager.hh:120: error: ‘G4int’ does not name a type
include/G4MPImanager.hh:121: error: ‘G4int’ does not name a type
include/G4MPImanager.hh:123: error: ‘G4bool’ does not name a type
include/G4MPImanager.hh:124: error: ‘G4bool’ does not name a type
include/G4MPImanager.hh:126: error: ‘G4bool’ does not name a type
include/G4MPImanager.hh:127: error: ISO C++ forbids declaration of ‘G4String’ with no type
include/G4MPImanager.hh:127: error: expected ‘;’ before ‘&’ token
include/G4MPImanager.hh:129: error: ‘G4bool’ does not name a type
include/G4MPImanager.hh:130: error: ISO C++ forbids declaration of ‘G4String’ with no type
include/G4MPImanager.hh:130: error: expected ‘;’ before ‘&’ token
include/G4MPImanager.hh:132: error: ‘G4double’ has not been declared
include/G4MPImanager.hh:133: error: ‘G4double’ does not name a type
include/G4MPImanager.hh:138: error: ‘G4String’ does not name a type
include/G4MPImanager.hh:141: error: ‘G4int’ has not been declared
include/G4MPImanager.hh:141: error: ‘G4long’ has not been declared
include/G4MPImanager.hh:146: error: expected ‘,’ or ‘...’ before ‘&’ token
include/G4MPImanager.hh:146: error: ISO C++ forbids declaration of ‘G4String’ with no type
include/G4MPImanager.hh:147: error: ‘G4bool’ does not name a type
include/G4MPImanager.hh:148: error: expected ‘,’ or ‘...’ before ‘&’ token
include/G4MPImanager.hh:148: error: ISO C++ forbids declaration of ‘G4String’ with no type
include/G4MPImanager.hh:149: error: expected ‘,’ or ‘...’ before ‘&’ token
include/G4MPImanager.hh:149: error: ISO C++ forbids declaration of ‘G4String’ with no type
include/G4MPImanager.hh:152: error: ‘G4int’ has not been declared
include/G4MPImanager.hh:152: error: ‘G4bool’ has not been declared
include/G4MPImanager.hh:153: error: expected ‘,’ or ‘...’ before ‘&’ token
include/G4MPImanager.hh:153: error: ISO C++ forbids declaration of ‘G4String’ with no type
include/G4MPImanager.hh:169: error: ‘G4int’ does not name a type
include/G4MPImanager.hh:174: error: variable or field ‘SetVerbose’ declared void
include/G4MPImanager.hh:174: error: ‘G4MPImanager::SetVerbose’ declared as an ‘inline’ variable
include/G4MPImanager.hh:174: error: ‘int G4MPImanager::SetVerbose’ is not a static member of ‘class G4MPImanager’
include/G4MPImanager.hh:174: error: ‘G4int’ was not declared in this scope
include/G4MPImanager.hh:175: error: expected ‘,’ or ‘;’ before ‘{’ token
include/G4MPImanager.hh:184: error: ‘G4int’ does not name a type
include/G4MPImanager.hh:189: error: ‘G4int’ does not name a type
include/G4MPImanager.hh:194: error: ‘G4bool’ does not name a type
include/G4MPImanager.hh:199: error: ‘G4bool’ does not name a type
include/G4MPImanager.hh:204: error: ‘G4bool’ does not name a type
include/G4MPImanager.hh:210: error: expected initializer before ‘&’ token
include/G4MPImanager.hh:216: error: ‘G4bool’ does not name a type
include/G4MPImanager.hh:221: error: expected initializer before ‘&’ token
include/G4MPImanager.hh:226: error: variable or field ‘SetMasterWeight’ declared void
include/G4MPImanager.hh:226: error: ‘G4MPImanager::SetMasterWeight’ declared as an ‘inline’ variable
include/G4MPImanager.hh:226: error: ‘int G4MPImanager::SetMasterWeight’ is not a static member of ‘class G4MPImanager’
include/G4MPImanager.hh:226: error: ‘G4double’ was not declared in this scope
include/G4MPImanager.hh:227: error: expected ‘,’ or ‘;’ before ‘{’ token
include/G4MPImanager.hh:234: error: ‘G4double’ does not name a type
src/G4MPIbatch.cc:41: error: expected ‘,’ or ‘...’ before ‘&’ token
src/G4MPIbatch.cc:41: error: ISO C++ forbids declaration of ‘G4String’ with no type
src/G4MPIbatch.cc: In function ‘void Tokenize(int)’:
src/G4MPIbatch.cc:46: error: ‘str_size’ was not declared in this scope
src/G4MPIbatch.cc:46: error: expected `;' before ‘pos0’
src/G4MPIbatch.cc:47: error: expected `;' before ‘pos’
src/G4MPIbatch.cc:49: error: ‘pos’ was not declared in this scope
src/G4MPIbatch.cc:49: error: ‘G4String’ is not a class or namespace
src/G4MPIbatch.cc:49: error: ‘pos0’ was not declared in this scope
src/G4MPIbatch.cc:49: error: ‘G4String’ is not a class or namespace
src/G4MPIbatch.cc:50: error: ‘str’ was not declared in this scope
src/G4MPIbatch.cc:52: error: ‘G4String’ is not a class or namespace
src/G4MPIbatch.cc:54: error: ‘str’ was not declared in this scope
src/G4MPIbatch.cc:56: error: ‘G4String’ is not a class or namespace
src/G4MPIbatch.cc:59: error: ‘tokens’ was not declared in this scope
src/G4MPIbatch.cc:59: error: ‘str’ was not declared in this scope
src/G4MPIbatch.cc: At global scope:
src/G4MPIbatch.cc:72: error: expected ‘,’ or ‘...’ before ‘&’ token
src/G4MPIbatch.cc:72: error: ISO C++ forbids declaration of ‘G4String’ with no type
src/G4MPIbatch.cc: In constructor ‘G4MPIbatch::G4MPIbatch(int)’:
src/G4MPIbatch.cc:74: error: class ‘G4MPIbatch’ does not have any field named ‘isOpened’
src/G4MPIbatch.cc:74: error: class ‘G4MPIbatch’ does not have any field named ‘isBatchMode’
src/G4MPIbatch.cc:74: error: ‘qbatch’ was not declared in this scope
src/G4MPIbatch.cc:77: error: ‘isMaster’ was not declared in this scope
src/G4MPIbatch.cc:78: error: ‘fname’ was not declared in this scope
src/G4MPIbatch.cc:80: error: ‘G4cerr’ was not declared in this scope
src/G4MPIbatch.cc:81: error: ‘G4endl’ was not declared in this scope
src/G4MPIbatch.cc:83: error: ‘isOpened’ was not declared in this scope
src/G4MPIbatch.cc: In destructor ‘G4MPIbatch::~G4MPIbatch()’:
src/G4MPIbatch.cc:93: error: ‘isOpened’ was not declared in this scope
src/G4MPIbatch.cc: At global scope:
src/G4MPIbatch.cc:98: error: ‘G4String’ does not name a type
src/G4MPIbatch.cc:169: error: expected constructor, destructor, or type conversion before ‘*’ token
make: *** [/gpfs/g4.9.5/g4work/tmp/Linux-g++/G4UImpi/G4MPIbatch.o] Error 1
[root@mgt mpi_interface]# cd ..
[root@mgt MPI]# cd mpi_interface/
[root@mgt mpi_interface]# make clean
Cleaning up ...
[root@mgt mpi_interface]# make
Making dependency for file src/G4VMPIsession.cc ...
In file included from src/G4VMPIsession.cc:34:
include/G4VMPIsession.hh:37:28: error: G4VBasicShell.hh: No such file or directory
In file included from src/G4VMPIsession.cc:35:
include/G4MPImanager.hh:38:22: error: globals.hh: No such file or directory
src/G4VMPIsession.cc:36:26: error: G4UImanager.hh: No such file or directory
src/G4VMPIsession.cc:37:26: error: G4UIcommand.hh: No such file or directory
Making dependency for file src/G4VMPIseedGenerator.cc ...
In file included from src/G4VMPIseedGenerator.cc:33:
include/G4VMPIseedGenerator.hh:37:22: error: globals.hh: No such file or directory
Making dependency for file src/G4UImpish.cc ...
In file included from src/G4UImpish.cc:34:
include/G4UImpish.hh:38:25: error: G4VUIshell.hh: No such file or directory
Making dependency for file src/G4MPIstatus.cc ...
In file included from src/G4MPIstatus.cc:34:
include/G4MPIstatus.hh:37:22: error: globals.hh: No such file or directory
include/G4MPIstatus.hh:38:33: error: G4ApplicationState.hh: No such file or directory
include/G4MPIstatus.hh:39:22: error: G4Timer.hh: No such file or directory
src/G4MPIstatus.cc:35:33: error: G4ApplicationState.hh: No such file or directory
Making dependency for file src/G4MPIsession.cc ...
In file included from include/G4MPIsession.hh:37,
                 from src/G4MPIsession.cc:34:
include/G4VMPIsession.hh:37:28: error: G4VBasicShell.hh: No such file or directory
In file included from src/G4MPIsession.cc:35:
include/G4MPImanager.hh:38:22: error: globals.hh: No such file or directory
src/G4MPIsession.cc:36:27: error: G4RunManager.hh: No such file or directory
src/G4MPIsession.cc:37:26: error: G4UImanager.hh: No such file or directory
src/G4MPIsession.cc:38:26: error: G4UIcommand.hh: No such file or directory
src/G4MPIsession.cc:39:22: error: G4UIcsh.hh: No such file or directory
In file included from src/G4MPIsession.cc:40:
include/G4UImpish.hh:38:25: error: G4VUIshell.hh: No such file or directory
Making dependency for file src/G4MPIrandomSeedGenerator.cc ...
In file included from include/G4MPIrandomSeedGenerator.hh:37,
                 from src/G4MPIrandomSeedGenerator.cc:34:
include/G4VMPIseedGenerator.hh:37:22: error: globals.hh: No such file or directory
src/G4MPIrandomSeedGenerator.cc:36:24: error: Randomize.hh: No such file or directory
Making dependency for file src/G4MPImessenger.cc ...
In file included from src/G4MPImessenger.cc:34:
include/G4MPImessenger.hh:37:28: error: G4UImessenger.hh: No such file or directory
In file included from src/G4MPImessenger.cc:35:
include/G4MPImanager.hh:38:22: error: globals.hh: No such file or directory
src/G4MPImessenger.cc:37:28: error: G4UIdirectory.hh: No such file or directory
src/G4MPImessenger.cc:38:38: error: G4UIcmdWithoutParameter.hh: No such file or directory
src/G4MPImessenger.cc:39:35: error: G4UIcmdWithAnInteger.hh: No such file or directory
src/G4MPImessenger.cc:40:33: error: G4UIcmdWithAString.hh: No such file or directory
src/G4MPImessenger.cc:41:33: error: G4UIcmdWithADouble.hh: No such file or directory
src/G4MPImessenger.cc:42:26: error: G4UIcommand.hh: No such file or directory
src/G4MPImessenger.cc:43:28: error: G4UIparameter.hh: No such file or directory
Making dependency for file src/G4MPImanager.cc ...
In file included from src/G4MPImanager.cc:34:
include/G4MPImanager.hh:38:22: error: globals.hh: No such file or directory
In file included from src/G4MPImanager.cc:35:
include/G4MPImessenger.hh:37:28: error: G4UImessenger.hh: No such file or directory
In file included from include/G4MPIsession.hh:37,
                 from src/G4MPImanager.cc:36:
include/G4VMPIsession.hh:37:28: error: G4VBasicShell.hh: No such file or directory
In file included from src/G4MPImanager.cc:38:
include/G4MPIstatus.hh:38:33: error: G4ApplicationState.hh: No such file or directory
include/G4MPIstatus.hh:39:22: error: G4Timer.hh: No such file or directory
src/G4MPImanager.cc:40:26: error: G4UImanager.hh: No such file or directory
src/G4MPImanager.cc:41:27: error: G4RunManager.hh: No such file or directory
src/G4MPImanager.cc:42:29: error: G4StateManager.hh: No such file or directory
src/G4MPImanager.cc:43:20: error: G4Run.hh: No such file or directory
Making dependency for file src/G4MPIbatch.cc ...
In file included from include/G4MPIbatch.hh:37,
                 from src/G4MPIbatch.cc:34:
include/G4VMPIsession.hh:37:28: error: G4VBasicShell.hh: No such file or directory
In file included from src/G4MPIbatch.cc:35:
include/G4MPImanager.hh:38:22: error: globals.hh: No such file or directory
src/G4MPIbatch.cc:36:26: error: G4UImanager.hh: No such file or directory
src/G4MPIbatch.cc:37:32: error: G4UIcommandStatus.hh: No such file or directory
Compiling G4MPIbatch.cc ...
In file included from include/G4MPIbatch.hh:37,
                 from src/G4MPIbatch.cc:34:
include/G4VMPIsession.hh:37:28: error: G4VBasicShell.hh: No such file or directory
In file included from src/G4MPIbatch.cc:35:
include/G4MPImanager.hh:38:22: error: globals.hh: No such file or directory
src/G4MPIbatch.cc:36:26: error: G4UImanager.hh: No such file or directory
src/G4MPIbatch.cc:37:32: error: G4UIcommandStatus.hh: No such file or directory
include/G4VMPIsession.hh:50: error: expected class-name before ‘{’ token
include/G4VMPIsession.hh:56: error: ‘G4bool’ does not name a type
include/G4VMPIsession.hh:57: error: ‘G4bool’ does not name a type
include/G4VMPIsession.hh:58: error: ‘G4int’ does not name a type
include/G4VMPIsession.hh:60: error: ‘G4int’ does not name a type
include/G4VMPIsession.hh:61: error: ‘G4String’ does not name a type
include/G4VMPIsession.hh:62: error: ‘G4String’ does not name a type
include/G4VMPIsession.hh:65: error: ‘G4bool’ does not name a type
include/G4VMPIsession.hh:73: error: ‘G4String’ has not been declared
include/G4VMPIsession.hh:75: error: ‘G4int’ does not name a type
include/G4VMPIsession.hh:76: error: ‘G4int’ does not name a type
include/G4MPIbatch.hh:49: error: ‘G4bool’ does not name a type
include/G4MPIbatch.hh:50: error: ‘G4bool’ does not name a type
include/G4MPIbatch.hh:53: error: ‘G4String’ does not name a type
include/G4MPIbatch.hh:56: error: expected ‘,’ or ‘...’ before ‘&’ token
include/G4MPIbatch.hh:56: error: ISO C++ forbids declaration of ‘G4String’ with no type
include/G4MPIbatch.hh:60: error: ISO C++ forbids declaration of ‘G4UIsession’ with no type
include/G4MPIbatch.hh:60: error: ‘G4UIsession’ declared as a ‘virtual’ field
include/G4MPIbatch.hh:60: error: expected ‘;’ before ‘*’ token
include/G4MPImanager.hh:58: error: ‘G4int’ does not name a type
include/G4MPImanager.hh:62: error: ‘G4bool’ does not name a type
include/G4MPImanager.hh:63: error: ‘G4bool’ does not name a type
include/G4MPImanager.hh:64: error: ‘G4int’ does not name a type
include/G4MPImanager.hh:65: error: ‘G4int’ does not name a type
include/G4MPImanager.hh:71: error: ‘G4bool’ does not name a type
include/G4MPImanager.hh:75: error: ‘G4bool’ does not name a type
include/G4MPImanager.hh:76: error: ‘G4String’ does not name a type
include/G4MPImanager.hh:77: error: ‘G4bool’ does not name a type
include/G4MPImanager.hh:78: error: ‘G4String’ does not name a type
include/G4MPImanager.hh:82: error: ‘G4int’ has not been declared
include/G4MPImanager.hh:83: error: ‘G4int’ has not been declared
include/G4MPImanager.hh:93: error: ‘G4double’ does not name a type
include/G4MPImanager.hh:117: error: ‘G4int’ does not name a type
include/G4MPImanager.hh:118: error: ‘G4int’ has not been declared
include/G4MPImanager.hh:120: error: ‘G4int’ does not name a type
include/G4MPImanager.hh:121: error: ‘G4int’ does not name a type
include/G4MPImanager.hh:123: error: ‘G4bool’ does not name a type
include/G4MPImanager.hh:124: error: ‘G4bool’ does not name a type
include/G4MPImanager.hh:126: error: ‘G4bool’ does not name a type
include/G4MPImanager.hh:127: error: ISO C++ forbids declaration of ‘G4String’ with no type
include/G4MPImanager.hh:127: error: expected ‘;’ before ‘&’ token
include/G4MPImanager.hh:129: error: ‘G4bool’ does not name a type
include/G4MPImanager.hh:130: error: ISO C++ forbids declaration of ‘G4String’ with no type
include/G4MPImanager.hh:130: error: expected ‘;’ before ‘&’ token
include/G4MPImanager.hh:132: error: ‘G4double’ has not been declared
include/G4MPImanager.hh:133: error: ‘G4double’ does not name a type
include/G4MPImanager.hh:138: error: ‘G4String’ does not name a type
include/G4MPImanager.hh:141: error: ‘G4int’ has not been declared
include/G4MPImanager.hh:141: error: ‘G4long’ has not been declared
include/G4MPImanager.hh:146: error: expected ‘,’ or ‘...’ before ‘&’ token
include/G4MPImanager.hh:146: error: ISO C++ forbids declaration of ‘G4String’ with no type
include/G4MPImanager.hh:147: error: ‘G4bool’ does not name a type
include/G4MPImanager.hh:148: error: expected ‘,’ or ‘...’ before ‘&’ token
include/G4MPImanager.hh:148: error: ISO C++ forbids declaration of ‘G4String’ with no type
include/G4MPImanager.hh:149: error: expected ‘,’ or ‘...’ before ‘&’ token
include/G4MPImanager.hh:149: error: ISO C++ forbids declaration of ‘G4String’ with no type
include/G4MPImanager.hh:152: error: ‘G4int’ has not been declared
include/G4MPImanager.hh:152: error: ‘G4bool’ has not been declared
include/G4MPImanager.hh:153: error: expected ‘,’ or ‘...’ before ‘&’ token
include/G4MPImanager.hh:153: error: ISO C++ forbids declaration of ‘G4String’ with no type
include/G4MPImanager.hh:169: error: ‘G4int’ does not name a type
include/G4MPImanager.hh:174: error: variable or field ‘SetVerbose’ declared void
include/G4MPImanager.hh:174: error: ‘G4MPImanager::SetVerbose’ declared as an ‘inline’ variable
include/G4MPImanager.hh:174: error: ‘int G4MPImanager::SetVerbose’ is not a static member of ‘class G4MPImanager’
include/G4MPImanager.hh:174: error: ‘G4int’ was not declared in this scope
include/G4MPImanager.hh:175: error: expected ‘,’ or ‘;’ before ‘{’ token
include/G4MPImanager.hh:184: error: ‘G4int’ does not name a type
include/G4MPImanager.hh:189: error: ‘G4int’ does not name a type
include/G4MPImanager.hh:194: error: ‘G4bool’ does not name a type
include/G4MPImanager.hh:199: error: ‘G4bool’ does not name a type
include/G4MPImanager.hh:204: error: ‘G4bool’ does not name a type
include/G4MPImanager.hh:210: error: expected initializer before ‘&’ token
include/G4MPImanager.hh:216: error: ‘G4bool’ does not name a type
include/G4MPImanager.hh:221: error: expected initializer before ‘&’ token
include/G4MPImanager.hh:226: error: variable or field ‘SetMasterWeight’ declared void
include/G4MPImanager.hh:226: error: ‘G4MPImanager::SetMasterWeight’ declared as an ‘inline’ variable
include/G4MPImanager.hh:226: error: ‘int G4MPImanager::SetMasterWeight’ is not a static member of ‘class G4MPImanager’
include/G4MPImanager.hh:226: error: ‘G4double’ was not declared in this scope
include/G4MPImanager.hh:227: error: expected ‘,’ or ‘;’ before ‘{’ token
include/G4MPImanager.hh:234: error: ‘G4double’ does not name a type
src/G4MPIbatch.cc:41: error: expected ‘,’ or ‘...’ before ‘&’ token
src/G4MPIbatch.cc:41: error: ISO C++ forbids declaration of ‘G4String’ with no type
src/G4MPIbatch.cc: In function ‘void Tokenize(int)’:
src/G4MPIbatch.cc:46: error: ‘str_size’ was not declared in this scope
src/G4MPIbatch.cc:46: error: expected `;' before ‘pos0’
src/G4MPIbatch.cc:47: error: expected `;' before ‘pos’
src/G4MPIbatch.cc:49: error: ‘pos’ was not declared in this scope
src/G4MPIbatch.cc:49: error: ‘G4String’ is not a class or namespace
src/G4MPIbatch.cc:49: error: ‘pos0’ was not declared in this scope
src/G4MPIbatch.cc:49: error: ‘G4String’ is not a class or namespace
src/G4MPIbatch.cc:50: error: ‘str’ was not declared in this scope
src/G4MPIbatch.cc:52: error: ‘G4String’ is not a class or namespace
src/G4MPIbatch.cc:54: error: ‘str’ was not declared in this scope
src/G4MPIbatch.cc:56: error: ‘G4String’ is not a class or namespace
src/G4MPIbatch.cc:59: error: ‘tokens’ was not declared in this scope
src/G4MPIbatch.cc:59: error: ‘str’ was not declared in this scope
src/G4MPIbatch.cc: At global scope:
src/G4MPIbatch.cc:72: error: expected ‘,’ or ‘...’ before ‘&’ token
src/G4MPIbatch.cc:72: error: ISO C++ forbids declaration of ‘G4String’ with no type
src/G4MPIbatch.cc: In constructor ‘G4MPIbatch::G4MPIbatch(int)’:
src/G4MPIbatch.cc:74: error: class ‘G4MPIbatch’ does not have any field named ‘isOpened’
src/G4MPIbatch.cc:74: error: class ‘G4MPIbatch’ does not have any field named ‘isBatchMode’
src/G4MPIbatch.cc:74: error: ‘qbatch’ was not declared in this scope
src/G4MPIbatch.cc:77: error: ‘isMaster’ was not declared in this scope
src/G4MPIbatch.cc:78: error: ‘fname’ was not declared in this scope
src/G4MPIbatch.cc:80: error: ‘G4cerr’ was not declared in this scope
src/G4MPIbatch.cc:81: error: ‘G4endl’ was not declared in this scope
src/G4MPIbatch.cc:83: error: ‘isOpened’ was not declared in this scope
src/G4MPIbatch.cc: In destructor ‘G4MPIbatch::~G4MPIbatch()’:
src/G4MPIbatch.cc:93: error: ‘isOpened’ was not declared in this scope
src/G4MPIbatch.cc: At global scope:
src/G4MPIbatch.cc:98: error: ‘G4String’ does not name a type
src/G4MPIbatch.cc:169: error: expected constructor, destructor, or type conversion before ‘*’ token
make: *** [/gpfs/g4.9.5/g4work/tmp/Linux-g++/G4UImpi/G4MPIbatch.o] Error 1

Question Query: polarized muon decays  by Tom Roberts <Tom Roberts>,   20 Mar, 2012
I am trying to simulate the the new Fermilab g-2 experiment, in which polarized muons from pion decay are injected into a storage ring and allowed to decay. The distribution of electrons from polarized muon decay is essential to this modeling. So far I have gotten pions to decay into polarized muons, and I can track the polarized muons and watch their spins precess correctly in the storage ring. But I cannot figure out how to handle muon decay with polarization.

How do I use G4DecayWithSpin and G4MuonDecayChannelWithSpin? Or other related classes?

Does anybody have an example of correctly handling polarized muon decay?

Note that G4DecayWithSpin appears to make a very risky assumption that all decay channels are instances of G4MuonDecayChannelWithSpin -- in DecayIt() the code does a C-style cast to G4MuonDecayChannelWithSpin*, and then calls G4MuonDecayChannelWithSpin::SetPolarization() via the pointer. That function is specific to G4MuonDecayChannelWithSpin, so any other type of decay channel will send the program off to never-never land.

Feedback Re: Query: polarized muon decays  by Gumplinger Peter <Gumplinger Peter>,   26 Mar, 2012
Re: Question Query: polarized muon decays (Tom Roberts)
Hi Tom,

Sorry for not replying but I don't monitor this particular Forum. Fred Jones has brought this to my attention. - There are postings in 'Fields: Magnetic and Otherwise' and 'Particles' about tracking spin and defining decays for particles with spin or into spin.

If you use the LXR browser you'd find extended examples where this functionality is exhibited, probably the easiest to learn from is:

geant4/examples/extended/field/field05

with F05PhysicsList showing how to replace the 'standard' decays of pi's and mu's with those required to get polarized muons and their decay. When a muon comes to rest their spin is precessed around the local magn. field for the remainder of the muon's lifetime.

All this functinality is also implemented in Kamil Sedlak's muSR program (at PSI):

http://lmu.web.psi.ch/simulation/index.html

We currently have one problem in that muons coming to rest are not re-accelerated along the local E-field:

http://hypernews.slac.stanford.edu/HyperNews/geant4/get/eventtrackmanage/1039.html

You wrote to Fred that:

" What is lacking:
 3. the force from grad B on the magnetic moment
 4. polarized muon decays

Geant4 9.5 claims to have implemented #3"

Geant4.9.5 has implemented field tracking in a gravitational field. I don't think I claimed #3(?) However, #4 is certainly implemented, including first order radiative corrections to get the correct e+/e- energy distribution and has been for a long time.

#3 is forthcoming for G4.9.6 and I can send you preliminary code.

Thanks as always for your interesting and illuminating Forum questions, Peter

None Problems with transportation with spin  by Tom Roberts <Tom Roberts>,   15 Mar, 2012
I am trying to track electrons and muons with spin in Geant4 9.5. I followed the prescription in the application developer's guide section 4.3.3. When muons go around in circles in a uniform B field, their polarization vector does indeed precess (initial polarization=[0,0,1] when headed in the +z direction).

But there are several problems:

1. The G4Track global time is not updated. This is surely a bug. When I use
   G4EqMagElectricField the track time is updated normally (but of course the
   track's polarization is zeroed).

2. The magnetic moment anomaly is set in G4Mag_SpinEqRhs, not in
   G4ParticleDefinition. This is a peculiar design decision which puts a
   rather complicated burden on developers (maintain a table of the anomalous
   magnetic moments for all particles, and set it in PreUserTrackingAction()).

3. The constructor of G4Mag_SpinEqRhs takes a G4MagneticField, not a
   G4ElectroMagneticField. As a result, the particles do not see any electric
   field -- neither spin nor momentum are changed by an E field.

4. According to the application developer's guide for 9.5, G4Transportation
   now has EnableUseMagneticMoment(). Calling this function does not seem to
   work: for a 2 MeV/c mu+ traveling along +z, with spin along +y, and in a 
   1000 tesla/meter B field gradient along +y (By=y in units tesla and mm),
   the track is not deflected.

I can live with item 2, but I need to get the others fixed. Suggestions?

None Re: Problems with transportation with spin  by Tom Roberts <Tom Roberts>,   20 Mar, 2012
Re: None Problems with transportation with spin (Tom Roberts)
On Thu, 15 Mar 2012 20:50:42 GMT, Tom Roberts wrote:
 > 1. The G4Track global time is not updated. [...]

This problem has disappeared, using G4EqEMFieldWithSpin for the equation of motion.

I have plotted the precession of a single mu+'s spin for the BNL g-2 experiment, and it agrees with the experiment to 4-digit accuracy over 45 turns (no real fit was performed, which is needed to get better accuracy; this is just computing the period from an eyeball estimate of the 45th zero crossing).

In PreUserTrackingAction() my code now sets the anomaly for electrons and muons, and I have documented that spin tracking only applies to them. So #2 is handled.

Problem #3 was resolved by using G4EqEMFieldWithSpin.

So the only remaining problem is #4, the magnetic moment does not respond to a B-field gradient. Any suggestions?

None Re: Problems with transportation with spin  by Tom Roberts <Tom Roberts>,   15 Mar, 2012
Re: None Problems with transportation with spin (Tom Roberts)
On Thu, 15 Mar 2012 20:50:42 GMT, Tom Roberts wrote:
> 3. The constructor of G4Mag_SpinEqRhs takes a G4MagneticField, not a
>    G4ElectroMagneticField. As a result, the particles do not see any electric
>    field -- neither spin nor momentum are changed by an E field.

I just stumbled across G4EqEMFieldWithSpin. It appears to resolve this -- a quick test shows that a mu+ moves in a constant E field just as for the usual equation of motion without spin, and the spin precessed a little bit.

In my class derived from G4ElectroMagneticField, I simply replaced
    G4EquationOfMotion *e = new G4Mag_SpinEqRhs((G4MagneticField*)this);
    pStepper = new G4ClassicalRK4(e,12);
with
    G4EquationOfMotion *e = new G4EqEMFieldWithSpin(this);
    pStepper = new G4ClassicalRK4(e,12);

Tom Roberts

Question Gas ionisation  by Mariusz <Mariusz>,   14 Jan, 2012
Hi,

   I'm sending protons through gas (Neon) at very low pressure. It is ionised and the electric field brings electrons to an electrode below the proton beam. I wanted to track the positive Neon ions as well, but I don't see them at all (looking at tracks in UserSteppingFunction). I guess I have something wrong with my physics list.
   It is quite simple (based on F02 example):

void PhysicsList::ConstructProcess()
{
  AddTransportation();
  ConstructEM();
  ConstructGeneral();
}

void PhysicsList::ConstructEM()
{
  theParticleIterator->reset();

  while( (*theParticleIterator)() )
  {
    G4ParticleDefinition* particle = theParticleIterator->value();
    G4ProcessManager* pmanager = particle->GetProcessManager();
    G4String particleName = particle->GetParticleName();

    if (particleName == "gamma") 
    {
      // Construct processes for gamma

      thePhotoElectricEffect = new G4PhotoElectricEffect();      
      theComptonScattering   = new G4ComptonScattering();
      theGammaConversion     = new G4GammaConversion();

      pmanager->AddDiscreteProcess(thePhotoElectricEffect);
      pmanager->AddDiscreteProcess(theComptonScattering);

      pmanager->AddDiscreteProcess(theGammaConversion);

    } 
    else if (particleName == "e-") 
    {
      // Construct processes for electron 

      theeminusIonisation = new G4eIonisation();
      theeminusBremsstrahlung = new G4eBremsstrahlung();

      pmanager->AddProcess(theeminusIonisation,-1,2,2);
      pmanager->AddProcess(theeminusBremsstrahlung,-1,-1,3); 

    } 
    else if (particleName == "e+") 
    {
      // Construct processes for positron 

      theeplusIonisation = new G4eIonisation();
      theeplusBremsstrahlung = new G4eBremsstrahlung();

      pmanager->AddProcess(theeplusIonisation,-1,2,2);
      pmanager->AddProcess(theeplusBremsstrahlung,-1,-1,3);

    } 
    else if( particleName == "mu+" || 
             particleName == "mu-"    ) 
    {
      // Construct processes for muon+ 

      G4MuIonisation* themuIonisation = new G4MuIonisation() ;
      pmanager->AddProcess(new G4MuMultipleScattering(),-1,1,1);
      pmanager->AddProcess(themuIonisation,-1,2,2);
      pmanager->AddProcess(new G4MuBremsstrahlung(),-1,-1,3);
      pmanager->AddProcess(new G4MuPairProduction(),-1,-1,4); 

    } 
    else if (
                particleName == "proton"  
               || particleName == "antiproton"  
               || particleName == "pi+"  
               || particleName == "pi-"  
               || particleName == "kaon+"  
               || particleName == "kaon-"  
              )
    {

      G4hIonisation* thehIonisation = new G4hIonisation() ; 
      G4hMultipleScattering* thehMultipleScattering =
                     new G4hMultipleScattering() ;

      pmanager->AddProcess(thehMultipleScattering,-1,1,1);
      pmanager->AddProcess(thehIonisation,-1,2,2);

    }
  }
}

thanks for suggestions,

     Mariusz

Idea Re: Gas ionisation  by Vladimir Ivanchenko <Vladimir Ivanchenko>,   14 Jan, 2012
Re: Question Gas ionisation (Mariusz)
Hello,

Please, move this discussion to EM forum, because it is nothing to do with fats simulation.

Second, please, have a look into $G4INSTALL/examples/extended/electromagnetic/TestEm8

where some hint how to simulate electron/ion pair in gas is given.

Finally, your problem is not problem of Physics List selection but problem of simulation of ion drift in field. By default, Geant4 does not provide such simulation, because it is detector response task and not pure tracking.

VI

Question Radioactive decay causes "Class G4AtomicDeexcitation is obsolete" warning  by Ioannis Sechopoulos <Ioannis Sechopoulos>,   12 Jan, 2012
After moving to 9.5, if I try to run a simulation that involves the radioactive decay of an ion, e.g. Rb-82, once in while I get the following message:

 ********************************************************** 
 *                  W A R N I N G ! ! !                   * 
 ********************************************************** 
 *                                                        * 
 *  Class G4AtomicDeexcitation is obsolete. It has been   * 
 * discontinued and is going to be removed by next Geant4 * 
 *     release please migrate to G4UAtomDeexcitation.     * 
 *                                                        * 
 ********************************************************** 

(By the way, this message also has an error since the new class is called G4UAtomicDeexcitation, not G4UAtomDeexcitation.)

I tried the example rdecay02, and if I run the following set of commands:

PreInit> /run/initialize

Idle> /gps/position 0 0 0 
Idle> /gps/energy 0 keV   
Idle> /gps/particle ion   
Idle> /gps/ion 92 238 0  0
Idle> /run/beamOn 10    

this warning message also appears, so the problem doesn't seem to be my particular physics list, but with the RadioactiveDecay class that is still using an obsolete class. If I still use the RadioactiveDecay class, are my results still correct? Is there a way to get rid of this warning? Is there something that should be changed in RadioactiveDecay?

Thanks!

Feedback Re: Radioactive decay causes   by L.G. Sarmiento <L.G. Sarmiento>,   31 Jan, 2012
Re: Question Radioactive decay causes "Class G4AtomicDeexcitation is obsolete" warning (Ioannis Sechopoulos)
I second this question. But I add my two cents:

In my case I use the so-called "Geant4 physics lists". But not all of them issue the warning. Here are my findings:

G4EmStandardPhysics   -  NO warning
G4EmLivermorePhysics  -  NO warning
G4EmPenelopePhysics   -  WARNING

I might be wrong but I have to say "it wasn't me this time" ;)

Any advice, besides the obvious "select another builder"?
Thanks in advance

/Pico
Idea Re: Radioactive decay causes   by Vladimir Ivanchenko <Vladimir Ivanchenko>,   09 Feb, 2012
Re: Feedback Re: Radioactive decay causes (L.G. Sarmiento)
Hello,

The warning will be removed with the next patch. Even with this warning main results are not affected.

I also would suggest to use other Forum - there is no relation between Penelope EM physics and fast simulation?

VI

Question How can I change Maximum Kinetic Energy from TeV to PeV?  by Lilia Drakopoulou <Lilia Drakopoulou>,   06 Oct, 2011
Hello

I'm trying to change maximum kinetic energy from 10 TeV to 10 PeV. So, I performed necessary changes in

G4LossTableManager.cc G4VUserPhysicsList.cc G4VEnergyLossProcess.cc

but the program is still running with the default maximum kinetic energy of 10 TeV. I keep searching the codes with no results. What am I missing?

Tahnks in advance. Lilia

Question Re: How can I change Maximum Kinetic Energy from TeV to PeV?  by Lilia Drakopoulou <Lilia Drakopoulou>,   14 Oct, 2011
Re: Question How can I change Maximum Kinetic Energy from TeV to PeV? (Lilia Drakopoulou)
Hi again,

The program's output seems correct as I also changed energy range in

G4RangetoEnergyConverter

and added G4ELASTIC1.1 and G4PII1.3 data files.

But: I was counting cherenkov photons from primary muon, travelling in water volume, choosing different values for muon's energy. When choosing 1 GeV muon I counted ~ 22000 cherenkov photons per meter. Then I tried 100 GeV, 500 GeV, 10TeV, 100 TeV, 1 PeV muon's energy but number of cherenkov photons didn't change a lot. It remained between 21900-22500.

Does it make any sense to you? I was expecting a dramatic change in number of cherenkov photons (as from MeV to GeV) while changing muon's energy.

I have to note that just counting photons from all secondaries produced dramatic changes were observed - as expected.

Any suggestions please?

Thank you Lilia

Idea Re: How can I change Maximum Kinetic Energy from TeV to PeV?  by Vladimir Ivanchenko <Vladimir Ivanchenko>,   16 Feb, 2012
Re: Question Re: How can I change Maximum Kinetic Energy from TeV to PeV? (Lilia Drakopoulou)
Hello,

It is not a good idea to modify G4RangetoEnergyConverter or any Geant4 kernel class. We usually advice users to add user classes if it is needed.

G4ELASTIC1.1 is not used anymore. G4PII1.3 is used in special Physics List only - not relevant to high energy muons.

How to increase energy for EM physics is shown in $G4INSTALL/examples/extended/electromagnetic/TestEm6, TestEm17 - it is normally may be done with UI commands. Models for muons allowing to increase the upper limit.

Tips for Cerenkov simulation are shown in optical examples.

VI

None Re: Transportation process  by Manish gohil <Manish gohil>,   15 Sep, 2011
Hi , 

thanks for replaying,
 
can you please tell me clearly is transportation calculation based on  Boltzmann transport equation or not ? 

best regards,

Manish Gohil,
Physics Group,
Variable Energy Cyclotron Centre, 
1/AF,Bidhan nagar,
Kolkata-700 064,
INDIA.
None Re: Transportation process  by michel maire <michel maire>,   16 Sep, 2011
Re: None Re: Transportation process (Manish gohil)
On Thu, 15 Sep 2011 11:53:29 GMT, Manish gohil wrote:
> Hi , 
> 
> thanks for replaying,
>  
> can you please tell me clearly is transportation calculation based on  Boltzmann transport equation or not ? 
> 
 the answer is not so simple. In short : analog mode for neutral particles (gamma), condensed history for charged (electron). See document in attachement.

   Attachment:
      http://hypernews.slac.stanford.edu/HyperNews/geant4/get/AUX/2011/09/16/03.07-64713-MCintroduction.pdf

None Transportation process   by Manish gohil <Manish gohil>,   14 Sep, 2011
Hi,

For the transportation calculation, does Geant4 solve Boltzmann equation for the one-body phase space distribution of transport particles ? where do I find detail documents about transportation process ?

Thanks.

Question Re: Transportation process   by Manish gohil <Manish gohil>,   14 Sep, 2011
Re: None Transportation process (Manish gohil)
Hi,

Simulation of particle transport in matter can be done by two major techniques: (1) using Boltzmann transport equation (2) Analogue Monte Carlo techniques.

Which technique does GEANT4 use to simulate particle transport through detector ?

Thanks,

None Re: Transportation process   by michel maire <michel maire>,   15 Sep, 2011
Re: Question Re: Transportation process (Manish gohil)
On Thu, 15 Sep 2011 06:12:20 GMT, Manish gohil wrote:
> Hi,
> 
> Simulation of particle transport in matter can be done by two major
> techniques: (1) using Boltzmann transport equation (2) Analogue Monte
> Carlo techniques.
> 
> Which technique does GEANT4 use to simulate particle transport through
> detector ?
> 
> Thanks,
> 

  Physics Reference Manual, page 6

Question How can i specified a physical process for a certain volume?  by <throwpen@163.com>,   26 May, 2011
How can i specified a physical process for a certain volume? ex: specified PIXE works only in a volume?

None Re: How can i specified a physical process for a certain volume?  by Marc Verderi <Marc Verderi>,   26 May, 2011
Re: Question How can i specified a physical process for a certain volume?
Hello,

Please, consider posting this message in the forum for electromagnetic 
physics.

Cheers,
Marc


Le 26/05/2011 15:05, throwpen@163.com a écrit :
> *** Discussion title: Fast Simulation, Transportation&  Others
>
> How can i specified a physical process for a certain volume? ex:
> specified PIXE works only in a volume?
>
> -------------------------------------------------------------
> Visit this GEANT4 at hypernews.slac.stanford.edu message (to reply or unsubscribe) at:
> http://hypernews.slac.stanford.edu/HyperNews/geant4/get/fastsim/56.html
Question G4ParticleGun vs. G4GeneralParticleSource: radiogenics, distributed sources  by Michael H. Kelsey <Michael H. Kelsey>,   22 Apr, 2011
I'm working on implementing a variety of sources for an application, but I'm not sure whether I should stick with G4ParticleGun, and do everything myself, or move to G4GPS. So I thought I'd solicit opinions here.

A general question -- how easy is it to configure GPS from code vs. from a macro? I'd like to define my source class such that the user can just select it from the macro, and all of the configuration happens behind the scenes. The two examples I found with GPS (ReverseMC01 and gflash) both seem to do everything with macros.

One of my sources is a carrier-plate with four Am-241 "hockey pucks" mounted on it. I want to let RadioactiveDecay generate the gammas and alphas, and to generate a distribution of primaries from throughout the "active source" volume. That way we'll get straggling, collimator spread, secondaries, etc., which should better match real data.

I also need to implement radiogenic contamination, both stuff on the surface of assembly components and isotopes mixed through a material. This is going to be primarily for neutrons, so I'll want to model sources spread all the way through a given volume. Again, I want to give the source generator a radioactive ion, and let RadioactiveDecay provide the actual primaries.

Does anyone have an example I could look at which is analogous to either of these scenarios? Is GPS the right way for me to go, or should I code up my own implementations (throwing random positions in my volume, etc.) using G4ParticleGun?

-- Michael Kelsey

Feedback Re: G4ParticleGun vs. G4GeneralParticleSource: radiogenics, distributed sources  by Pedro Arce <Pedro Arce>,   28 Apr, 2011
Re: Question G4ParticleGun vs. G4GeneralParticleSource: radiogenics, distributed sources (Michael H. Kelsey)
Hi Michael,

I think I have an example of what you want in GAMOS: http://fismed.ciemat.es/GAMOS

You select the tracks created directly from Am241 and you apply importance sampling on their direction (phi, theta, sin(theta)*cos(phi) or what you want), giving more weight to those particles in your preferred direction with the distribution shape you like. Everything with user commands.

Pedro

None Re: G4ParticleGun vs. G4GeneralParticleSource: radiogenics, distributed sources  by michel maire <michel maire>,   26 Apr, 2011
Re: Question G4ParticleGun vs. G4GeneralParticleSource: radiogenics, distributed sources (Michael H. Kelsey)
On Sat, 23 Apr 2011 05:44:30 GMT, Michael H. Kelsey wrote:

> Does anyone have an example I could look at which is analogous to either
> of these scenarios? Is GPS the right way for me to go, or should I code
> up my own implementations (throwing random positions in my volume, etc.)
> using G4ParticleGun?
>
  Not an answer to your general question, but some elements :

 1-  extended/eventgenerator/particleGun illustrates few cases where we can use simple particle gun

 2- radioactivedecay/rdecay01 use radioactive ion as particle gun

           michel 

Question Re: G4ParticleGun and radiogenics -- is "particle_momentum_direction" used?  by Michael H. Kelsey <Michael H. Kelsey>,   26 Apr, 2011
Re: None Re: G4ParticleGun vs. G4GeneralParticleSource: radiogenics, distributed sources (michel maire)
On Tue, 26 Apr 2011 09:51:11 GMT, michel maire wrote:
> On Sat, 23 Apr 2011 05:44:30 GMT, Michael H. Kelsey wrote:
> > Does anyone have an example I could look at which is analogous to either
> > of these scenarios? Is GPS the right way for me to go, or should I code
> > up my own implementations (throwing random positions in my volume, etc.)
> > using G4ParticleGun?
> >
>  2- radioactivedecay/rdecay01 use radioactive ion as particle gun

Hi, Michel. I have a question about this example.

In our source holder, the Am-241 "hockey puck" is up against a lead collimator, with a small (200 um) hole to let the gammas out. When I set the particleGun to have zero energy (i.e., the ions are at rest), does the momentum direction have any meaning?

In particular, is it passed on to RadioactiveDecay in such a way that the daughters only come out in that direction? Or am I going to have to generate a large number of "useless" events in order to get a few which actually make it through the collimator and into our detector?

-- Mike

None Re: G4ParticleGun and radiogenics -- is   by michel maire <michel maire>,   26 Apr, 2011
Re: Question Re: G4ParticleGun and radiogenics -- is "particle_momentum_direction" used? (Michael H. Kelsey)
On Tue, 26 Apr 2011 18:54:53 GMT, Michael H. Kelsey wrote:

> > >
> >  2- radioactivedecay/rdecay01 use radioactive ion as particle gun
> 
> Hi, Michel. I have a question about this example.
> 
> In our source holder, the Am-241 "hockey puck" is up against a lead
> collimator, with a small (200 um) hole to let the gammas out. When I set
> the particleGun to have zero energy (i.e., the ions are at rest), does
> the momentum direction have any meaning?

  I hope no !
  In fact, the ion decays immediatly, at first step, as you can see by running few events with tracking/verbose and visualisation.     
 On visualisation, you will see that decay products are isotropic. 
> 
> In particular, is it passed on to RadioactiveDecay in such a way that
> the daughters only come out in that direction? Or am I going to have to
> generate a large number of "useless" events in order to get a few which
> actually make it through the collimator and into our detector?
>
  You can always kill events as soon as possible.
  Examples are given in TestEm13 and 14

Ok Re: G4ParticleGun vs. G4GeneralParticleSource: radiogenics, distributed sources  by Michael H. Kelsey <Michael H. Kelsey>,   26 Apr, 2011
Re: None Re: G4ParticleGun vs. G4GeneralParticleSource: radiogenics, distributed sources (michel maire)
On Tue, 26 Apr 2011 09:51:11 GMT, michel maire wrote:
> On Sat, 23 Apr 2011 05:44:30 GMT, Michael H. Kelsey wrote:
> > Does anyone have an example I could look at which is analogous to either
> > of these scenarios? Is GPS the right way for me to go, or should I code
> > up my own implementations (throwing random positions in my volume, etc.)
> > using G4ParticleGun?
> >
>   Not an answer to your general question, but some elements :
> 
>  1-  extended/eventgenerator/particleGun illustrates few cases where we can use simple particle gun
> 
>  2- radioactivedecay/rdecay01 use radioactive ion as particle gun

Thanks, Michel! Those examples are a good help for me.

  -- Mike

Question Energy conservation problem.  by Gianfranco Gargano <Gianfranco Gargano>,   21 Mar, 2011
Hy, I'm trying to simulate a 150 MeV proton in a water cube. There's a strange effect: the sum of all energies deposed in the water cube is not 150 MeV. I have considered the energy which escape from the water cube (neutrons or gammas), but anyway seems that in the last proton interaction near 15 MeV disappear. I'm using an energy cut value of 0.01mm and no step max limitation. I've used the physics list of the ProtonTherapy example.

Note Re: Energy conservation problem.  by Loïc Grevillot <Loïc Grevillot>,   22 Mar, 2011
Re: Question Energy conservation problem. (Gianfranco Gargano)
Hello,

I noticed also this difference in energy deposited. It increases with proton energy and it is only due to the nuclear interactions (you can switch on or off the inelastic hadronic collisions to check it). At 230 MeV, 205.5 MeV/incident proton is deposited using Geant4, 204.7 MeV with PHITS and 205.6 with MCNPX. At 100 MeV, if I remember well, about 99% of the energy of the incident particle is deposited. I did not investigated which reaction causes this difference, but if you do so, it would be interesting.

None Re: Energy conservation problem.  by Gianfranco Gargano <Gianfranco Gargano>,   22 Mar, 2011
Re: Question Energy conservation problem. (Gianfranco Gargano)
As you can see in the attached file at proton interaction #424 it loose 71.6 MeV, and if you look forward you can see a N15 carrying 1.24 MeV, a gamma carrying 6.15 MeV (it exit from the 'world' carrying 2 MeV), a proton carrying 3.11 MeV and another proton carrying 49 MeV. The sum of this energies is near 59 MeV. But it should be 71.6 MeV... why?

   Attachment:
      http://hypernews.slac.stanford.edu/HyperNews/geant4/get/AUX/2011/03/22/00.38-37095-EnergyLoose.text

Question Information about "frozen shower libraries"  by Mario <Mario>,   22 Dec, 2010
Hello Geant users,

I'm looking for information about creating and using frozen shower libraries. I want to simulate an iron-scintillator-sandwich-calorimeter and would like to know more about this option.

Google provided me only with some papers from the ATLAS collaboration comparing it with a full simulation. But i do not find any information about how to use it.

I would appreciate any link to a guide / tutorial / school whatever.

Thanks in advance

Mario

None Re: Information about "frozen shower libraries"  by Marc Verderi <Marc Verderi>,   22 Dec, 2010
Re: Question Information about "frozen shower libraries" (Mario)
Hello Mario,

Do you really want to focus on a shower library (which would need to be 
produced a priori for your special case). Have you considered the 
parameterised model presented in section "5.2.6.9.  Using the Gflash 
Parameterisation" of the application developpers guide ?

Cheers,
Marc

Le 22/12/2010 16:34, Mario a écrit :
> *** Discussion title: Fast Simulation, Transportation&  Others
>
> Hello Geant users,
>
> I'm looking for information about creating and using frozen shower
> libraries. I want to simulate an iron-scintillator-sandwich-calorimeter
> and would like to know more about this option.
>
> Google provided me only with some papers from the ATLAS collaboration
> comparing it with a full simulation. But i do not find any information
> about how to use it.
>
> I would appreciate any link to a guide / tutorial / school whatever.
>
> Thanks in advance
>
> Mario
>
> -------------------------------------------------------------
> Visit this GEANT4 at hypernews.slac.stanford.edu message (to reply or unsubscribe) at:
> http://hypernews.slac.stanford.edu/HyperNews/geant4/get/fastsim/53.html
None Re: Information about "frozen shower libraries"  by Mario <Mario>,   23 Dec, 2010
Re: None Re: Information about "frozen shower libraries" (Marc Verderi)
Hello Marc,

at this moment I'm just gathering information. The idea about the shower libraries is from my supervising tutor, because they used something similar for the NA48 simulation.

So if it worked for NA48, it will work for NA62 ;-)

Thanks for your hint to 5.2.6.9. This I will present to my tutor.

Do you have any references about the libraries?

None Re: Information about "frozen shower libraries"  by Marc Verderi <Marc Verderi>,   23 Dec, 2010
Re: None Re: Information about "frozen shower libraries" (Mario)
Hello Mario,

Thank you for considering this option.

You can the reference in the section itself.

Cheers,
Marc

Le 23/12/2010 10:52, Mario a écrit :
> *** Discussion title: Fast Simulation, Transportation&  Others
>
> Hello Marc,
>
> at this moment I'm just gathering information. The idea about the shower
> libraries is from my supervising tutor, because they used something
> similar for the NA48 simulation.
>
> So if it worked for NA48, it will work for NA62 ;-)
>
> Thanks for your hint to 5.2.6.9. This I will present to my tutor.
>
> Do you have any references about the libraries?
>
> -------------------------------------------------------------
> Visit this GEANT4 at hypernews.slac.stanford.edu message (to reply or unsubscribe) at:
> http://hypernews.slac.stanford.edu/HyperNews/geant4/get/fastsim/53/1/1.html
None Geant4 simulation in PIXE  by Soumendu Sekhar Bhattacharjee <Soumendu Sekhar Bhattacharjee>,   20 Dec, 2010
Hi,
 I am simulating the proton of energy 3Mev collide a fixed target of Aluminium/ Iron.. etc target and I want to study there X ray spectra. But I can not define the physics list properly. Please send me the physics list of the above simulation. I can not get the x ray emission of the above experimental simulation technique.

None Re: Geant4 simulation in PIXE  by Marc Verderi <Marc Verderi>,   20 Dec, 2010
Re: None Geant4 simulation in PIXE (Soumendu Sekhar Bhattacharjee)
Dear Soumendu,

May I suggest you to post this message to the EM forum ?

Cheers,
Marc


Le 20/12/2010 14:41, Soumendu Sekhar Bhattacharjee a écrit :
> *** Discussion title: Fast Simulation, Transportation&  Others
>
> Hi,
>   I am simulating the proton of energy 3Mev collide a fixed target of Aluminium/ Iron.. etc target and I want to study there X ray spectra. But I can not define the physics list properly. Please send me the physics list of the above simulation. I can not get the x ray emission of the above experimental simulation technique.
>
> -------------------------------------------------------------
> Visit this GEANT4 at hypernews.slac.stanford.edu message (to reply or unsubscribe) at:
> http://hypernews.slac.stanford.edu/HyperNews/geant4/get/fastsim/52.html
Question Is it possible to record track steps in a G4VFastSimulationModel?  by Phil Jones <Phil Jones>,   27 Jul, 2010
Hello,

I'm using a bespoke model that extends the G4VFastSimulationModel class, this tracks photons through some complex geometry. It is not obvious to me if it is possible to record these track steps (though the geometry) in the track information, as only the G4FastStep is returned. Does anyone know if this is possible?

Question geant4 transportation issue  by Isabelle Fonteille <Isabelle Fonteille>,   04 May, 2010
Dear all,

I'm having issues with my geant4 simulation. I'm simulating the passage of high energy ions through two planes of silicium. I'm running the simulation with carbon genericIons. The kinetic energy of ions is 3TeV.

I get a strange transportation process behaviour. The energy deposit of this process is always a multiple of a certain value (here 6.6). This behaviour disappear if I run the simulation at 300 GeV. What is the reason for such a behaviour ?

My physics list is a standard one with only EM processes.

Thank you very much.

Here is the output of tracking/verbose

*********************************************************************************************************
*G4Track Information: Particle = C12[0.0], Track ID = 1, Parent ID = 0
*********************************************************************************************************

Step#    X(mm)    Y(mm)    Z(mm) KinE(MeV)  dE(MeV) StepLeng TrackLeng  NextVolume ProcName
    0     -109      267  1.3e+03     3e+06        0        0         0   world_phy initStep
    1      -45     92.4      738     3e+06 3.17e-18      592       592 ChC_world_phy Transportation
    2    -16.5       15      489     3e+06 1.41e-18      263       854   world_phy Transportation
    3     -8.5    -6.87      418     3e+06 3.98e-19     74.4       929 SCDTopCover_phy Transportation
    4    -8.38    -7.18      417     3e+06     19.9     1.05       930   world_phy Transportation
    5    -5.68    -14.5      393     3e+06 1.34e-19       25       955 SCDTopContainer_phy Transportation
    6    -5.64    -14.6      393     3e+06 2.14e-21      0.4       955   world_phy Transportation
    7    -5.38    -15.4      391     3e+06 1.29e-20      2.4       958 SCDTopSensorFrame_phy Transportation
    8    -5.24    -15.7      390     3e+06     6.57     1.25       959   world_phy Transportation
    9    -4.97    -16.5      387     3e+06 1.35e-20     2.52       961 SCDTopLadder_phy Transportation
   10    -4.84    -16.8      386     3e+06     13.2     1.23       963 SCDTopLadder_phy ionIoni
   11    -4.79      -17      386     3e+06        0    0.444       963   world_phy Transportation
   12    -4.78      -17      385     3e+06 5.94e-22    0.111       963 SCDTopThermalStrap_phy Transportation
   13    -4.66    -17.3      384     3e+06     6.64     1.05       964   world_phy Transportation
   14   -0.614    -28.3      349     3e+06    2e-19     37.4     1e+03 SCDBottomSensor_phys803 Transportation
   15   -0.571    -28.4      349     3e+06     13.3      0.4     1e+03   world_phy Transportation
   16   -0.311    -29.1      346     3e+06 1.29e-20      2.4     1e+03 SCDBottomSensorFrame_phy Transportation
   17   -0.305    -29.2      346     3e+06        0   0.0552     1e+03 SCDBottomSensorFrame_phy ionIoni
   18   -0.176    -29.5      345     3e+06        0     1.19  1.01e+03   world_phy Transportation
   19   0.0934    -30.2      343     3e+06 1.33e-20     2.49  1.01e+03 SCDBottomLadder_phy Transportation
   20    0.246    -30.6      341     3e+06        0     1.41  1.01e+03 SCDBottomLadder_phy ionIoni
   21    0.281    -30.7      341     3e+06        0    0.326  1.01e+03   world_phy Transportation
   22     0.29    -30.8      341     3e+06 4.32e-22   0.0806  1.01e+03 SCDBottomThermalStrap_phy Transportation
   23    0.363      -31      340     3e+06     26.6    0.677  1.01e+03 SCDBottomThermalStrap_phy ionIoni
   24    0.518    -31.4      339     3e+06     26.5     1.43  1.01e+03   world_phy Transportation
   25     1.66    -34.5      329     3e+06 5.64e-20     10.5  1.02e+03 SCDBottomCover_phy Transportation
   26      1.7    -34.6      329     3e+06        0    0.416  1.02e+03 SCDBottomCover_phy ionIoni
   27     1.71    -34.6      329     3e+06        0    0.111  1.02e+03   world_phy Transportation
   28      187     -540 -1.3e+03     3e+06 9.19e-18 1.72e+03  2.74e+03  OutOfWorld Transportation

*********************************************************************************************************
* G4Track Information:   Particle = e-,   Track ID = 2,   Parent ID = 1
*********************************************************************************************************

Step#    X(mm)    Y(mm)    Z(mm) KinE(MeV)  dE(MeV) StepLeng TrackLeng  NextVolume ProcName
    0    -4.84    -16.8      386      7.43        0        0         0 SCDTopLadder_phy initStep
    1    -4.95      -17      386      7.29    0.144    0.455     0.455   world_phy Transportation
    2    -4.98      -17      385      7.29 1.28e-23    0.117     0.572 SCDTopThermalStrap_phy Transportation
    3    -5.26    -17.4      384      6.96    0.332     1.13       1.7   world_phy Transportation
    4      -21      -34      349      6.96 4.62e-21     42.3        44 SCDBottomSensor_phys2403 Transportation
    5    -21.1    -34.2      349      6.84     0.12    0.455      44.4   world_phy Transportation
    6    -22.7    -35.1      346      6.84  3.2e-22     2.94      47.3 SCDBottomSensorFrame_phy Transportation
    7    -23.6    -35.6      345      6.54    0.296     1.54      48.9   world_phy Transportation
    8    -25.5    -36.8      343      6.54 3.58e-22     3.29      52.2 SCDBottomLadder_phy Transportation
    9    -26.9    -37.6      341      5.85    0.685     2.34      54.5   world_phy Transportation
   10      -27    -37.7      341      5.85 1.01e-23   0.0941      54.6 SCDBottomThermalStrap_phy Transportation
   11    -27.8    -38.8      339      3.49     2.36     2.61      57.2   world_phy Transportation
   12    -32.5    -44.6      329      3.49 1.27e-21     12.5      69.7 SCDBottomCover_phy Transportation
   13    -32.7    -44.9      329      3.27    0.218    0.645      70.3   world_phy Transportation
   14     -618     -273 -1.3e+03      3.27 1.77e-19 1.75e+03  1.82e+03  OutOfWorld Transportation

*********************************************************************************************************
* G4Track Information:   Particle = e-,   Track ID = 3,   Parent ID = 1
*********************************************************************************************************

Step#    X(mm)    Y(mm)    Z(mm) KinE(MeV)  dE(MeV) StepLeng TrackLeng  NextVolume ProcName
    0   -0.305    -29.2      346      3.11        0        0         0 SCDBottomSensorFrame_phy initStep
    1    0.248    -29.4      346      2.96    0.144    0.855     0.855 SCDBottomSensorFrame_phy eBrem
    2    0.716    -29.7      345      2.83    0.133    0.781      1.64   world_phy Transportation
    3     1.88    -30.9      343      2.83  2.9e-22     2.89      4.53 SCDBottomLadder_phy Transportation
    4     2.25    -31.7      342      2.41     0.42     1.48         6 SCDBottomLadder_phy msc
    5     2.26    -32.1      341      2.26    0.148    0.653      6.66   world_phy Transportation
    6     2.27    -32.1      341      2.26 8.25e-24   0.0835      6.74 SCDBottomThermalStrap_phy Transportation
    7     2.33    -32.2      341      2.17   0.0886     0.21      6.95 SCDBottomThermalStrap_phy msc
    8     2.39    -32.2      341      2.11   0.0645     0.21      7.16 SCDBottomThermalStrap_phy msc
    9     2.44    -32.3      340      2.05   0.0552     0.21      7.37 SCDBottomThermalStrap_phy msc
   10     2.49    -32.3      340         2   0.0542     0.21      7.58 SCDBottomThermalStrap_phy msc
   11     2.53    -32.4      340      1.92   0.0806     0.21      7.79 SCDBottomThermalStrap_phy msc
   12     2.56    -32.4      340      1.86     0.06     0.21         8 SCDBottomThermalStrap_phy msc
   13     2.49    -32.6      340      1.79   0.0731     0.21      8.21 SCDBottomThermalStrap_phy msc
   14     2.39    -32.6      340      1.72   0.0629     0.21      8.42 SCDBottomThermalStrap_phy msc
   15     2.35    -32.7      339      1.66   0.0583     0.21      8.63 SCDBottomThermalStrap_phy msc
   16     2.34    -32.9      339      1.59   0.0782     0.21      8.84 SCDBottomThermalStrap_phy msc
   17     2.35      -33      339      1.51   0.0777     0.21      9.05 SCDBottomThermalStrap_phy msc
   18     2.35    -33.1      339      1.48   0.0254   0.0795      9.13   world_phy Transportation
   19     4.44    -39.6      329      1.48 1.18e-21     12.1      21.2 SCDBottomCover_phy Transportation
   20     4.46    -39.7      329      1.43   0.0491    0.103      21.4 SCDBottomCover_phy msc
   21     4.48    -39.7      329       1.4   0.0351    0.103      21.5 SCDBottomCover_phy msc
   22     4.45    -39.7      329      1.37   0.0308    0.103      21.6 SCDBottomCover_phy msc
   23     4.43    -39.7      329      1.31   0.0592    0.103      21.7 SCDBottomCover_phy msc
   24     4.39    -39.7      329      1.26   0.0437    0.103      21.8 SCDBottomCover_phy msc
   25     4.37    -39.7      329      1.25   0.0186   0.0613      21.8   world_phy Transportation
   26     -468      480 -1.3e+03      1.25 1.73e-19 1.77e+03   1.8e+03  OutOfWorld Transportation

*********************************************************************************************************
* G4Track Information:   Particle = gamma,   Track ID = 7,   Parent ID = 3
*********************************************************************************************************

Step#    X(mm)    Y(mm)    Z(mm) KinE(MeV)  dE(MeV) StepLeng TrackLeng  NextVolume ProcName
    0    0.248    -29.4      346   0.00715        0        0         0 SCDBottomSensorFrame_phy initStep
    1    0.705    -29.7      345   0.00715        0    0.774     0.774   world_phy Transportation
    2     2.71    -31.1      343   0.00715        0      3.4      4.18 SCDBottomLadder_phy Transportation
    3     2.81    -31.2      343         0  0.00404    0.161      4.34 SCDBottomLadder_phy phot

*********************************************************************************************************
* G4Track Information:   Particle = e-,   Track ID = 8,   Parent ID = 7
*********************************************************************************************************

Step#    X(mm)    Y(mm)    Z(mm) KinE(MeV)  dE(MeV) StepLeng TrackLeng  NextVolume ProcName
    0     2.81    -31.2      343    0.0031        0        0         0 SCDBottomLadder_phy initStep
    1     2.81    -31.2      343         0   0.0031 0.000241  0.000241 SCDBottomLadder_phy eIoni

*********************************************************************************************************
* G4Track Information:   Particle = e-,   Track ID = 4,   Parent ID = 1
*********************************************************************************************************

Step#    X(mm)    Y(mm)    Z(mm) KinE(MeV)  dE(MeV) StepLeng TrackLeng  NextVolume ProcName
    0    0.246    -30.6      341       1.8        0        0         0 SCDBottomLadder_phy initStep
    1    0.191    -30.6      341      1.72   0.0818    0.334     0.334   world_phy Transportation
    2    0.183    -30.5      341      1.72 8.03e-24   0.0821     0.417 SCDBottomThermalStrap_phy Transportation
    3     0.18    -30.5      341      1.68   0.0352     0.13     0.546 SCDBottomThermalStrap_phy msc
    4    0.175    -30.4      341      1.65   0.0382     0.13     0.676 SCDBottomThermalStrap_phy msc
    5     0.21    -30.3      341      1.61    0.034     0.13     0.806 SCDBottomThermalStrap_phy msc
    6    0.205    -30.2      341      1.57   0.0385     0.13     0.936 SCDBottomThermalStrap_phy msc
    7    0.205    -30.2      340      1.54   0.0352     0.13      1.07 SCDBottomThermalStrap_phy msc
    8    0.174    -30.1      340       1.5   0.0378     0.13       1.2 SCDBottomThermalStrap_phy msc
    9    0.139      -30      340      1.45   0.0521     0.13      1.33 SCDBottomThermalStrap_phy msc
   10   0.0618      -30      340      1.41   0.0339     0.13      1.45 SCDBottomThermalStrap_phy msc
   11  -0.0176      -30      340      1.35   0.0599    0.144       1.6 SCDBottomThermalStrap_phy msc
   12  -0.0541    -29.9      340      1.22    0.137    0.161      1.76 SCDBottomThermalStrap_phy msc
   13  -0.0973    -29.8      340      1.15   0.0687    0.184      1.94 SCDBottomThermalStrap_phy msc
   14   -0.198    -29.8      340       1.1   0.0533    0.184      2.13 SCDBottomThermalStrap_phy msc
   15   -0.277    -29.9      339      1.04   0.0519    0.184      2.31 SCDBottomThermalStrap_phy msc
   16    -0.43    -29.9      339     0.968   0.0755    0.184       2.5 SCDBottomThermalStrap_phy msc
   17   -0.564      -30      339     0.768    0.199    0.184      2.68 SCDBottomThermalStrap_phy msc
   18    -0.68    -30.1      339     0.714   0.0544    0.184      2.87 SCDBottomThermalStrap_phy msc
   19   -0.774      -30      339     0.649   0.0655    0.184      3.05 SCDBottomThermalStrap_phy msc
   20   -0.819    -29.9      339     0.594   0.0542    0.184      3.23 SCDBottomThermalStrap_phy msc
   21   -0.863    -29.7      339     0.466    0.129    0.184      3.42 SCDBottomThermalStrap_phy msc
   22   -0.859    -29.7      339     0.361    0.105    0.149      3.57   world_phy Transportation
   23   -0.859    -29.7      339     0.361        0        0      3.57 SCDBottomThermalStrap_phy Transportation
   24   -0.864    -29.6      339     0.355   0.0064   0.0118      3.58 SCDBottomThermalStrap_phy msc
   25   -0.865    -29.6      339     0.354 0.000422  0.00194      3.58   world_phy Transportation
   26    -45.9     55.8      329     0.354 1.19e-20     97.1       101 SCDBottomCover_phy Transportation
   27    -45.9     55.8      329     0.349  0.00469   0.0115       101 SCDBottomCover_phy msc
   28    -45.9     55.8      329     0.342  0.00789   0.0115       101 SCDBottomCover_phy msc
   29    -45.9     55.8      329     0.337   0.0042   0.0115       101 SCDBottomCover_phy msc
   30    -45.9     55.8      329     0.326   0.0114   0.0115       101 SCDBottomCover_phy msc
   31    -45.9     55.8      329     0.323  0.00337   0.0115       101 SCDBottomCover_phy msc
   32    -45.9     55.8      329     0.318  0.00456   0.0115       101 SCDBottomCover_phy msc
   33    -45.9     55.9      329     0.315  0.00306   0.0115       101 SCDBottomCover_phy msc
   34    -45.9     55.9      329     0.311  0.00358   0.0115       101 SCDBottomCover_phy msc
   35    -45.9     55.9      329     0.307  0.00385   0.0115       101 SCDBottomCover_phy msc
   36    -45.9     55.9      329     0.302  0.00528   0.0115       101 SCDBottomCover_phy msc
   37      -46     55.9      329     0.299  0.00324   0.0115       101 SCDBottomCover_phy msc
   38      -46     55.9      329     0.294  0.00484   0.0115       101 SCDBottomCover_phy msc
   39      -46     55.9      329     0.289  0.00498   0.0115       101 SCDBottomCover_phy msc
   40      -46     55.9      329     0.285   0.0046   0.0115       101 SCDBottomCover_phy msc
   41      -46     55.9      329      0.14    0.145   0.0115       101 SCDBottomCover_phy msc
   42      -46     55.9      329     0.128   0.0121   0.0115       101 SCDBottomCover_phy msc
   43      -46     55.9      329     0.111    0.017   0.0115       101 SCDBottomCover_phy msc
   44      -46     55.9      329     0.105  0.00628   0.0115       101 SCDBottomCover_phy msc
   45      -46     55.9      329    0.0962  0.00836   0.0115       101 SCDBottomCover_phy msc
   46      -46     55.9      329    0.0898  0.00636   0.0115       101 SCDBottomCover_phy msc
   47      -46     55.9      329    0.0798     0.01   0.0115       101 SCDBottomCover_phy msc
   48      -46     55.9      329      0.07  0.00978   0.0115       101 SCDBottomCover_phy msc
   49      -46     55.9      329    0.0516   0.0184   0.0115       101 SCDBottomCover_phy msc
   50      -46     55.9      329    0.0274   0.0242   0.0115       101 SCDBottomCover_phy msc
   51      -46     55.9      329         0   0.0274  0.00758       101 SCDBottomCover_phy eIoni

*********************************************************************************************************
* G4Track Information:   Particle = e-,   Track ID = 5,   Parent ID = 1
*********************************************************************************************************

Step#    X(mm)    Y(mm)    Z(mm) KinE(MeV)  dE(MeV) StepLeng TrackLeng  NextVolume ProcName
    0    0.363      -31      340      2.88        0        0         0 SCDBottomThermalStrap_phy initStep
    1    0.527    -30.9      340      2.79   0.0956    0.379     0.379 SCDBottomThermalStrap_phy msc
    2    0.616    -30.8      340      2.66    0.123    0.379     0.758 SCDBottomThermalStrap_phy msc
    3    0.785    -30.7      339      2.55    0.109    0.379      1.14 SCDBottomThermalStrap_phy msc
    4     0.94      -31      339       2.4    0.156    0.379      1.52 SCDBottomThermalStrap_phy msc
    5     1.13    -31.3      339      2.29    0.106    0.379      1.89 SCDBottomThermalStrap_phy msc
    6     1.34    -31.6      339      2.15    0.143    0.379      2.27 SCDBottomThermalStrap_phy msc
    7     1.66    -31.8      339      2.03    0.121    0.379      2.65 SCDBottomThermalStrap_phy msc
    8     1.82    -31.9      339      1.95   0.0794    0.185      2.84   world_phy Transportation
    9       14    -38.7      329      1.95 1.68e-21     17.2        20 SCDBottomCover_phy Transportation
   10     14.1    -38.7      329       1.9   0.0506     0.16      20.2 SCDBottomCover_phy msc
   11     14.2    -38.8      329      1.85   0.0465     0.16      20.3 SCDBottomCover_phy msc
   12     14.3    -38.8      329       1.8   0.0544     0.16      20.5 SCDBottomCover_phy msc
   13     14.4    -38.7      329      1.75   0.0464     0.16      20.6 SCDBottomCover_phy msc
   14     14.5    -38.7      329       1.7   0.0525    0.157      20.8   world_phy Transportation
   15  1.3e+03      236     -727       1.7 1.65e-19 1.69e+03  1.71e+03  OutOfWorld Transportation

*********************************************************************************************************
* G4Track Information:   Particle = e-,   Track ID = 6,   Parent ID = 1
*********************************************************************************************************

Step#    X(mm)    Y(mm)    Z(mm) KinE(MeV)  dE(MeV) StepLeng TrackLeng  NextVolume ProcName
    0      1.7    -34.6      329      2.89        0        0         0 SCDBottomCover_phy initStep
    1     1.77    -34.7      329      2.85    0.039    0.159     0.159   world_phy Transportation
    2      908 -1.3e+03 -1.21e+03      2.85  2.2e-19 2.19e+03  2.19e+03  OutOfWorld Transportation

None Re: geant4 transportation issue  by Marc Verderi <Marc Verderi>,   04 May, 2010
Re: Question geant4 transportation issue (Isabelle Fonteille)
Hi Isabelle,

I would suggest you to post your message on the EM or hadronic physics 
forum.

Cheers,
Marc

Le 04/05/2010 10:55, Isabelle Fonteille a écrit :
> *** Discussion title: Fast Simulation, Transportation&  Others
>
> Dear all,
>
> I'm having issues with my geant4 simulation. I'm simulating the passage
> of high energy ions through two planes of silicium. I'm running the
> simulation with carbon genericIons. The kinetic energy of ions is 3TeV.
>
> I get a strange transportation process behaviour. The energy deposit of
> this process is always a multiple of a certain value (here 6.6). This
> behaviour disappear if I run the simulation at 300 GeV. What is the
> reason for such a behaviour ?
>
> My physics list is a standard one with only EM processes.
>
> Thank you very much.
>
> Here is the output of tracking/verbose
>
> *********************************************************************************************************
> *G4Track Information: Particle = C12[0.0], Track ID = 1, Parent ID = 0
> *********************************************************************************************************
>
> Step#    X(mm)    Y(mm)    Z(mm) KinE(MeV)  dE(MeV) StepLeng TrackLeng  NextVolume ProcName
>      0     -109      267  1.3e+03     3e+06        0        0         0   world_phy initStep
>      1      -45     92.4      738     3e+06 3.17e-18      592       592 ChC_world_phy Transportation
>      2    -16.5       15      489     3e+06 1.41e-18      263       854   world_phy Transportation
>      3     -8.5    -6.87      418     3e+06 3.98e-19     74.4       929 SCDTopCover_phy Transportation
>      4    -8.38    -7.18      417     3e+06     19.9     1.05       930   world_phy Transportation
>      5    -5.68    -14.5      393     3e+06 1.34e-19       25       955 SCDTopContainer_phy Transportation
>      6    -5.64    -14.6      393     3e+06 2.14e-21      0.4       955   world_phy Transportation
>      7    -5.38    -15.4      391     3e+06 1.29e-20      2.4       958 SCDTopSensorFrame_phy Transportation
>      8    -5.24    -15.7      390     3e+06     6.57     1.25       959   world_phy Transportation
>      9    -4.97    -16.5      387     3e+06 1.35e-20     2.52       961 SCDTopLadder_phy Transportation
>     10    -4.84    -16.8      386     3e+06     13.2     1.23       963 SCDTopLadder_phy ionIoni
>     11    -4.79      -17      386     3e+06        0    0.444       963   world_phy Transportation
>     12    -4.78      -17      385     3e+06 5.94e-22    0.111       963 SCDTopThermalStrap_phy Transportation
>     13    -4.66    -17.3      384     3e+06     6.64     1.05       964   world_phy Transportation
>     14   -0.614    -28.3      349     3e+06    2e-19     37.4     1e+03 SCDBottomSensor_phys803 Transportation
>     15   -0.571    -28.4      349     3e+06     13.3      0.4     1e+03   world_phy Transportation
>     16   -0.311    -29.1      346     3e+06 1.29e-20      2.4     1e+03 SCDBottomSensorFrame_phy Transportation
>     17   -0.305    -29.2      346     3e+06        0   0.0552     1e+03 SCDBottomSensorFrame_phy ionIoni
>     18   -0.176    -29.5      345     3e+06        0     1.19  1.01e+03   world_phy Transportation
>     19   0.0934    -30.2      343     3e+06 1.33e-20     2.49  1.01e+03 SCDBottomLadder_phy Transportation
>     20    0.246    -30.6      341     3e+06        0     1.41  1.01e+03 SCDBottomLadder_phy ionIoni
>     21    0.281    -30.7      341     3e+06        0    0.326  1.01e+03   world_phy Transportation
>     22     0.29    -30.8      341     3e+06 4.32e-22   0.0806  1.01e+03 SCDBottomThermalStrap_phy Transportation
>     23    0.363      -31      340     3e+06     26.6    0.677  1.01e+03 SCDBottomThermalStrap_phy ionIoni
>     24    0.518    -31.4      339     3e+06     26.5     1.43  1.01e+03   world_phy Transportation
>     25     1.66    -34.5      329     3e+06 5.64e-20     10.5  1.02e+03 SCDBottomCover_phy Transportation
>     26      1.7    -34.6      329     3e+06        0    0.416  1.02e+03 SCDBottomCover_phy ionIoni
>     27     1.71    -34.6      329     3e+06        0    0.111  1.02e+03   world_phy Transportation
>     28      187     -540 -1.3e+03     3e+06 9.19e-18 1.72e+03  2.74e+03  OutOfWorld Transportation
>
> *********************************************************************************************************
> * G4Track Information:   Particle = e-,   Track ID = 2,   Parent ID = 1
> *********************************************************************************************************
>
> Step#    X(mm)    Y(mm)    Z(mm) KinE(MeV)  dE(MeV) StepLeng TrackLeng  NextVolume ProcName
>      0    -4.84    -16.8      386      7.43        0        0         0 SCDTopLadder_phy initStep
>      1    -4.95      -17      386      7.29    0.144    0.455     0.455   world_phy Transportation
>      2    -4.98      -17      385      7.29 1.28e-23    0.117     0.572 SCDTopThermalStrap_phy Transportation
>      3    -5.26    -17.4      384      6.96    0.332     1.13       1.7   world_phy Transportation
>      4      -21      -34      349      6.96 4.62e-21     42.3        44 SCDBottomSensor_phys2403 Transportation
>      5    -21.1    -34.2      349      6.84     0.12    0.455      44.4   world_phy Transportation
>      6    -22.7    -35.1      346      6.84  3.2e-22     2.94      47.3 SCDBottomSensorFrame_phy Transportation
>      7    -23.6    -35.6      345      6.54    0.296     1.54      48.9   world_phy Transportation
>      8    -25.5    -36.8      343      6.54 3.58e-22     3.29      52.2 SCDBottomLadder_phy Transportation
>      9    -26.9    -37.6      341      5.85    0.685     2.34      54.5   world_phy Transportation
>     10      -27    -37.7      341      5.85 1.01e-23   0.0941      54.6 SCDBottomThermalStrap_phy Transportation
>     11    -27.8    -38.8      339      3.49     2.36     2.61      57.2   world_phy Transportation
>     12    -32.5    -44.6      329      3.49 1.27e-21     12.5      69.7 SCDBottomCover_phy Transportation
>     13    -32.7    -44.9      329      3.27    0.218    0.645      70.3   world_phy Transportation
>     14     -618     -273 -1.3e+03      3.27 1.77e-19 1.75e+03  1.82e+03  OutOfWorld Transportation
>
> *********************************************************************************************************
> * G4Track Information:   Particle = e-,   Track ID = 3,   Parent ID = 1
> *********************************************************************************************************
>
> Step#    X(mm)    Y(mm)    Z(mm) KinE(MeV)  dE(MeV) StepLeng TrackLeng  NextVolume ProcName
>      0   -0.305    -29.2      346      3.11        0        0         0 SCDBottomSensorFrame_phy initStep
>      1    0.248    -29.4      346      2.96    0.144    0.855     0.855 SCDBottomSensorFrame_phy eBrem
>      2    0.716    -29.7      345      2.83    0.133    0.781      1.64   world_phy Transportation
>      3     1.88    -30.9      343      2.83  2.9e-22     2.89      4.53 SCDBottomLadder_phy Transportation
>      4     2.25    -31.7      342      2.41     0.42     1.48         6 SCDBottomLadder_phy msc
>      5     2.26    -32.1      341      2.26    0.148    0.653      6.66   world_phy Transportation
>      6     2.27    -32.1      341      2.26 8.25e-24   0.0835      6.74 SCDBottomThermalStrap_phy Transportation
>      7     2.33    -32.2      341      2.17   0.0886     0.21      6.95 SCDBottomThermalStrap_phy msc
>      8     2.39    -32.2      341      2.11   0.0645     0.21      7.16 SCDBottomThermalStrap_phy msc
>      9     2.44    -32.3      340      2.05   0.0552     0.21      7.37 SCDBottomThermalStrap_phy msc
>     10     2.49    -32.3      340         2   0.0542     0.21      7.58 SCDBottomThermalStrap_phy msc
>     11     2.53    -32.4      340      1.92   0.0806     0.21      7.79 SCDBottomThermalStrap_phy msc
>     12     2.56    -32.4      340      1.86     0.06     0.21         8 SCDBottomThermalStrap_phy msc
>     13     2.49    -32.6      340      1.79   0.0731     0.21      8.21 SCDBottomThermalStrap_phy msc
>     14     2.39    -32.6      340      1.72   0.0629     0.21      8.42 SCDBottomThermalStrap_phy msc
>     15     2.35    -32.7      339      1.66   0.0583     0.21      8.63 SCDBottomThermalStrap_phy msc
>     16     2.34    -32.9      339      1.59   0.0782     0.21      8.84 SCDBottomThermalStrap_phy msc
>     17     2.35      -33      339      1.51   0.0777     0.21      9.05 SCDBottomThermalStrap_phy msc
>     18     2.35    -33.1      339      1.48   0.0254   0.0795      9.13   world_phy Transportation
>     19     4.44    -39.6      329      1.48 1.18e-21     12.1      21.2 SCDBottomCover_phy Transportation
>     20     4.46    -39.7      329      1.43   0.0491    0.103      21.4 SCDBottomCover_phy msc
>     21     4.48    -39.7      329       1.4   0.0351    0.103      21.5 SCDBottomCover_phy msc
>     22     4.45    -39.7      329      1.37   0.0308    0.103      21.6 SCDBottomCover_phy msc
>     23     4.43    -39.7      329      1.31   0.0592    0.103      21.7 SCDBottomCover_phy msc
>     24     4.39    -39.7      329      1.26   0.0437    0.103      21.8 SCDBottomCover_phy msc
>     25     4.37    -39.7      329      1.25   0.0186   0.0613      21.8   world_phy Transportation
>     26     -468      480 -1.3e+03      1.25 1.73e-19 1.77e+03   1.8e+03  OutOfWorld Transportation
>
> *********************************************************************************************************
> * G4Track Information:   Particle = gamma,   Track ID = 7,   Parent ID = 3
> *********************************************************************************************************
>
> Step#    X(mm)    Y(mm)    Z(mm) KinE(MeV)  dE(MeV) StepLeng TrackLeng  NextVolume ProcName
>      0    0.248    -29.4      346   0.00715        0        0         0 SCDBottomSensorFrame_phy initStep
>      1    0.705    -29.7      345   0.00715        0    0.774     0.774   world_phy Transportation
>      2     2.71    -31.1      343   0.00715        0      3.4      4.18 SCDBottomLadder_phy Transportation
>      3     2.81    -31.2      343         0  0.00404    0.161      4.34 SCDBottomLadder_phy phot
>
> *********************************************************************************************************
> * G4Track Information:   Particle = e-,   Track ID = 8,   Parent ID = 7
> *********************************************************************************************************
>
> Step#    X(mm)    Y(mm)    Z(mm) KinE(MeV)  dE(MeV) StepLeng TrackLeng  NextVolume ProcName
>      0     2.81    -31.2      343    0.0031        0        0         0 SCDBottomLadder_phy initStep
>      1     2.81    -31.2      343         0   0.0031 0.000241  0.000241 SCDBottomLadder_phy eIoni
>
> *********************************************************************************************************
> * G4Track Information:   Particle = e-,   Track ID = 4,   Parent ID = 1
> *********************************************************************************************************
>
> Step#    X(mm)    Y(mm)    Z(mm) KinE(MeV)  dE(MeV) StepLeng TrackLeng  NextVolume ProcName
>      0    0.246    -30.6      341       1.8        0        0         0 SCDBottomLadder_phy initStep
>      1    0.191    -30.6      341      1.72   0.0818    0.334     0.334   world_phy Transportation
>      2    0.183    -30.5      341      1.72 8.03e-24   0.0821     0.417 SCDBottomThermalStrap_phy Transportation
>      3     0.18    -30.5      341      1.68   0.0352     0.13     0.546 SCDBottomThermalStrap_phy msc
>      4    0.175    -30.4      341      1.65   0.0382     0.13     0.676 SCDBottomThermalStrap_phy msc
>      5     0.21    -30.3      341      1.61    0.034     0.13     0.806 SCDBottomThermalStrap_phy msc
>      6    0.205    -30.2      341      1.57   0.0385     0.13     0.936 SCDBottomThermalStrap_phy msc
>      7    0.205    -30.2      340      1.54   0.0352     0.13      1.07 SCDBottomThermalStrap_phy msc
>      8    0.174    -30.1      340       1.5   0.0378     0.13       1.2 SCDBottomThermalStrap_phy msc
>      9    0.139      -30      340      1.45   0.0521     0.13      1.33 SCDBottomThermalStrap_phy msc
>     10   0.0618      -30      340      1.41   0.0339     0.13      1.45 SCDBottomThermalStrap_phy msc
>     11  -0.0176      -30      340      1.35   0.0599    0.144       1.6 SCDBottomThermalStrap_phy msc
>     12  -0.0541    -29.9      340      1.22    0.137    0.161      1.76 SCDBottomThermalStrap_phy msc
>     13  -0.0973    -29.8      340      1.15   0.0687    0.184      1.94 SCDBottomThermalStrap_phy msc
>     14   -0.198    -29.8      340       1.1   0.0533    0.184      2.13 SCDBottomThermalStrap_phy msc
>     15   -0.277    -29.9      339      1.04   0.0519    0.184      2.31 SCDBottomThermalStrap_phy msc
>     16    -0.43    -29.9      339     0.968   0.0755    0.184       2.5 SCDBottomThermalStrap_phy msc
>     17   -0.564      -30      339     0.768    0.199    0.184      2.68 SCDBottomThermalStrap_phy msc
>     18    -0.68    -30.1      339     0.714   0.0544    0.184      2.87 SCDBottomThermalStrap_phy msc
>     19   -0.774      -30      339     0.649   0.0655    0.184      3.05 SCDBottomThermalStrap_phy msc
>     20   -0.819    -29.9      339     0.594   0.0542    0.184      3.23 SCDBottomThermalStrap_phy msc
>     21   -0.863    -29.7      339     0.466    0.129    0.184      3.42 SCDBottomThermalStrap_phy msc
>     22   -0.859    -29.7      339     0.361    0.105    0.149      3.57   world_phy Transportation
>     23   -0.859    -29.7      339     0.361        0        0      3.57 SCDBottomThermalStrap_phy Transportation
>     24   -0.864    -29.6      339     0.355   0.0064   0.0118      3.58 SCDBottomThermalStrap_phy msc
>     25   -0.865    -29.6      339     0.354 0.000422  0.00194      3.58   world_phy Transportation
>     26    -45.9     55.8      329     0.354 1.19e-20     97.1       101 SCDBottomCover_phy Transportation
>     27    -45.9     55.8      329     0.349  0.00469   0.0115       101 SCDBottomCover_phy msc
>     28    -45.9     55.8      329     0.342  0.00789   0.0115       101 SCDBottomCover_phy msc
>     29    -45.9     55.8      329     0.337   0.0042   0.0115       101 SCDBottomCover_phy msc
>     30    -45.9     55.8      329     0.326   0.0114   0.0115       101 SCDBottomCover_phy msc
>     31    -45.9     55.8      329     0.323  0.00337   0.0115       101 SCDBottomCover_phy msc
>     32    -45.9     55.8      329     0.318  0.00456   0.0115       101 SCDBottomCover_phy msc
>     33    -45.9     55.9      329     0.315  0.00306   0.0115       101 SCDBottomCover_phy msc
>     34    -45.9     55.9      329     0.311  0.00358   0.0115       101 SCDBottomCover_phy msc
>     35    -45.9     55.9      329     0.307  0.00385   0.0115       101 SCDBottomCover_phy msc
>     36    -45.9     55.9      329     0.302  0.00528   0.0115       101 SCDBottomCover_phy msc
>     37      -46     55.9      329     0.299  0.00324   0.0115       101 SCDBottomCover_phy msc
>     38      -46     55.9      329     0.294  0.00484   0.0115       101 SCDBottomCover_phy msc
>     39      -46     55.9      329     0.289  0.00498   0.0115       101 SCDBottomCover_phy msc
>     40      -46     55.9      329     0.285   0.0046   0.0115       101 SCDBottomCover_phy msc
>     41      -46     55.9      329      0.14    0.145   0.0115       101 SCDBottomCover_phy msc
>     42      -46     55.9      329     0.128   0.0121   0.0115       101 SCDBottomCover_phy msc
>     43      -46     55.9      329     0.111    0.017   0.0115       101 SCDBottomCover_phy msc
>     44      -46     55.9      329     0.105  0.00628   0.0115       101 SCDBottomCover_phy msc
>     45      -46     55.9      329    0.0962  0.00836   0.0115       101 SCDBottomCover_phy msc
>     46      -46     55.9      329    0.0898  0.00636   0.0115       101 SCDBottomCover_phy msc
>     47      -46     55.9      329    0.0798     0.01   0.0115       101 SCDBottomCover_phy msc
>     48      -46     55.9      329      0.07  0.00978   0.0115       101 SCDBottomCover_phy msc
>     49      -46     55.9      329    0.0516   0.0184   0.0115       101 SCDBottomCover_phy msc
>     50      -46     55.9      329    0.0274   0.0242   0.0115       101 SCDBottomCover_phy msc
>     51      -46     55.9      329         0   0.0274  0.00758       101 SCDBottomCover_phy eIoni
>
> *********************************************************************************************************
> * G4Track Information:   Particle = e-,   Track ID = 5,   Parent ID = 1
> *********************************************************************************************************
>
> Step#    X(mm)    Y(mm)    Z(mm) KinE(MeV)  dE(MeV) StepLeng TrackLeng  NextVolume ProcName
>      0    0.363      -31      340      2.88        0        0         0 SCDBottomThermalStrap_phy initStep
>      1    0.527    -30.9      340      2.79   0.0956    0.379     0.379 SCDBottomThermalStrap_phy msc
>      2    0.616    -30.8      340      2.66    0.123    0.379     0.758 SCDBottomThermalStrap_phy msc
>      3    0.785    -30.7      339      2.55    0.109    0.379      1.14 SCDBottomThermalStrap_phy msc
>      4     0.94      -31      339       2.4    0.156    0.379      1.52 SCDBottomThermalStrap_phy msc
>      5     1.13    -31.3      339      2.29    0.106    0.379      1.89 SCDBottomThermalStrap_phy msc
>      6     1.34    -31.6      339      2.15    0.143    0.379      2.27 SCDBottomThermalStrap_phy msc
>      7     1.66    -31.8      339      2.03    0.121    0.379      2.65 SCDBottomThermalStrap_phy msc
>      8     1.82    -31.9      339      1.95   0.0794    0.185      2.84   world_phy Transportation
>      9       14    -38.7      329      1.95 1.68e-21     17.2        20 SCDBottomCover_phy Transportation
>     10     14.1    -38.7      329       1.9   0.0506     0.16      20.2 SCDBottomCover_phy msc
>     11     14.2    -38.8      329      1.85   0.0465     0.16      20.3 SCDBottomCover_phy msc
>     12     14.3    -38.8      329       1.8   0.0544     0.16      20.5 SCDBottomCover_phy msc
>     13     14.4    -38.7      329      1.75   0.0464     0.16      20.6 SCDBottomCover_phy msc
>     14     14.5    -38.7      329       1.7   0.0525    0.157      20.8   world_phy Transportation
>     15  1.3e+03      236     -727       1.7 1.65e-19 1.69e+03  1.71e+03  OutOfWorld Transportation
>
> *********************************************************************************************************
> * G4Track Information:   Particle = e-,   Track ID = 6,   Parent ID = 1
> *********************************************************************************************************
>
> Step#    X(mm)    Y(mm)    Z(mm) KinE(MeV)  dE(MeV) StepLeng TrackLeng  NextVolume ProcName
>      0      1.7    -34.6      329      2.89        0        0         0 SCDBottomCover_phy initStep
>      1     1.77    -34.7      329      2.85    0.039    0.159     0.159   world_phy Transportation
>      2      908 -1.3e+03 -1.21e+03      2.85  2.2e-19 2.19e+03  2.19e+03  OutOfWorld Transportation
>
> -------------------------------------------------------------
> Visit this GEANT4 at hypernews.slac.stanford.edu message (to reply or unsubscribe) at:
> http://hypernews.slac.stanford.edu/HyperNews/geant4/get/fastsim/50.html
>    
None RE: detecting particle leaving a volume  by naima <naima>,   18 Feb, 2010
--_b683cf6c-26f2-4e8a-bcc9-d2653a00bf9b_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable



=20
=20


 Hi there  =2C
In fact in my works=2CI try to simulate interactions of neutrons with mater=
ials(this is for neutron diffraction experiment).In particular =2Cnow I try=
 to optimize the dimensions of shielding material composed of Al2O3 (sapphi=
re ) as filter of thermal neutrons ....the geometries are very simple=2CI u=
se only cylinders or cubes . In other words =2Csuppose I use  12 cm of Al2O=
3 as shielding material =2C and I would like to determine the efficiency of=
 this shielding material=2Cthen I have to determine the fraction of neutron=
s that are transmitted .
After the shielding material =2CI'm created a vacuum geometry in ''Detector=
Construction'' and defined it as sensitive detector .I use  PostStepPoint =
=3D=3DfGeometryBoundary to detect a particle leaving from shielding materia=
l Al2O3 =2Cand I use touchable to verified (gives volume or region which lo=
cate the particle leaved from the shielding material Al2O3).
But we have 2 procedure to make in file ''SD'' =20
 G4bool neutronTrackerSD::ProcessHits(G4Step* aStep=2CG4TouchableHistory* R=
Ohist)
{
  G4Track* aTrack =3D aStep->GetTrack()=3B
  G4double edep =3D aStep->GetTotalEnergyDeposit()=3B
  G4StepPoint* point1=3DaStep->GetPreStepPoint()=3B
  G4StepPoint* point2=3DaStep->GetPostStepPoint()=3B
 =20
if (point2->GetStepStatus()=3D=3DfGeomBoundary)
  {
  G4TouchableHandle touch2 =3D point1->GetTouchableHandle()=3B
  G4VPhysicalVolume* volume2 =3D touch2->GetVolume()=3B
  G4String name =3D volume2->GetName()=3B
  G4cout<<"volume "<<name<<G4endl=3B
                                                   and=20
G4bool neutronTrackerSD::ProcessHits(G4Step* aStep=2CG4TouchableHistory* RO=
hist)
{
  G4Track* aTrack =3D aStep->GetTrack()=3B
  G4double edep =3D aStep->GetTotalEnergyDeposit()=3B
  G4StepPoint* point1=3DaStep->GetPreStepPoint()=3B
  G4StepPoint* point2=3DaStep->GetPostStepPoint()=3B
 =20
  if (point2->GetStepStatus()=3D=3DfGeomBoundary)
  {
  G4TouchableHandle touch2 =3D point2->GetTouchableHandle()=3B
  G4VPhysicalVolume* volume2 =3D touch2->GetVolume()=3B
  G4String name =3D volume2->GetName()=3B
  G4cout<<"volume "<<name<<G4endl=3B
=20
 In the file ''neutronTrackerSD.cc ' 'If I use=20
G4bool neutronTrackerSD::ProcessHits(G4Step* aStep=2CG4TouchableHistory* RO=
hist)
{
  G4Track* aTrack =3D aStep->GetTrack()=3B
  G4double edep =3D aStep->GetTotalEnergyDeposit()=3B
  G4StepPoint* point1=3DaStep->GetPreStepPoint()=3B
  G4StepPoint* point2=3DaStep->GetPostStepPoint()=3B
 =20
  if (point2->GetStepStatus()=3D=3DfGeomBoundary)
  {
  G4TouchableHandle touch2 =3D point1->GetTouchableHandle()=3B
  G4VPhysicalVolume* volume2 =3D touch2->GetVolume()=3B
  G4String name =3D volume2->GetName()=3B
  G4cout<<"volume "<<name<<G4endl=3B
I get this results volume Tubs1
>>> Event 62
    420 trajectories stored in this event.
volume Tubs
volume Tubs1
volume Tubs
volume Tubs1
volume Tubs
volume Tubs1
volume Tubs
volume Tubstransmission
volume Tubs1
volume Tubs
volume Tubs1
volume Tubs
volume Tubs1
volume Tubs
volume Tubs1
(such as tubs1 is the name of the world volume(vacuum)=2C Tubs is the name =
of  shielding material(Al2O3) and Tubstransmission is the name of vaccum ge=
ometry('detector' after shielding material)).

Hi there =2C
In fact in my works=2CI try to simulate interactions of neutrons with mater=
ials(this is for neutron diffraction experiment).In particular =2Cnow I try=
 to optimize the dimensions of shielding material composed of Al2O3 (sapphi=
re ) as filter of thermal neutrons ....the geometries are very simple=2CI u=
se only cylinders or cubes . In other words =2Csuppose I use  12 cm of Al2O=
3 as shielding material =2C and I would like to determine the efficiency of=
 this shielding material=2Cthen I have to determine the fraction of neutron=
s that are transmitted .
After the shielding material =2CI'm created a vacuum geometry in ''Detector=
Construction'' and defined it as sensitive detector .I use  PostStepPoint =
=3D=3DfGeometryBoundary to detect a particle leaving from shielding materia=
l Al2O3 =2Cand I use touchable to verified (gives volume or region which lo=
cate the particle leaved from the shielding material Al2O3).
But we have 2 procedure to make in file ''SD'' =20
 G4bool neutronTrackerSD::ProcessHits(G4Step* aStep=2CG4TouchableHistory* R=
Ohist)
{
  G4Track* aTrack =3D aStep->GetTrack()=3B
  G4double edep =3D aStep->GetTotalEnergyDeposit()=3B
  G4StepPoint* point1=3DaStep->GetPreStepPoint()=3B
  G4StepPoint* point2=3DaStep->GetPostStepPoint()=3B
 =20
  if (point2->GetStepStatus()=3D=3DfGeomBoundary)
  {
  G4TouchableHandle touch2 =3D point1->GetTouchableHandle()=3B
  G4VPhysicalVolume* volume2 =3D touch2->GetVolume()=3B
  G4String name =3D volume2->GetName()=3B
  G4cout<<"volume "<<name<<G4endl=3B
                                                   and=20
G4bool neutronTrackerSD::ProcessHits(G4Step* aStep=2CG4TouchableHistory* RO=
hist)
{
  G4Track* aTrack =3D aStep->GetTrack()=3B
  G4double edep =3D aStep->GetTotalEnergyDeposit()=3B
  G4StepPoint* point1=3DaStep->GetPreStepPoint()=3B
  G4StepPoint* point2=3DaStep->GetPostStepPoint()=3B
 =20
  if (point2->GetStepStatus()=3D=3DfGeomBoundary)
  {
  G4TouchableHandle touch2 =3D point2->GetTouchableHandle()=3B
  G4VPhysicalVolume* volume2 =3D touch2->GetVolume()=3B
  G4String name =3D volume2->GetName()=3B
  G4cout<<"volume "<<name<<G4endl=3B
=20
 In the file ''neutronTrackerSD.cc ' 'If I use=20
G4bool neutronTrackerSD::ProcessHits(G4Step* aStep=2CG4TouchableHistory* RO=
hist)
{
  G4Track* aTrack =3D aStep->GetTrack()=3B
  G4double edep =3D aStep->GetTotalEnergyDeposit()=3B
  G4StepPoint* point1=3DaStep->GetPreStepPoint()=3B
  G4StepPoint* point2=3DaStep->GetPostStepPoint()=3B
 =20
  if (point2->GetStepStatus()=3D=3DfGeomBoundary)
  {
  G4TouchableHandle touch2 =3D point1->GetTouchableHandle()=3B
  G4VPhysicalVolume* volume2 =3D touch2->GetVolume()=3B
  G4String name =3D volume2->GetName()=3B
  G4cout<<"volume "<<name<<G4endl=3B
I get this results volume Tubs1
>>> Event 62
    420 trajectories stored in this event.
volume Tubs
volume Tubs1
volume Tubs
volume Tubs1
volume Tubs
volume Tubs1
volume Tubs
volume Tubstransmission
volume Tubs1
volume Tubs
volume Tubs1
volume Tubs
volume Tubs1
volume Tubs
volume Tubs1
(such as tubs1 is the name of the world volume(vacuum)=2C Tubs is the name =
of  shielding material(Al2O3) and Tubstransmission is the name of vaccum ge=
ometry('detector' after shielding material)).

> If I use  in the file ''SD''
if (point2->GetStepStatus()=3D=3DfGeomBoundary)
  {
  G4TouchableHandle touch2 =3D point2->GetTouchableHandle()=3B
  G4VPhysicalVolume* volume2 =3D touch2->GetVolume()=3B
  G4String name =3D volume2->GetName()=3B
  G4cout<<"volume "<<name<<G4endl=3B=20
I get this result
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
### Run 0 start.
/tracking/storeTrajectory 1
/vis~/clear/view
/vis~/draw/current
volume Tubs1
 *** Break *** segmentation violation
(no debugging symbols found)
Using host libthread_db library "/lib64/tls/libthread_db.so.1".
Attaching to program: /proc/9544/exe=2C process 9544
(no debugging symbols found)...done.
(no debugging symbols found)...done.
> My problem is what's the difference betweenif (point2->GetStepStatus()=3D=
=3DfGeomBoundary)
  {
  G4TouchableHandle touch2 =3D point2->GetTouchableHandle()=3B=20
                                          and
 if (point2->GetStepStatus()=3D=3DfGeomBoundary)
  {
  G4TouchableHandle touch2 =3D point1->GetTouchableHandle()=3B
>what's the corectness result I use to give the fraction of particle are tr=
ansmitted and how to resolve error of segmentation violation.
Many thanks.
Naima.=20



Hotmail : une messagerie performante et gratuite avec une s=E9curit=E9 sign=
=E9e Microsoft Profitez-en



Hotmail : un service de messagerie gratuit=2C fiable et complet Profitez-en



Hotmail : une messagerie performante et gratuite avec une s=E9curit=E9 sign=
=E9e Microsoft Profitez-en
           =20
_________________________________________________________________
Hotmail : une messagerie fiable avec la protection anti-spam performante de=
 Microsoft
https://signup.live.com/signup.aspx?id=3D60969=

--_b683cf6c-26f2-4e8a-bcc9-d2653a00bf9b_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style><!--
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
--></style>
</head>
<body class=3D'hmmessage'>
<BR>&nbsp=3B<BR>&nbsp=3B<BR>
<STYLE>
.ExternalClass .ecxhmmessage P
{padding:0px=3B}
.ExternalClass body.ecxhmmessage
{font-size:10pt=3Bfont-family:Verdana=3B}
</STYLE>
&nbsp=3BHi there &nbsp=3B=2C<BR>In fact in my works=2CI try to simulate int=
eractions of neutrons with materials(this is for neutron diffraction experi=
ment).In particular =2Cnow I try to optimize the dimensions of shielding ma=
terial composed of Al2O3 (sapphire ) as filter of thermal neutrons ....the =
geometries are very simple=2CI use only cylinders or cubes . In other&nbsp=
=3Bwords =2Csuppose I use&nbsp=3B 12 cm of Al2O3&nbsp=3Bas shielding materi=
al&nbsp=3B=2C and I&nbsp=3Bwould like to determine the efficiency of this s=
hielding material=2Cthen I have to determine the fraction of neutrons that =
are transmitted .<BR>After the shielding material =2CI'm created a vacuum g=
eometry in ''DetectorConstruction'' and defined it as sensitive detector .I=
 use&nbsp=3B PostStepPoint =3D=3DfGeometryBoundary to detect a particle lea=
ving from shielding material Al2O3 =2Cand I use touchable to verified (give=
s volume or region which locate the particle leaved from the shielding mate=
rial Al2O3).<BR>But we have 2 procedure to make in file ''SD'' &nbsp=3B<BR>=
&nbsp=3B<STRONG>G4bool neutronTrackerSD::ProcessHits(G4Step* aStep=2CG4Touc=
hableHistory* ROhist)<BR>{<BR>&nbsp=3B G4Track* aTrack =3D aStep-&gt=3BGetT=
rack()=3B<BR>&nbsp=3B G4double edep =3D aStep-&gt=3BGetTotalEnergyDeposit()=
=3B<BR>&nbsp=3B G4StepPoint* point1=3DaStep-&gt=3BGetPreStepPoint()=3B<BR>&=
nbsp=3B G4StepPoint* point2=3DaStep-&gt=3BGetPostStepPoint()=3B<BR>&nbsp=3B=
&nbsp=3B<BR></STRONG><STRONG><FONT color=3D#ff0000>if (point2-&gt=3BGetStep=
Status()=3D=3DfGeomBoundary)<BR></FONT>&nbsp=3B {<BR>&nbsp=3B G4TouchableHa=
ndle touch2 =3D <FONT color=3D#ff0000>point1</FONT>-&gt=3BGetTouchableHandl=
e()=3B<BR>&nbsp=3B G4VPhysicalVolume* volume2 =3D touch2-&gt=3BGetVolume()=
=3B<BR>&nbsp=3B G4String name =3D volume2-&gt=3BGetName()=3B<BR>&nbsp=3B G4=
cout&lt=3B&lt=3B"volume "&lt=3B&lt=3Bname&lt=3B&lt=3BG4endl=3B<BR><FONT col=
or=3D#002060>&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=
=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B=
&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nb=
sp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=
=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B=
&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B and</FONT> <BR>G4bool neutronTrack=
erSD::ProcessHits(G4Step* aStep=2CG4TouchableHistory* ROhist)<BR>{<BR>&nbsp=
=3B G4Track* aTrack =3D aStep-&gt=3BGetTrack()=3B<BR>&nbsp=3B G4double edep=
 =3D aStep-&gt=3BGetTotalEnergyDeposit()=3B<BR>&nbsp=3B G4StepPoint* point1=
=3DaStep-&gt=3BGetPreStepPoint()=3B<BR>&nbsp=3B G4StepPoint* point2=3DaStep=
-&gt=3BGetPostStepPoint()=3B<BR></STRONG>&nbsp=3B <BR><FONT color=3D#ff0000=
>&nbsp=3B <STRONG>if (point2-&gt=3BGetStepStatus()=3D=3DfGeomBoundary)</STR=
ONG></FONT><BR>&nbsp=3B<STRONG> {<BR>&nbsp=3B G4TouchableHandle touch2 =3D<=
/STRONG> <STRONG><FONT color=3D#ff0000>point2</FONT>-&gt=3BGetTouchableHand=
le()=3B<BR></STRONG>&nbsp=3B <STRONG>G4VPhysicalVolume* volume2 =3D touch2-=
&gt=3BGetVolume()=3B<BR>&nbsp=3B G4String name =3D volume2-&gt=3BGetName()=
=3B<BR>&nbsp=3B G4cout&lt=3B&lt=3B"volume "&lt=3B&lt=3Bname&lt=3B&lt=3BG4en=
dl=3B<BR></STRONG>&nbsp=3B<BR>&nbsp=3BIn the file ''neutronTrackerSD.cc ' '=
If I use <BR><STRONG>G4bool neutronTrackerSD::ProcessHits(G4Step* aStep=2CG=
4TouchableHistory* ROhist)<BR>{<BR>&nbsp=3B G4Track* aTrack =3D aStep-&gt=
=3BGetTrack()=3B<BR>&nbsp=3B G4double edep =3D aStep-&gt=3BGetTotalEnergyDe=
posit()=3B<BR>&nbsp=3B G4StepPoint* point1=3DaStep-&gt=3BGetPreStepPoint()=
=3B<BR>&nbsp=3B G4StepPoint* point2=3DaStep-&gt=3BGetPostStepPoint()=3B<BR>=
&nbsp=3B <BR>&nbsp=3B </STRONG><STRONG><FONT color=3D#ff0000>if (point2-&gt=
=3BGetStepStatus()=3D=3DfGeomBoundary)<BR></FONT>&nbsp=3B {<BR>&nbsp=3B G4T=
ouchableHandle touch2 =3D <FONT color=3D#ff0000>point1</FONT>-&gt=3BGetTouc=
hableHandle()=3B<BR>&nbsp=3B G4VPhysicalVolume* volume2 =3D touch2-&gt=3BGe=
tVolume()=3B<BR>&nbsp=3B G4String name =3D volume2-&gt=3BGetName()=3B<BR>&n=
bsp=3B G4cout&lt=3B&lt=3B"volume "&lt=3B&lt=3Bname&lt=3B&lt=3BG4endl=3B<BR>=
</STRONG>I get this results volume Tubs1<BR>&gt=3B&gt=3B&gt=3B Event 62<BR>=
&nbsp=3B&nbsp=3B&nbsp=3B 420 trajectories stored in this event.<BR>volume T=
ubs<BR>volume Tubs1<BR>volume Tubs<BR>volume Tubs1<BR>volume Tubs<BR>volume=
 Tubs1<BR>volume Tubs<BR>volume Tubstransmission<BR>volume Tubs1<BR>volume =
Tubs<BR>volume Tubs1<BR>volume Tubs<BR>volume Tubs1<BR>volume Tubs<BR>volum=
e Tubs1<BR>(such as <FONT color=3D#ff0000>tubs1</FONT> is the name of the w=
orld volume(vacuum)=2C <FONT color=3D#ff0000>Tubs</FONT> is&nbsp=3Bthe name=
 of &nbsp=3Bshielding material(Al2O3) and Tubstransmission is the name&nbsp=
=3Bof vaccum geometry('detector' after shielding material)).<BR><BR>Hi ther=
e =2C<BR>In fact in my works=2CI try to simulate interactions of neutrons w=
ith materials(this is for neutron diffraction experiment).In particular =2C=
now I try to optimize the dimensions of shielding material composed of Al2O=
3 (sapphire ) as filter of thermal neutrons ....the geometries are very sim=
ple=2CI use only cylinders or cubes . In other&nbsp=3Bwords =2Csuppose I us=
e&nbsp=3B 12 cm of Al2O3&nbsp=3Bas shielding material&nbsp=3B=2C and I&nbsp=
=3Bwould like to determine the efficiency of this shielding material=2Cthen=
 I have to determine the fraction of neutrons that are transmitted .<BR>Aft=
er the shielding material =2CI'm created a vacuum geometry in ''DetectorCon=
struction'' and defined it as sensitive detector .I use&nbsp=3B PostStepPoi=
nt =3D=3DfGeometryBoundary to detect a particle leaving from shielding mate=
rial Al2O3 =2Cand I use touchable to verified (gives volume or region which=
 locate the particle leaved from the shielding material Al2O3).<BR>But we h=
ave 2 procedure to make in file ''SD'' &nbsp=3B<BR>&nbsp=3B<STRONG>G4bool n=
eutronTrackerSD::ProcessHits(G4Step* aStep=2CG4TouchableHistory* ROhist)<BR=
>{<BR>&nbsp=3B G4Track* aTrack =3D aStep-&gt=3BGetTrack()=3B<BR>&nbsp=3B G4=
double edep =3D aStep-&gt=3BGetTotalEnergyDeposit()=3B<BR>&nbsp=3B G4StepPo=
int* point1=3DaStep-&gt=3BGetPreStepPoint()=3B<BR>&nbsp=3B G4StepPoint* poi=
nt2=3DaStep-&gt=3BGetPostStepPoint()=3B<BR>&nbsp=3B <BR>&nbsp=3B <FONT colo=
r=3D#ff0000>if (point2-&gt=3BGetStepStatus()=3D=3DfGeomBoundary)<BR></FONT>=
&nbsp=3B {<BR>&nbsp=3B G4TouchableHandle touch2 =3D <FONT color=3D#ff0000>p=
oint1</FONT>-&gt=3BGetTouchableHandle()=3B<BR>&nbsp=3B G4VPhysicalVolume* v=
olume2 =3D touch2-&gt=3BGetVolume()=3B<BR>&nbsp=3B G4String name =3D volume=
2-&gt=3BGetName()=3B<BR>&nbsp=3B G4cout&lt=3B&lt=3B"volume "&lt=3B&lt=3Bnam=
e&lt=3B&lt=3BG4endl=3B</STRONG><BR><STRONG><FONT color=3D#002060>&nbsp=3B&n=
bsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=
=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B=
&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nb=
sp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=
=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B=
&nbsp=3B&nbsp=3B and</FONT> </STRONG><BR><STRONG>G4bool neutronTrackerSD::P=
rocessHits(G4Step* aStep=2CG4TouchableHistory* ROhist)<BR>{<BR>&nbsp=3B G4T=
rack* aTrack =3D aStep-&gt=3BGetTrack()=3B<BR>&nbsp=3B G4double edep =3D aS=
tep-&gt=3BGetTotalEnergyDeposit()=3B<BR>&nbsp=3B G4StepPoint* point1=3DaSte=
p-&gt=3BGetPreStepPoint()=3B<BR>&nbsp=3B G4StepPoint* point2=3DaStep-&gt=3B=
GetPostStepPoint()=3B<BR></STRONG>&nbsp=3B <BR><FONT color=3D#ff0000>&nbsp=
=3B <STRONG>if (point2-&gt=3BGetStepStatus()=3D=3DfGeomBoundary)</STRONG></=
FONT><BR>&nbsp=3B<STRONG> {<BR>&nbsp=3B G4TouchableHandle touch2 =3D</STRON=
G> <STRONG><FONT color=3D#ff0000>point2</FONT>-&gt=3BGetTouchableHandle()=
=3B<BR></STRONG>&nbsp=3B <STRONG>G4VPhysicalVolume* volume2 =3D touch2-&gt=
=3BGetVolume()=3B<BR>&nbsp=3B G4String name =3D volume2-&gt=3BGetName()=3B<=
BR>&nbsp=3B G4cout&lt=3B&lt=3B"volume "&lt=3B&lt=3Bname&lt=3B&lt=3BG4endl=
=3B<BR></STRONG>&nbsp=3B<BR>&nbsp=3BIn the file ''neutronTrackerSD.cc ' 'If=
 I use <BR><STRONG>G4bool neutronTrackerSD::ProcessHits(G4Step* aStep=2CG4T=
ouchableHistory* ROhist)<BR>{<BR>&nbsp=3B G4Track* aTrack =3D aStep-&gt=3BG=
etTrack()=3B<BR>&nbsp=3B G4double edep =3D aStep-&gt=3BGetTotalEnergyDeposi=
t()=3B<BR>&nbsp=3B G4StepPoint* point1=3DaStep-&gt=3BGetPreStepPoint()=3B<B=
R>&nbsp=3B G4StepPoint* point2=3DaStep-&gt=3BGetPostStepPoint()=3B<BR>&nbsp=
=3B <BR>&nbsp=3B </STRONG><STRONG><FONT color=3D#ff0000>if (point2-&gt=3BGe=
tStepStatus()=3D=3DfGeomBoundary)<BR></FONT>&nbsp=3B {<BR>&nbsp=3B G4Toucha=
bleHandle touch2 =3D <FONT color=3D#ff0000>point1</FONT>-&gt=3BGetTouchable=
Handle()=3B<BR>&nbsp=3B G4VPhysicalVolume* volume2 =3D touch2-&gt=3BGetVolu=
me()=3B<BR>&nbsp=3B G4String name =3D volume2-&gt=3BGetName()=3B<BR>&nbsp=
=3B G4cout&lt=3B&lt=3B"volume "&lt=3B&lt=3Bname&lt=3B&lt=3BG4endl=3B</STRON=
G><BR>I get this results volume Tubs1<BR>&gt=3B&gt=3B&gt=3B Event 62<BR>&nb=
sp=3B&nbsp=3B&nbsp=3B 420 trajectories stored in this event.<BR>volume Tubs=
<BR>volume Tubs1<BR>volume Tubs<BR>volume Tubs1<BR>volume Tubs<BR>volume Tu=
bs1<BR>volume Tubs<BR>volume Tubstransmission<BR>volume Tubs1<BR>volume Tub=
s<BR>volume Tubs1<BR>volume Tubs<BR>volume Tubs1<BR>volume Tubs<BR>volume T=
ubs1<BR>(such as <FONT color=3D#ff0000>tubs1</FONT> is the name of the worl=
d volume(vacuum)=2C <FONT color=3D#ff0000>Tubs</FONT> is&nbsp=3Bthe name of=
 &nbsp=3Bshielding material(Al2O3) and Tubstransmission is the name&nbsp=3B=
of vaccum geometry('detector' after shielding material)).<BR><BR>&gt=3B If =
I use&nbsp=3B in the file ''SD''<BR><STRONG><FONT color=3D#ff0000>if (point=
2-&gt=3BGetStepStatus()=3D=3DfGeomBoundary)<BR></FONT></STRONG>&nbsp=3B<STR=
ONG> {<BR>&nbsp=3B G4TouchableHandle touch2 =3D</STRONG> <STRONG><FONT colo=
r=3D#ff0000>point2</FONT>-&gt=3BGetTouchableHandle()=3B<BR></STRONG>&nbsp=
=3B <STRONG>G4VPhysicalVolume* volume2 =3D touch2-&gt=3BGetVolume()=3B<BR>&=
nbsp=3B G4String name =3D volume2-&gt=3BGetName()=3B<BR>&nbsp=3B G4cout&lt=
=3B&lt=3B"volume "&lt=3B&lt=3Bname&lt=3B&lt=3BG4endl=3B </STRONG><BR><STRON=
G>I get this result</STRONG><BR>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<BR>###=
 Run 0 start.<BR>/tracking/storeTrajectory 1<BR>/vis~/clear/view<BR>/vis~/d=
raw/current<BR>volume Tubs1<BR>&nbsp=3B*** Break *** segmentation violation=
<BR>(no debugging symbols found)<BR>Using host libthread_db library "/lib64=
/tls/libthread_db.so.1".<BR>Attaching to program: /proc/9544/exe=2C process=
 9544<BR>(no debugging symbols found)...done.<BR>(no debugging symbols foun=
d)...done.<BR><STRONG>&gt=3B</STRONG> My problem is what's the difference b=
etween<STRONG><FONT color=3D#ff0000>if (point2-&gt=3BGetStepStatus()=3D=3Df=
GeomBoundary)<BR></FONT></STRONG>&nbsp=3B<STRONG> {<BR>&nbsp=3B G4Touchable=
Handle touch2 =3D</STRONG> <STRONG><FONT color=3D#ff0000>point2</FONT>-&gt=
=3BGetTouchableHandle()=3B </STRONG><BR><STRONG>&nbsp=3B&nbsp=3B&nbsp=3B&nb=
sp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=
=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B=
&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nb=
sp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=
=3B <FONT color=3D#002060>and</FONT></STRONG><BR><STRONG><FONT color=3D#002=
060>&nbsp=3B<FONT color=3D#ff0000>if (point2-&gt=3BGetStepStatus()=3D=3DfGe=
omBoundary)<BR></FONT><FONT color=3D#000000>&nbsp=3B {<BR>&nbsp=3B G4Toucha=
bleHandle touch2 =3D </FONT><FONT color=3D#ff0000>point1</FONT><FONT color=
=3D#000000>-&gt=3BGetTouchableHandle()=3B</FONT></FONT></STRONG><BR><FONT c=
olor=3D#002060><FONT color=3D#000000><STRONG>&gt=3B</STRONG>what's the core=
ctness result I use to give the fraction of particle are transmitted and ho=
w to resolve&nbsp=3Berror of segmentation violation.</FONT></FONT><BR><FONT=
 color=3D#002060><FONT color=3D#000000>Many thanks.</FONT></FONT><BR><FONT =
color=3D#002060><FONT color=3D#000000>Naima. </FONT><BR></FONT><BR>
<HR>
Hotmail : une messagerie performante et gratuite avec une s=E9curit=E9 sign=
=E9e Microsoft <A href=3D"https://signup.live.com/signup.aspx?id=3D60969">P=
rofitez-en</A><BR><BR>
<HR>
Hotmail : un service de messagerie gratuit=2C fiable et complet <A href=3D"=
https://signup.live.com/signup.aspx?id=3D60969">Profitez-en</A><BR><BR>
<HR>
Hotmail : une messagerie performante et gratuite avec une s=E9curit=E9 sign=
=E9e Microsoft <A href=3D"https://signup.live.com/signup.aspx?id=3D60969">P=
rofitez-en</A><BR>            <br /><hr />Hotmail : une messagerie fiable a=
vec la protection anti-spam performante de Microsoft <a href=3D'https://sig=
nup.live.com/signup.aspx?id=3D60969' target=3D'_new'>Inscrivez-vous</a></bo=
dy>
</html>=

--_b683cf6c-26f2-4e8a-bcc9-d2653a00bf9b_--

None Re: RE: detecting particle leaving a volume  by smith <smith>,   08 Oct, 2012
Re: None RE: detecting particle leaving a volume (naima)
Hello, i am working on neutron detector.i am using two material in it upper layer is TIB2 and lower is made of silicon.i want to know that how i can confirm that material are deposited correctly. Regards smith

Warning Pitfall in materials building  by Wm. Heintzelman <Wm. Heintzelman>,   22 Jan, 2010
The design of the class G4NistMaterialBuilder makes it possible for
a Geant user to unknowingly introduce an error in materials building.

A list of pointers to the materials that have already been built
is maintained in class 'G4Material' as 'static G4MaterialTable
theMaterialTable;'.  As materials are built, pointers to them are
added to this table.  When NIST materials are built, they are added
to the table by 'G4NistMaterialBuilder::FindOrBuildMaterial()',
and the index of the NIST material's entry in 'theMaterialTable'
is saved in class 'G4NistMaterialBuilder' in a private array
'std::vector<G4int> matIndex;'.  In subsequent calls to
'G4NistMaterialBuilder::FindOrBuildMaterial' for a NIST material
that has already been built, the routine does not search in the name
array associated with 'theMaterialTable' to determine the index to
use to obtain the pointer to the material from 'theMaterialTable',
but simply uses the index that was previously saved in 'matIndex'.

If the user wants to build a list of materials, some of which have
components that are in the same list, a reasonable design is to
proceed through the list, attempt to build each material in turn,
and if a component is encountered that has not yet been built, to
return later for a another attempt at building the material after
the whole list has been processed.

Suppose the user's BuildMaterial routine begins to build a material
(for clarity, let's call that the target material), and creates
a new instance of the material class for the target and adds its
pointer to 'theMaterialTable'.  It then attempts to add all the
specified constituent materials to the target's definition.
However, if a constituent is encountered that has not yet been built,
it removes the target from 'theMaterialTable' and puts it on a list
for later reconsideration.

Now suppose that several materials A, B, and C have already been
built, and the remaining materials to be built are D, E, and X.
Further suppose D has a NIST constituent, N, and the non-NIST
constituent, X.  The 'G4Material' instance for D is created and
the pointer to D is added to 'theMaterialTable'; N is then built by
'G4NistMaterialBuilder::FindOrBuildMaterial' and added to the table,
which now has pointers to  (A B C D N); the value of 'matIndex' for
material N is set to the value 4, and N is added to the definition
of D.  But in continuing the building of D, X is encountered next.
Because X has not yet been built, building of D is aborted, its
'G4Material' instance is deleted, and its pointer is removed from
the table.  D is placed on the list for later re-consideration.
The table now has pointers to (A B C N).  E is built next,
followed by X, and finally D is built on the  second attempt, so
the table now contains (A B C N E X D), in that order.  However,
when 'G4NistMaterialBuilder::FindOrBuildMaterial' was called for
constituent material N during the second attempt at building D,
because N had previously been built, 'FindOrBuildMaterial' accessed
'matIndex' to retrieve the pointer to N from 'theMaterialTable'.
The index value, however, had not been changed after N was built
and still had the value 4; consequently the pointer used for N in
building material D actually pointed to material E, and material D
was built incorrectly, and its physical properties used in subsequent
calculations will be incorrect.

To avoid problems of this sort, I recommend that 'matIndex' in
'G4NistMaterialBuilder::FindOrBuildMaterial' should not
be used to save the index to the pointer of a built NIST material.
Instead, the material's name should be used to search the list of 
built materials and determine the index value at the time it is 
needed.

Below is output from "diff" comparing the standard 4.9.2 versions of 
G4NistMaterialBuilder.hh and G4NistMaterialBuilder.cc with changed 
versions that eliminate this pitfall.

---------------------------------------------------------------

G4NistMaterialBuilder.hh :
187c187
<   std::vector<G4int>     matIndex;
---
>   std::vector<G4bool>    builtFlag;

---------------------------------------------------------------

G4NistMaterialBuilder.cc :
101d100
<
104,111c103,107
<
<       // Build new Nist material
<       if(matIndex[i] == -1) mat = BuildMaterial(i, isotopes);
<       // Nist material was already built
<       else                  mat = (*theMaterialTable)[matIndex[i]];
<
<       return mat;
<
---
>         // Build Nist material if it hasn't already been built
>         if(~builtFlag[i]) {
>             mat = BuildMaterial(i, isotopes);
>             return mat;
>         }
115c111
<   // Check the list of all materials
---
>   // Check the list of materials already built
190c186
<   matIndex[i] = mat->GetIndex();
---
>   builtFlag[i] = true;
328c324
<   matIndex[idx] = mat->GetIndex();
---
>   builtFlag[idx] = true;
452c448
<   matIndex.push_back(-1);
---
>   builtFlag.push_back(false);

---------------------------------------------------------------

Note: This problem was found when using Geant 4.9.2.
Question Deposited energy larger than incoming energy in HadronElastic  by Estela Suarez <Estela Suarez>,   28 Sep, 2009
Hi,

I am simulating neutrons in the energy range 1MeV to 10MeV interacting in a plastic scintillator detector. I am quite puzzled about a phenomena that I have often observed when looking at the output of the GEANT4 simulation.

When an incoming neutron interacts with a proton of the scintillator via HadronElastic process, I have observed that in many cases the energy transmitted to the proton is larger than the one the neutron originally had.

I show you here an example of the verbose output where you can see that:

*********************************************************************************************************
* G4Track Information:   Particle = neutron,   Track ID = 1,   Parent ID = 0
*********************************************************************************************************
   1 12.340542 cm  13.62 cm 8.9103372 cm 4.150874 MeV     0 eV 30.735689 cm 30.735689 cm        World  Transportation
   2 12.250517 cm  13.42 cm 8.8474109 cm 4.150874 MeV     0 eV 2.2817578 mm 30.963864 cm    PMreplica  Transportation
  ........
  ... //some more transportation steps here that I remove to save space
  ........
  28 11.657142 cm 12.10175 cm 8.4326477 cm 4.150874 MeV     0 eV 11.408789 um 32.467828 cm   av_2_impr_46_scintelem_pv_0  Transportation
  29 11.598697 cm 11.971909 cm 8.3917955 cm      0 eV      0 eV 1.4813341 mm 32.615961 cm   scintillator  HadronElastic
Track (trackID 1, parentID 0) is processed with stopping code 2
### pop requested out of 1 stacked tracks.

*********************************************************************************************************
* G4Track Information:   Particle = proton,   Track ID = 2,   Parent ID = 1
*********************************************************************************************************

   1 11.588893 cm 11.950127 cm 8.3849425 cm      0 eV 4.1565704 MeV248.77296 um 248.77296 um   scintillator       hIoni

So, as you can see, the neutron energy was 4.150874 MeV , and the proton energy is after the Elastic interaction 4.1565704 MeV, i.e. 15.6964 keV higher.

I was wondering if this is a result of some mistake in my physics list that allows for energy violation, or if this extra energy is coming from somewhere else. Could it be something related with the difference between the neutron and proton mass? The mass ratio mp/mn = 0.99756, according to literature. I have calculated for some of my outputs the ratio Ep/En, and I have obtained values which are around 0,99863. Is it just by chance or are those values related?

I would be very thankful if somebody could give a clue of what is going on here.

Cheers, Estela.

Question Memory leakage using G4WrapperProcess: a user implementation  by Soon Yung Jun <Soon Yung Jun>,   31 Jul, 2009
Dear G4FastSimulation or Tracking Experts,

      The CMS experiment has developed and tested fast simulation models 
(named GflashEMShowerModel and GflashHadronShowerModel) for the CMS calorimeter
simulation based on G4VFastSimulationModel and tuned to various test beam data 
taken recently as well as geant4. However, we are experiencing a serious memory
leak from our hadronic model while testing a full chain of simulation for 
aiming a large scale production. Quantitatively the amount of memory leakage 
when using geant4 and GflashHadronShowerModel together is around 120 MB for 
100 ttbar events while the baseline memory consumption is only 50 MB when using
the full geant4.  We believe that this memory leakage comes from a possible 
ill-implementation of our hadronic wrapper process even though it has 
functionally worked for its own purpose of the hadronic shower 
parameterization.  Even though the source of the memory leakage may not be 
directly from the core geant4 routines, we would like to have your suggestions 
or comments on what we may try to resolve the issue.
   
To have more information how we use the G4WrapperProcess for our 
GflashHadronWrapperProcess in conjunction with GflashHadronShowerModel,
you may refer to our latest code from the cms lxr:

http://cmslxr.fnal.gov/lxr/source/SimG4Core/GFlash/src/GflashHadronShowerModel.cc 
http://cmslxr.fnal.gov/lxr/source/SimG4Core/GFlash/src/GflashHadronWrapperProcess.cc

Following is a short description of underlying logic flow of these two 
routines;

1) the first time call for GflashHadronShowerModel (i.e., fParameterisation 
   process) is simply by-passed when testing ``GPIL for PostStep'' in 
   G4SteppingManager (i.e., when testing fCurrentProcess->PostStepGPIL in 
   G4SteppingManager2.cc) 
2) GflashHadronWrapperProcess (which is now a wrapper process for the selected 
   process) is testing ``GPIL for PostStep'' again only for the 
   fParameterisation process whether dynamic conditions for 
   GflashHadronShowerModel::ModelTrigger is met after performing the 
   PostStepDoIt of the original process.
3) If GflashHadronShowerModel is selected as an ``ExclusivelyForced'' process, 
   then we invoke PostStepDoIt for the fParameterisation process and return 
   paticleChange from GflashHadronWrapperProcess.

There are redundant procedures of tracking in this logic flow, but at least the
wrapper has worked out as implemented for the rest of the parameterization 
process (i.e., making hits and killing the track).  Concerning to the memory 
leakage issue, a relevant question is whether switching the process from the 
original process (hadron inelastic interaction) to the parameterization process
during the stepping (i.e., at the particular stage of InvokePostStepDoItProcs 
in G4SteppingManager).  

Following lines of simplified code may be a snippet of the wrapper process, in 
which whether the second ``particleChange'' below the second commented line is 
legitimated or not:

G4VParticleChange* GflashHadronWrapperProcess::PostStepDoIt(
const G4Track& track, const G4Step& step) {

  //1. invoke PostStepDoIt for the original process
  particleChange = pRegProcess->PostStepDoIt(track, step);

  for(G4int ipm = 0 ; ipm < fProcessVector->entries() ; ipm++) {
    fProcess = (*fProcessVector)(ipm);

    if ( fProcess->GetProcessType() == fParameterisation ) {
      testGPIL = fProcess->PostStepGPIL(track,fStepLength,&fForceCondition );

      if( fForceCondition == ExclusivelyForced) {
        particleChange->Clear();

        //2. invoke PostStepDoIt for fParameterisation process
        particleChange = fProcess->PostStepDoIt(track,step);
      }
    }
  }
  return particleChange;
}

Our various tests show that invoking the second PostStepDoIt is directly
related to the memory leakage in question.  We also tested alternative 
implementations avoiding a possible mangle between the original process and 
the parameterization process;

1) instead of the invoking the second PostStepDoIt, we substitute all 
   implementations of GflashHadronShowerModel::DoIt to the line in question.
   In this case, the memory leak happens if we kill the track, i.e., including 
   following two lines which is equivalent to fastStep.KillPrimaryTrack(), 

   (const_cast<G4Track *> (&track))->SetTrackStatus( fStopAndKill );
   (const_cast<G4Track *> (&track))->SetKineticEnergy( 0.0);

2) an implementation without the wrapper, but invoking PostStepDoIt of the 
   original process locally inside GflashHadronShowerModel::ModelTrigger 
   to access information of secondary tracks.  Again, invoking the particular
   call of the line,
   particleChange = fProcess->PostStepDoIt(...);
   is directly responsible for the memory leak.

Our question is how memories of the original process including the
particleChange are cleaned up if we discard the process and switch to
a new process.  Or is the switching processes during stepping not allowed
at all?

Sorry for too much technical details, but please let us know if we did not
explain our problem clearly or did not provide enough information.  
Thank you for your help or any comment.

Regards,
---Soon Yung Jun
for the calorimeter task force of CMS

Ok Re: Memory leakage using G4WrapperProcess: a user implementation  by Soon Yung Jun <Soon Yung Jun>,   07 Aug, 2009
Re: Question Memory leakage using G4WrapperProcess: a user implementation (Soon Yung Jun)
It turns out that we should have deleted all secondaries of the original process to clean up leftover memory if the process is changed during stepping. This is a counter clean up for "new G4Track"s added in G4HadronicProcess::FillTotalResult which is called inside G4VParticleChange *G4HadronicProcess::PostStepDoIt once the process defined the step is switched to the parametrization process. So a proposed solution inside G4VParticleChange* GflashHadronWrapperProcess::PostStepDoIt is:

from
        particleChange->Clear();

to
        G4int nsecondary = particleChange->GetNumberOfSecondaries();
        for(G4int DSecLoop=0 ; DSecLoop< nsecondary ; DSecLoop++){
          G4Track* secondaryTrack = particleChange->GetSecondary(DSecLoop);
          delete secondaryTrack;
        }
        particleChange->Clear();

before switching to the parametrized process, i.e., particleChange = fProcess->PostStepDoIt(track,step). In other words, particleChange->Clear() is just setting theNumberOfSecondary=0, but not responsible for deleting objects (secondary tracks). With the proposed addition, the observed memory leak is disappeared.

Regards, ---Soon

News Re: Memory leakage using G4WrapperProcess: a user implementation  by Vladimir Ivanchenko <Vladimir Ivanchenko>,   12 Aug, 2009
Re: Ok Re: Memory leakage using G4WrapperProcess: a user implementation (Soon Yung Jun)
Hello Soon,

Your proposed fix is correct. Please, note that the class with the memory leak is in CMSSW and not in Geant4.

VI

None Error messages when tracking gammas: UnexpectedPositionShift  by Kyrre Ness Sjøbæk <Kyrre Ness Sjøbæk>,   26 Jul, 2009
Hello!

I am writing a fairly simple program to calculate the energy deposition distribution in a thin slice of silicon from different sources.

Right now I am shooting 180 GeV pions into the setup consiting of the target and some support materials. I am using the physics list from example N07 (modified to set the tracking cut down to 5 µm), and a few times I get this error message:

*********************************************************************************************************
* G4Track Information:   Particle = gamma,   Track ID = 27,   Parent ID = 23
*********************************************************************************************************

Step#    X(mm)    Y(mm)    Z(mm) KinE(MeV)  dE(MeV) StepLeng TrackLeng  NextVolume ProcName
    0     0.38  -0.0686      201    0.0751        0        0         0      LV_DUT initStep
    1     8.58    -1.67      202    0.0751        0     8.49      8.49    PV_world Transportation

*** G4Exception : UnexpectedPositionShift
      issued by : G4Navigator::ComputeStep()
Accuracy ERROR or slightly inaccurate position shift.
*** This is just a warning message.
     The Step's starting point has moved 202.493908 mm 
     since the last call to a Locate method.
     This has resulted in moving 8.491137061 mm  from the last point at which the safety      was calculated 
     which is more than the computed safety= 0 mm  at that point.
     This difference is 8.491137061 mm.
     The tolerated accuracy is 1e-06 mm.
  This problem can be due to either 
    - a process that has proposed a displacement larger than the current safety , or
    - inaccuracy in the computation of the safety
  We suggest that you 
   - find i) what particle is being tracked, and  ii) through what part of your geometry 
      for example by re-running this event with 
         /tracking/verbose 1 
    - check which processes you declare for this particle (and look at non-standard ones)
   - in case, create a detailed logfile of this event using:
         /tracking/verbose 6 
ERROR - G4Navigator::ComputeStep()
        Position has shifted considerably without notifying the navigator !
        Tolerated safety: 1e-06
        Computed shift  : 72.09940859

*** G4Exception : SignificantPositionShift
      issued by : G4Navigator::ComputeStep()
May lead to a crash or unreliable results.
*** This is just a warning message.
    2    1e+03     -196      383    0.0751        0 1.03e+03  1.03e+03  OutOfWorld Transportation

I only recive this error message when a photon is transported out of world, but has a stop in the world volume (air). What is going on? How can I fix it?

Idea Re: Error messages when tracking gammas: UnexpectedPositionShift  by Vladimir Ivanchenko <Vladimir Ivanchenko>,   26 Jul, 2009
Re: None Error messages when tracking gammas: UnexpectedPositionShift (Kyrre Ness Sjøbæk)
Hello,

Please, read documentation and look into $G4INSTALL/examples/extended/electromagnetic/ In particular TestEm5

I am not sure if Fast Simulation approach is good to thin detectors.

VI

None Re: Error messages when tracking gammas: UnexpectedPositionShift  by Kyrre Ness Sjøbæk <Kyrre Ness Sjøbæk>,   26 Jul, 2009
Re: Idea Re: Error messages when tracking gammas: UnexpectedPositionShift (Vladimir Ivanchenko)
On Sun, 26 Jul 2009 17:40:37 GMT, Vladimir Ivanchenko wrote:
> Hello,
> 
> Please, read documentation and look into
> $G4INSTALL/examples/extended/electromagnetic/ In particular TestEm5
> 
> I am not sure if Fast Simulation approach is good to thin detectors.
> 
> VI
> 

Ah, thanks, looking at it right now.

I am not using fast sim (unless I've done something wrong), I am posting here because it looks like something is wrong with the transportation, as the warning always occur when G4 tries to transport a gamma in the world volume (air).

--- Kyrre

Question fast simulation for neutron  by keyuan <keyuan>,   12 May, 2009
Hello ,everyone!
  I'm sorry for my poor English first!
  I'm studying neutron interract with Si in a small geometry,the cross section of hadronic
interaction are too small.It cost me too much time .
   I want to use "hadronic cross section biasing",but it just used for gamma and eletron.
   Is there anybody who has enhanced the cross section of  hadronic interaction ?
   I'm appreciated for your help!
  A part of my codes are showed bellow:
 G4ProcessManager* pmanager = G4Neutron::Neutron()->GetProcessManager(); 

   // add process 
  G4HadronElasticProcess* thenElasticProcess                               
                         = new G4HadronElasticProcess(); 
   thenElasticProcess->AddDataSet(new G4HadronElasticDataSet);  

   G4LElastic* thenElasticModel = new G4LElastic(); 
   thenElasticModel->SetMinEnergy(20.*MeV); 
   G4NeutronHPElastic* theNeutronHPElasticModel= new G4NeutronHPElastic(); 
   theNeutronHPElasticModel ->SetMaxEnergy(20.*MeV); 
   thenElasticProcess->RegisterMe(thenElasticModel); 
   thenElasticProcess->RegisterMe(theNeutronHPElasticModel); 

   pmanager->AddDiscreteProcess(thenElasticProcess); 

Question Forced Interaction in a given volume??  by chen <chen>,   09 Dec, 2008
In my simulation,the detector is a very tiny electric device,like a SRAM.Primary partilces pass through the detector 
before interaction with material.
In order to save computer time and decrease the variance,
I am wandering it is possible to implement Forced Interaction skill in Geant4.
 Tkank you.

Question proton beam-optical photon beam interactions possible?  by jerimy <jerimy>,   04 Dec, 2008
Is it possible to simulate the interaction of a proton beam with an optical photon beam? i would like to study polarimetry measurements of a proton beam. to do so i need to simulate the scattering of optical photons (polarized and unpolarized) from a proton beam (polarized and unpolarized).


possible ideas for such simulations:
1) define 2 separate source particles (optical photons and protons) and set the direction of the beams to intersect.
2) define a cylinder filled with "hydrogen ions" as our proton source and then shoot optical photons at it.

Are either of these options possible, or is there a better way to so this???


Any help or ideas would be appreciated.
cheers,
Jerimy
Question CRY and Geant4  by Caroline Guimaraes <Caroline Guimaraes>,   25 Aug, 2008
Hi,

I am interested in seeing the effects of cosmic rays in future experiments so I am developing simulations with Geant4 that include cosmic rays. I found a cosmic ray package called 'CRY' at http://nuclear.llnl.gov/simulation/ but I am having difficulties with it.

First of all, when I open the Cigwin window which I have been using in order to run Geant4, I locate the directory of cry_v1.5 and type 'make'. I get an error saying: CRY::CRYPrimary: Missing solar minimum function assertion "0" failed: file "CRYPrimary.cc", line 78 11 [sig] testMain 3984 c:\cry_v1.5\test\testMain.exe: ***fatal error- called with threadlist_ix -1 /bin/sh: line1: 3984 Hangup ./testMain setup.file > testMain.out make[1] : *** [run] Error 129 make: *** [test] Error 2

When I try to run the geant4 example given by locating the Geant folder ( cd c:/cry_v1.5/geant) and typing 'make' I get another error: make: *** No rule to make target 'include/CRYUtils.h', needed by '[c:/g4work/tmp/WIN32-VC/cosmic/PrimaryGeneratorMessenger.d'. Stop.

I was wondering if anyone has ever used that package, knows what these errors mean or knows how to solve them. If not, is there any other cosmic rays packages which I could use?

Thanks in advance,

Caroline

Feedback Re: CRY and Geant4  by Sean Turnbull <Sean Turnbull>,   16 Feb, 2009
Re: Question CRY and Geant4 (Caroline Guimaraes)
Hi Caroline,

I am wondering did you get CRY working and integrated within Geant4? If so I would be interested in finding out how you did it if that's possible?

Thanks

Sean

None Forcing a Reaction  by Alan Shippen <Alan Shippen>,   09 Jul, 2008
Hello, 
      Is it possible in Geant4 to force a particular reaction in a volume, like you can in MCNPX?

What I have is a simulated Lithium Fluorine Target in a 1.94MeV proton beam. Due to the extremely small cross-section of the target reaction (Li7(p,n)) in a straight, unbiased, run I get 1 neutron produced every three million protons. As I wish to study the resultant field of these neutrons at a point 100cm away this neutron yield becomes untenable.

Question Forced Compton interaction with Penelope model  Keywords: Forced Compton interaction with Penelope model
by Chibueze Zimuzo <Chibueze Zimuzo>,   30 Mar, 2008

Hello,

My problem is to increase Compton scattering in a silicon detector. I followed the instruction in the previous tread on fanoCavity but it didn't work for me as I am using PenelopeCompton which doesn't setModel method as in G4ComptonScattering.

Many thanks for your kind help.

Chibueze Uche.

None Re: Forced Compton interaction with Penelope model  Keywords: Forced Compton interaction with Penelope model
by Luciano Pandola <Luciano Pandola>,   17 Apr, 2008
Re: Question Forced Compton interaction with Penelope model (Chibueze Zimuzo)
Hello

> My problem is to increase Compton scattering in a silicon detector. 
> I followed the instruction in the previous tread on fanoCavity but 
> it didn't work for me as I am using PenelopeCompton which doesn't 
> setModel method as in G4ComptonScattering.
Right. The G4PenelopeCompton() has not the same interface as 
G4ComptonScattering().

What exactly do you need to do? Would be enough for you to inactivate all 
other gamma processes, so that Compton scattering has not competitors? 

Ciao,
Luciano
None Re: Forced Compton interaction with Penelope model  Keywords: Forced Compton interaction with Penelope model
by michel maire <michel maire>,   18 Apr, 2008
Re: None Re: Forced Compton interaction with Penelope model (Luciano Pandola)

User Luciano wrote:

>> Right. The G4PenelopeCompton() has not the same interface as 
>> G4ComptonScattering().

 In your physicsList, replace G4PenelopeCompton by MyPenelopeCompton below.
 Play with factor and myMaterial.
                                    Michel

  #ifndef MyPenelopeCompton_HH
  #define MyPenelopeCompton_HH 1

  //....oooOO0OOooo........oooOO0OOooo........oooOO0OOooo........oooOO0OOooo....

  #include "globals.hh"
  #include "G4PenelopeCompton.hh"

  class G4Track;

  //....oooOO0OOooo........oooOO0OOooo........oooOO0OOooo........oooOO0OOooo....

  class MyPenelopeCompton : public G4PenelopeCompton {

  public:

    MyPenelopeCompton(const G4String& processName ="PenCompton");

   ~MyPenelopeCompton();

    G4double GetMeanFreePath(const G4Track&, G4double, G4ForceCondition*);

  };

  //....oooOO0OOooo........oooOO0OOooo........oooOO0OOooo........oooOO0OOooo....

  #endif

  //....oooOO0OOooo........oooOO0OOooo........oooOO0OOooo........oooOO0OOooo....

  #include "MyPenelopeCompton.hh"
  #include "G4Track.hh"

  //....oooOO0OOooo........oooOO0OOooo........oooOO0OOooo........oooOO0OOooo....

  MyPenelopeCompton::MyPenelopeCompton(const G4String& processName)
    : G4PenelopeCompton(processName)
  { }

  //....oooOO0OOooo........oooOO0OOooo........oooOO0OOooo........oooOO0OOooo....

  MyPenelopeCompton::~MyPenelopeCompton()
  { }

  //....oooOO0OOooo........oooOO0OOooo........oooOO0OOooo........oooOO0OOooo....

  G4double MyPenelopeCompton::GetMeanFreePath(const G4Track& track, 
	  				     G4double previousStepSize,
					     G4ForceCondition* condition)
  {
    const G4double factor = 10.;
    G4Material* material  = track.GetMaterial();  
    G4double meanFreePath = G4PenelopeCompton::GetMeanFreePath(track,
                                                previousStepSize, condition);
    if (material->GetName() == "myMaterial") meanFreePath /= factor;
    return meanFreePath;
  }

  //....oooOO0OOooo........oooOO0OOooo........oooOO0OOooo........oooOO0OOooo....

None Re: Forced Compton interaction with Penelope model  by Vladimir IVANTCHENKO <vnivanch@mail.cern.ch>,   17 Apr, 2008
Re: None Re: Forced Compton interaction with Penelope model (Luciano Pandola)
On Thu, 17 Apr 2008, Luciano wrote:

> *** Discussion title: Fast Simulation, Transportation & Others
> Email replies to PublicHyperNews@slac.stanford.edu must include:
>   In-Reply-To: <"/fastsim/38/1"@geant4-hn.slac.stanford.edu>
>   Subject: ...change this to be about your reply.
> 
> Hello
> 
> > My problem is to increase Compton scattering in a silicon detector. 
> > I followed the instruction in the previous tread on fanoCavity but 
> > it didn't work for me as I am using PenelopeCompton which doesn't 
> > setModel method as in G4ComptonScattering.
> Right. The G4PenelopeCompton() has not the same interface as 
> G4ComptonScattering().
> 
> What exactly do you need to do? Would be enough for you to inactivate all 
> other gamma processes, so that Compton scattering has not competitors? 
> 
> Ciao,
> Luciano
> 

Sorry Luciano,

It is not so simple. Unfortunatelly, for today we have no forced
interactions in both EM packages. There is a possibility of cross section
biasing only for few high energy processes with very low cross sections.

What can be done for today: create user action whihc use following logic:
if no Compton happen in the volume of interest, then a particular gamma is
killed (or event is killed). However, this trick should be done 
accurately.

VI

None correct random seed  by Mariusz <Mariusz>,   11 Mar, 2008

Hi,

  I get the below information in the output:

JamesRandom state (vector) description improper. restoreStatus has failed. Input stream is probably mispositioned now.

My random seed file looks like that: Uvec 1878463799 0 1558248240 494829112

 Is that wrong?

   Regards, Mariusz Sapinski

None Re: correct random seed  by Mariusz <Mariusz>,   12 Mar, 2008
Re: None correct random seed (Mariusz)

OK, I had no proper initialization of random number engine.

 Mariusz

Question FORCED PHOTONS INTERACTION  Keywords: Forced interaction, fast simulation
by Francisco <Francisco>,   18 Jan, 2008

I am studying deposition of energy in a detector of about 20 microns. In order to increase my statistics and decrease my computing time I need to force photons to interact. I am following the approach of Rogers and Bielajew. Could someone tell me how I can implement it by changing the mean free path or cross section? Can this approach be implemented in Geant4 4.8.3? Is this the best way to do it?

None Re: FORCED PHOTONS INTERACTION  Keywords: Forced interaction, fast simulation
by michel maire <michel maire>,   21 Jan, 2008
Re: Question FORCED PHOTONS INTERACTION (Francisco)

User Francisco wrote:

>> I am studying deposition of energy in a detector of about 20 microns. In
>> order to increase my statistics and decrease my computing time I need to
>> force photons to interact. I am following the approach of Rogers and
>> Bielajew. Could someone tell me how I can implement it by changing the
>> mean free path or cross section? Can this approach be implemented in
>> Geant4 4.8.3? Is this the best way to do it?

 Do I understand correctly : the incident particle is photon, and its energy is such
 that Compton interaction is dominant ?

 If so, there is an example of biased Compton interaction in
 examples/extended/medical/fanoCavity  (see README)

 In Geant4, each process has one or several models attached to it :
 by default, G4KleinNishinaCompton model is attached to G4ComptonScattering process.

 In this example, MyKleinNishinaCompton model inherites from G4KleinNishina,
 and a multiplicative factor is applied to CrossSectionPerVolume.

 MyKleinNishinaCompton model is assigned to G4ComptonScattering in PhysicsList.cc

 I hope this can help,      Michel

 

Question Fictitious interaction, G4VEmProcess  Keywords: Processes, G4VProcess, Materials
by Niklas Rehfeld <Niklas.Rehfeld_REMOVE_THIS_@imed.jussieu.fr>,   19 Oct, 2007

Hello,

I would like to introduce the VR reduction technique of fictitious interaction/delta tracking (see for example http://www.irs.inms.nrc.ca/EGSnrc/pirs701/node57.html) into a Geant4 toolkit (Gate). It is promising for voxel geometries where the voxel size is smaller than the smallest mean interaction path length that can occur for a given energy (or energy range). This is is very promising for PET photon tracking in patient geometries based on computed tomograph (CT) images (typically 512x512 x (20 to 100) voxels, up to 4096 densities/materials), where the smallest mean interaction path lengths of photons at 511 keV can be expected to be around a few centimeters (cortical bone: ca. 3.5 cm) and also for photons in the energy range of 100-1000 keV this is not much worse.

The ficititious process does not change the state of the particle, but accounts for the inhomogeneity of the geometry. For this reason, a process (the fictitious process) must be introduced that depends on the homogeneous replacement material and the actual material and the particle energy. It should be implemented to be quite efficient.

Where do I find further information how this can be done, or in other words:

- Should this process be better derived by G4VDiscreteProcess or G4VEmProcess?

- Or can this be done by only introducing a model?

- For the efficient implementation: It is important that the integral cross sections can be calculated fast. Is there a place where I can find information how this lambdaTable of G4VEmProcess can be used for that purpose (or how to tabulate/parameterize the process)?

- In order to reduce these tables, is there a way to store a table for a material type and calculate the cross section and mean free path length for the same material of other density on-the-fly (or is this done already?) ?

Thank you!

Question Fictitious interaction, G4VEmProcess  Keywords: Processes, Materials, G4VDiscreteProcess, G4VEmProcess
by Niklas Rehfeld <niklas.rehfeld_REMOVETHIS@imed.jussieu.fr>,   19 Oct, 2007

Hello,

I would like to introduce the VR reduction technique of fictitious interaction/delta tracking (see for example http://www.irs.inms.nrc.ca/EGSnrc/pirs701/node57.html) into a Geant4 toolkit (Gate). It is promising for voxel geometries where the voxel size is smaller than the smallest mean interaction path length that can occur for a given energy (or energy range). This is is very promising for PET photon tracking in patient geometries based on computed tomograph (CT) images (typically 512x512 x (20 to 100) voxels, up to 4096 densities/materials), where the smallest mean interaction path lengths of photons at 511 keV can be expected to be around a few centimeters (cortical bone: ca. 3.5 cm) and also for photons in the energy range of 100-1000 keV this is not much worse.

The ficititious process does not change the state of the particle, but accounts for the inhomogeneity of the geometry. For this reason, a process (the fictitious process) must be introduced that depends on the homogeneous replacement material and the actual material and the particle energy. It should be implemented to be quite efficient.

Where do I find further information how this can be done, or in other words:

- Should this process be better derived by G4VDiscreteProcess or G4VEmProcess?

- Or can this be done by only introducing a model?

- For the efficient implementation: It is important that the integral cross sections can be calculated fast. Is there a place where I can find information how this lambdaTable of G4VEmProcess can be used for that purpose (or how to tabulate/parameterize the process)?

- In order to reduce these tables, is there a way to store a table for a material type and calculate the cross section and mean free path length for the same material of other density on-the-fly (or is this done already?) ?

Thank you!

None Using a new Library  Keywords: new library
by <laurent.millischer@student.ecp.fr>,   13 Jul, 2007

Hello !

I am newbie with both Geant4 and C++. I have to use a certain library (for cold neutrons) that is not among the basics. I did two things

- I called the header files of the library in my /src/PhysicsList.cc - I changed the binmake.gmk to binmake2.gmk and added the header's location to the flags.

But when I try to define the processes contained in the header files for my neutron ( in void NeuTransPhysicsList::ConstructProcess() ) with

    G4ParticleDefinition* particle = G4Neutron::NeutronDefinition();
    G4ProcessManager* pmanager = particle->GetProcessManager();
    pmanager->AddProcess(new UCNTransportation, 	-1,1,1);

the compiler doesn't want to and answers:

/home/local1/geant4/work/tmp/Linux-g++/neuTrans/libneuTrans.a (NeuTransPhysicsList.o)(.text+0x36d): In function `NeuTransPhysicsList::ConstructProcess()': src/NeuTransPhysicsList.cc:58: undefined reference to `UCNTransportation::UCNTransportation(int)'

What should I do ?

Could someone help me ? Thank you very much.

None triggering hadronic Inelastic interactions inside ModelTrigger  by Soon Yung Jun <Soon Yung Jun>,   09 May, 2007
Hi G4FastSimulation expert:

I want to trigger a fast simulation model at the point of a particular
hadronic interaction, for an example, at the first hadronic inelastic 
interaction inside an envelope.  Below is a snipet of my code 
implemented inside ModelTrigger with geant4.8.2.p01

---------------------------------------------------------------------->

G4bool trigger = false;

G4StepPoint* postStep = fastTrack.GetPrimaryTrack()->GetStep()->GetPostStepPoint();
G4String procName = postStep->GetProcessDefinedStep()->GetProcessName();
G4TrackVector* secondary = fastTrack.GetPrimaryTrack()->GetStep()->GetSecondary();

if( procName == "PionPlusInelastic" && (*secondary).size() > 0 ) {
  trigger = true;
  //should delete secondaries
  //fastTrack.GetPrimaryTrack()->GetStep()->DeleteSecondaryVector();
}

return trigger;

<----------------------------------------------------------------------

The problem that I encountered is that the kinetic energy of the fastTrack
(i.e., fastTrack.GetPrimaryTrack()->GetKineticEnergy()) in the "DoIt" 
method is the energy after the hadronic interaction (i.e., after loosing 
primary energy).  Since I want to
parameterize the hadronic shower (energy) with a fast simulation model, 
the condition that I implemented in ModelTrigger is actually one 
step "behind" the step where the parameterized physics should be 
triggered.  It seems that this may be a general problem if the condition 
in ModelTrigger depends on a specific physics process.  Is there any 
fundamental logistics to get around this problem?
Thanks for your help.

Regards,
---Soon     
None Re: triggering hadronic Inelastic interactions inside ModelTrigger  by Marc Verderi <Marc Verderi>,   10 May, 2007
Re: None triggering hadronic Inelastic interactions inside ModelTrigger (Soon Yung Jun)
Dear Soon,

     It is true that your request is "not standard" but I think your  
approach may work. However I have two surprises I will explain below.

     First about the approch. The "ModelTrigger" method is called at a  
stage in the G4SteppingManager where no interaction (modification of  
the primary or secondary creation) has occured yet. At this stage,  
only the step lenght is estiamted. However, the G4Step information,  
about the process limiting the step is updated.
     The important point here is to ensure that your  
G4FastSimulationProcess appeared just before the G4Transportation: ie  
after all other processes. This ordering is the one in the  
"GetPhysicalInteractionLength" loop of the G4SteppingMananger. If  
"PionPlusInelastic" limits the step, then your condition:

     if( procName == "PionPlusInelastic")

should be fulfilled.

     Then, as the interaction has not occured yet at this stage, and  
since your parameterisation will take over without letting a chance to  
this interaction to occur, the primary track will not be affected by  
other processes.

     At this stage, I believe you do not need to test other  
information. One point of "performance" however: checking a string  
might not be optimal. If you could keep and check the process pointer,  
that would be more efficient.


     Now my surprises. I am confused about the fact that:

                    (*secondary).size() > 0

can be fulfilled at the "ModelTrigger" stage. As I wrote above, since  
no interaction occured yet at this stage, I would expect no  
secondaries at this stage. Could you confirm that your condition

     if( procName == "PionPlusInelastic" && (*secondary).size() > 0 ) {
        trigger = true;
     }

was fulfilled ?

     Also, you say that in the DoIt method of the fast simulation  
model, you see the primary track after interaction. As I said above,  
if the fast simulation model is triggered, nothing should happen to  
the primary after the call to ModelTrigger and the call to the DoIt  
one (I'm asking, as this would be a bug...).

     Could you let me know if you confirm that you see a change of  
state of the primary track between the ModelTrigger and DoIt methods ?

Regards,
Marc


Soon Yung Jun <syjun@fnal.gov> a écrit :

> *** Discussion title: Fast Simulation, Transportation & Others
> Email replies to PublicHyperNews@slac.stanford.edu must include:
>   In-Reply-To: <"/fastsim/26"@geant4-hn.slac.stanford.edu>
>   Subject: ...change this to be about your reply.
>
> Hi G4FastSimulation expert:
>
> I want to trigger a fast simulation model at the point of a particular
> hadronic interaction, for an example, at the first hadronic inelastic
> interaction inside an envelope.  Below is a snipet of my code
> implemented inside ModelTrigger with geant4.8.2.p01
>
> ---------------------------------------------------------------------->
>
> G4bool trigger = false;
>
> G4StepPoint* postStep =   
> fastTrack.GetPrimaryTrack()->GetStep()->GetPostStepPoint();
> G4String procName = postStep->GetProcessDefinedStep()->GetProcessName();
> G4TrackVector* secondary =   
> fastTrack.GetPrimaryTrack()->GetStep()->GetSecondary();
>
> if( procName == "PionPlusInelastic" && (*secondary).size() > 0 ) {
>   trigger = true;
>   //should delete secondaries
>   //fastTrack.GetPrimaryTrack()->GetStep()->DeleteSecondaryVector();
> }
>
> return trigger;
>
> <----------------------------------------------------------------------
>
> The problem that I encountered is that the kinetic energy of the fastTrack
> (i.e., fastTrack.GetPrimaryTrack()->GetKineticEnergy()) in the "DoIt"
> method is the energy after the hadronic interaction (i.e., after loosing
> primary energy).  Since I want to
> parameterize the hadronic shower (energy) with a fast simulation model,
> the condition that I implemented in ModelTrigger is actually one
> step "behind" the step where the parameterized physics should be
> triggered.  It seems that this may be a general problem if the condition
> in ModelTrigger depends on a specific physics process.  Is there any
> fundamental logistics to get around this problem?
> Thanks for your help.
>
> Regards,
> ---Soon
>



----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.



None Re: triggering hadronic Inelastic interactions inside ModelTrigger  by Soon Yung Jun <Soon Yung Jun>,   10 May, 2007
Re: None Re: triggering hadronic Inelastic interactions inside ModelTrigger (Marc Verderi)
Thank you Marc for sharing your expertise on G4FastSimulation.
Your comments are very informative.

Just for my curiosity and to be right from the next time,
can you elaborate how the "standard request" should be?
- i.e., can you explain why my request was "not standard"?

Regrading to your comment on the approach, I'd like to add little
more details and a practical example with the skeleton code in the
previous mail.

I am shooting 20 GeV a pion to envelopes (PbWO4 in front followed
by Brass, a.k.a., CMS ECAL+HCAL) of which interaction lengths are
around 22cm and 16cm, respectively and want to parameterize its
hadronic shower energy distribution with a fast simulation model. 
It is important to trigger the model at the first (primary) hadronic
shower starting point so that the longitudinal profile of shower is
correctly distribute over two envelopes - we still want to follow
the full geant4 with a list hadronic physics for the dE/dx type of
energy loss before it reach to the fist hadronic shower starting point.
As a first naive trial, I implemented a condition for "ModelTrigger"
only with the process defined the step as similar to what you suggest;

if( procName == "PionPlusInelastic" ||
    procName == "PionMinusInelastic" ) trigger = true;

which selected the shower starting point much shorter
than what I expected.  Then I printed out the process name
in each step inside envelopes and found that energy losses for most of
first PionPlusInelastic are very small (see the example below), 

- inside "ModelTrigger"

procName         Nsec StepLength Energy  
                         (cm)     (GeV)
-----------------------------------------
hElastic           0   0.15939   19.8697 
hElastic           0   0.02025   19.8697 
........................................
hElastic           0   4.50236   19.8172 
PionPlusInelastic  0   11.6331   19.6992 <- 1st inelastic
Decay              0   3.98176   19.641  
PionPlusInelastic  0   0.03306   19.641  
PionPlusInelastic  0   0.02481   19.6409 
Decay              0   0.05787   19.6408 
PionPlusInelastic  0   0.24786   19.6408 
Decay              0   0.005793  19.6407 
PionPlusInelastic  0   0.34509   19.6407 
Decay              0   0.35864   19.6362 
PionPlusInelastic  0   0.37265   19.6362 
PionPlusInelastic  0   0.17602   19.6359 
Decay              0   0.07549   19.6357 
PionPlusInelastic  0   0.02397   19.6357 
Decay              0   1.24381   19.6234 
Decay              0   0.50385   19.6234 
PionPlusInelastic  0   1.64877   19.6234 <- proposed trigger
PionPlusInelastic 14   2.46423   3.13696 <- actual trigger

- inside "DoIt"

DoIt for Energy = 3.13696 results Parameterized Energy = 5.36714

- end of the example

Hinted by Michel (see the following link
http://geant4-hn.slac.stanford.edu:5090/HyperNews/public/get/hadronprocess/676/2/1/1.html
under the "Hadronic Processes" forum), I convinced myself that
additional condition ((*secondary).size() > 0) might be required
to get the first major (or real) hadronic shower starting point
correctly.  However, the energy (3.13696 GeV in the example) at
the step with secondaries is the one after a major energy lost
has happened in the step (G4Step are already updated).

I think that the right place to fulfill the "ModelTrigger" is
the step, at the "proposed trigger" in above example which is the
one step "ahead" the step "actual trigger" - i.e., I want to
parameterize "19.6234 GeV" (before interaction), but not "3.13696 GeV"
(after interaction) which is the kinetic energy that I get in the
DoIt step.  This was my problem that I asked in the previous mail.

Further more, I have another curiosity for the major energy
loss point in the tracking process with the same example code -
probably this question should go to the "Hadronic Process" forum.
Anyway, I categorize the step that loses a big energy loss;

case 1) PionPlusInelastic and secondaries > 0  (example above)

case 2) PionPlusInelastic and GetStepLength() == 0

            procName      Nsec StepLength  Energy  
        -------------------------------------------
        PionPlusInelastic  0   0.11139726 19.491284
        PionPlusInelastic  0   0          5.5933457

case 3) hElastic and secondaries > 0

        PionPlusInelastic  0 1 0.03415558 19.810742
        hElastic          30 1 12.014869  3.5630114

case 4) hElastic and GetStepLength() == 0

        PionPlusInelastic  0 1 0.05562974 19.626172
        hElastic 2.3803647 0 1 0          2.3803647

I wonder why hElastic (by G4HadronElasticPhysics) process
produces secondaries or loses a big energy.  Anyway, with requiring
these type of cases, the envisaged first shower point (x) makes much
a sense roughly following by e^{-x/interaction_length}.

With the example shown above, I believe that I mostly answered to
your question concerning to the condition (*secondary).size() > 0)
in the ModelTrigger step.  Just to confirm one more time, the
conditional statement,

 if( procName == "PionPlusInelastic" && (*secondary).size() > 0 ) {
    trigger =true;
 }

is fulfilled in "ModelTrigger" as shown the example. 

To your last point, I didn't mean that the primary track information
is changed from the stage at "ModelTrigger" to at "DoIt".  What I
meant was that the kinetic energy in DoIt step is whatever left over
"after" the hadronic process that fulfills conditions in ModelTrigger.

Sorry for verbose descriptions, but thanks for any additional comment.

Regards,
---Soon

Feedback Re: triggering hadronic Inelastic interactions inside ModelTrigger  Keywords: fast simulation, parameterization, trigger, hadronic
by John Apostolakis <John Apostolakis>,   26 Jun, 2007
Re: None Re: triggering hadronic Inelastic interactions inside ModelTrigger (Soon Yung Jun)

Hello.

I think that a few key points are not clear in the discussion of some detailed aspects of the existing module and of the suer needs and the emerging user implementation.

I will try to step back and summarize my understanding of the relevant capability in fast simulation. Then I note what I see as a new scenario or use case, emphasizing aspects which appear different to the existing one(s).

I see these as necessary steps for understanding how your use case differs from existing Geant4 use cases/scenarios. Once this is clear we can potentially offer advise and suggestions how to use the existing functionality for the new use case (if it can be adapted). Else we will need to consider the needs of your scenario and try to see how to respond with potential new development. (Also note that the fast simulation interface is not the only mechanism for such 'interaction' with the Geant4 system.)

First I try to clarify the existing scenario(s) for fast simulation in G4, and then below to express simply the new scenario/use case for this way of hadronic parameterization.

A. Clarifying existing capability

The current use case or scenario for Fast Simulation has some key characteristics:

- The parameterisation determines when it will trigger using its own criteria, independent of other processes;

- The fast simulation process takes over full control of the relevant step, before other processes occur.

I have checked these key aspects with our fast simulation developer and maintainer.

Other aspects, likely less relevant:

-The fast simulation process calls the trigerring parameterization.

-The parameterization deposits hits.

-The parameterization can propose new tracks (eg a punch-through primary) for further full/detailed simulation.

Note: in this scenario, the Fast Simulation Manager Process must act before any physics processes.

B. Use-case for hadronic shower parameterization

The proposed use-case/scenario for hadronic fast simulation appears to differ from this existing scenario (what Marc tried to call the 'standard' scenario) for Fast simulation. Here are the key points as I currently understand them:

 - The parameterization wishes to trigger using the occurrence of an 
inelastic interaction;
 - It wishes to take all the energy of the particle exactly before the 
interaction, and to use it itself (in fact replacing the results of 
the interaction, as modeled by the relevant Geant4 process.)  

Eg if the initial pre-step energy of the step was 72.304 GeV and energy loss (or something else) had reduced it to 72.230 GeV by the Post-Step point (before the interaction occurred or was applied by G4), then it would want to see 72.230 GeV as the energy available for itself.

Implementation issue(s):

* Currently identifying the process as the Inelastic interaction does not appear to be enough: sometimes the process does not produce secondaries).

* The trigger now involves checking the results of the interaction, to ensure that secondaries were created (and possibly in the future that more than one resulted?)

Could we try to clarify these points - to establish the differences of the existing capabilities and the ones needed for your case ?

After these, I suggest that we:

- understand how, if possible, the new scenario could utilize existing capabilities, in order to work with existing releases;

- consider having a presentation of the scenario and the new needs at the next Technical Forum (expected mid-July) to make these known more widely and enable a dialog that includes other users who could be interested or potentially affected.

Best regards, John Apostolakis

Question May I modify the energy threshold?  Keywords: energy threshold
by Vito <vito.palladino@na.infn.it>,   01 Feb, 2007
Hello, I'm trying to modify a Geant4 code in way of obtain a stepsize shorter.
I have seen the Geant4 manual: for application developers, in it  
is explained a method that involve the introduction of a particular kind 
code in the PhysicsList, but in my code no "User PhysicsList" is implemented,
rather than is used the general PhysicsList LHEP. 

How I can modify the stepsize (then the energy threshold) in this case?

Many thanks
       Vito Palladino
None Re: May I modify the energy threshold?  by Vladimir IVANTCHENKO <vnivanch@mail.cern.ch>,   06 Feb, 2007
Re: Question May I modify the energy threshold? (Vito)
On Thu, 1 Feb 2007, Vito wrote:

> *** Discussion title: Fast Simulation, Transportation & Others
> Email replies to PublicHyperNews@slac.stanford.edu must include:
>   In-Reply-To: <"/fastsim/24"@geant4-hn.slac.stanford.edu>
>   Subject: ...change this to be about your reply.
> 
> Hello, I'm trying to modify a Geant4 code in way of obtain a stepsize shorter.
> I have seen the Geant4 manual: for application developers, in it  
> is explained a method that involve the introduction of a particular kind 
> code in the PhysicsList, but in my code no "User PhysicsList" is implemented,
> rather than is used the general PhysicsList LHEP. 
> 
> How I can modify the stepsize (then the energy threshold) in this case?
> 
> Many thanks
>        Vito Palladino
> 

Hello,

You can try follwoing. In in your main instead of one line

runManager->SetUserInitialization(new LHEP());

insert more lines:

G4double myCut = 0.1*mm;
LHEP* pLHEP = new LHEP();
pLHEP->SetDefaultCutValue(myCut);
runManager->SetUserInitialization(pLHEP);

VI  
Note Problem with very small stepsize caused by transportation process?  Keywords: small stepsize, transportation
by Henning Gast <Henning Gast>,   10 Jan, 2007

Hi,

I am simulating a cosmic-ray detector in G4.8.2 and have encountered the following problem:

In some (1/1000) events, there is a very tiny step size in one of my "TrdLayer" volumes, leading to the event being practically stuck, for example: (description continues below)

*********************************************************************************************************
* G4Track Information:   Particle = e-,   Track ID = 391,   Parent ID = 319
*********************************************************************************************************

Step#    X(mm)    Y(mm)    Z(mm) KinE(MeV)  dE(MeV) StepLeng TrackLeng  NextVolume ProcName
    0      132      262     -136      2.93        0        0         0 TrdRadiator initStep
    1      134      265     -125      2.81    0.122     11.3      11.3 TrdRadiator msc
    2      134      265     -125       2.8  0.00425    0.535      11.9 TrdRadiator msc
    3      134      265     -125       2.8  0.00012  0.00768      11.9   TrdModule Transportation
    4      135      265     -124       2.8 0.000112     1.35      13.2   TrdModule msc
    5      136      265     -123       2.8 0.000321     1.35      14.6   TrdModule msc
    6      137      265     -122       2.8 8.46e-05     1.35        16   TrdModule msc
    7      137      265     -122       2.8 4.34e-05    0.138      16.1 TrdStrawTubeWall2 Transportation
    8      137      265     -122      2.78   0.0224    0.135      16.2 TrdStrawTubeWall2 msc
    9      137      265     -122      2.75    0.025    0.135      16.4 TrdStrawTubeWall2 msc
   10      137      265     -121      2.74   0.0143    0.075      16.4 TrdStrawTubeWall2 msc
   11      137      265     -121      2.74        0  0.00011      16.4 TrdStrawTubeGas2 Transportation
   12      138      266     -121      2.74 0.000465     1.08      17.5 TrdStrawTubeGas2 msc
   13      139      266     -120      2.74 3.31e-05     1.08      18.6 TrdStrawTubeGas2 msc
   14      140      266     -120      2.74 8.01e-05     1.08      19.7 TrdStrawTubeGas2 msc
   15      141      266     -119      2.74 2.18e-05     1.06      20.7 TrdStrawTubeGas2 msc
   16      141      266     -119      2.74  1.4e-05    0.188      20.9 TrdStrawTubeGas2 msc
   17      141      266     -119      2.74        0   0.0078      20.9 TrdStrawTubeWall2 Transportation
   18      142      266     -119      2.59    0.151     0.28      21.2 TrdStrawTubeWall2 msc
   19      142      266     -119      2.52   0.0693     0.28      21.5 TrdStrawTubeWall2 msc
   20      142      266     -119      2.51  0.00798   0.0414      21.5 TrdStrawTubeGas2 Transportation
   21      145      267     -119      2.51 0.000523     3.56      25.1 TrdStrawTubeGas2 msc
   22      148      269     -120      2.51 0.000431     3.56      28.6 TrdStrawTubeGas2 msc
   23      150      271     -123      2.51 0.000999     3.56      32.2 TrdStrawTubeGas2 msc
   24      151      271     -123      2.51 0.000195    0.529      32.7 TrdStrawTubeWall2 Transportation
   25      151      271     -123       2.5  0.00469   0.0242      32.8 TrdStrawTubeWall2 msc
   26      151      271     -123       2.5  0.00342   0.0242      32.8 TrdStrawTubeWall2 msc
   27      151      271     -123       2.5  0.00262   0.0242      32.8 TrdStrawTubeWall2 msc
   28      151      271     -123      2.49  0.00219    0.017      32.8 TrdStrawTubeWall2 msc
   29      151      271     -123      2.49  3.8e-07 1.72e-06      32.8   TrdModule Transportation
   30      151      271     -123      2.49 0.000203    0.677      33.5   TrdModule msc
   31      151      272     -124      2.49 1.66e-05    0.677      34.2   TrdModule msc
   32      152      272     -124      2.49 2.13e-05    0.677      34.8   TrdModule msc
   33      152      272     -125      2.49 1.75e-05    0.525      35.4 TrdRadiator Transportation
   34      154      278     -132      2.41    0.084      9.2      44.6 TrdRadiator msc
   35      151      282     -139      2.31    0.103      9.2      53.8 TrdRadiator msc
   36      144      286     -143      2.22   0.0882      9.1      62.9 TrdRadiator msc
   37      136      291     -142      2.13   0.0881      9.2      72.1 TrdRadiator msc
   38      129      293     -136      2.05   0.0843      9.2      81.3 TrdRadiator msc
   39      127      297     -128      1.95   0.0997      9.2      90.5 TrdRadiator msc
   40      129      299     -125      1.91   0.0342     4.19      94.7 TrdRadiator msc
   41      130      300     -125       1.9  0.00977    0.987      95.6 TrdRadiator msc
   42      130      300     -125       1.9 0.000779    0.055      95.7 TrdRadiator msc
   43      130      300     -125       1.9 9.59e-07  9.4e-05      95.7   TrdModule Transportation
   44      130      300     -125       1.9        0    0.267        96   TrdModule msc
   45      130      300     -124       1.9        0    0.267      96.2   TrdModule msc
   46      130      300     -124       1.9 9.27e-06   0.0642      96.3 TrdStrawTubeWall7 Transportation
   47      130      300     -124       1.9   0.0062   0.0328      96.3 TrdStrawTubeWall7 msc
   48      130      300     -124      1.89  0.00481   0.0328      96.4 TrdStrawTubeWall7 msc
   49      130      300     -124      1.88   0.0121   0.0328      96.4 TrdStrawTubeWall7 msc
   50      130      300     -124      1.87  0.00599   0.0328      96.4 TrdStrawTubeWall7 msc
   51      130      300     -124      1.87  0.00671   0.0328      96.5 TrdStrawTubeWall7 msc
   52      130      300     -124      1.86  0.00223   0.0102      96.5 TrdStrawTubeWall7 msc
   53      130      300     -124      1.86  4.3e-06 1.93e-05      96.5 TrdStrawTubeGas7 Transportation
   54      130      301     -124      1.86 0.000166    0.436      96.9 TrdStrawTubeGas7 msc
   55      130      301     -124      1.86 0.000733    0.436      97.3 TrdStrawTubeGas7 msc
   56      131      301     -124      1.86 0.000134    0.436      97.8 TrdStrawTubeGas7 msc
   57      131      301     -124      1.86 0.000116    0.162      97.9 TrdStrawTubeGas7 eIoni
   58      131      302     -124      1.86  8.8e-05    0.183      98.1 TrdStrawTubeWall7 Transportation
   59      131      302     -124      1.84   0.0169   0.0992      98.2 TrdStrawTubeWall7 msc
   60      131      302     -124      1.83   0.0147   0.0992      98.3 TrdStrawTubeWall7 msc
   61      131      302     -124      1.81   0.0176   0.0992      98.4 TrdStrawTubeWall7 msc
   62      131      302     -124      1.81  0.00361    0.017      98.4   TrdModule Transportation
   63      131      303     -124      1.81 5.91e-05     0.84      99.3   TrdModule msc
   64      132      303     -124      1.81 0.000893     0.84       100   TrdModule msc
   65      132      304     -123      1.81 4.51e-05     0.67       101   TrdModule msc
   66      132      304     -123      1.81 1.06e-06  0.00734       101 TrdStrawTubeWall8 Transportation
   67      132      304     -123      1.79   0.0139   0.0532       101 TrdStrawTubeWall8 msc
   68      132      304     -123      1.78   0.0129   0.0532       101 TrdStrawTubeWall8 msc
   69      132      304     -123      1.78  0.00086   0.0081       101 TrdStrawTubeWall8 msc
   70      132      304     -123      1.78 9.78e-07  4.4e-06       101 TrdStrawTubeGas8 Transportation
   71      134      306     -124      1.78 0.000717     3.11       104 TrdStrawTubeGas8 msc
   72      135      308     -124      1.78 0.000352     1.57       106 TrdStrawTubeWall8 Transportation
   73      135      308     -124      1.77   0.0134   0.0751       106 TrdStrawTubeWall8 msc
   74      135      308     -124      1.75   0.0148   0.0658       106   TrdModule Transportation
   75      136      308     -124      1.75 6.12e-05    0.917       107   TrdModule msc
   76      136      309     -124      1.75   0.0001    0.917       108   TrdModule msc
   77      136      309     -124      1.75        0     0.22       108 TrdLongStiffener3 Transportation
   78      137      309     -124      1.73   0.0259   0.0991       108 TrdLongStiffener3 msc
   79      137      309     -124      1.68   0.0412   0.0902       108   TrdModule Transportation
   80      137      310     -125      1.68        0    0.574       109   TrdModule msc
   81      137      310     -125      1.68 6.89e-05    0.447       109 TrdRadiator Transportation
   82      143      322     -135      1.47    0.161     16.9       126 TrdRadiator eIoni
   83      141      329     -143      1.33    0.145     11.3       137 TrdRadiator msc
   84      138      331     -144      1.29   0.0385     3.32       141 TrdRadiator msc
   85      135      334     -144      1.25   0.0424     5.04       146 TrdRadiator msc
   86      134      351     -131      1.05    0.197     21.2       167 TrdRadiator msc
   87      137      351     -126     0.998   0.0537     6.19       173 TrdRadiator msc
   88      138      351     -125     0.985   0.0132     1.47       175 TrdRadiator msc
   89      139      351     -125     0.982  0.00315    0.404       175 TrdRadiator msc
   90      139      351     -125     0.982 2.46e-05  0.00647       175   TrdModule Transportation
   91      139      351     -125     0.982 0.000123    0.526       175   TrdModule msc
   92      140      352     -124     0.982 9.75e-06    0.526       176   TrdModule msc
   93      140      352     -124     0.982        0    0.213       176 TrdStrawTubeWall15 Transportation
   94      140      352     -124     0.954   0.0275    0.153       176 TrdStrawTubeWall15 msc
   95      140      352     -124       0.9   0.0538    0.153       177 TrdStrawTubeWall15 msc
   96      140      352     -124     0.887   0.0137   0.0531       177   TrdModule Transportation
   97      140      352     -124     0.887 7.62e-05    0.351       177   TrdModule msc
   98      141      352     -125     0.886 3.12e-05    0.351       177   TrdModule msc
   99      141      352     -125     0.886        0     0.11       177 TrdRadiator Transportation
  100      142      353     -128     0.846   0.0408     4.08       181 TrdRadiator msc
  101      141      352     -132     0.805   0.0406     4.08       186 TrdRadiator msc
  102      139      352     -135     0.763   0.0417     4.08       190 TrdRadiator msc
  103      135      352     -136     0.724   0.0398     4.08       194 TrdRadiator msc
  104      132      352     -134     0.677   0.0468     4.08       198 TrdRadiator msc
  105      130      353     -130      0.63   0.0467     4.08       202 TrdRadiator msc
  106      131      353     -127     0.586   0.0443     4.08       206 TrdRadiator msc
  107      134      353     -126     0.555   0.0303     3.35       209 TrdRadiator msc
  108      136      353     -129     0.513   0.0428     4.08       213 TrdRadiator msc
  109      134      353     -132     0.468   0.0448     2.99       216 TrdRadiator msc
  110      134      353     -132     0.467 0.000904   0.0512       216 TrdRadiator msc
  111      134      354     -132     0.467 3.81e-08 3.16e-06       216    TrdLayer Transportation
  112      128      355     -128     0.466  0.00138     9.91       226    TrdLayer msc
  113      130      356     -125     0.464  0.00111     3.66       230    TrdLayer msc
  114      131      356     -125     0.464  0.00065     1.13       231    TrdLayer msc
  115      131      356     -125     0.464  4.4e-05    0.471       232    TrdLayer msc
  116      131      356     -125     0.464 2.08e-05    0.124       232    TrdLayer Transportation
  117      131      356     -125     0.464 1.69e-13 1.02e-09       232    TrdLayer Transportation
  118      131      356     -125     0.464 1.66e-13    1e-09       232    TrdLayer Transportation
  119      131      356     -125     0.464 1.69e-13 1.02e-09       232    TrdLayer Transportation
  120      131      356     -125     0.464 1.66e-13    1e-09       232    TrdLayer Transportation
  121      131      356     -125     0.464 1.69e-13 1.02e-09       232    TrdLayer Transportation
  122      131      356     -125     0.464 1.66e-13    1e-09       232    TrdLayer Transportation
  123      131      356     -125     0.464 1.69e-13 1.02e-09       232    TrdLayer Transportation
  124      131      356     -125     0.464 1.66e-13    1e-09       232    TrdLayer Transportation
  125      131      356     -125     0.464 1.69e-13 1.02e-09       232    TrdLayer Transportation
  126      131      356     -125     0.464 1.66e-13    1e-09       232    TrdLayer Transportation
  127      131      356     -125     0.464 1.69e-13 1.02e-09       232    TrdLayer Transportation
  128      131      356     -125     0.464 7.58e-13 4.58e-09       232    TrdLayer Transportation
  129      131      356     -125     0.464 1.69e-13 1.02e-09       232    TrdLayer Transportation
  130      131      356     -125     0.464 1.66e-13    1e-09       232    TrdLayer Transportation
  131      131      356     -125     0.464 1.69e-13 1.02e-09       232    TrdLayer Transportation
  132      131      356     -125     0.464 1.66e-13    1e-09       232    TrdLayer Transportation
  133      131      356     -125     0.464 1.69e-13 1.02e-09       232    TrdLayer Transportation
  134      131      356     -125     0.464 1.66e-13    1e-09       232    TrdLayer Transportation
  135      131      356     -125     0.464 1.69e-13 1.02e-09       232    TrdLayer Transportation
  136      131      356     -125     0.464 1.66e-13    1e-09       232    TrdLayer Transportation
  137      131      356     -125     0.464 1.69e-13 1.02e-09       232    TrdLayer Transportation
  138      131      356     -125     0.464 1.66e-13    1e-09       232    TrdLayer Transportation
  139      131      356     -125     0.464 1.69e-13 1.02e-09       232    TrdLayer Transportation
  140      131      356     -125     0.464 7.58e-13 4.58e-09       232    TrdLayer Transportation
  141      131      356     -125     0.464 1.69e-13 1.02e-09       232    TrdLayer Transportation
  142      131      356     -125     0.464 1.66e-13    1e-09       232    TrdLayer Transportation
  143      131      356     -125     0.464 1.69e-13 1.02e-09       232    TrdLayer Transportation
  144      131      356     -125     0.464 1.66e-13    1e-09       232    TrdLayer Transportation
  145      131      356     -125     0.464 1.69e-13 1.02e-09       232    TrdLayer Transportation
  146      131      356     -125     0.464 1.66e-13    1e-09       232    TrdLayer Transportation
  147      131      356     -125     0.464 1.69e-13 1.02e-09       232    TrdLayer Transportation
  148      131      356     -125     0.464 1.66e-13    1e-09       232    TrdLayer Transportation
  149      131      356     -125     0.464 1.69e-13 1.02e-09       232    TrdLayer Transportation
  150      131      356     -125     0.464 1.66e-13    1e-09       232    TrdLayer Transportation
  151      131      356     -125     0.464 1.69e-13 1.02e-09       232    TrdLayer Transportation
  152      131      356     -125     0.464 7.58e-13 4.58e-09       232    TrdLayer Transportation
  153      131      356     -125     0.464 1.69e-13 1.02e-09       232    TrdLayer Transportation
  154      131      356     -125     0.464 1.66e-13    1e-09       232    TrdLayer Transportation
  155      131      356     -125     0.464 1.69e-13 1.02e-09       232    TrdLayer Transportation
  156      131      356     -125     0.464 1.66e-13    1e-09       232    TrdLayer Transportation
  157      131      356     -125     0.464 1.69e-13 1.02e-09       232    TrdLayer Transportation
  158      131      356     -125     0.464 1.66e-13    1e-09       232    TrdLayer Transportation
  159      131      356     -125     0.464 1.69e-13 1.02e-09       232    TrdLayer Transportation
  160      131      356     -125     0.464 1.66e-13    1e-09       232    TrdLayer Transportation
  161      131      356     -125     0.464 1.69e-13 1.02e-09       232    TrdLayer Transportation

... and so on...

In some events, G4 seems to be able to recognize and amend the situation:

WARNING - G4Navigator::ComputeStep()
          Track stuck, not moving for 10 steps
          in volume -TrdLayer- at point (-9.019548462,-67.04845417,311.976)
          direction: (0.9993687785,0.004953406355,0.03517823564).
          Potential geometry or navigation problem !
          Trying pushing it of 9e-10 mm ...
WARNING - G4Navigator::ComputeStep()
          Track stuck, not moving for 10 steps
          in volume -TrdLayer- at point (-9.019548454,-67.04845417,311.976)
          direction: (0.9993687787,0.004953406355,0.03517823201).
          Potential geometry or navigation problem !
          Trying pushing it of 9e-10 mm ...
... and so on ...

I also attach some output from /tracking/verbose 6 which seems to indicate a problem in the transportation process:

#Step#    X(mm)    Y(mm)    Z(mm) KinE(MeV)  dE(MeV) StepLeng TrackLeng  NextVolume ProcName
 1082    -89.7    -63.5     -285     0.207 1.17e-10 6.93e-09      32.1   TrdModule Transportation

 >>DefinePhysicalStepLength (List of proposed StepLengths): 
    ++ProposedStep(PostStep ) = 1.797693134862316e+308 : ProcName = GammaXTRadiator (No ForceCondition)
    ++ProposedStep(PostStep ) = 1.797693134862316e+308 : ProcName = ElectroNuclear (No ForceCondition)
    ++ProposedStep(PostStep ) = 66843.92633942491 : ProcName = eBrem (No ForceCondition)
    ++ProposedStep(PostStep ) = 43.73431611726596 : ProcName = eIoni (No ForceCondition)
    ++ProposedStep(PostStep ) = 1.797693134862316e+308 : ProcName = msc (Forced)
    ++ProposedStep(PostStep ) = 1.797693134862316e+308 : ProcName = Transportation (Forced)
    ++ProposedStep(AlongStep) = 1.797693134862316e+308 : ProcName = eBrem (CandidateForSelection)
    ++ProposedStep(AlongStep) = 559.1135940543439 : ProcName = eIoni (CandidateForSelection)
    ++ProposedStep(AlongStep) = 0.1951978999090939 : ProcName = msc (CandidateForSelection)
    ++ProposedStep(AlongStep) =         0 : ProcName = Transportation (CandidateForSelection)

 >>AlongStepDoIt (process by process):    Process Name = Transportation

    ++G4Step Information 
      Address of G4Track    : 0xc7b28c8
      Step Length (mm)      : 0
      Energy Deposit (MeV)  : 0
      -----------------------------------------------------------------------
        StepPoint Information               PreStep            PostStep
      -----------------------------------------------------------------------
         Position - x (mm)   :   -89.70796591921498  -89.70796591921498
         Position - y (mm)   :   -63.48666293803226  -63.48666293803226
         Position - z (mm)   :             -285.232            -285.232
         Global Time (ns)    :    4.079087373687271   4.079087373687271
         Local Time (ns)     :   0.1366161237314643  0.1366161237314643
         Proper Time (ns)    :  0.08792145067135242 0.08792145067135242
         Momentum Direct - x :  -0.9805329125797901 -0.9805329125797901
         Momentum Direct - y :   0.1807490143955495  0.1807490143955494
         Momentum Direct - z : -0.07671376110471373-0.07671376110471372
         Momentum - x (MeV/c):  -0.4943958688733998 -0.4943958688733998
         Momentum - y (MeV/c):  0.09113571291042878 0.09113571291042877
         Momentum - z (MeV/c): -0.03867995259447763-0.03867995259447762
         Total Energy (MeV)  :    0.717878242726697   0.717878242726697
         Kinetic Energy (MeV):   0.2068791827266971  0.2068791827266971
         Velocity (mm/ns)    :    210.5632471109914   210.5632471109914
         Volume Name         :            TrdModule           TrdModule
         Safety (mm)         :                    0                   0
         Polarization - x    :                    0                   0
         Polarization - y    :                    0                   0
         Polarization - Z    :                    0                   0
         Weight              :                    1                   1
         Step Status         :           Geom Limit          Geom Limit
         Process defined Step:       Transportation      Transportation
      -----------------------------------------------------------------------
          !Note! Safety of PostStep is only valid after all DoIt invocations.

    ++G4ParticleChange Information 
      -----------------------------------------------
        G4ParticleChange Information  
      -----------------------------------------------
        # of 2ndaries       :                    0
      -----------------------------------------------
        Energy Deposit (MeV):                    0
        Track Status        :                Alive
        True Path Length (mm) :                    0
        Stepping Control      :                    0
        Mass (GeV)   :                    0
        Charge (eplus)   :                    0
        Position - x (mm)   :                -89.7
        Position - y (mm)   :                -63.5
        Position - z (mm)   :                 -285
        Time (ns)           :                 4.08
        Proper Time (ns)    :               0.0879
        Momentum Direct - x :               -0.981
        Momentum Direct - y :                0.181
        Momentum Direct - z :              -0.0767
        Kinetic Energy (MeV):                0.207
        Polarization - x    :                    0
        Polarization - y    :                    0
        Polarization - z    :                    0
        Track Weight      :                    0
        Touchable (pointer) :            0xce40500

    ++List of secondaries generated (x,y,z,kE,t,PID):  No. of secodaries = 0

... and so on ...

The following output is generated by my SteppingAction, for every 100th tiny step:

/tracking/verbose 0
 PROBLEM! 1100 tiny steps for Track ID 24, created by hIoni
   Particle: e- E= 0.2068791823444467 MeV
   Position: (-89.70796597055939,-63.48666292857455,-285.2320000000736)
   Currently in volume TrdModule
 PROBLEM! 1200 tiny steps for Track ID 24, created by hIoni
   Particle: e- E= 0.2068791822041985 MeV
   Position: (-89.70796601061012,-63.48666292118423,-285.2320000002578)
   Currently in volume TrdLayer
 PROBLEM! 1300 tiny steps for Track ID 24, created by hIoni
   Particle: e- E= 0.2068791819313116 MeV
   Position: (-89.70796605944828,-63.48666291218628,-285.2320000004788)
   Currently in volume TrdRadiator
 PROBLEM! 1400 tiny steps for Track ID 24, created by hIoni
   Particle: e- E= 0.2068791815863 MeV
   Position: (-89.70796611145013,-63.48666290259673,-285.2320000001471)
   Currently in volume TrdModule
 PROBLEM! 1500 tiny steps for Track ID 24, created by hIoni
   Particle: e- E= 0.2068791813122284 MeV
   Position: (-89.70796615936021,-63.48666289376921,-285.232000000331)
   Currently in volume TrdLayer
 PROBLEM! 1600 tiny steps for Track ID 24, created by hIoni
   Particle: e- E= 0.2068791810473755 MeV
   Position: (-89.70796620763744,-63.48666288485973,-285.2320000000367)
   Currently in volume TrdRadiator
 PROBLEM! 1700 tiny steps for Track ID 24, created by hIoni
   Particle: e- E= 0.2068791806160801 MeV
   Position: (-89.70796626474066,-63.48666287434693,-285.232000000257)
   Currently in volume TrdModule
 PROBLEM! 1800 tiny steps for Track ID 24, created by hIoni
   Particle: e- E= 0.2068791804162851 MeV
   Position: (-89.70796630829986,-63.48666286632119,-285.2320000004406)
   Currently in volume TrdLayer
 PROBLEM! 1900 tiny steps for Track ID 24, created by hIoni
   Particle: e- E= 0.2068791796872486 MeV
   Position: (-89.70796638370334,-63.4866628524233,-285.2320000001464)
   Currently in volume TrdRadiator
 PROBLEM! 2000 tiny steps for Track ID 24, created by hIoni
   Particle: e- E= 0.2068791794378897 MeV
   Position: (-89.70796643017182,-63.48666284385618,-285.2320000003289)
   Currently in volume TrdModule

The interesting part is the current volume that fluctuates although the position of the particle remains virtually constant. The hierarchy in my geometry is as follows:

TrdLayer
 |
 |__ TrdModule
     |
     |__TrdRadiator (among others)

So, a particle should never really enter a "TrdLayer" volume explicitly because the daughter volume "TrdRadiator" in each "TrdModule" fills the upper part of the layer completely.

My setup contains a homogeneous magnetic field. What also puzzles me is the fact that the minimum stepsize in the G4MagInt_Driver should prevent steps from being as small as I observe them, shouldn't it? The parameters for tracking in the magnetic field are as follows:

 Magnetic field: min epsilon step:   5e-05 mm
 Magnetic field: max epsilon step:   0.001 mm
 Magnetic field: delta one step:     0.01 mm
 Magnetic field: delta intersection: 0.001 mm

Unfortunately, the G4MagInt_Driver doesn't have a Get() for the minimum stepsize, so I assume it is the default value of stepMinimum = 1.0e-2 * mm (see G4ChordFinder). Can this be ignored by the transportation process?

I carefully checked the geometry for volume overlaps.

Any insight would be appreciated,

kind regards

Henning

None Re: Problem with very small stepsize caused by transportation process?  Keywords: small stepsize, transportation
by John Apostolakis <John Apostolakis>,   11 Jan, 2007
Re: Note Problem with very small stepsize caused by transportation process? (Henning Gast)

[ I started writing this before you last posting - but I have now read it.]

Your problem is unusual, and could suggest a difficulty in the Navigator or in your setup. My first suggestion would be to run overlap checking. Since you report doing this already, I will provide a different suggestion. [ However, if you can try to check for overlaps a second time, using a different method, it could help too. ]

Could you please see whether you can reproduce the problem when locating a point by yourself with just the Navigator.

From your output I see that the difficulty is at

 Position - x (mm)   :   -89.70796591921498  
 Position - y (mm)   :   -63.48666293803226 
 Position - z (mm)   :             -285.232

Can you call the Navigator at this point, (you can get its pointer from the G4TransportationManager), using LocateGlobalPointAndSetup ? I suggest to call it repeatedly and compare its output.

Then add the direction, which from your print out appears to be
 Momentum Direct - x :  -0.9805329125797901 
 Momentum Direct - y :   0.1807490143955495 
 Momentum Direct - z : -0.07671376110471373

From the values of the position, it is my guess that there is a boundary
exactly at this z value:
 Position - z (mm)   :             -285.232
Can you confirm whether the point is at a boundary of one of the
TrdLayer volumes at this point ? 

If so, it would be very useful to create a custom sub-class of G4SteppingVerbose that prints out the copy number of the current TrdLayer (and potentially the parent volume's copy number as well.) This way we can check whether it is confused by bouncing between different copies at their interface.

After this, please try to call the Navigator's ComputeStep method yourself. If it returns zero, you are seeing the same problem.

I suggest to repeat
    Locate( point, direction, ...
    step= ComputeStep( point, direction, ...
    point += step * direction; 
a few more times (say 20 times in a loop) to confirm that the problem
is with Navigation, not the field.

The code for propagating in a magnetic field should take care for difficult cases, where it can be unclear what volume a track is actually crossing. In this case, though, it appears that it is the Navigator which is having difficulties.

I noted that you said that "" a particle should never really enter a "TrdLayer" volume explicitly because the daughter volume "TrdRadiator" in each "TrdModule" fills the upper part of the layer completely. ""

This seems to indicate that it is experiencing significant difficult at this level. What type of volume is a 'TrdModule'? A box, a tubs, or other ?? Also what is the TrdRadiator ?

None Re: Problem with very small stepsize caused by transportation process?  by Henning Gast <Henning Gast>,   12 Jan, 2007
Re: None Re: Problem with very small stepsize caused by transportation process? (John Apostolakis)
Dear John,

thank you for your detailed proposals. Please see my findings below:

John Apostolakis wrote:
> *** Discussion title: Fast Simulation, Transportation & Others
> Email replies to PublicHyperNews@slac.stanford.edu must include:
>   In-Reply-To: <"/fastsim/22/2"@geant4-hn.slac.stanford.edu>
>   Subject: ...change this to be about your reply.
> 

> From the values of the position, it is my guess that there is a boundary
> exactly at this z value:
>  Position - z (mm)   :             -285.232
> Can you confirm whether the point is at a boundary of one of the
> TrdLayer volumes at this point ? 

Yes indeed, I find that the problem seems to occur at the boundary 
between two TrdLayer volumes.

> If so, it would be very useful to create a custom sub-class of
> G4SteppingVerbose that prints out the copy number of the current
> TrdLayer (and potentially the parent volume's copy number as well.) This
> way we can check whether it is confused by bouncing between different
> copies at their interface.

That is exactly what happens:

#Step#      X         Y         Z        KineE    dEStep   StepLeng 
TrakLeng              Volume          Process
   514   31.1 cm  -35.7 cm  -23.2 cm    990 keV1.45e-07 eV  1e+03 fm 
2.94 cm               TrdLayer   Transportation
PreStepPoint:
  at 0: TrdLayer  replica 3 copy 3
  at 1: TrdLowerSuperLayer  replica 0 copy 0
  at 2: Tracker  replica 0 copy 0
  at 3: World  replica 0 copy 0
PostStepPoint:
  at 0: TrdLayer  replica 2 copy 2
  at 1: TrdLowerSuperLayer  replica 0 copy 0
  at 2: Tracker  replica 0 copy 0
  at 3: World  replica 0 copy 0

#Step#      X         Y         Z        KineE    dEStep   StepLeng 
TrakLeng              Volume          Process
   515   31.1 cm  -35.7 cm  -23.2 cm    990 keV1.47e-07 eV 1.01e+03 fm 
  2.94 cm               TrdLayer   Transportation
PreStepPoint:
  at 0: TrdLayer  replica 2 copy 2
  at 1: TrdLowerSuperLayer  replica 0 copy 0
  at 2: Tracker  replica 0 copy 0
  at 3: World  replica 0 copy 0
PostStepPoint:
  at 0: TrdLayer  replica 3 copy 3
  at 1: TrdLowerSuperLayer  replica 0 copy 0
  at 2: Tracker  replica 0 copy 0
  at 3: World  replica 0 copy 0

#Step#      X         Y         Z        KineE    dEStep   StepLeng 
TrakLeng              Volume          Process
   516   31.1 cm  -35.7 cm  -23.2 cm    990 keV1.45e-07 eV  1e+03 fm 
2.94 cm               TrdLayer   Transportation
PreStepPoint:
  at 0: TrdLayer  replica 3 copy 3
  at 1: TrdLowerSuperLayer  replica 0 copy 0
  at 2: Tracker  replica 0 copy 0
  at 3: World  replica 0 copy 0
PostStepPoint:
  at 0: TrdLayer  replica 2 copy 2
  at 1: TrdLowerSuperLayer  replica 0 copy 0
  at 2: Tracker  replica 0 copy 0
  at 3: World  replica 0 copy 0

#Step#      X         Y         Z        KineE    dEStep   StepLeng 
TrakLeng              Volume          Process
   517   31.1 cm  -35.7 cm  -23.2 cm    990 keV1.47e-07 eV 1.01e+03 fm 
  2.94 cm               TrdLayer   Transportation
PreStepPoint:
  at 0: TrdLayer  replica 2 copy 2
  at 1: TrdLowerSuperLayer  replica 0 copy 0
  at 2: Tracker  replica 0 copy 0
  at 3: World  replica 0 copy 0
PostStepPoint:
  at 0: TrdLayer  replica 3 copy 3
  at 1: TrdLowerSuperLayer  replica 0 copy 0
  at 2: Tracker  replica 0 copy 0
  at 3: World  replica 0 copy 0

... and so on ...


> After this, please try to call the Navigator's ComputeStep method
> yourself. If it returns zero, you are seeing the same problem.
> 
> I suggest to repeat
>     Locate( point, direction, ...
>     step= ComputeStep( point, direction, ...
>     point += step * direction; 
> a few more times (say 20 times in a loop) to confirm that the problem
> is with Navigation, not the field.
> 

I put the following code in my SteppingAction:

     G4cout << "LOOP:" << G4endl;
     for( G4int i=0 ; i<20 ; ++i ){

       G4cout << " physVol: " << navigator->LocateGlobalPointAndSetup( 
position, &direction )->GetName() << G4endl;
       G4double safety = 0.0;
       G4double step = navigator->ComputeStep( position, direction, 
1.0*km,safety);
       G4cout << "STEP: " << step/mm << " mm." << G4endl;
       position += step*direction;
       G4cout << " new pos: " << position << G4endl;

     }

The result is curious:

LOOP:
  physVol: TrdLayer
STEP: 3.7272604e-09 mm.
  new pos: (311.25547,-357.47662,-231.744)
  physVol: TrdLayer
STEP: 1e-09 mm.
  new pos: (311.25547,-357.47662,-231.744)
  physVol: TrdLayer
STEP: 1e-09 mm.
  new pos: (311.25547,-357.47662,-231.744)
  physVol: TrdLayer
STEP: 1e-09 mm.
  new pos: (311.25547,-357.47662,-231.744)
  physVol: TrdLayer
STEP: 1e-09 mm.
  new pos: (311.25547,-357.47662,-231.744)
  physVol: TrdLayer
STEP: 167.71476 mm.
  new pos: (149.96333,-397.5,-254.35406)
  physVol: TrdLayer
STEP: 0 mm.
  new pos: (149.96333,-397.5,-254.35406)
  physVol: TrdLayer
STEP: 0 mm.
  new pos: (149.96333,-397.5,-254.35406)
  physVol: TrdLayer
STEP: 0 mm.
  new pos: (149.96333,-397.5,-254.35406)
  physVol: TrdLayer
STEP: 0 mm.
  new pos: (149.96333,-397.5,-254.35406)
  physVol: TrdLayer
STEP: 0 mm.
  new pos: (149.96333,-397.5,-254.35406)
  physVol: TrdLayer
STEP: 0 mm.
  new pos: (149.96333,-397.5,-254.35406)
  physVol: TrdLayer
STEP: 0 mm.
  new pos: (149.96333,-397.5,-254.35406)
  physVol: TrdLayer
STEP: 0 mm.
  new pos: (149.96333,-397.5,-254.35406)
  physVol: TrdLayer
STEP: 0 mm.
  new pos: (149.96333,-397.5,-254.35406)
  physVol: TrdLayer
STEP: 9e-10 mm.
  new pos: (149.96333,-397.5,-254.35406)
  physVol: TrdLayer
STEP: 9e-10 mm.
  new pos: (149.96333,-397.5,-254.35406)
  physVol: TrdLayer
STEP: 9e-10 mm.
  new pos: (149.96333,-397.5,-254.35406)
  physVol: CFCtube
STEP: 10.476048 mm.
  new pos: (139.88846,-400,-255.76636)
  physVol: CFCtube
STEP: 0 mm.
  new pos: (139.88846,-400,-255.76636)



> The code for propagating in a magnetic field should take care for
> difficult cases, where it can be unclear what volume a track is actually
> crossing. In this case, though, it appears that it is the Navigator
> which is having difficulties.
> 
> I noted that you said that "" a particle should never really enter a
> "TrdLayer" volume explicitly because the daughter volume "TrdRadiator"
> in each "TrdModule" fills the upper part of the layer completely. ""

I have to change my statement regarding this point. As a matter of fact, 
the problem occurs most frequently (only??) in a part of TrdLayer that 
is not filled by further daughters. You see, the inner part of a 
TrdLayer is filled with TrdModules but there is some remaining gap at 
the fringe which is just filled with air.

> This seems to indicate that it is experiencing significant difficult at
> this level. What type of volume is a 'TrdModule'? A box, a tubs, or
> other ?? Also what is the TrdRadiator ?
>  

TrdLayer, TrdModule and TrdRadiator are all simple boxes. TrdLayer is a 
G4PVReplica slicing a TrdSuperLayer into eight divisions along z.

Cheers

Henning


None Re: Problem with very small stepsize caused by transportation process?  by Vladimir IVANTCHENKO <vnivanch@mail.cern.ch>,   10 Jan, 2007
Re: Note Problem with very small stepsize caused by transportation process? (Henning Gast)
On Wed, 10 Jan 2007, Henning Gast wrote:

> *** Discussion title: Fast Simulation, Transportation & Others
> Email replies to PublicHyperNews@slac.stanford.edu must include:
>   In-Reply-To: <"/fastsim/22"@geant4-hn.slac.stanford.edu>
>   Subject: ...change this to be about your reply.
> 
> Hi,
> 
> I am simulating a cosmic-ray detector in G4.8.2 and have encountered the
> following problem:
> 
> In some (1/1000) events, there is a very tiny step size in one of my
> "TrdLayer" volumes, leading to the event being practically stuck, for
> example: (description continues below)

Hello,

Can I ask you to try following:

/process/eLoss/MscStepLimit 0.2 false

This command switches off step limitation from multiple scattering. Doing 
this test we can distinguish msc and transportation in field problems.

VI
None Re: Problem with very small stepsize caused by transportation process?  by Henning Gast <Henning Gast>,   10 Jan, 2007
Re: None Re: Problem with very small stepsize caused by transportation process? (Vladimir IVANTCHENKO )
Hi Vladimir,

thank you for the quick response. I have run some tests using the 
command you mentioned, but the situation is unchanged: the problem still 
occurs.

Kind regards

Henning



Vladimir IVANTCHENKO wrote:
> *** Discussion title: Fast Simulation, Transportation & Others
> Email replies to PublicHyperNews@slac.stanford.edu must include:
>   In-Reply-To: <Pine.LNX.4.58.0701101523060.10346@pcepsft17.cern.ch>
>   Subject: ...change this to be about your reply.
> 
> Hello,
> 
> Can I ask you to try following:
> 
> /process/eLoss/MscStepLimit 0.2 false
> 
> This command switches off step limitation from multiple scattering. Doing 
> this test we can distinguish msc and transportation in field problems.
> 
> VI
> 
> 
> 

None Re: Problem with very small stepsize caused by transportation process?  by Henning Gast <Henning Gast>,   11 Jan, 2007
Re: None Re: Problem with very small stepsize caused by transportation process? (Henning Gast)
Hi,

I have investigated some more, and have come to a puzzling conclusion:

First, when I take my troublesome "TrdSuperLayer" volume, which forms 
part of a larger detector system, and make a separate program where I 
put it into its own world volume, everything works fine.

Second, and more importantly, in my detector construction I had the 
following code:

   physiTrdLayer = new G4PVReplica( "TrdLayer", logicTrdLayer, 
logicTrdSuperLayer, kZAxis, NbOfTrdLayersPerSuperLayer,
				   TrdLayerHeight );

I created a G4PVReplica of single layers which I then filled with some 
stuff. When I change this part as follows, replacing the replica by 
manual placements of layers, the problem disappears. Or to be more 
precise, it becomes at least two orders of magnitude less frequent.

   G4double trdLayerZ = -0.5*TrdSuperLayerHeight+0.5*TrdLayerHeight;
   for( G4int i=0 ; i<NbOfTrdLayersPerSuperLayer ; ++i ){
     new G4PVPlacement( 0, G4ThreeVector( 0.0,0.0,trdLayerZ), 
logicTrdLayer, "TrdLayer", logicTrdSuperLayer, false, i );
     trdLayerZ += TrdLayerHeight;
   }

Greetings

Henning


Henning Gast wrote:
> *** Discussion title: Fast Simulation, Transportation & Others
> Email replies to PublicHyperNews@slac.stanford.edu must include:
>   In-Reply-To: <45A504FA.7030400@physik.rwth-aachen.de>
>   Subject: ...change this to be about your reply.
> 

Question Geant4 useful for chemical reactions?  Keywords: chemical reactions
by <machado@soton.ac.uk>,   20 Oct, 2006

Hi

Does anybody know whether or not Geant4 has been used or is useful for any kind of chemical reaction problems?

Thanks

None Geant4 in parallel jobs  by leo_ams2 <leo_ams2>,   13 Oct, 2006

Does anyone out there tried Geant4 simulations in parallel jobs (batch jobs)? ...because I'm trying to run Geant4 simulations in CONDOR batch system.

Any insights would be appreciated.

Leo

Question questions about G4Region and FastSimulationModel  Keywords: G4Region FastSimulationModel
by <zhongwl@ihep.ac.cn>,   27 Mar, 2006

Hello,

I want to do a Fast Simulation with a PMT logical volume, part of my code is:

  G4Region *PmtRegion = new G4Region("PMT-Region");
  PmtRegion->AddRootLogicalVolume(pmt_log);/*the pmt_log is the
 sensitive detector*/
  new PMTOpticalModel( "pmt_optical_model", pmt_phys);

and the class PMTOpticalModel is inherited from G4VFastSimulationModel, its constructor is:

PMTOpticalModel::PMTOpticalModel (G4String modelName,
                                  G4VPhysicalVolume* envelope_phys)
  : G4VFastSimulationModel(modelName, envelope_phys->GetLogicalVolume()
   ->GetRegion())
{......
}

the program runs well and the results seems right, and there are normal output information about the optical photons in the PMT Optical Model, but there are some warnings:

WARNING - G4Region::G4Region()
          Region PMT-Region already existing in store !

*** G4Exception : InvalidSetup
      issued by : G4Region::G4Region()
The region has NOT been registered !
*** This is just a warning message.
G4ProcessManager::GetAttribute(): particle[GenericIon]
  index out of range 
  #processes[2]  index [-1]
G4ProcessManager::GetAttribute(): particle[GenericIon]
  index out of range 
  #processes[2]  index [-1]

What's the meaning of the warnings? if the region isn't registered, why the FastSimulationProcess, PMTOpticalModel have functions on optical photons when they hit on the PMTs?

Thank you!

Question Problem defining FastSimulationModel with Logical World Volume  Keywords: Problem FastSimulationModel World Volume
by Apostolos Tsirigotis <Apostolos Tsirigotis>,   24 Feb, 2006

Hi,

I want to implement a Fast Simulation Model in the World Logical Volume with Geant 4.8. I have the following code in the Detector Construction:

**************************************************************

G4VPhysicalVolume* MyDetector::Construct( )
{
......
......
  G4Region* detectorRegion = new G4Region("EM_Detector_Region");
  detectorRegion->AddRootLogicalVolume(logicalMyWorld);
  MyEMShowerModel* myShowerModel =
    new MyEMShowerModel("emShowerModel",detectorRegion);
......
......
}

***************************************************************

MyEMShowerModel class inherits from the Abstract Class G4VFastSimulationModel

But, when I run the program I get the following error:

****************************************************************

......... ......... .........

The world volume has a user-defined region <EM_Detector_Region>.

*** G4Exception : RUN:WorldHasUserDefinedRegion
      issued by : G4RunManager::DefineWorldVolume
World would have a default region assigned by RunManagerKernel.
*** Fatal Exception *** core dump ***

*** G4Exception: Aborting execution *** Aborted

****************************************************************

I have done this , and is working properly with Geant 4.7.

How can I do this in Geant 4.8 without having to change the detector geometry?

thanks...

None Re: Problem defining FastSimulationModel with Logical World Volume  Keywords: Problem FastSimulationModel World Volume
by Makoto Asai <Makoto Asai>,   27 Feb, 2006
Re: Question Problem defining FastSimulationModel with Logical World Volume (Apostolos Tsirigotis)
 G4RunManagerKernel does not allow the user to define a region 
to the world volume. The world volume has a default region set
by G4RunManagerKernel, where the default cut values are used.

 If you really want to make the world volume be the envelope
of your fast simulation, you should get the pointer of the
default region and set your FastSimulationModel to it.

 G4Region* defRegion
  = G4RegionStore::GetInstance()
     ->GetRegion("DefaultRegionForTheWorld");
 MyEMShowerModel* myShowerModel =
    new MyEMShowerModel("emShowerModel",defRegion);

Question Transportation deposits energy?  Keywords: transportation energy deposit
by Scott Zelakiewicz <zelakiew@crd.ge.com>,   10 Oct, 2005

Hi,

While examining the output of some code, I noticed that a "Transportation" process is depositing energy in my sensitive detector which seemed a little strange to me. I then modified examples/novice/N02 where I define the stepping action to be:

 void ExN02SteppingAction::UserSteppingAction(const G4Step* aStep)
 {
   G4String process = aStep->GetPostStepPoint()->GetProcessDefinedStep()
                           ->GetProcessName();
   if(process == "Transportation"){
   G4cout << "In transport step action, energy dep = "
          << "\t" << aStep->GetTotalEnergyDeposit() << G4endl;
   }
 }

and then run the run1.mac macro with no other changes. Here is a snippet of the output:

 ### Run 1 start.
 Start Run processing.
 In transport step action, energy dep =  0.022127794
 In transport step action, energy dep =  9.6219292
 In transport step action, energy dep =  0.014266496
 In transport step action, energy dep =  0.090739375
 In transport step action, energy dep =  0.0048101879
 In transport step action, energy dep =  0.10046924
 In transport step action, energy dep =  0.0018481132
 In transport step action, energy dep =  0.11301416
 In transport step action, energy dep =  0.040421597
 In transport step action, energy dep =  0.11809491
 In transport step action, energy dep =  0.0043232425
 In transport step action, energy dep =  0.040039835
 In transport step action, energy dep =  0.092960496
 In transport step action, energy dep =  0.034912215
 In transport step action, energy dep =  0.11443206
 In transport step action, energy dep =  0
 In transport step action, energy dep =  0.016303982
 >>> Event 0

This has been seen in both Geant4 6.2.p01 and 7.1. Can someone help me understand what is going on?

Thanks, Scott.

None Re: Transportation deposits energy?  by Vladimir Ivantchenko <vnivanch@mail.cern.ch>,   10 Oct, 2005
Re: Question Transportation deposits energy? (Scott Zelakiewicz)
On Mon, 10 Oct 2005, Scott Zelakiewicz wrote:

> *** Discussion title: Fast Simulation, Transportation & Others
> Email replies to PublicHyperNews@slac.stanford.edu must include:
>   In-Reply-To: <"/fastsim/8"@geant4-hn.slac.stanford.edu>
>   Subject: ...change this to be about your reply.
> 
> Hi,
> 
> While examining the output of some code, I noticed that a
> "Transportation" process is depositing energy in my sensitive detector
> which seemed a little strange to me. I then modified examples/novice/N02
> where I define the stepping action to be:
> 
>  void ExN02SteppingAction::UserSteppingAction(const G4Step* aStep)
>  {
>    G4String process = aStep->GetPostStepPoint()->GetProcessDefinedStep()
>                            ->GetProcessName();
>    if(process == "Transportation"){
>    G4cout << "In transport step action, energy dep = "
>           << "\t" << aStep->GetTotalEnergyDeposit() << G4endl;
>    }
>  }
> 
> and then run the run1.mac macro with no other changes. Here is a snippet
> of the output:
> 
>  ### Run 1 start.
>  Start Run processing.
>  In transport step action, energy dep =  0.022127794
>  In transport step action, energy dep =  9.6219292
>  In transport step action, energy dep =  0.014266496
>  In transport step action, energy dep =  0.090739375
>  In transport step action, energy dep =  0.0048101879
>  In transport step action, energy dep =  0.10046924
>  In transport step action, energy dep =  0.0018481132
>  In transport step action, energy dep =  0.11301416
>  In transport step action, energy dep =  0.040421597
>  In transport step action, energy dep =  0.11809491
>  In transport step action, energy dep =  0.0043232425
>  In transport step action, energy dep =  0.040039835
>  In transport step action, energy dep =  0.092960496
>  In transport step action, energy dep =  0.034912215
>  In transport step action, energy dep =  0.11443206
>  In transport step action, energy dep =  0
>  In transport step action, energy dep =  0.016303982
>  >>> Event 0
> 
> This has been seen in both Geant4 6.2.p01 and 7.1. Can someone help me
> understand what is going on?
> 
> Thanks, Scott.
> 

Hello,

When you start any SteppingAction all continious processes already make 
its contribution to energy loss and you see the sum of all. Likely energy 
were lost because of ionisation. Transportation only limits the step.

VI 
Note Re: Transportation deposits energy?  by John Apostolakis <John Apostolakis>,   11 Oct, 2005
Re: None Re: Transportation deposits energy? (Vladimir Ivantchenko )

I can confirm that the Transportation process only alters the energy of a charged particle in an external electric field. ( I note that I am G4Transportation's principal author.)

It generally limits the step only when a boundary is encountered between volumes. During such a step the only processes that can affect the particle are those which have a continuous component (or, in Geant4 parlance, an 'AlongStep' action).

In other steps as well, in addition to the process that limited the step (which is printed) other processes contribute to the energy loss of a track.

Regards, John Apostolakis

None Re: Transportation deposits energy?  by Samir Banik <Samir Banik>,   24 Mar, 2017
Re: Note Re: Transportation deposits energy? (John Apostolakis)
I have defined a geometry of cylindrical shape with diameter 7.6cm and height 2.5 cm. There is no electric field. When I am passing particles through the detector I still see energy loss through the process transportation. I use "step->GetPostStepPoint()->GetProcessDefinedStep()->GetProcessName()" to print the process name in a step. Can anyone please answer why GEANT is showing energy deposition in Transportation when there is no electric field?

Regards, Samir Banik

None Re: Transportation deposits energy?  by Samir Banik <Samir Banik>,   24 Mar, 2017
Re: Note Re: Transportation deposits energy? (John Apostolakis)
I have defined a geometry of cylindrical shape with diameter 7.6cm and height 2.5 cm. There is no electric field. When I am passing particles through the detector I still see energy loss through the process transportation. I use "step->GetPostStepPoint()->GetProcessDefinedStep()->GetProcessName()" to print the process name in a step. Can anyone please answer why GEANT is showing energy deposition in Transportation when there is no electric field?

Regards, Samir Banik

None Re: Transportation deposits energy?  by John Apostolakis <John Apostolakis>,   24 Mar, 2017
Re: None Re: Transportation deposits energy? (Samir Banik)
Dear Samir,

It is the ionisation process which is depositing the energy.  It occurs 
in any step, even if it is not the process which determined the step 
size  (it only limits the step if a delta electron above the current 
production threshold is emitted.)

In all steps of a charged particle the ionisation process has what is 
called an "along step" action in Geant4 which deposits energy that 
corresponds to the energy of delta electrons which have been produced, 
but fall below the production threshold - this is standard practice in 
Type II particle transport algorithms (Berger).   Please refer to the 
Physics Reference manual for further details and for references.

The transportation process simply limits the step at a boundary in some 
steps, including the one which you observed.

Best regards,

John


On 24/03/17 10:39, Samir Banik wrote:
> *** Discussion title: Fast Simulation, Transportation & Others
>
> I have defined a geometry of cylindrical shape with diameter 7.6cm and
> height 2.5 cm. There is no electric field. When I am passing particles
> through the detector I still see energy loss through the process
> transportation. I use
> "step->GetPostStepPoint()->GetProcessDefinedStep()->GetProcessName()" to
> print the process name in a step. Can anyone please answer why GEANT is
> showing energy deposition in Transportation when there is no electric
> field?
>
> Regards, Samir Banik
>
> -------------------------------------------------------------
> Visit this GEANT4 at hypernews.slac.stanford.edu message (to reply or unsubscribe) at:
> http://hypernews.slac.stanford.edu/HyperNews/geant4/get/fastsim/8/1/1/1.html
Question NEGATIVE ION DRIFT IN ELECTRIC FIELD, in TPC  Keywords: NEGATIVE ION DRIFT
by Chamkaur Ghag <Chamkaur Ghag>,   07 Dec, 2004

Can GEANT4 handle negative ion drift? I mean, if an incoming particle causes a recoil and ionisation along a track in a time projection chamber, normally the electrons would drift to the readout in an electric field. However, in a gas such as carbon disulphide, the electrons from the ionisation can attach themselves to the CS2 to form negative ions, CS2-, and drift with less diffusion. In an area of high field near the readout detector, the electrons detach from the CS2- and normal avalanche occurs. Can GEANT4 handle drifting of electrons in the E-field; can it handle attaching electrons to CS2; can CS2- ions be drifted; can the electrons detach; can the electrons avalanche in high E-field?

I hope someone can answer this for me.

Question Weird bug - energy deposit from transportation plus OutOfWorld when really well inside it.  Keywords: Bug, transportation, OutOfWorld
by Colin <cf@astro.soton.ac.uk>,   27 Apr, 2004
Hi,

I am simulating a simple geometry - the experimentalHall is just air 
and is 4m cubed, inside this is a sand pit 120*120*30cm. I am starting
1461 keV photons at the centre of the sand pit and emitting them 
isotropically.

My simulation crashes and the last thing the log file tells me is:

*********************************************************************************************************
* G4Track Information:   Particle = e-,   Track ID = 3,   Parent ID = 1
*********************************************************************************************************

Step#    X(mm)    Y(mm)    Z(mm) KinE(MeV)  dE(MeV) StepLeng TrackLeng  NextVolume ProcName
    0      452     -599    -11.6     0.998        0        0         0    pit_phys initStep
    1      451     -600    -10.9     0.585    0.413     1.68      1.68     expHall Transportation
    2      451     -600    -10.9     0.585        0        0      1.68  OutOfWorld eBrem

3 things puzzle me about this log:

1) The final step is listed as OutOfWorld, when the position of the 
point (451,-600,-10.9) is very much within my world.

2) In the second step (#1) the transportation process is listed along 
side an energy deposit - is this supposed to happen? I thought by 
definition transportation didnt deposit any energy.

3) The final step has the process eBrem listed (not transportation) and 
has no energy deposit listed.

Can anyone shed any light on what has gone wrong here or am misunderstanding the log file?

Cheers,

Colin
None Re: Weird bug - energy deposit from transportation plus OutOfWorld when really well inside it.   by Vladimir IVANTCHENKO <vnivanch@mail.cern.ch>,   27 Apr, 2004
Re: Question Weird bug - energy deposit from transportation plus OutOfWorld when really well inside it. (Colin)
On Tue, 27 Apr 2004, Colin wrote:

> *** Discussion title: Fast Simulation, Transportation & Others
> Email replies to PublicHyperNews@slac.stanford.edu must include:
>   In-Reply-To: <"/fastsim/5"@geant4-hn.slac.stanford.edu>
>   Subject: ...change this to be about your reply.
> 
> Hi,
> 
> I am simulating a simple geometry - the experimentalHall is just air 
> and is 4m cubed, inside this is a sand pit 120*120*30cm. I am starting
> 1461 keV photons at the centre of the sand pit and emitting them 
> isotropically.
> 
> My simulation crashes and the last thing the log file tells me is:
> 
> *********************************************************************************************************
> * G4Track Information:   Particle = e-,   Track ID = 3,   Parent ID = 1
> *********************************************************************************************************
> 
> Step#    X(mm)    Y(mm)    Z(mm) KinE(MeV)  dE(MeV) StepLeng TrackLeng  NextVolume ProcName
>     0      452     -599    -11.6     0.998        0        0         0    pit_phys initStep
>     1      451     -600    -10.9     0.585    0.413     1.68      1.68     expHall Transportation
>     2      451     -600    -10.9     0.585        0        0      1.68  OutOfWorld eBrem
> 
> 3 things puzzle me about this log:
> 
> 1) The final step is listed as OutOfWorld, when the position of the 
> point (451,-600,-10.9) is very much within my world.
> 
> 2) In the second step (#1) the transportation process is listed along 
> side an energy deposit - is this supposed to happen? I thought by 
> definition transportation didnt deposit any energy.
> 
> 3) The final step has the process eBrem listed (not transportation) and 
> has no energy deposit listed.
> 
> Can anyone shed any light on what has gone wrong here or am misunderstanding the log file?
> 
> Cheers,
> 
> Colin
> 
> 

Hi,

Something is wrong. What G4 release is used?

In any case I would suggest to take 
example/extended/electromagnetic/TestEm3 define your material as Air, take 
your proton, and reproduce your problem.

VI 

Warning G4DataInterpolation bug ?  by Dmitry Onoprienko <Dmitry Onoprienko>,   22 Apr, 2004
PolynomInterpolation() function in the G4DataInterpolation class
doesn't seem to be working correctly - the results can be 
unreasonable and different from invocation to invocation.

I took a quick look at the source - it looks like the first
element of internal arrays is not initialized but can be
used in calculation, depending on the argument value.
None Re: G4DataInterpolation bug ?  by Vladimir Grichine <Vladimir Grichine>,   22 Apr, 2004
Re: Warning G4DataInterpolation bug ? (Dmitry Onoprienko)
Hi Dmitry,

Yes sure, I just fixed the bug for starting i to be 0 (was 1). It was
committed as version 1.5 and I hope it will appear in the nearest
reference tag.

Cheers, Vladimir



None Will photon lose energy in a transportation process?  by Lei Zhu <leizhu@stanford.edu>,   03 Aug, 2003

Hi, there,

I am doing x-ray simulation now. 50keV gamma particles are generated in the source and in the sensitive detector, those particles only involved in transportation processes will be separated. To do this, I tracked every particle and fulfilled this functionality in the UserSteppingAction and UserTrackingAction. However, I found some particles I separated were not 50keV when they hit on the detector. This is definitely not what I expected. Will particles lose energy in transportation process? or Must I have done sth wrong in tracking particles?

Thanks in advance!

Regards, Lei

Question Problem in deuteron inelastic for plasma focus fusion   by Lam Yihua <Lam Yihua>,   09 May, 2002
dear experts,

Sorry... I dont know where shall i put this Question...
How's ur life there? :)
Currently, I'm working with condensed plasma.

At the plasma focus situation, the deuterium'll confined into a condensed volume
volume  = ~1*e-6 m3
density  = ~1*e19  particles/cm3
temperature = ~10 MeV

1) Well, i assume this situation can be created as a "detector" or "material"
2)  I assume no ion in that condensed volume

3) so, i made a volume to contain such condense plasma.
 
in my own class DetectorConstruction:


*********************************************************
G4VPhysicalVolume* LamCoDetectorConstruction::Construct()
{
   ...
   ...

  //------------------------------------------------------
  // Condensed Plasma Gas
  //------------------------------------------------------
  G4double const pi    = 3.1416;
  G4double const radius    = 0.1 *cm;
  G4double const length = 1.0 *cm;

G4double const ParticlePerML              = pow(19, 10);  
G4double const CondensedPlasmaTemperature = 110000000;
G4double const BoltzmanConst              = 1.380658*pow(-23, 10);
G4double const volume              = length*pi*(radius*radius);

G4double const CondensedPlasmaPressure    
               = (ParticlePerML*BoltzmanConst*CondensedPlasmaTemperature);
           

density         = CalculatedDensity*mg/cm3;
pressure        = (CondensedPlasmaPressure*9.869*pow(-6, 10)) *atmosphere;
temperature     = (CondensedPlasmaTemperature)*kelvin;


  //
  // Deuterium
  //
G4Material *CondensedPlasmaDeuterium = new G4Material(name="CondensedPlasmaDeuterium", density, ncomponents=1,
                                     kStateGas,temperature,pressure);
CondensedPlasmaDeuterium->AddElement(D, natoms=1);

 ...
 ...

}
***********************************************
4)  In the PhysicsList, i'd added in DeuteronInelastic process:

***********************************************
void ExN01PhysicsList::ConstructNeutronCollision()
{
    ....
    ....

   // Deuteron
  else if (particleName == "deuteron")
     {
G4DeuteronInelasticProcess *theDeuteronInelasticProcess
               = new G4DeuteronInelasticProcess("DeuteronInelastic");

  theLEDeuteronModel = new G4LEDeuteronInelastic;

 
  theLEDeuteronModel->SetMinEnergy(0.000001*eV);
  //theLENeutronModel->SetMaxEnergy(14*MeV);
 
  theDeuteronInelasticProcess->RegisterMe(theLEDeuteronModel);
  pManager->AddDiscreteProcess(theDeuteronInelasticProcess);
     }

  ....
  ....
}

***********************************************
5) When plasma focus occurs, deuterium in that condensed volume
will collide with one another to produce fusion. The expected outcome
are neutrons and deuterons+.

I assume deuteron will be created during plasma focus, then I
used GSPM class to create Deuteron, and stated the created
deuteron in the middle of that condensed plasma volume above.

I think after Deuteron created from Geant4 with GSPM
that Deuteron will interact with deuterium atoms in
condensed volume deuterium to produce neutrons.

below is the macro file for using GSPM
***********************************************

/gps/particle deuteron
/gps/type Volume
/gps/shape Cylinder
/gps/centre -10. 0. 0. cm
/gps/posrot1 1. 0. 0.
/gps/posrot2 0. 1. 0.
/gps/radius 1.0 mm
/gps/halfz 0.5 cm
/gps/angtype cos
/gps/angrot1 1. 0. 0.
/gps/angrot2 0. 1. 0.
/gps/maxtheta 1. deg
/gps/energytype Mono
/gps/monoenergy 1. MeV


/run/beamOn 1

***********************************************
6) but the output of the simulation is
***********************************************

Start Run processing.
=====================================
G4EventManager::ProcessOneEvent()
=====================================
1 vertices passed from G4Event.
G4PrimaryTransformer::PrimaryVertex (-99.4487(mm),0.476494(mm),0.582398(mm),0(nsec))
Primary particle (deuteron) --- Transfered with momentum (-8.22679,-6.97099,-8.44329)
A new track 0x8085150 (trackID 1, parentID 0) is passed to G4StackManager.
1 primaries are passed from G4EventTransformer.
!!!!!!! Now start processing an event !!!!!!!
### pop requested out of 1 stacked tracks.
Selected G4StackedTrack : 0x8090030 with G4Track 0x8085150 (trackID 1, parentID 0)
Track 0x8085150 (trackID 1, parentID 0) is passed to G4TrackingManager.

*********************************************************************************************************
* G4Track Information:   Particle = deuteron,   Track ID = 1,   Parent ID = 0
*********************************************************************************************************

Step#    X(mm)    Y(mm)    Z(mm) KinE(MeV)  dE(MeV) StepLeng TrackLeng  NextVolume ProcName
0    -99.4    0.476    0.582      1.        0        0         0 innerChamber           initStep
Track (trackID 1, parentID 0) is processed with stopping code 2
### pop requested out of 0 stacked tracks.
### 0 waiting tracks are re-classified to
0 urgent tracks and 0 waiting tracks.
NULL returned from G4StackManager.
Terminate current event processing.
Run terminated.
Run Summary
Number of events processed : 1
User=0s Real=0.01s Sys=0.01s

**********************************************
7) the Deuteron produced didnt collide with deuterium atom in that confined volume and fly into another
volume (innerChamber), and no more process had been carried out.... :(

8) I think :
a) the method i used to simulate deuteron-deuteron collision/interaction to produced fused neutron
    is wrong. Perhaps there's a better way to do so, could u please suggest some method for me to do with
    GEANT4?

b) the physics process i added in for Deuteron Inelastic may not suitable for this situation.
    Shall I need to define other physics process for Deuteron Inelastic to produce fused neutron?
       
c) The data library may not support the energy range situation?

d) Is it possible for me to fill in the Logical volume of a "detector" with ion, like H+?


thanks... :)


Note Counting optical photons  Keywords: countig photons
by Rui Bugalho de Moura <bugalho.moura@netc.pt>,   12 Feb, 2002

Hi everyone,

I'm simulating hundreds of optical photons in a scintillator, with two APD's attached to it. I want to count photons arriving at the APD on top (APD1) and the photons arriving at the APD on bottom (APD2).

Presently I have a Data singleton class with two int data members (APD1 and APD2 counters), and some other useful stuff like a ThreeVector which holds the position where the optical photons were generated. This class saves the data to a specified file at EndOfEventAction and prints last data to screen at EndOfRunAction. I my PrimaryGeneratorAction I set my data threevector to the generation position (of particle gun), and in my SteppingAction I check whether or not the particle (which can only be an optical photon) crosses a G4LogicalBorderSurface. If it does I check the name of that surface against the name of the name of APD1 and APD2 surface to know if I should increment my data class respective counters.

At the end I pretend to use the data file(s) to generate some histograms within the cint interface of root.

If someone has an opinion or comment about this, or more logic or easier or elegant way to do this, I'm glad to hear it.

Thank's in advance.

Best regards,

Rui Moura

 Add Message Add Message
to: "Fast Simulation, Transportation & Others"

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 ]