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

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

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: --------------------------------------------------------------- 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
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
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 
Re: Missing de-excitation for *Bi210 in version 10.3.p01  by michel maire <michel maire>,   25 Jul, 2017
Re: 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 
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 
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
Re: Why did my Method not Work  by michel maire <michel maire>,   10 Feb, 2017
Re: 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 
Re: Why did my Method not Work  by Sahra <Sahra>,   13 Feb, 2017
Re: 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
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 
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: 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 
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: 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 
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: 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 
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 
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 ? 
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 
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.
Re: low-energy tracks incorrectly stopped  by Tom Roberts <Tom Roberts>,   30 Nov, 2015
Re: 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.
Re: low-energy tracks incorrectly stopped  by Vladimir Ivanchenko <Vladimir Ivanchenko>,   04 Jan, 2016
Re: 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 
Re: low-energy tracks incorrectly stopped  by Artem Zontikov <Artem Zontikov>,   28 Nov, 2015
Re: 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.
Re: low-energy tracks incorrectly stopped  by Tom Roberts <Tom Roberts>,   28 Nov, 2015
Re: 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....
Re: low-energy tracks incorrectly stopped  by Artem Zontikov <Artem Zontikov>,   29 Nov, 2015
Re: 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.
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 
Re: Energy loss in Tranport  by Vladimir Ivanchenko <Vladimir Ivanchenko>,   04 Jan, 2016
Re: 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
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:
_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});
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 
Re: G4Transportation and dynamic charge and mass  by Vladimir Ivanchenko <Vladimir Ivanchenko>,   04 Jan, 2016
Re: 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 
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
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
Re: Step Length  by Michael H. Kelsey <Michael H. Kelsey>,   03 Feb, 2015
Re: 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.
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.
Re: get Mean free path  by michel maire <michel maire>,   04 Mar, 2014
Re: 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 �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 
Re: get Mean free path  by Artem Basalaev <Artem Basalaev>,   04 Mar, 2014
Re: 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 �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 > 
Re: get Mean free path  by michel maire <michel maire>,   05 Mar, 2014
Re: 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 
Re: get Mean free path  by Artem Basalaev <Artem Basalaev>,   06 Mar, 2014
Re: 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 > 
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
Re: Interaction length comparison  by Marc Verderi <Marc Verderi>,   07 Feb, 2014
Re: 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 
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
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
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
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.
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.
Re: G4PhantomParameterisation and parallel world problem  by Pedro Arce <Pedro Arce>,   06 Nov, 2012
Re: 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
Re: G4PhantomParameterisation and parallel world problem  by Mathieu Plamondon <Mathieu Plamondon>,   06 Nov, 2012
Re: 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
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.
Re: How to collect the results from MPI parrallel  by Matthew Lund <Matthew Lund>,   06 Sep, 2014
Re: 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.
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 
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
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.
Re: Query: polarized muon decays  by Gumplinger Peter <Gumplinger Peter>,   26 Mar, 2012
Re: 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): We currently have one problem in that muons coming to rest are not re-accelerated along the local E-field: 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
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?
Re: Problems with transportation with spin  by Tom Roberts <Tom Roberts>,   20 Mar, 2012
Re: 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?
Re: Problems with transportation with spin  by Tom Roberts <Tom Roberts>,   15 Mar, 2012
Re: 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
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 
Re: 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 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! Re: Radioactive decay causes by L.G. Sarmiento <L.G. Sarmiento>, 31 Jan, 2012 Re: 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  Re: Radioactive decay causes by Vladimir Ivanchenko <Vladimir Ivanchenko>, 09 Feb, 2012 Re: 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 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 Re: How can I change Maximum Kinetic Energy from TeV to PeV? by Lilia Drakopoulou <Lilia Drakopoulou>, 14 Oct, 2011 Re: 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 Re: How can I change Maximum Kinetic Energy from TeV to PeV? by Vladimir Ivanchenko <Vladimir Ivanchenko>, 16 Feb, 2012 Re: 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
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. 
Re: Transportation process  by michel maire <michel maire>,   16 Sep, 2011
Re: 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 
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.
Re: Transportation process   by Manish gohil <Manish gohil>,   14 Sep, 2011
Re: 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,
Re: Transportation process   by michel maire <michel maire>,   15 Sep, 2011
Re: 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 
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?
Re: How can i specified a physical process for a certain volume?  by Marc Verderi <Marc Verderi>,   26 May, 2011
Re: 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 
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
Re: G4ParticleGun vs. G4GeneralParticleSource: radiogenics, distributed sources  by Pedro Arce <Pedro Arce>,   28 Apr, 2011
Re: 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
Re: G4ParticleGun vs. G4GeneralParticleSource: radiogenics, distributed sources  by michel maire <michel maire>,   26 Apr, 2011
Re: 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 
Re: G4ParticleGun and radiogenics -- is "particle_momentum_direction" used?  by Michael H. Kelsey <Michael H. Kelsey>,   26 Apr, 2011
Re: 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
Re: G4ParticleGun and radiogenics -- is   by michel maire <michel maire>,   26 Apr, 2011
Re: 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 
Re: G4ParticleGun vs. G4GeneralParticleSource: radiogenics, distributed sources  by Michael H. Kelsey <Michael H. Kelsey>,   26 Apr, 2011
Re: 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 
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.
Re: Energy conservation problem.  by Loïc Grevillot <Loïc Grevillot>,   22 Mar, 2011
Re: 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.
Re: Energy conservation problem.  by Gianfranco Gargano <Gianfranco Gargano>,   22 Mar, 2011
Re: 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 
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
Re: Information about "frozen shower libraries"  by Marc Verderi <Marc Verderi>,   22 Dec, 2010
Re: 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 
Re: Information about "frozen shower libraries"  by Mario <Mario>,   23 Dec, 2010
Re: 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?
Re: Information about "frozen shower libraries"  by Marc Verderi <Marc Verderi>,   23 Dec, 2010
Re: 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 
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. 
Re: Geant4 simulation in PIXE  by Marc Verderi <Marc Verderi>,   20 Dec, 2010
Re: 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 
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?
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
Re: geant4 transportation issue  by Marc Verderi <Marc Verderi>,   04 May, 2010
Re: 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 > 
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 "<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 "<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 "<>> 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 "<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 "<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 "<>> 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 "< 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
=3B
=3B
=3BHi there  =3B=2C
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 = =3Bwords =2Csuppose I use =3B 12 cm of Al2O3 =3Bas shielding materi= al =3B=2C and I =3Bwould like to determine the efficiency of this s= hielding material=2Cthen I have to determine the fraction of neutrons that = are transmitted .
After the shielding material =2CI'm created a vacuum g= eometry in ''DetectorConstruction'' and defined it as sensitive detector .I= use =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).
But we have 2 procedure to make in file ''SD''  =3B
=  =3BG4bool neutronTrackerSD::ProcessHits(G4Step* aStep=2CG4Touc= hableHistory* ROhist)
{
=3B G4Track* aTrack =3D aStep->=3BGetT= rack()=3B
=3B G4double edep =3D aStep->=3BGetTotalEnergyDeposit()= =3B
=3B G4StepPoint* point1=3DaStep->=3BGetPreStepPoint()=3B
&= nbsp=3B G4StepPoint* point2=3DaStep->=3BGetPostStepPoint()=3B
=3B=  =3B
if (point2->=3BGetStep= Status()=3D=3DfGeomBoundary)
=3B {
=3B G4TouchableHa= ndle touch2 =3D point1->=3BGetTouchableHandl= e()=3B
=3B G4VPhysicalVolume* volume2 =3D touch2->=3BGetVolume()= =3B
=3B G4String name =3D volume2->=3BGetName()=3B
=3B G4= cout<=3B<=3B"volume "<=3B<=3Bname<=3B<=3BG4endl=3B
=3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B and
G4bool neutronTrack= erSD::ProcessHits(G4Step* aStep=2CG4TouchableHistory* ROhist)
{
= =3B G4Track* aTrack =3D aStep->=3BGetTrack()=3B
=3B G4double edep= =3D aStep->=3BGetTotalEnergyDeposit()=3B
=3B G4StepPoint* point1= =3DaStep->=3BGetPreStepPoint()=3B
=3B G4StepPoint* point2=3DaStep= ->=3BGetPostStepPoint()=3B
=3B
=3B if (point2->=3BGetStepStatus()=3D=3DfGeomBoundary)
=3B {
=3B G4TouchableHandle touch2 =3D<= /STRONG> point2->=3BGetTouchableHand= le()=3B
=3B G4VPhysicalVolume* volume2 =3D touch2-= >=3BGetVolume()=3B
=3B G4String name =3D volume2->=3BGetName()= =3B
=3B G4cout<=3B<=3B"volume "<=3B<=3Bname<=3B<=3BG4en= dl=3B
=3B
=3BIn the file ''neutronTrackerSD.cc ' '= If I use
G4bool neutronTrackerSD::ProcessHits(G4Step* aStep=2CG= 4TouchableHistory* ROhist)
{
=3B G4Track* aTrack =3D aStep->= =3BGetTrack()=3B
=3B G4double edep =3D aStep->=3BGetTotalEnergyDe= posit()=3B
=3B G4StepPoint* point1=3DaStep->=3BGetPreStepPoint()= =3B
=3B G4StepPoint* point2=3DaStep->=3BGetPostStepPoint()=3B
=  =3B
=3B
if (point2->= =3BGetStepStatus()=3D=3DfGeomBoundary)
=3B {
=3B G4T= ouchableHandle touch2 =3D point1->=3BGetTouc= hableHandle()=3B
=3B G4VPhysicalVolume* volume2 =3D touch2->=3BGe= tVolume()=3B
=3B G4String name =3D volume2->=3BGetName()=3B
&n= bsp=3B G4cout<=3B<=3B"volume "<=3B<=3Bname<=3B<=3BG4endl=3B
=
I get this results volume Tubs1
>=3B>=3B>=3B Event 62
=  =3B =3B =3B 420 trajectories stored in this event.
volume T= ubs
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
volum= e Tubs1
(such as tubs1 is the name of the w= orld volume(vacuum)=2C Tubs is =3Bthe name= of  =3Bshielding material(Al2O3) and Tubstransmission is the name = =3Bof vaccum geometry('detector' after shielding material)).

Hi ther= e =2C
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 =3Bwords =2Csuppose I us= e =3B 12 cm of Al2O3 =3Bas shielding material =3B=2C and I = =3Bwould like to determine the efficiency of this shielding material=2Cthen= I have to determine the fraction of neutrons that are transmitted .
Aft= er the shielding material =2CI'm created a vacuum geometry in ''DetectorCon= struction'' and defined it as sensitive detector .I use =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).
But we h= ave 2 procedure to make in file ''SD''  =3B
=3BG4bool n= eutronTrackerSD::ProcessHits(G4Step* aStep=2CG4TouchableHistory* ROhist){
=3B G4Track* aTrack =3D aStep->=3BGetTrack()=3B
=3B G4= double edep =3D aStep->=3BGetTotalEnergyDeposit()=3B
=3B G4StepPo= int* point1=3DaStep->=3BGetPreStepPoint()=3B
=3B G4StepPoint* poi= nt2=3DaStep->=3BGetPostStepPoint()=3B
=3B
=3B if (point2->=3BGetStepStatus()=3D=3DfGeomBoundary)
=  =3B {
=3B G4TouchableHandle touch2 =3D p= oint1->=3BGetTouchableHandle()=3B
=3B G4VPhysicalVolume* v= olume2 =3D touch2->=3BGetVolume()=3B
=3B G4String name =3D volume= 2->=3BGetName()=3B
=3B G4cout<=3B<=3B"volume "<=3B<=3Bnam= e<=3B<=3BG4endl=3B

=3B&n= bsp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B and
G4bool neutronTrackerSD::P= rocessHits(G4Step* aStep=2CG4TouchableHistory* ROhist)
{
=3B G4T= rack* aTrack =3D aStep->=3BGetTrack()=3B
=3B G4double edep =3D aS= tep->=3BGetTotalEnergyDeposit()=3B
=3B G4StepPoint* point1=3DaSte= p->=3BGetPreStepPoint()=3B
=3B G4StepPoint* point2=3DaStep->=3B= GetPostStepPoint()=3B
=3B
= =3B if (point2->=3BGetStepStatus()=3D=3DfGeomBoundary)
=3B {
=3B G4TouchableHandle touch2 =3D point2->=3BGetTouchableHandle()= =3B
=3B G4VPhysicalVolume* volume2 =3D touch2->= =3BGetVolume()=3B
=3B G4String name =3D volume2->=3BGetName()=3B<= BR> =3B G4cout<=3B<=3B"volume "<=3B<=3Bname<=3B<=3BG4endl= =3B
=3B
=3BIn the file ''neutronTrackerSD.cc ' 'If= I use
G4bool neutronTrackerSD::ProcessHits(G4Step* aStep=2CG4T= ouchableHistory* ROhist)
{
=3B G4Track* aTrack =3D aStep->=3BG= etTrack()=3B
=3B G4double edep =3D aStep->=3BGetTotalEnergyDeposi= t()=3B
=3B G4StepPoint* point1=3DaStep->=3BGetPreStepPoint()=3B =3B G4StepPoint* point2=3DaStep->=3BGetPostStepPoint()=3B
= =3B
=3B
if (point2->=3BGe= tStepStatus()=3D=3DfGeomBoundary)
=3B {
=3B G4Toucha= bleHandle touch2 =3D point1->=3BGetTouchable= Handle()=3B
=3B G4VPhysicalVolume* volume2 =3D touch2->=3BGetVolu= me()=3B
=3B G4String name =3D volume2->=3BGetName()=3B
= =3B G4cout<=3B<=3B"volume "<=3B<=3Bname<=3B<=3BG4endl=3B
I get this results volume Tubs1
>=3B>=3B>=3B Event 62
&nb= sp=3B =3B =3B 420 trajectories stored in this event.
volume Tubs=
volume Tubs1
volume Tubs
volume Tubs1
volume Tubs
volume Tu= bs1
volume Tubs
volume Tubstransmission
volume Tubs1
volume Tub= s
volume Tubs1
volume Tubs
volume Tubs1
volume Tubs
volume T= ubs1
(such as tubs1 is the name of the worl= d volume(vacuum)=2C Tubs is =3Bthe name of=  =3Bshielding material(Al2O3) and Tubstransmission is the name =3B= of vaccum geometry('detector' after shielding material)).

>=3B If = I use =3B in the file ''SD''
if (point= 2->=3BGetStepStatus()=3D=3DfGeomBoundary)
=3B {
=3B G4TouchableHandle touch2 =3D
point2->=3BGetTouchableHandle()=3B
= =3B G4VPhysicalVolume* volume2 =3D touch2->=3BGetVolume()=3B
&= nbsp=3B G4String name =3D volume2->=3BGetName()=3B
=3B G4cout<= =3B<=3B"volume "<=3B<=3Bname<=3B<=3BG4endl=3B

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~/d= raw/current
volume Tubs1
=3B*** Break *** segmentation violation=
(no debugging symbols found)
Attaching to program: /proc/9544/exe=2C process= 9544
(no debugging symbols found)...done.
(no debugging symbols foun= d)...done.
>=3B My problem is what's the difference b= etweenif (point2->=3BGetStepStatus()=3D=3Df= GeomBoundary)
=3B {
=3B G4Touchable= Handle touch2 =3D
point2->= =3BGetTouchableHandle()=3B
=3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B and
=3Bif (point2->=3BGetStepStatus()=3D=3DfGe= omBoundary)
=3B {
=3B G4Toucha= bleHandle touch2 =3D
point1->=3BGetTouchableHandle()=3B

>=3Bwhat's the core= ctness result I use to give the fraction of particle are transmitted and ho= w to resolve =3Berror of segmentation violation.
Many thanks.

Naima.

Hotmail : une messagerie performante et gratuite avec une s=E9curit=E9 sign= =E9e Microsoft P= rofitez-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 P= rofitez-en

Hotmail : une messagerie fiable a= vec la protection anti-spam performante de Microsoft Inscrivez-vous = --_b683cf6c-26f2-4e8a-bcc9-d2653a00bf9b_-- 
Re: RE: detecting particle leaving a volume  by smith <smith>,   08 Oct, 2012
Re: 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
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 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 matIndex; --- > std::vector 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. 
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.
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 (&track))->SetTrackStatus( fStopAndKill ); (const_cast (&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 
Re: Memory leakage using G4WrapperProcess: a user implementation  by Soon Yung Jun <Soon Yung Jun>,   07 Aug, 2009
Re: 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
Re: Memory leakage using G4WrapperProcess: a user implementation  by Vladimir Ivanchenko <Vladimir Ivanchenko>,   12 Aug, 2009
Re: 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
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?
Re: Error messages when tracking gammas: UnexpectedPositionShift  by Vladimir Ivanchenko <Vladimir Ivanchenko>,   26 Jul, 2009
Re: 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 Re: Error messages when tracking gammas: UnexpectedPositionShift by Kyrre Ness Sjøbæk <Kyrre Ness Sjøbæk>, 26 Jul, 2009 Re: 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
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);
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. 
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
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
Re: CRY and Geant4  by Sean Turnbull <Sean Turnbull>,   16 Feb, 2009
Re: 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
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.
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.
Re: Forced Compton interaction with Penelope model  Keywords: Forced Compton interaction with Penelope model
by Luciano Pandola <Luciano Pandola>,   17 Apr, 2008
Re: 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 
Re: Forced Compton interaction with Penelope model  Keywords: Forced Compton interaction with Penelope model
by michel maire <michel maire>,   18 Apr, 2008
Re: 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....
Re: Forced Compton interaction with Penelope model  by Vladimir IVANTCHENKO <vnivanch@mail.cern.ch>,   17 Apr, 2008
Re: 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 
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 
Re: correct random seed  by Mariusz <Mariusz>,   12 Mar, 2008
Re: correct random seed (Mariusz)
 OK, I had no proper initialization of random number engine.  Mariusz
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?
Re: FORCED PHOTONS INTERACTION  Keywords: Forced interaction, fast simulation
by michel maire <michel maire>,   21 Jan, 2008
Re: 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 
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!
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!
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.
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 
Re: triggering hadronic Inelastic interactions inside ModelTrigger  by Marc Verderi <Marc Verderi>,   10 May, 2007
Re: 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 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. 
Re: triggering hadronic Inelastic interactions inside ModelTrigger  by Soon Yung Jun <Soon Yung Jun>,   10 May, 2007
Re: 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 
Re: triggering hadronic Inelastic interactions inside ModelTrigger  Keywords: fast simulation, parameterization, trigger, hadronic
by John Apostolakis <John Apostolakis>,   26 Jun, 2007
Re: 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
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 
Re: May I modify the energy threshold?  by Vladimir IVANTCHENKO <vnivanch@mail.cern.ch>,   06 Feb, 2007
Re: 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 
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
Re: Problem with very small stepsize caused by transportation process?  Keywords: small stepsize, transportation
by John Apostolakis <John Apostolakis>,   11 Jan, 2007
Re: 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 ?
Re: Problem with very small stepsize caused by transportation process?  by Henning Gast <Henning Gast>,   12 Jan, 2007
Re: 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 
Re: Problem with very small stepsize caused by transportation process?  by Vladimir IVANTCHENKO <vnivanch@mail.cern.ch>,   10 Jan, 2007
Re: 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 
Re: Problem with very small stepsize caused by transportation process?  by Henning Gast <Henning Gast>,   10 Jan, 2007
Re: 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: > 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 > > > 
Re: Problem with very small stepsize caused by transportation process?  by Henning Gast <Henning Gast>,   11 Jan, 2007
Re: 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 *** 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. > 
Geant4 useful for chemical reactions?  Keywords: chemical reactions
 Hi Does anybody know whether or not Geant4 has been used or is useful for any kind of chemical reaction problems? Thanks
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
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!
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 . *** 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...
Re: Problem defining FastSimulationModel with Logical World Volume  Keywords: Problem FastSimulationModel World Volume
by Makoto Asai <Makoto Asai>,   27 Feb, 2006
Re: 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); 
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.
Re: Transportation deposits energy?  by Vladimir Ivantchenko <vnivanch@mail.cern.ch>,   10 Oct, 2005
Re: 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 
Re: Transportation deposits energy?  by John Apostolakis <John Apostolakis>,   11 Oct, 2005
Re: 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
Re: Transportation deposits energy?  by Samir Banik <Samir Banik>,   24 Mar, 2017
Re: 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
Re: Transportation deposits energy?  by Samir Banik <Samir Banik>,   24 Mar, 2017
Re: 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
Re: Transportation deposits energy?  by John Apostolakis <John Apostolakis>,   24 Mar, 2017
Re: 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 
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.
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 
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: 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 
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. 
Re: G4DataInterpolation bug ?  by Vladimir Grichine <Vladimir Grichine>,   22 Apr, 2004
Re: 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 
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
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... :) 
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
 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 ]