Forums by Category Forums by Time Order Request a New Forum Recent Postings Search in Forums Subscribe to Forums Member Info Members List New Member Overview Contact Admin

Show subscribers

  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

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

Inline Depth:

0

1

Add message:

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 Re: Memory leakage using G4WrapperProcess: a user implementation  by Soon Yung Jun <Soon Yung Jun>,   Aug 07, 14:11 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>,   Aug 12, 01:14 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>,   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? Re: Error messages when tracking gammas: UnexpectedPositionShift  by Vladimir Ivanchenko <Vladimir Ivanchenko>,   Jul 26, 10:40 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>,   Jul 26, 14:41 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 <syjun@fnal.gov> a écrit : > *** Discussion title: Fast Simulation, Transportation & Others > Email replies to PublicHyperNews@slac.stanford.edu must include: > In-Reply-To: <"/fastsim/26"@geant4-hn.slac.stanford.edu> > Subject: ...change this to be about your reply. > > Hi G4FastSimulation expert: > > I want to trigger a fast simulation model at the point of a particular > hadronic interaction, for an example, at the first hadronic inelastic > interaction inside an envelope. Below is a snipet of my code > implemented inside ModelTrigger with geant4.8.2.p01 > > ----------------------------------------------------------------------> > > G4bool trigger = false; > > G4StepPoint* postStep = > fastTrack.GetPrimaryTrack()->GetStep()->GetPostStepPoint(); > G4String procName = postStep->GetProcessDefinedStep()->GetProcessName(); > G4TrackVector* secondary = > fastTrack.GetPrimaryTrack()->GetStep()->GetSecondary(); > > if( procName == "PionPlusInelastic" && (*secondary).size() > 0 ) { > trigger = true; > //should delete secondaries > //fastTrack.GetPrimaryTrack()->GetStep()->DeleteSecondaryVector(); > } > > return trigger; > > <---------------------------------------------------------------------- > > The problem that I encountered is that the kinetic energy of the fastTrack > (i.e., fastTrack.GetPrimaryTrack()->GetKineticEnergy()) in the "DoIt" > method is the energy after the hadronic interaction (i.e., after loosing > primary energy). Since I want to > parameterize the hadronic shower (energy) with a fast simulation model, > the condition that I implemented in ModelTrigger is actually one > step "behind" the step where the parameterized physics should be > triggered. It seems that this may be a general problem if the condition > in ModelTrigger depends on a specific physics process. Is there any > fundamental logistics to get around this problem? > Thanks for your help. > > Regards, > ---Soon > ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. 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: <Pine.LNX.4.58.0701101523060.10346@pcepsft17.cern.ch> > Subject: ...change this to be about your reply. > > Hello, > > Can I ask you to try following: > > /process/eLoss/MscStepLimit 0.2 false > > This command switches off step limitation from multiple scattering. Doing > this test we can distinguish msc and transportation in field problems. > > VI > > > 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<NbOfTrdLayersPerSuperLayer ; ++i ){ new G4PVPlacement( 0, G4ThreeVector( 0.0,0.0,trdLayerZ), logicTrdLayer, "TrdLayer", logicTrdSuperLayer, false, i ); trdLayerZ += TrdLayerHeight; } Greetings Henning Henning Gast wrote: > *** Discussion title: Fast Simulation, Transportation & Others > Email replies to PublicHyperNews@slac.stanford.edu must include: > In-Reply-To: <45A504FA.7030400@physik.rwth-aachen.de> > Subject: ...change this to be about your reply. >

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

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

Add Message

to: "Fast Simulation, Transportation & Others"