Fast Simulation, Transportation & Others

Help: Forums, postings and threads

Forums, postings and threads

Click on the Forum title, e.g. on the "Forums by Category" page, to read a sequence of postings to the Forum and its threads all in one page. If you are only interested in one thread or the thread following a specific posting, click the thread or the posting, which takes you to a smaller page, which contains only the part you are interested in and may be easier to navigate.

Layout of the posting thread(s)

The posting threads can be shown with/without the text of the postings ("Inline depth"). In addition the depth of the thread can be controlled ("Outline depth"). For both cases several values are provided, which can be toggled. Note that the displayed values are those, which can be chosen, they do not correspond to the actual display status of the thread(s).

Add message

Add a new posting thread to this Forum

Show subscribers

Click "Show subscribers" to get the List of all subscribers, who receive e-mail from postings to this Forum, if they have not explictly unsubscribed from a posting thread. This includes:

Subscribers to the forum
Explicit subscribers to the posting or any of its ancestors
The author of the posting (if he has not unsubscribed)
The authors of any ancestor posting (if they have not unsubscribed)

Some browsers display old pages from the cache

Some browsers (e.g. Firefox) display a page from the cache even though the page has been updated. As a result, one may not get the latest messages in the forum's outline or the logon ID of the previous session appears on the upper right corner. If one suspects that he or she does not get the latest content of a page, try clearing up the personal data from the browser's cache as the following:

Tools -> Clear Private Data -> Clear Private Data (from browser Firefox)

Tools -> Delete Private Data (from browser Opera)

then reflesh the current page to get the latest content.

Details on "Inline depth" and "Outline depth"

Threads and the follow-up messages are numbered. There is one line per posting, normally starting with the posting number. The URLs of a posting and its responses reflect the depth of the follow-up postings. Watch the URLs to see how this is done. Depending on the chosen display options, the thread-display may be incomplete; the number of messages at the next level is, however, displayed, e.g. "…3 message(s)". You may not see all contributors unless you choose "All".

Messages are "chained" if there are only replies at the first level, i.e. 1/1.html, 1/1/1.html etc. In case of "chained" messages the message number is replaced by the icon and there is no indentation.

Inline: Display the subject line only or also the text of the posting(s); for the choice "All" the "Outline" choices are switched off.

Argument Default value Alternative Comment

1 0 1 no text / full text of posting

2 1 All text for level 1 only / text for All postings

Argument	Default value	Alternative		Comment
1	0	1		no text / full text of posting
2	1	All		text for level 1 only / text for All postings

Outline: Choose the depth of the posting thread, successive toggle controls provide increasing detail.

Argument Default value Alternative Comment

1 2 1 2 levels / 1 level (original posting)

2 3 2 3 levels / 2 levels

3 3 All 3 levels / all levels (all postings)

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.

Argument	Default value	Alternative	Comment
1	2	1	2 levels / 1 level (original posting)
2	3	2	3 levels / 2 levels
3	3	All	3 levels / all levels (all postings)

Deposited energy larger than incoming energy in HadronElastic by Estela Suarez <Estela Suarez>, Sep 28, 08:23

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>, Jul 31, 14:29 Dear G4FastSimulation or Tracking Experts, The CMS experiment has developed and tested fast simulation models (named GflashEMShowerModel and GflashHadronShowerModel) for the CMS calorimeter simulation based on G4VFastSimulationModel and tuned to various test beam data taken recently as well as geant4. However, we are experiencing a serious memory leak from our hadronic model while testing a full chain of simulation for aiming a large scale production. Quantitatively the amount of memory leakage when using geant4 and GflashHadronShowerModel together is around 120 MB for 100 ttbar events while the baseline memory consumption is only 50 MB when using the full geant4. We believe that this memory leakage comes from a possible ill-implementation of our hadronic wrapper process even though it has functionally worked for its own purpose of the hadronic shower parameterization. Even though the source of the memory leakage may not be directly from the core geant4 routines, we would like to have your suggestions or comments on what we may try to resolve the issue. To have more information how we use the G4WrapperProcess for our GflashHadronWrapperProcess in conjunction with GflashHadronShowerModel, you may refer to our latest code from the cms lxr: http://cmslxr.fnal.gov/lxr/source/SimG4Core/GFlash/src/GflashHadronShowerModel.cc http://cmslxr.fnal.gov/lxr/source/SimG4Core/GFlash/src/GflashHadronWrapperProcess.cc Following is a short description of underlying logic flow of these two routines; 1) the first time call for GflashHadronShowerModel (i.e., fParameterisation process) is simply by-passed when testing ``GPIL for PostStep'' in G4SteppingManager (i.e., when testing fCurrentProcess->PostStepGPIL in G4SteppingManager2.cc) 2) GflashHadronWrapperProcess (which is now a wrapper process for the selected process) is testing ``GPIL for PostStep'' again only for the fParameterisation process whether dynamic conditions for GflashHadronShowerModel::ModelTrigger is met after performing the PostStepDoIt of the original process. 3) If GflashHadronShowerModel is selected as an ``ExclusivelyForced'' process, then we invoke PostStepDoIt for the fParameterisation process and return paticleChange from GflashHadronWrapperProcess. There are redundant procedures of tracking in this logic flow, but at least the wrapper has worked out as implemented for the rest of the parameterization process (i.e., making hits and killing the track). Concerning to the memory leakage issue, a relevant question is whether switching the process from the original process (hadron inelastic interaction) to the parameterization process during the stepping (i.e., at the particular stage of InvokePostStepDoItProcs in G4SteppingManager). Following lines of simplified code may be a snippet of the wrapper process, in which whether the second ``particleChange'' below the second commented line is legitimated or not: G4VParticleChange* GflashHadronWrapperProcess::PostStepDoIt( const G4Track& track, const G4Step& step) { //1. invoke PostStepDoIt for the original process particleChange = pRegProcess->PostStepDoIt(track, step); for(G4int ipm = 0 ; ipm < fProcessVector->entries() ; ipm++) { fProcess = (*fProcessVector)(ipm); if ( fProcess->GetProcessType() == fParameterisation ) { testGPIL = fProcess->PostStepGPIL(track,fStepLength,&fForceCondition ); if( fForceCondition == ExclusivelyForced) { particleChange->Clear(); //2. invoke PostStepDoIt for fParameterisation process particleChange = fProcess->PostStepDoIt(track,step); } } } return particleChange; } Our various tests show that invoking the second PostStepDoIt is directly related to the memory leakage in question. We also tested alternative implementations avoiding a possible mangle between the original process and the parameterization process; 1) instead of the invoking the second PostStepDoIt, we substitute all implementations of GflashHadronShowerModel::DoIt to the line in question. In this case, the memory leak happens if we kill the track, i.e., including following two lines which is equivalent to fastStep.KillPrimaryTrack(), (const_cast<G4Track *> (&track))->SetTrackStatus( fStopAndKill ); (const_cast<G4Track *> (&track))->SetKineticEnergy( 0.0); 2) an implementation without the wrapper, but invoking PostStepDoIt of the original process locally inside GflashHadronShowerModel::ModelTrigger to access information of secondary tracks. Again, invoking the particular call of the line, particleChange = fProcess->PostStepDoIt(...); is directly responsible for the memory leak. Our question is how memories of the original process including the particleChange are cleaned up if we discard the process and switch to a new process. Or is the switching processes during stepping not allowed at all? Sorry for too much technical details, but please let us know if we did not explain our problem clearly or did not provide enough information. Thank you for your help or any comment. Regards, ---Soon Yung Jun for the calorimeter task force of CMS

Error messages when tracking gammas: UnexpectedPositionShift by Kyrre Ness Sj�b�k <Kyrre Ness Sj�b�k>, Jul 26, 02:29

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?

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

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.

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

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?

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

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

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

Geant4 useful for chemical reactions? Keywords: chemical reactions by <machado@soton.ac.uk>, 20 Oct, 2006 Hi Does anybody know whether or not Geant4 has been used or is useful for any kind of chemical reaction problems? Thanks

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

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

*** G4Exception: Aborting execution *** Aborted

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

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

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

thanks...

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.

NEGATIVE ION DRIFT IN ELECTRIC FIELD, in TPC Keywords: NEGATIVE ION DRIFT by Chamkaur Ghag <c.ghag@ed.ac.uk>, 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

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.

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

Add Message

to: "Fast Simulation, Transportation & Others"