Fields: Magnetic and Otherwise

Help: Forums, postings and threads

Forums, postings and threads

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

Layout of the posting thread(s)

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

Add message

Add a new posting thread to this Forum

Show subscribers

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

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

Some browsers display old pages from the cache

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

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

Tools -> Delete Private Data (from browser Opera)

then reflesh the current page to get the latest content.

Details on "Inline depth" and "Outline depth"

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

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

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

Argument Default value Alternative Comment

1 0 1 no text / full text of posting

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

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

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

Argument Default value Alternative Comment

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

2 3 2 3 levels / 2 levels

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

This is a discussion of uniform and non-uniform fields, magnetic, electric and otherwise, in which particles are propagated, and their relation to particle steppers.

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)

How turn on the magnetic field by Paul <Paul>, Nov 20, 06:18 Hi Users, Two weeks I try to add magnetic field to my simulation. I used to N03 and in this case it was verry simple. I wrote line /N03/det/setField 3 tesla in file.mac and gave control/execute file.mac in Idle> and it worked. Next I tried to do this same method in TestEm3. When I wrote /testem/det/setField 5 tesla in file.mac and started in Idle> I got the command: COMMAND NOT FOUND. On the other hand iI tried to modify the codes in DetectorConstruction.cc file. void DetectorConstruction::SetMagField(G4double fieldValue) { //apply a global uniform magnetic field along Z axis // fieldValue = 3. * tesla; G4FieldManager* fieldMgr = G4TransportationManager::GetTransportationManager()->GetFieldManager(); if(magField) delete magField; //delete the existing magn field if(fieldValue!=0.) // create a new one if non nul { magField = new G4UniformMagField(G4ThreeVector(0.,fieldValue,0.)); fieldMgr->SetDetectorField(magField); fieldMgr->CreateChordFinder(magField); } else { magField = 0; fieldMgr->SetDetectorField(magField); } } But the results from simulations without magnetic field are this same like 3 tesla and 20 tesla. Maybe I should to switch on magnetic filed but I don't know how. Why command from .mac file is don't working. Help me please Pawel

=?UTF-8?B?QnVnPz8=?= A question of G4EqEMFieldWithSpin.cc by Hiromi Iinuma <Hiromi Iinuma>, Nov 04, 23:32 Hello, I am checking spin direction as a function of time in electromagnetic field. G4EqEMFieldWithSpin.cc includes Thomas-BMT equation as follows: http://www-geant4.kek.jp/lxr/source//geometry/magneticfield/src/ G4EqEMFieldWithSpin.cc#L27 ------snip--------- 128 G4ThreeVector BField(Field[0],Field[1],Field[2]); 129 G4ThreeVector EField(Field[3],Field[4],Field[5]); 130 131 G4ThreeVector u(y[3], y[4], y[5]); 132 u *= pModuleInverse; 133 134 G4double udb = anomaly*beta*gamma/(1.+gamma) * (BField * u); 135 G4double ucb = (anomaly+1./gamma)/beta; 136 G4double uce = anomaly + 1./(gamma+1.); 137 138 G4ThreeVector Spin(y[9],y[10],y[11]); 139 140 G4ThreeVector dSpin 141 = ParticleCharge*omegac*( ucb*(Spin.cross(BField))-udb*(Spin. cross(u)) 142 // from Jackson 143 // -uce*Spin.cross(u.cross(EField)) ); 144 // but this form has one less operation 145 - uce*(u*(Spin*EField) - EField*(Spin *u)) ); 146 ----snip-------- I think "EField" or "usb" should be divided by "c_light". Relativistic charged particle feels electric field as magnetic field via "\vec{B} =\vec{beta} x \vec{E} /light_c". In the source code (G4EqEMFieldWithSpin.cc), dimension does not match. "EField [volt/m]=[kg*m/(sec^3*A)]" "BField[tesla]=[kg/(sec^2*A)]" Without applying "EField *=1/light_c " or "uce = uce/light_c", simulated spin rotation frequency do not agree with the correct frequency from Thomas-BMT equation. If you look at a different part of "G4EqEMFieldWithSpin.cc", this problem may be clear. -----snip------- 101 G4double cof2 = Energy/c_light ; -----snip-------- 117 dydx[3] = cof1*(cof2*Field[3] + (y[4]*Field[2] - y[5]*Field[1])) ; 118 119 dydx[4] = cof1*(cof2*Field[4] + (y[5]*Field[0] - y[3]*Field[2])) ; 120 121 dydx[5] = cof1*(cof2*Field[5] + (y[3]*Field[1] - y[4]*Field[0])) ; ------snip-------- In this part, Electric field; Field[3-5] is multiplied by 1/c_light. Here, 128 G4ThreeVector BField(Field[0],Field[1],Field[2]); 129 G4ThreeVector EField(Field[3],Field[4],Field[5]); Does anybody has such a problem? Thanks in advance, Hiromi

the proper time goes back by Olivier Dadoun <Olivier Dadoun>, Sep 10, 07:04 Hello, I am trying to put an Electromagnetic field (in a localized volume) after an Tungsten target. I have followed the recommendation gave by Peter Gumplinger http://tinyurl.com/nfpk7t So inside my DetectorConstruction I have G4ThreeVector positionTarget= G4ThreeVector(0,0,samplerLength+targetSizeZ/2); G4Box* solidTarget = new G4Box("Target",targetSizeXY/2.,targetSizeXY/2.,targetSizeZ/2.); G4LogicalVolume* logicTarget = new G4LogicalVolume(solidTarget, aMaterial,"Target"); pTarget = new G4PVPlacement(0,positionTarget,logicTarget,"Target",lWorld,false,0); G4VisAttributes* LogVisAttTarget= new G4VisAttributes(G4Colour(.0,1.,0.)); logicTarget ->SetVisAttributes(LogVisAttTarget); // register logical Volume in PolarizationManager with zero polarization G4PolarizationManager * polMgr = G4PolarizationManager::GetInstance(); polMgr->SetVolumePolarization(logicTarget,G4ThreeVector(0.,0.,0.)); //Target Calo PPSTargetCaloSD* TargetCaloSD= new PPSTargetCaloSD("TargetCaloSD",this); SDman->AddNewDetector(TargetCaloSD); logicTarget->SetSensitiveDetector(TargetCaloSD); static G4bool fieldIsInitialized = false; if(!fieldIsInitialized) { Field = new PPSField(); pEquation = new G4EqMagElectricField(Field); pStepper = new G4ClassicalRK4 (pEquation); pFieldMgr = new G4FieldManager(); //pFieldMgr = G4TransportationManager::GetTransportationManager()->GetFieldManager(); pIntgrDriver = new G4MagInt_Driver(0.000001*mm,pStepper,pStepper->GetNumberOfVariables() ); pChordFinder = new G4ChordFinder(pIntgrDriver); pFieldMgr->SetChordFinder( pChordFinder ); pFieldMgr->SetDetectorField(Field); fieldIsInitialized = true; } G4ThreeVector positionCapture= G4ThreeVector(0,0,targetSizeZ+CaptureLength/2.); G4Box *solidCapture = new G4Box("CaptureBox",AMD_XY_size,AMD_XY_size,CaptureLength/2); G4LogicalVolume* logicCapture = new G4LogicalVolume(solidCapture,Vacuum,"theCaptureBox"); pCapture=new G4PVPlacement(0,positionCapture,logicCapture,"CaptureBox",lWorld,false,0); G4VisAttributes* LogVisAttCapture= new G4VisAttributes(G4Colour(1.0,0.5,0.5)); logicCapture ->SetVisAttributes(LogVisAttCapture); logicCapture->SetFieldManager(pFieldMgr,true); And my PPSField class is only: PPSField::PPSField() { } void PPSField::GetFieldValue(const double point[4], double *Bfield ) const { // Magnetic field Bfield[0] = 0; Bfield[1] = 0; Bfield[2] = 0.5*tesla; // Electric field Bfield[3] = 0; Bfield[4] = 0; Bfield[5] = 17.*megavolt/m; } When I run a electron beam of Several MeV impinging on my target I have those following error: G4ParticleChange::CheckIt : the global time goes back !! Difference: 0.074773488261472[ns] G4ParticleChange::CheckIt : the proper time goes back !! Difference: 0.0026325540767444[ns] G4ParticleChange::CheckIt ----------------------------------------------- G4ParticleChange Information ----------------------------------------------- # of 2ndaries : 0 ----------------------------------------------- Energy Deposit (MeV): 0 Non-ionizing Energy Deposit (MeV): 0 Track Status : Alive True Path Length (mm) : 11.1 Stepping Control : 0 Mass (GeV) : 0 Charge (eplus) : 0 MagneticMoment : 0 : = 0*[e hbar]/[2 m] Position - x (mm) : -9 Position - y (mm) : -2.96 Position - z (mm) : 14.9 Time (ns) : 0 Proper Time (ns) : -0.00249 Momentum Direct - x : -0.795 Momentum Direct - y : -0.55 Momentum Direct - z : 0.255 Kinetic Energy (MeV): 14 Polarization - x : 0 Polarization - y : 0 Polarization - z : 0 Touchable (pointer) : 0x4dbd0a0 Do you have an idea of what I am doing wrong ? by advance thank you Olivier

A problem on the creation of electric field by <lesward>, 23 May, 2009 In the examples provided in Geant4 which I've read, all the electric fields are created in the whole detector geometry. Therefore, I find it hard to describe a field for only a part of the detector. Is there anybody who can show me an example which sets electric fields for specific parts of the volume hierarchy? Thanks very much!

Problems with Radial Electric Field by Clarisse <Clarisse>, 27 Apr, 2009

Hi,
I designed a class derived from G4ElectricField to setup a non-uniform, radial electric field inside a cylindrical He3 Tube (E = Voltage / ( radius * ln(b/a)), where Voltage, b, and a are 3 parameters and r is the radius at which the field is evaluated and contains the position dependence).
I am attaching the relevant files (4 of them). In addition, I have the following few lines in myDetDetectorConstruction:
#include "myDetFieldSetup.hh"
logicGasTube = new G4LogicalVolume(solidGasTube , gasmixture, "gastube_log");

// Set local field manager and local Electric Field in he3 tube G4bool allLocal = true ;

logicGasTube->SetFieldManager( fEmFieldSetup->GetLocalFieldManager(), allLocal ) ;

The code compiles fine, but I am getting the following error as I throw a thermal neutron at my tube:

Start Run processing. G4ParticleChange::CheckIt : the global time goes back !! Difference: 11577.237025344[ns] G4ParticleChange::CheckIt : the proper time goes back !! Difference: 11576.449246183[ns] G4ParticleChange::CheckIt ----------------------------------------------- G4ParticleChange Information ----------------------------------------------- # of 2ndaries : 0 ----------------------------------------------- Energy Deposit (MeV): 0 Non-ionizing Energy Deposit (MeV): 0 Track Status : Alive True Path Length (mm) : 0.8 Stepping Control : 0 Mass (GeV) : 0 Charge (eplus) : 0 MagneticMoment : 0 : = 0*[e hbar]/[2 m] Position - x (mm) : 14.2 Position - y (mm) : 20.8 Position - z (mm) : -4.77 Time (ns) : 0 Proper Time (ns) : -1.16e+04 Momentum Direct - x : 0.493 Momentum Direct - y : -0.863 Momentum Direct - z : -0.115 Kinetic Energy (MeV): 0.191 Polarization - x : 0 Polarization - y : 0 Polarization - z : 0 Touchable (pointer) : 0xab1b008

*** G4Exception : 200 issued by : G4ParticleChange::CheckIt momentum, energy, and/or time was illegal *** Event Must Be Aborted Run terminated.

I would appreciate your input in what I may be doing wrong here.
Thank you,
Clarisse

Attachment: http://hypernews.slac.stanford.edu/HyperNews/geant4/get/AUX/2009/04/27/07.35-23670-nclude_myDetFieldSetup.hh http://hypernews.slac.stanford.edu/HyperNews/geant4/get/AUX/2009/04/27/07.35-32084-DetRadialElectricField.hh http://hypernews.slac.stanford.edu/HyperNews/geant4/get/AUX/2009/04/27/07.35-88341-3_src_myDetFieldSetup.cxx http://hypernews.slac.stanford.edu/HyperNews/geant4/get/AUX/2009/04/27/07.35-98902-etRadialElectricField.cxx

The Strangest Problem I've ever met by Zukai Wang <Zukai Wang>, 19 Feb, 2009 Dear All: Actually, I really have no idea which category my problem belongs to. If my magnetic field definition is in a simple way like this: ------------------------------------------------------------------------- void ExN02MagneticField::GetFieldValue(const double Point[3],double *Bfield) const { Bfield[0]=0.; Bfield[1]=0.; Bfield[2]=0.; if(fabs(Point[0])<75.*mm && fabs(Point[1])<405.*mm && fabs(Point[2])<705.*mm) Bfield[0]=-6450.*gauss;} -------------------------------------------------------------------------- The whole project works well. But when I put on a real magnetic field like this: ------------------------------------------------------------------ void ExN02MagneticField::GetFieldValue(const double Point[3],double *Bfield) const { Bfield[0]=0.; Bfield[1]=0.; Bfield[2]=0.; fstream in; G4double x=0.,y=0.,z=0.,Bx=0.,By=0.,Bz=0.; if (fabs(fabs(Point[0])-70.*mm)<5.*mm) in.open("Bmap36.dat"); else if (fabs(fabs(Point[0])-60.*mm)<5.*mm) in.open("Bmap37.dat"); else if (fabs(fabs(Point[0])-50.*mm)<5.*mm) in.open("Bmap38.dat"); else if (fabs(fabs(Point[0])-40.*mm)<5.*mm) in.open("Bmap39.dat"); else if (fabs(fabs(Point[0])-30.*mm)<5.*mm) { if (fabs(Point[1])<75.*mm) in.open("Bmap401.dat"); else if (fabs(Point[1])<145.*mm) in.open("Bmap4022.dat"); else in.open("Bmap4021.dat"); } else if (fabs(fabs(Point[0])-20.*mm)<5.*mm) {if (fabs(Point[1])<65.*mm) in.open("Bmap411.dat"); else in.open("Bmap412.dat");} else if (fabs(fabs(Point[0])-10.*mm)<5.*mm) in.open("Bmap42.dat"); else if (fabs(Point[0])<5.*mm) in.open("Bmap43.dat"); while ( fabs(Point[1])<405.*mm && fabs(Point[2])<705.*mm) { in>>x>>y>>z>>Bx>>By>>Bz; if (!in.good()) break; if(Point[0]>0 && fabs(Point[1]-y*mm)<5.*mm && fabs(Point[2]-z*mm)<5.*mm) { Bfield[0]=Bx*gauss; Bfield[1]=By*gauss; Bfield[2]=Bz*gauss; break; } else if (Point[0]<0 && fabs(Point[1]-y*mm)<5.*mm && fabs(Point[2]-z*mm)<5.*mm) { Bfield[0]=Bx*gauss; Bfield[1]=-By*gauss; Bfield[2]=-Bz*gauss; break; } else if (Point[0]>0 && fabs(-Point[1]-y*mm)<5.*mm && fabs(Point[2]-z*mm)<5.*mm) { Bfield[0]=Bx*gauss; Bfield[1]=-By*gauss; Bfield[2]=Bz*gauss; break; } else if (Point[0]<0 && fabs(-Point[1]-y*mm)<5.*mm && fabs(Point[2]-z*mm)<5.*mm) { Bfield[0]=Bx*gauss; Bfield[1]=By*gauss; Bfield[2]=-Bz*gauss; break; } else if (Point[0]>0 && fabs(Point[1]-y*mm)<5.*mm && fabs(-Point[2]-z*mm)<5.*mm) { Bfield[0]=Bx*gauss; Bfield[1]=By*gauss; Bfield[2]=-Bz*gauss; break; } else if (Point[0]<0 && fabs(Point[1]-y*mm)<5.*mm && fabs(-Point[2]-z*mm)<5.*mm) { Bfield[0]=Bx*gauss; Bfield[1]=-By*gauss; Bfield[2]=Bz*gauss; break; } else if (Point[0]>0 && fabs(-Point[1]-y*mm)<5.*mm && fabs(-Point[2]-z*mm)<5.*mm) { Bfield[0]=Bx*gauss; Bfield[1]=-By*gauss; Bfield[2]=-Bz*gauss; break; } else if (Point[0]<0*mm && fabs(-Point[1]-y*mm)<5.*mm && fabs(-Point[2]-z*mm)<5.*mm) { Bfield[0]=Bx*gauss; Bfield[1]=By*gauss; Bfield[2]=Bz*gauss; break; } } if (in.good()) in.close(); } -------------------------------------------------------------------------- The magnetic field values must be read from several files. The magnetic field values of more than 17000*8 points should be defined. I have edited the data files in a certain way to make the running of the program as fast as possible. The codes compiled and nothing wrong has been found. I shoot Krypton 78 in the particle gun and it will hit a detector which can record its kinetic energy and other information. The information has been showed on the screen. And at the end of an event, the event id should show up on the screen according to my codes. However, the event id has never appeared on the screen. Never one event has been finished! I wrote something in SteppingAction to track the Krypton 78 and found it pass through the magnetic field quickly (only 3 or 4 min) and hit the detector. And then, this ion kept on going. It reached the end of World and since then, the program ceased running. I mean, it was not aborted, it just stopped as if the poor ion did not know what to do next! I then increased the size of World. The ion (Kr78) lost all its energy in the last step, and the program stopped again! No errors and no segment faults have been reported. If I didn't track the ion from the particle gun, I would think that the whole program might last for hours! So, I doubt that the pointers (or something else) has exceed the maximum of Geant4.8.3(my version). If you have come across similar problems, I'd like to thank you in advance for your direction. Zukai Wang

Spin tracking of muons at rest by Kevin Lynch <Kevin Lynch>, 18 Feb, 2009 As a follow-up to my previous question on muon spin tracking of moving muons (post 155, http://hypernews.slac.stanford.edu/HyperNews/geant4/get/emfields/155.html), I have a new question about hybrid systems where moving muons come to rest in a target. To help myself and others in future, I'm going to start with a few observations that aren't handled in much detail in the documentation, and then get to my question: 1) To decay a muon, you need to instantiate a "Decay" process, and Geant4 provides 2: G4Decay, and G4DecayWithSpin. The Decay processes can be attached to both moving and resting particles by appropriate calls to G4ProcessManager::SetProcessOrdering, with the ProcessManager of the given particle type. 2) These processes permit decay, but somewhat confusingly (at least to me!) have nothing to do with whether or not the daughter products are produced in correlation with the spin; that determination is made by the selection of DecayChannels that are attached to the G4Muon{Plus,Minus} class. Geant4 provides a number of choices, depending on your needs: G4MuonDecayChannel, G4MuonDecayChannelWithSpin, and G4MuonRadiativeDecayChannelWithSpin. 3) This (well, and the code) leads me to conclude that the only real difference between the two Decay processes is whether the muon spin is evolved. The G4Decay class provides no evolution, while the G4DecayWithSpin class provides the static BMT \vec{s} \cross \vec{B} component. My experiments confirm that this does something to the spin of at rest muons, although I haven't tested the precession in detail. 4) For muons in motion, the spin is evolved differently, by the G4Transportation processes. In particular, the partial (full) BMT spin evolution equations given in the G4Mag_SpinEqRhs (G4EqEMFieldWithSpin) class. I hope my understanding is correct. Assuming it is, here's my question: For muons at rest, I clearly need to attach the G4DecayWithSpin class, via a call equivalent to G4MuonPlus::MuonPlus()->SetProcessOrdering(new G4DecayWithSpin(), idxAtRest), to get at rest spin evolution. But if I attach G4DecayWithSpin to idxPostStep, do I simultaneously get BOTH G4Mag_EqRhs BMT evolution, AND the G4DecayWithSpin evolution? In other words, do I double count the spin rotation for muons in motion? Should I attach G4Decay to idxPostStep instead of G4DecayWithSpin? The only example in the 4.9.2 distribution that uses G4DecayWithSpin is extended/field04, which attaches G4DecayWithSpin in both cases. Assuming I'm wrong, can you point out how the code in the distribution ensures the G4DecayWithSpin terms don't come in to play for moving muons? Setting up a test environment to figure this out in detail is somewhat onerous, hence my hope that someone can quickly set me straight. Thanks in advance for you comments!

Spin tracking of moving muons by Kevin Lynch <Kevin Lynch>, 12 Feb, 2009 I have a number of questions about spin tracking of moving particles (muons particularly). To set up the questions, a few words about our experimental environment: We have a polarized (of course:-) muon beam travelling in vacuum through a set of magnetic fields, and coming to rest in a target, also immersed in a magnetic field. We need to track the muon spin, and apply spin dependent muon decay. During transport, we use the G4Mag_SpinEqRhs equations, and see the spin precessing correctly (we think). We use G4DecayWithSpin, and see the proper distribution of muon decays around the muon spin direction. I'm currently using both 4.9.1 and 4.9.2 on Linux machines. So far so good. Here are some of the issues that I don't quite understand: 1) If I understand correctly, the units of the evolution equation have d\vec{s}/dx = (1/\beta)(d\vec{s}/dt). The dominant term on the RHS in the BMT spin evolution for low energy muons is the \vec{s} \cross \vec{B} term, which has no problem as \beta->0. But, because we multiply by a number that diverges (1/\beta) in the stopping limit, we in principle could have a big problem with inaccurate evolution. Practically, given the way Geant4 handles the energy loss, should I be worried about this? Do we ever end up in a condition where 1/\beta gets big enough to be a problem? If so, is there any good way to deal with this? 2) In some of the EqRhs equation classes, the EvaluatRhsGivenB term includes the statements: dydx[6] = dydx[8] = 0.;//not used // Lab Time of flight dydx[7] = inverse_velocity; for example, G4EqEMFieldWithSpin. But others, particularly the G4Mag_SpinEqRhs that I need, has instead // Initialise the values of dydx that we do not update. dydx[6] = dydx[7] = dydx[8] = 0.0; Is the difference meaningful? I definitely need the lab TOF to have the right value. 3) In another experiment, we have higher momentum muons and also electric fields. All else being correct, I should be able to use G4EqEMFieldWithSpin to evolve the spin in these fields. But I think there's a problem with the implementation in G4EqEMFieldWithSpin::EvaluateRhsGivenB: the BMT equation has a term of the form \vec{s} \cross (\vec{\beta} \cross \vec{E}), but the implementation of the spin evolution in this class is identical to that of G4Mag_SpinEqRhs. Is this intentional (am I missing something), or an oversight (ie. bug)?

recommendation for atmosphere mag field setup by Scott Nutter <Scott Nutter>, 01 Feb, 2009 I am working on a simulation of the production of synchrotron radiation by very high energy electrons traversing the Earth's magnetic field. I have to have times of synchrotron photons arriving at a certain height in the atmosphere good to better than a nanosecond. I have been having trouble getting this kind of accuracy. I base this conclusion on an algorithm to reconstruct the zenith angle looking at the time difference of two spatially nearby photons at a certain height, which arrive on essentially parallel trajectories. The resulting calculated zenith angles indicate the photons are all arriving from nearly vertically above. This algorithm works fine in a simple monte carlo using geant3 RK tracking and simple straight projection of photon tracks from production positions returned by the g3synge generator. In reading about magnetic field setup in the application users manual, I noticed a small reference to "integrating over time" in the section on stepper choice. (The code fragment has "nvar=8" and subsequent comments in the version for G4.9.1, the section is 4.3.2.4.) Since the atmosphere is a completely different scale than the typical HEP experiment, I think it best if I get some recommendations on setting up a field properly, so that times of synchrotron photon production are very carefully computed. The field characteristics are: o The purely magnetic field B~0.5 gauss strength, typical Bperp ~0.1 gauss. The field varies very little (<25% over 360 km). o Atmosphere geometry is G4Orbs setup like "Russian dolls" with radii the size of the Earth + different heights. The resulting layer thicknesses range from several meters to 50 km. The thickness of each atmosphere layer is determined by requiring it to have a column density of 20 mg/cm2. Thus the G4Orbs are filled with air of different densities. The lowest density of the air is 1e-22 g/cm3, the lowest limit I could get G4.9.2 to accept. I track from 400 km height above the Earth's surface to 38 km height. o Electron energies are from 2-50 TeV. o My test case is a straightdown electron. With all physics off, the deflection for a constant perpendicular field is in agreement with calculations, and is ~19.5 m for Bperp=0.1 gauss over 362 km. o My current code for defining the field: myField = new CrestMagField(latitude, longitude, time); G4FieldManager* fieldMgr = G4TransportationManager::GetTransportationManager() ->GetFieldManager(); fieldMgr->SetDetectorField(myField); fieldMgr->CreateChordFinder(myField); Any recommendations? There is much discussion of special cases and fine tuning of the field. I believe the default tracker is tracking correctly now, but I do not believe the times yet. Thanks.

electron stuck on volume boundary with (local) uniform magnetic field by Brian Fisher <Brian Fisher>, 21 Jul, 2008

I'm experiencing a situation similar to posting #96 in this forum. That thread seems to have gone dead, so I'm posting a new thread. I'm using Geant4 9.1p02 In a very simple setup, electrons sometimes are "bouncing" between a volume (with a local magnetic field) and its mother (which does not have a magnetic field). Both volumes are filled with "vacuum." I get many (tens of thousands) of messages like these: WARNING - G4Navigator::ComputeStep() Track stuck, not moving for 10 steps in volume -expHall- at point (-8.257550732,-9.52505,18.49195399) direction: (-0.01057780492,7.285534641e-05,0.9999440508). Potential geometry or navigation problem ! Trying pushing it of 9e-10 mm ... I've been modeling charged particle detector telescopes, and in the process of hunting this problem down, I have reduced the geometry of my problem to: 1) a 1x1x1 m^3 box filled with vacuum. This is the "expHall" volume 2) a "BFieldZone" box also filled with vacuum with the following parameters: Solid type: G4Box Parameters: half length X: 1.39526 cm half length Y: 0.952505 cm half length Z: 0.952505 cm ----------------------------------------------------------- Center of Box: X = 0 cm Y = 0 cm Z = 1.98525 cm 3) the "BFieldZone" box has a uniform 2 kilogauss magnetic field in the +X direction. This is how I've defined the (local) magnetic field for the "BFieldZone" volume: G4double = fFieldValue = 2.0*kilogauss; fMagField = new G4UniformMagField(G4ThreeVector(fFieldValue, 0.0, 0.0)); fEquation = new G4Mag_UsualEqRhs(fMagField); fStepper = new G4ExactHelixStepper(fEquation); fIntgrDriver = new G4MagInt_Driver(1.0*micrometer, fStepper, fStepper->GetNumberOfVariables(), 2); fChordFinder = new G4ChordFinder(fIntgrDriver); fFieldMgr = new G4FieldManager(fMagField, fChordFinder); logicBFieldZone->SetFieldManager(fFieldMgr, true); 4) The "expHall" box has no magnetic field. When I turn the tracking verbosity up to 2, the 'offending' event looks like this: ********************************************************************************************************* * G4Track Information: Particle = e-, Track ID = 1, Parent ID = 0 ********************************************************************************************************* Step# X Y Z KineE dEStep StepLeng TrakLeng Volume Process 0 -8.06 mm -9.69 mm 7.87e-55 fm 1.97 MeV 0 eV 0 fm 0 fm expHall initStep 1 -8.25 mm -9.53 mm 1.81 cm 1.97 MeV4.82e-19 eV 1.81 cm 1.81 cm expHall Transportation 2 -8.25 mm -9.53 mm 1.81 cm 1.97 MeV 0 eV 0 fm 1.81 cm physiBFieldZone Transportation 3 -8.25 mm -9.53 mm 1.81 cm 1.97 MeV 0 eV 0 fm 1.81 cm expHall Transportation 4 -8.25 mm -9.53 mm 1.81 cm 1.97 MeV 0 eV 0 fm 1.81 cm physiBFieldZone Transportation 5 -8.25 mm -9.53 mm 1.81 cm 1.97 MeV 0 eV 0 fm 1.81 cm expHall Transportation 6 -8.25 mm -9.53 mm 1.81 cm 1.97 MeV 0 eV 0 fm 1.81 cm physiBFieldZone Transportation 7 -8.25 mm -9.53 mm 1.81 cm 1.97 MeV 0 eV 0 fm 1.81 cm expHall Transportation 8 -8.25 mm -9.53 mm 1.81 cm 1.97 MeV 0 eV 0 fm 1.81 cm physiBFieldZone Transportation 9 -8.25 mm -9.53 mm 1.81 cm 1.97 MeV 0 eV 0 fm 1.81 cm expHall Transportation 10 -8.25 mm -9.52 mm 1.82 cm 1.97 MeV2.39e-21 eV 89.9 um 1.82 cm physiBFieldZone Transportation 11 -8.25 mm -9.53 mm 1.82 cm 1.97 MeV1.91e-22 eV 7.16 um 1.82 cm physiBFieldZone Transportation 12 -8.25 mm -9.53 mm 1.82 cm 1.97 MeV 0 eV 0 fm 1.82 cm expHall Transportation 13 -8.25 mm -9.53 mm 1.82 cm 1.97 MeV 0 eV 0 fm 1.82 cm physiBFieldZone Transportation 14 -8.25 mm -9.53 mm 1.82 cm 1.97 MeV 0 eV 0 fm 1.82 cm expHall Transportation 15 -8.25 mm -9.53 mm 1.82 cm 1.97 MeV 0 eV 0 fm 1.82 cm physiBFieldZone Transportation 16 -8.25 mm -9.53 mm 1.82 cm 1.97 MeV 0 eV 0 fm 1.82 cm expHall Transportation 17 -8.25 mm -9.53 mm 1.82 cm 1.97 MeV 0 eV 0 fm 1.82 cm physiBFieldZone Transportation 18 -8.25 mm -9.53 mm 1.82 cm 1.97 MeV 0 eV 0 fm 1.82 cm expHall Transportation 19 -8.25 mm -9.53 mm 1.82 cm 1.97 MeV 0 eV 0 fm 1.82 cm physiBFieldZone Transportation 20 -8.25 mm -9.53 mm 1.82 cm 1.97 MeV 0 eV 0 fm 1.82 cm expHall Transportation 21 -8.26 mm -9.52 mm 1.83 cm 1.97 MeV2.39e-21 eV 89.9 um 1.83 cm physiBFieldZone Transportation 22 -8.26 mm -9.53 mm 1.83 cm 1.97 MeV1.32e-22 eV 4.96 um 1.83 cm physiBFieldZone Transportation 23 -8.26 mm -9.53 mm 1.83 cm 1.97 MeV 0 eV 0 fm 1.83 cm expHall Transportation 24 -8.26 mm -9.53 mm 1.83 cm 1.97 MeV 0 eV 0 fm 1.83 cm physiBFieldZone Transportation 25 -8.26 mm -9.53 mm 1.83 cm 1.97 MeV 0 eV 0 fm 1.83 cm expHall Transportation 26 -8.26 mm -9.53 mm 1.83 cm 1.97 MeV 0 eV 0 fm 1.83 cm physiBFieldZone Transportation [and so on, seemingly forever] If the verbosity is turned up to 3, I get this: [snip] #Step# X Y Z KineE dEStep StepLeng TrakLeng Volume Process 30132 -8.26 mm -9.53 mm 1.85 cm 1.97 MeV 0 eV 0 fm 1.85 cm physiBFieldZone Transportation >>AlongStepDoIt (after all invocations): ++List of invoked processes 1) Transportation 2) msc 3) eIoni 4) eBrem ++G4Step Information Address of G4Track : 0x3046970 Step Length (mm) : 0 Energy Deposit (MeV) : 0 ----------------------------------------------------------------------- StepPoint Information PreStep PostStep ----------------------------------------------------------------------- Position - x (mm) : -8.257551022101929 -8.257551022101929 Position - y (mm) : -9.52505 -9.52505 Position - z (mm) : 18.49198141201282 18.49198141201282 Global Time (ns) : 0.06304591361302052 0.06304591361302052 Local Time (ns) : 0.06304591361302052 0.06304591361302052 Proper Time (ns) : 0.01300913309755812 0.01300913309755812 Momentum Direct - x : -0.01057780492354854-0.01057780492354854 Momentum Direct - y : 7.285445476253925e-057.285445476253925e-05 Momentum Direct - z : 0.9999440508024575 0.9999440508024575 Momentum - x (MeV/c): -0.02563161644372119-0.02563161644372119 Momentum - y (MeV/c): 0.00017653733021041490.0001765373302104149 Momentum - z (MeV/c): 2.423015224859268 2.423015224859268 Total Energy (MeV) : 2.476444998409542 2.476444998409542 Kinetic Energy (MeV): 1.965445938409542 1.965445938409542 Velocity (mm/ns) : 293.3407906754122 293.3407906754122 Volume Name : expHall expHall Safety (mm) : 5e-10 5e-10 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 ----------------------------------------------------------------------- ++List of secondaries generated (x,y,z,kE,t,PID): No. of secodaries = 0 **PostStepDoIt (after all invocations): ++List of invoked processes 1) Transportation 2) msc 3) eIoni (Forced) ++G4Step Information Address of G4Track : 0x3046970 Step Length (mm) : 0 Energy Deposit (MeV) : 0 ----------------------------------------------------------------------- StepPoint Information PreStep PostStep ----------------------------------------------------------------------- Position - x (mm) : -8.257551022101929 -8.257551022101929 Position - y (mm) : -9.52505 -9.52505 Position - z (mm) : 18.49198141201282 18.49198141201282 Global Time (ns) : 0.06304591361302052 0.06304591361302052 Local Time (ns) : 0.06304591361302052 0.06304591361302052 Proper Time (ns) : 0.01300913309755812 0.01300913309755812 Momentum Direct - x : -0.01057780492354854-0.01057780492354854 Momentum Direct - y : 7.285445476253925e-057.285445476253925e-05 Momentum Direct - z : 0.9999440508024575 0.9999440508024575 Momentum - x (MeV/c): -0.02563161644372119-0.02563161644372119 Momentum - y (MeV/c): 0.00017653733021041490.0001765373302104149 Momentum - z (MeV/c): 2.423015224859268 2.423015224859268 Total Energy (MeV) : 2.476444998409542 2.476444998409542 Kinetic Energy (MeV): 1.965445938409542 1.965445938409542 Velocity (mm/ns) : 293.3407906754122 293.3407906754122 Volume Name : expHall physiBFieldZone Safety (mm) : 5e-10 5e-10 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 ----------------------------------------------------------------------- ++List of secondaries generated (x,y,z,kE,t,PID): No. of secodaries = 0 [Note]Secondaries from AlongStepDoIt included. #Step# X Y Z KineE dEStep StepLeng TrakLeng Volume Process 30133 -8.26 mm -9.53 mm 1.85 cm 1.97 MeV 0 eV 0 fm 1.85 cm expHall Transportation >>AlongStepDoIt (after all invocations): ++List of invoked processes 1) Transportation 2) msc 3) eIoni 4) eBrem ++G4Step Information Address of G4Track : 0x3046970 Step Length (mm) : 0 Energy Deposit (MeV) : 0 ----------------------------------------------------------------------- StepPoint Information PreStep PostStep ----------------------------------------------------------------------- Position - x (mm) : -8.257551022101929 -8.257551022101929 Position - y (mm) : -9.52505 -9.52505 Position - z (mm) : 18.49198141201282 18.49198141201282 Global Time (ns) : 0.06304591361302052 0.06304591361302052 Local Time (ns) : 0.06304591361302052 0.06304591361302052 Proper Time (ns) : 0.01300913309755812 0.01300913309755812 Momentum Direct - x : -0.01057780492354854-0.01057780492354854 Momentum Direct - y : 7.285445476253925e-057.285445476253925e-05 Momentum Direct - z : 0.9999440508024575 0.9999440508024575 Momentum - x (MeV/c): -0.02563161644372119-0.02563161644372119 Momentum - y (MeV/c): 0.00017653733021041490.0001765373302104149 Momentum - z (MeV/c): 2.423015224859268 2.423015224859268 Total Energy (MeV) : 2.476444998409542 2.476444998409542 Kinetic Energy (MeV): 1.965445938409542 1.965445938409542 Velocity (mm/ns) : 293.3407906754122 293.3407906754122 Volume Name : physiBFieldZone physiBFieldZone Safety (mm) : 5e-10 5e-10 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 ----------------------------------------------------------------------- ++List of secondaries generated (x,y,z,kE,t,PID): No. of secodaries = 0 **PostStepDoIt (after all invocations): ++List of invoked processes 1) Transportation 2) msc 3) eIoni (Forced) ++G4Step Information Address of G4Track : 0x3046970 Step Length (mm) : 0 Energy Deposit (MeV) : 0 ----------------------------------------------------------------------- StepPoint Information PreStep PostStep ----------------------------------------------------------------------- Position - x (mm) : -8.257551022101929 -8.257551022101929 Position - y (mm) : -9.52505 -9.52505 Position - z (mm) : 18.49198141201282 18.49198141201282 Global Time (ns) : 0.06304591361302052 0.06304591361302052 Local Time (ns) : 0.06304591361302052 0.06304591361302052 Proper Time (ns) : 0.01300913309755812 0.01300913309755812 Momentum Direct - x : -0.01057780492354854-0.01057780492354854 Momentum Direct - y : 7.285445476253925e-057.285445476253925e-05 Momentum Direct - z : 0.9999440508024575 0.9999440508024575 Momentum - x (MeV/c): -0.02563161644372119-0.02563161644372119 Momentum - y (MeV/c): 0.00017653733021041490.0001765373302104149 Momentum - z (MeV/c): 2.423015224859268 2.423015224859268 Total Energy (MeV) : 2.476444998409542 2.476444998409542 Kinetic Energy (MeV): 1.965445938409542 1.965445938409542 Velocity (mm/ns) : 293.3407906754122 293.3407906754122 Volume Name : physiBFieldZone expHall Safety (mm) : 5e-10 5e-10 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 ----------------------------------------------------------------------- ++List of secondaries generated (x,y,z,kE,t,PID): No. of secodaries = 0 [Note]Secondaries from AlongStepDoIt included. #Step# X Y Z KineE dEStep StepLeng TrakLeng Volume Process 30134 -8.26 mm -9.53 mm 1.85 cm 1.97 MeV 0 eV 0 fm 1.85 cm physiBFieldZone Transportation [and so on... ] So I'm wondering why is my step length at the boundary being set to zero? Do I have a bad set of physics lists? Is the fact that this particle is nearly perpendicular to the field the problem? Any help anyone can provide is GREATLY appreciated. Thanks, Brian

non-uniform electric field in chamber by <janitor0405@126.com>, 28 Jun, 2008 Dear sir, I am a beginner of Geant4,I want to setup a non-uniform electric field in my chamber filled with Xenon,I follow the example from/advanced/purging_magnet,I just made a conversion from the magnetic field to electric field,compiling is completed but when beamOn I receive some strange information as follows: ---> Begin Of Event: 0 G4MagIntegratorDriver::OneGoodStep: Stepsize underflow in Stepper Step's start x=7.24397 and end x= 7.24397 are equal !! Due to step-size= 5.62767e-20 . Note that input step was 0.562767 G4MagIntegratorDriver::OneGoodStep: Stepsize underflow in Stepper Step's start x=0.410347 and end x= 0.410347 are equal !! Due to step-size= 1.08637e-20 . Note that input step was 10.8637 G4MagIntegratorDriver::OneGoodStep: Stepsize underflow in Stepper .... I really don't know what is the problem,I need some help.can you help me?thank you very much. janitor

Gradient in G4QuadrupoleMagField Keywords: quadrupole magnetic field by Mariusz <Mariusz>, 27 Feb, 2008 Hello, Im just asking because I have not found any example. The gradient in G4QuadrupoleMagField(gradient) can be given in tesla/m? G4double gradient=223*tesla/m; Regards, Mariusz Sapinski PS actually is this code correct for setting up the Quadrupole mag field in only a part of geometry (logicSpace_Pipe): G4double fGradient = -223.*tesla/m; G4QuadrupoleMagField* pipeField = new G4QuadrupoleMagField(fGradient); G4Mag_UsualEqRhs* myEquation = new G4Mag_UsualEqRhs(pipeField); G4MagIntegratorStepper* myStepper = new G4ClassicalRK4(myEquation); G4ChordFinder* myChordFinder = new G4ChordFinder(pipeField,0.1*mm,myStepper); G4FieldManager* fieldMgr = new G4FieldManager(pipeField,myChordFinder,false); logicSpace_Pipe->SetFieldManager(fieldMgr,true); I'm asking because it gives warnings in the parts of the geometry which are quite far from Space_Pipe: WARNING - G4Navigator::ComputeStep() Track stuck, not moving for 10 steps in volume -Austenitic_Steel_Collar- at point (89.47743818,103.7805885,1461.432287) direction: (0.1819718324,-0.1776272256,0.9671270966). Potential geometry or navigation problem ! Trying pushing it of 9e-10 mm ...

Local Electric Field: GetFieldValue() problem Keywords: coordinate systems nonuniform electric field by Mario <Mario>, 15 Feb, 2008 Hello Geant4 Gurus!! I am using geant4.8.2.p01 currently and am implementing an electric field, and later a magnetic field, to a specified local volume. I have defined my own electric field class, all of the code is below for that class. The main concern is point[4] which comes in at the GetFieldValue() function. I have displayed point[0], point[1], point[2] and calculated the magnitude of this vector and in some instances it is larger than my entire world volume, which obviously makes no sense. I guess I am curious about the coordinate system that point[4] is using... does it use the logicalVolume in which the fieldManager of the field belongs to as the coordinate system, or is it with respect to the global volume?? Also, when I place this field_vol into the global and it overlaps with other volumes already there or new ones that are placed on, it does not give me a 'overlap' warning, and the protons (which is what I am using) go through all volumes, overlapping or not, and it seems okay... is there something special about a volume that is made of Vacuum and holds a field manager?? The main issue is what this point[4] is, because the EField is calculated based on that number, so if I am using it incorrectly then there is a problem. Thanks in advance for your help. Cheers, Mario HEADER: #ifndef ChargeShell_hh #define ChargeShell_hh 1 #include "G4Types.hh" #include "G4ThreeVector.hh" #include "G4ElectricField.hh" class ChargeShell : public G4ElectricField { public: ChargeShell(); virtual ~ChargeShell() ; virtual void GetFieldValue(const G4double point[4], G4double *field) const; G4ThreeVector CalcVolumeCharge(const G4double[4]) const; G4ThreeVector CalcSurfaceCharge(const G4double[4]) const; G4double GetLength() {return 10.0*ro;}; G4ThreeVector GetPos() {return srcToShellPos;}; private: void ReadInputFile(); G4double ri; G4double ro; G4double Q; G4ThreeVector srcToShellPos; G4double fourPiEpsNot; }; #endif CC FILE: #include "ChargeShell.hh" extern int readFileVerbose; ChargeShell::ChargeShell() { ReadInputFile(); fourPiEpsNot = 4.0*3.14159265359*8.85418781762e-12*farad/meter; } // ------------------------------------------------------------------------ ChargeShell::~ChargeShell() { } void ChargeShell::GetFieldValue (const G4double point[4],G4double *fieldOut) const { if(ri > ro){ G4cout << "ri cannot be larger than ro" << G4endl; return; } G4ThreeVector fieldVal = G4ThreeVector(0.0,0.0,0.0); if(ro == ri){fieldVal = CalcSurfaceCharge(point);} else{fieldVal = CalcVolumeCharge(point);} G4cout << "fieldVal.x() = " << fieldVal.x()/(volt/m) << G4endl; G4cout << "fieldVal.y() = " << fieldVal.y()/(volt/m) << G4endl; G4cout << "fieldVal.z() = " << fieldVal.z()/(volt/m) << G4endl << G4endl; fieldOut[0]= 0.0; fieldOut[1]= 0.0; fieldOut[2]= 0.0; fieldOut[3]= fieldVal.x(); fieldOut[4]= fieldVal.y(); fieldOut[5]= fieldVal.z(); return; } G4ThreeVector ChargeShell::CalcSurfaceCharge(const G4double p[4]) const { G4double x = p[0]; G4double y = p[1]; G4double z = p[2]; G4double r = std::sqrt(x*x + y*y + z*z); G4double Er; G4cout << "r = " << r/mm << G4endl; if(r <= ro){Er = 0.0*volt/m;G4cout << "----->>>>>Er = 0<<<<<-----" << G4endl;} else{Er = Q/(fourPiEpsNot*r*r);} G4cout << "Er = " << Er/(volt/m) << G4endl; G4ThreeVector out = G4ThreeVector(Er*(x/r),Er*(y/r),Er*(z/r)); return out; } G4ThreeVector ChargeShell::CalcVolumeCharge(const G4double p[4]) const { G4double x = p[0]; G4double y = p[1]; G4double z = p[2]; G4double r = std::sqrt(x*x + y*y + z*z); double riOverro = ri/ro; double riOverr = ri/r; G4double Er; if(r >= 0.0 && r <= ri){Er = 0.0*volt/m;} else if(r > ri && r < ro){ Er = (Q/(fourPiEpsNot*ro*ro))*(r/ro)*(1-riOverr*riOverr*riOverr)/(1-riOverro*riOverro*riOverro); } else{Er = Q/(fourPiEpsNot*r*r);} G4ThreeVector out = G4ThreeVector(Er*(x/r),Er*(y/r),Er*(z/r)); return out; } void ChargeShell::ReadInputFile() { //read in parameters from text file FILE *chargeShellInput; char* inputFile = "C:\\g4work\\PRSim\\src\\Param_Files\\Param_ChargeShellField.txt"; chargeShellInput = fopen(inputFile,"rt"); if(chargeShellInput == NULL){ G4cout << "Param_ChargeShellField.txt did not come in correctly, check path" << G4endl; G4cout << "chargeShellInput = " << chargeShellInput << G4endl; G4cout << "errno = " << errno << G4endl; return; } char readWholeLineBuff[500]; float tmpFloat; char tmpString[50]; //read line of text for ri fgets(readWholeLineBuff,500,chargeShellInput); if(readWholeLineBuff != NULL){ fscanf(chargeShellInput,"%f\n",&tmpFloat); ri = tmpFloat*um; if(readFileVerbose > 0){ G4cout << "readWholeLineBuff = " << readWholeLineBuff << G4endl; G4cout << ri/um << G4endl; } } else{G4cout << "Did not read in ri" << G4endl; return;} //read line of text for ro fgets(readWholeLineBuff,500,chargeShellInput); if(readWholeLineBuff != NULL){ fscanf(chargeShellInput,"%f\n",&tmpFloat); ro = tmpFloat*um; if(readFileVerbose > 0){ G4cout << "readWholeLineBuff = " << readWholeLineBuff << G4endl; G4cout << ro/um << G4endl; } } else{G4cout << "Did not read in ro" << G4endl; return;} //read line of text for Q fgets(readWholeLineBuff,500,chargeShellInput); fgets(readWholeLineBuff,500,chargeShellInput); if(readWholeLineBuff != NULL){ fscanf(chargeShellInput,"%f\n",&tmpFloat); Q = tmpFloat*coulomb; if(readFileVerbose > 0){ G4cout << "readWholeLineBuff = " << readWholeLineBuff << G4endl; G4cout << Q/coulomb << G4endl; } } else{G4cout << "Did not read in Q" << G4endl; return;} //read line of text for srcToShellPos fgets(readWholeLineBuff,500,chargeShellInput); if(readWholeLineBuff != NULL){ fscanf(chargeShellInput,"%f",&tmpFloat); srcToShellPos.setX(tmpFloat*cm); fscanf(chargeShellInput,"%f",&tmpFloat); srcToShellPos.setY(tmpFloat*cm); fscanf(chargeShellInput,"%f\n",&tmpFloat); srcToShellPos.setZ(tmpFloat*cm); if(readFileVerbose > 0){ G4cout << "readWholeLineBuff = " << readWholeLineBuff << G4endl; G4cout << srcToShellPos << G4endl; } } else{G4cout << "Did not read in srcToShellPos" << G4endl; return;} fclose(chargeShellInput); return; }

Problem with magnetic field from a table Keywords: field map by Mariusz <Mariusz>, 25 Jan, 2008 Hi, I have a 2d table with values of Bx and By (Bz is 0). It is quite large: 4900 points with spacing of 7.7mm. I use Geant 4.9.0.p01. I have a class: ---------------------VVV ------------------------ class WSMagneticField: public G4MagneticField { public: WSMagneticField(G4ThreeVector); // The value of the field WSMagneticField(); // A zero field ~WSMagneticField(); void SetFieldValue(G4double fieldValue); void SetFieldValue(G4ThreeVector fieldVector); void GetFieldValue(const double Point[3], double *Bfield) const; protected: // Find the global Field Manager G4FieldManager* GetGlobalFieldManager(); private: static const int imesh=4900; float x[imesh]; float y[imesh]; float Bx[imesh]; float By[imesh]; }; ----------------------AAA--------------------- In the constructor I fill the tables x,y,Bx,By: ---------------------VVV---------------------- WSMagneticField::WSMagneticField() { // here open and read file ifstream bmap; string line; const char *charline; int ni1,ni2,idx=0; float modB; char ni3; bmap.open("Bfield.data"); while(bmap) { getline(bmap,line); charline=line.c_str(); sscanf(charline," %d %d %f %f %f %f %f %c\n", &ni1,&ni2,&x[idx],&y[idx],&Bx[idx],&By[idx],&modB,&ni3); G4cout << "mag field check i = " << idx << " x = " << x[idx] << " Bx = " << Bx[idx] <<G4endl; idx++; } GetGlobalFieldManager()->SetDetectorField(this); GetGlobalFieldManager()->CreateChordFinder(this); } --------------------AAA------------------------- and I have GetFieldValue function: --------------------VVV------------------------- // argument is position in mm void WSMagneticField::GetFieldValue(const double Point[3], double *Bfield) const { Bfield[0] = 0.; Bfield[1] = 0.; Bfield[2] = 0.; G4float dmesh=7.93; // [mm] G4double cPoint[3]; cPoint[0]=Point[0]; cPoint[1]=Point[1]-77.; // [mm] shift back the Quad to World ref. cPoint[2]=Point[2]; G4double radius = pow(pow(cPoint[0],2)+pow(cPoint[1],2),0.5); if(cPoint[0]>0 && radius < 240. && fabs(cPoint[2]) < 1400.) { for(G4int i=0; i<3; i++) if(cPoint[i]<0) cPoint[i]*=(-1); // because of symmetry for(G4int i=0; i<4900; i++) { if(fabs(cPoint[0]-x[i])<dmesh/2 && fabs(cPoint[1]-y[i])<dmesh/2) { Bfield[0]=Bx[i]; Bfield[1]=By[i]; break; } } } } -------------------AAA------------------------- And then, in DetectorConstruction I have: -------------------VVV------------------------- WSMagneticField* myField = new WSMagneticField(); G4FieldManager* fieldMgr = G4TransportationManager::GetTransportationManager() ->GetFieldManager(); // I tried this and it did not work either // fieldMgr->SetDetectorField(myField); // fieldMgr->CreateChordFinder(myField); /* ... geometry declaration ... */ G4FieldManager *localFieldMgr = new G4FieldManager(myField); logicQ5->SetFieldManager(localFieldMgr,true); --------------------AAA------------------------- The program compiles, the file with table of values is read but never ever any event has finished being calculated. I've left it even for the whole night even if in normal conditions one event takes about 15 minutes. I would appreciate any suggestion leading to solution;-) Mariusz Sapinski

non-uniform magnetic field by <adammachona@yahoo.co.uk>, 15 Nov, 2007 I'm a new Geant4 user and so you will have to forgive me if I ask a stupid question. I want to create a non-uniform magnetic field in my detector. What is the simplest way to do this? Thank you for your time.

non-uniform electric field by <janitor0405@126.com>, 12 Nov, 2007 Dear sir, I am a beginner of Geant4,I want to setup a non-uniform electric field in my chamber filled with Xenon, I follow the example from/advanced/purging_magnet,I just made a conversion from the magnetic field to electric field, when gmakeing I receive some strange information about syntax error such as << and so on, I already include the head file G4ios.hh and globals.hh,I really don't know what is the problem,I need some help. thank you very much. Jane

Electric potential / non-uniform electric field Keywords: non-uniform electric field, electric potential by Hannele <hatueron@jyu.fi>, 17 Sep, 2007 Is it possible to add an electric potential to components? And if not, how can I create a non-uniform electric field?

Overlapping Fields by Maurizio <ungaro@jlab.org>, 31 Jul, 2007 I read in #74 that one can have electric and magnetic field at the same time by using the return values of bfield (components 0-2 and 3-5) What about overlapping magnetic fields? If I multiple magnetic fields at one point in space, can I add them together somehow? This is important when working with strong fringe fields. thanks, mauri

Questions about SetLargestAcceptableStep() Keywords: SetLargestAcceptableStep by <throwpen@163.com>, 21 Jul, 2007 When do i need to set the maximum acceptable step using the SetLargestAcceptableStep() method ? I know that if i want to get a smooth trajectory for a charged particle in the magnetic field, i need to set the maximum acceptable step to small one.However, the tracking consumes too much time. whether the maximum acceptable step setting will affect the final result or not? The dimension of detector in my simulation is <1 meter.

simultaneous B and E fields Keywords: magnetic field, electric field by Abigail Bickley <bickley@nscl.msu.edu>, 16 Jul, 2007 Hello, I am trying to simulate a detector that has a local electric field applied to a subset of the detector volume and a global magnetic field. I understand from message #74 that this is possible using the G4ElectroMagneticField class, but it is unclear to me from the response to this message how to apply this class. If I setup global and local fields as in example field03 then do I simply convert fField = new G4UniformElectricField(G4ThreeVector(0.0,0.0*volt,0.0 )); fLocalField = new G4UniformElectricField(G4ThreeVector(0.0,-5000.0*volt/m,0.0 )); to fField = new G4ElectroMagneticField(gbl_Bfield_x, gbl_Bfield_y, gbl_Bfieldz, gbl_Efield_x, gbl_Efield_y, gbl_Efield_z); fLocalField = new G4ElectroMagneticField(lcl_Bfield_x, lcl_Bfield_y, lcl_Bfieldz, lcl_Efield_x, lcl_Efield_y, lcl_Efield_z )); Thank you for your advice. ps. In reality I would prefer to apply both a local electric field and a local magnetic field to different subsets of my geometry. Is this really not possible in Geant4?

Magnetic Field from field01 Example Keywords: magnetic field ield01 by Matthew Middione <middionematt@csufresno.edu>, 13 Jul, 2007 It is probabbly apparent by my multiple magnetic field postings on the forum that I am having difficulties getting my magnetic field to work. The basic run down of my situation is as follows. I am using code from TestEm1 (Geant/examples/extended/electromagnetic/TestEm1) and exGPS (Geant/examples/extended/eventgenerator/exGPS). I am using the GeneralParticleSource to create positron emitting point sources and examining their the distance that these positrons travel prior to annihilation with electrons in a tissue like material. I also want to utilize a uniform transverse magnetic field to see how the field alters the distance the positrons travel. The distance should be reduced, because the magnetic field will cause the charged particles to spiral inwards due to the transverse nature of the field. For the magnetic field code I have used the F01FieldSetup.cc/hh and F01FieldMessenger.cc/hh found in example field01 (Geant/examples/extended/field/field01). Everything compiles, links, and runs beautifully. The problem is that I do not believe that the magnetic field is taking any effect. I know I have introduced a magnetic field because the simulation is hard coded to print out the magnetic field paramaters. These are the paramaters that were printed: PreInit> /control/execute Mono.in F01FieldSetup: magnetic field set to Uniform( 0, 0, 9.4 ) EpsilonStep: set min= 1e-05 max= 0.0001 G4ClassicalRK4 (default) is called The minimal step is equal to 0.01 mm The Box is 2 m of Tissue PhysicsList::SetCuts:CutLength : 1 mm To simplyify a test of the magnetic field's effect, I use the following macro file to shoot monoentergetic positrons: /pr/det/setMat Tissue /pr/det/setSize 2 m /run/initialize # /process/eLoss/verbose 1 /tracking/verbose 1 /pr/stepMax 6 mm /gps/particle e+ /gps/ene/type Mono /gps/ene/mono 4 MeV /gps/direction 1 0 0 /run/beamOn 1 I do this with both the field set to 0 Tesla and then 9.4 Tesla and I change nothing else. The outputs are identical. The track length, ending position in x-y-z, and range of the particles are the same. This indicated that the effect of the magnetic field is not being realized. I intend on shooting ions using the gps commands, but it is easier to test the magnetic field via positrons for now. Do you have any suggestions or assistance that can help in this matter. I have been working on getting this magnetic field to operate properly for weeks. I sincerely appreciate any input you may provide. Thanks, Matthew Middione

Placing a magnetic field inside of a volume Keywords: magnetic field, logical volume, testem1 by Matthew Middione <middionematt@csufresno.edu>, 11 Jul, 2007 I need to place a magnetic field in a volume. I am a Geant novice so a step by step approach would be much appreciated. I want to apply a local uniform transverse magnetic field in my logical volume, but I do not know how to go about doing so. I would like to control its strength via a detector messenger and I already have that taken care of. I just need to know how to apply a field to a logical volume. I have tried to follow some of the other postings regarding this topic on the HyperNews forum, but when I do so the results are dismal and it doesn't work. Thanks, Matthew Middione

Help setting up an Electric Field by Adam <ax_blais@laurentian.ca>, 10 Jul, 2007 I have a xenon cylinder surrounded by air. I want to make an electric field in only the xenon. I tried borrowing the class from the field02 extended example. My field setup class is this: #include "ExN02ElectricFieldSetup.hh" #include "ExN02FieldMessenger.hh" #include "G4UniformElectricField.hh" #include "G4UniformMagField.hh" #include "G4MagneticField.hh" #include "G4FieldManager.hh" #include "G4TransportationManager.hh" #include "G4EquationOfMotion.hh" #include "G4EqMagElectricField.hh" #include "G4Mag_UsualEqRhs.hh" #include "G4MagIntegratorStepper.hh" #include "G4MagIntegratorDriver.hh" #include "G4ChordFinder.hh" #include "G4ExplicitEuler.hh" #include "G4ImplicitEuler.hh" #include "G4SimpleRunge.hh" #include "G4SimpleHeum.hh" #include "G4ClassicalRK4.hh" #include "G4HelixExplicitEuler.hh" #include "G4HelixImplicitEuler.hh" #include "G4HelixSimpleRunge.hh" #include "G4CashKarpRKF45.hh" #include "G4RKG3_Stepper.hh" ////////////////////////////////////////////////////////////////////////// // // Constructors: ExN02ElectricFieldSetup::ExN02ElectricFieldSetup() : fChordFinder(0), fStepper(0), fIntgrDriver(0) { fEMfield = new G4UniformElectricField( G4ThreeVector(0.0,1000.0*kilovolt/cm,0.0)); fFieldMessenger = new ExN02FieldMessenger(this) ; fEquation = new G4EqMagElectricField(fEMfield); fMinStep = 0.010*mm ; // minimal step of 10 microns fStepperType = 4 ; // ClassicalRK4 -- the default stepper fFieldManager = GetGlobalFieldManager(); UpdateField(); } ///////////////////////////////////////////////////////////////////////////////// ExN02ElectricFieldSetup::ExN02ElectricFieldSetup(G4ThreeVector pFV) : fChordFinder(0), fStepper(0), fIntgrDriver(0) { fEMfield = new G4UniformElectricField(pFV); // GetGlobalFieldManager()->CreateChordFinder(this); fFieldMessenger = new ExN02FieldMessenger(this) ; fEquation = new G4EqMagElectricField(fEMfield); fMinStep = 0.010*mm ; // minimal step of 10 microns fStepperType = 4 ; // ClassicalRK4 -- the default stepper fFieldManager = GetGlobalFieldManager(); UpdateField(); } //////////////////////////////////////////////////////////////////////////////// ExN02ElectricFieldSetup::~ExN02ElectricFieldSetup() { if(fChordFinder) delete fChordFinder; if(fStepper) delete fStepper; if(fEquation) delete fEquation; if(fEMfield) delete fEMfield; } ///////////////////////////////////////////////////////////////////////////// // // Register this field to 'global' Field Manager and // Create Stepper and Chord Finder with predefined type, minstep (resp.) // void ExN02ElectricFieldSetup::UpdateField() { SetStepper(); G4cout<<"The minimal step is equal to "<<fMinStep/mm<<" mm"<<G4endl ; fFieldManager->SetDetectorField(fEMfield ); if(fChordFinder) delete fChordFinder; // fChordFinder = new G4ChordFinder( fEMfield, fMinStep, fStepper); fIntgrDriver = new G4MagInt_Driver(fMinStep, fStepper, fStepper->GetNumberOfVariables() ); fChordFinder = new G4ChordFinder(fIntgrDriver); fFieldManager->SetChordFinder( fChordFinder ); } ///////////////////////////////////////////////////////////////////////////// // // Set stepper according to the stepper type // void ExN02ElectricFieldSetup::SetStepper() { G4int nvar = 8; if(fStepper) delete fStepper; switch ( fStepperType ) { case 0: fStepper = new G4ExplicitEuler( fEquation, nvar ); G4cout<<"G4ExplicitEuler is calledS"<<G4endl; break; case 1: fStepper = new G4ImplicitEuler( fEquation, nvar ); G4cout<<"G4ImplicitEuler is called"<<G4endl; break; case 2: fStepper = new G4SimpleRunge( fEquation, nvar ); G4cout<<"G4SimpleRunge is called"<<G4endl; break; case 3: fStepper = new G4SimpleHeum( fEquation, nvar ); G4cout<<"G4SimpleHeum is called"<<G4endl; break; case 4: fStepper = new G4ClassicalRK4( fEquation, nvar ); G4cout<<"G4ClassicalRK4 (default) is called"<<G4endl; break; case 5: fStepper = new G4CashKarpRKF45( fEquation, nvar ); G4cout<<"G4CashKarpRKF45 is called"<<G4endl; break; case 6: fStepper = 0; // new G4RKG3_Stepper( fEquation, nvar ); G4cout<<"G4RKG3_Stepper is not currently working for Electric Field"<<G4endl; break; case 7: fStepper = 0; // new G4HelixExplicitEuler( fEquation ); G4cout<<"G4HelixExplicitEuler is not valid for Electric Field"<<G4endl; break; case 8: fStepper = 0; // new G4HelixImplicitEuler( fEquation ); G4cout<<"G4HelixImplicitEuler is not valid for Electric Field"<<G4endl; break; case 9: fStepper = 0; // new G4HelixSimpleRunge( fEquation ); G4cout<<"G4HelixSimpleRunge is not valid for Electric Field"<<G4endl; break; default: fStepper = 0; } } ///////////////////////////////////////////////////////////////////////////// // // Set the value of the Global Field to fieldValue along Z // void ExN02ElectricFieldSetup::SetFieldValue(G4double fieldValue) { G4ThreeVector fieldVector( 0.0, 0.0, fieldValue ); SetFieldValue( fieldVector ); } /////////////////////////////////////////////////////////////////////////////// // // Set the value of the Global Field value to fieldVector // void ExN02ElectricFieldSetup::SetFieldValue(G4ThreeVector fieldVector) { // Find the Field Manager for the global field G4FieldManager* fieldMgr= GetGlobalFieldManager(); if(fieldVector != G4ThreeVector(0.,0.,0.)) { if(fEMfield) delete fEMfield; fEMfield = new G4UniformElectricField(fieldVector); fEquation->SetFieldObj(fEMfield); // must now point to the new field // UpdateField(); fieldMgr->SetDetectorField(fEMfield); } else { // If the new field's value is Zero, then it is best to // insure that it is not used for propagation. if(fEMfield) delete fEMfield; fEMfield = 0; fEquation->SetFieldObj(fEMfield); // As a double check ... G4MagneticField* fEMfield = 0; fieldMgr->SetDetectorField(fEMfield); } } //////////////////////////////////////////////////////////////////////////////// // // Utility method G4FieldManager* ExN02ElectricFieldSetup::GetGlobalFieldManager() { return G4TransportationManager::GetTransportationManager() ->GetFieldManager(); } I added the line: ExN02ElectricFieldSetup* field = new ExN02ElectricFieldSetup(); to my main. When the simulation starts, it seems as though particles are leaving the xenon and keep going on forever until they exit the world volume, which gives me a segmentation fault. I know that to isolate the field to only the xenon cylinder, I need to use the line: xenon_log->SetFieldManager(field->GetGlobalFieldManager(), false); Is this right? If it is right, in what class do I put this line? The documentation isn't very specific about this.

Magnetic Field doesn't work when point source positioined at origin Keywords: GPS, Magnetic Field, Point Source at Origin, TestEm1, exgps by Matthew Middione <middionematt@csufresno.edu>, 02 Jul, 2007 I am using the following two examples in Geant4 to model my simulation: TestEm1 and exgps I have effectively created a hybrid model of the two to allow TestEm1 to use the GPS as opposed ot the ParticleGun. I did this so I could model a positron emitting point source. I have a transverse magnetic field applied in the simulation as well and its strength can be changed. When I run the simulation with a 0.0 T magnetic field the calculated range of a 4 MeV positron is 2.0205 g/cm2. Then I apply a 9.4 T magnetic field expecting to see a significant reduction in the range of the same positron and the resulting range is 2.0279 g/cm2. If I run the normal TestEm1 which does not utilize the GPS and instead uses the Particle Gun the results are what I expect. However, if I use the same example and change the location of the positron being emitted to the origin as opposed to the face of the detector, which was previously used, the results are consistent with what I first described above in the hybrid example. Basically there is the magnetic field takes no effect. What is causing this problem? Any help would be much appreciated... Thanks in anticipation, Matthew Middione

endless loop in magnetic field by Anton <Anton>, 16 Jun, 2007 Hello, I found problem of charged particles propagation in magnetic field. In test program I define only world volume with magnetic field and electron/positron as primary particle. This simple setup leads to endless loop. (I use geant4 8.3) I try different electron energies (200 eV, 200 keV), different world volume materials (vacuum, aluminum), different directions of magnetic field - in all this cases I obtain endless loop. You can find short program, which reproduce it here: http://cern.ch/begemot/testb.zip

Problem with local magnetic field by alex <caraboy@gmail.com>, 11 Mar, 2007

Hello,

I am trying to add a local magnetic field into a box, and I encounter several compiler errors that I can`t fix. I managed to add a global uniform magnetic field but it is not what I need, so after searching the forum and studying some .ppt I found at some workshops I managed to add the code, but I get the following errors:

--------------- root@ubuntu:~/GeantProjects/teste/N01# make

Making dependency for file src/ExN01DetectorConstruction.cc ...

Compiling ExN01DetectorConstruction.cc ...

src/ExN01DetectorConstruction.cc: In member function virtual G4VPhysicalVolume* ExN01DetectorConstruction::Construct():

src/ExN01DetectorConstruction.cc:72: error: expected type-specifier before G4ClassicalRK4

src/ExN01DetectorConstruction.cc:72: error: cannot convert int* to G4MagIntegratorStepper* in initialization

src/ExN01DetectorConstruction.cc:72: error: expected , or ; before G4ClassicalRK4

src/ExN01DetectorConstruction.cc:70: warning: unused variable myEquation

make: *** [/home/oem/GeantProjects/tmp/Linux-g++/testN01/ExN01DetectorConstruction.o] Error 1
------------------

Can you help me figure out what am I doing wrong? I have the following detectorconstruction source:

-------------------- #include "ExN01DetectorConstruction.hh"

#include "G4Material.hh" #include "G4Box.hh" #include "G4Tubs.hh" #include "G4LogicalVolume.hh" #include "G4ThreeVector.hh" #include "G4PVPlacement.hh" #include "globals.hh" #include "G4NistManager.hh"

#include <G4UniformMagField.hh> #include <G4FieldManager.hh> #include <G4TransportationManager.hh>

#include <G4Mag_UsualEqRhs.hh> #include <G4MagIntegratorStepper.hh> #include <G4ChordFinder.hh>

ExN01DetectorConstruction::ExN01DetectorConstruction() : experimentalHall_log(0), tracker_log(0), calorimeterBlock_log(0), calorimeterLayer_log(0), experimentalHall_phys(0), calorimeterLayer_phys(0), calorimeterBlock_phys(0), tracker_phys(0) {;}

ExN01DetectorConstruction::~ExN01DetectorConstruction() { }

G4VPhysicalVolume* ExN01DetectorConstruction::Construct() {

//------------------------------------------------------ materiale - definire materiale

G4double a; G4double z; G4double density;

G4Material* Pb = new G4Material("Lead", z= 82., a= 207.19*g/mole, density= 11.35*g/cm3); // Plumb sau Fier

G4NistManager* man = G4NistManager::Instance(); G4Material* Air = man->FindOrBuildMaterial("G4_AIR"); // Aer G4cout <<Air<<"\r"; G4cout << *(G4Material::GetMaterialTable()); // lista materiale

//------------------------------------------------------ volumes

//------------------------------ experimental hall (world volume) //------------------------------ beam line along x axis

G4double expHall_x = 6.0*m; G4double expHall_y = 3.0*m; G4double expHall_z = 3.0*m; G4Box* experimentalHall_box = new G4Box("World_Box_Shape",expHall_x,expHall_y,expHall_z); // dedinesc shape pt World Volume experimentalHall_log = new G4LogicalVolume(experimentalHall_box, Air,"World_Box__Logical",0,0,0); // definesc proprietati pentru World Volume experimentalHall_phys = new G4PVPlacement(0,G4ThreeVector(), experimentalHall_log,"World_Box",0,false,0); //pozitionez in scena World Volume

G4double block_x = 1.0*m; G4double block_y = 50.0*cm; G4double block_z = 50.0*cm;

G4double fieldValue = 10.0*tesla; G4UniformMagField* myField =new G4UniformMagField(G4ThreeVector(0.0,fieldValue,0.0));

G4Mag_UsualEqRhs* myEquation = new G4Mag_UsualEqRhs(myField);

G4MagIntegratorStepper* myStepper = new G4ClassicalRK4(myEquation);

G4ChordFinder* myChordFinder = new G4ChordFinder(myField,0.01*mm,myStepper);

G4FieldManager* fieldMgr = new G4FieldManager(myField,myChordFinder);

G4Box* calorimeterBlock_box = new G4Box("calorimetru_box", block_x, block_y, block_z); calorimeterBlock_log = new G4LogicalVolume(calorimeterBlock_box,Pb,"calorimetru_log", fieldMgr,0,0); //camp mg

G4double blockPos_x = 1.0*m; G4double blockPos_y = 0.0*m; G4double blockPos_z = 0.0*m;

calorimeterBlock_phys = new G4PVPlacement(0,G4ThreeVector(blockPos_x,blockPos_y,blockPos_z),calorimeterBlock_log,"calorimetru",experimentalHall_log,false,0);

return experimentalHall_phys; }

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

Thank you for you time.

multiple field maps Keywords: multiple field maps magnetic field by Kazutaka Nakahara <nakahara@post.kek.jp>, 27 Feb, 2007 Hi, I'd like to use multiple field maps in my simulation. Does the G4FieldManager allow this? I basically have: ---------------------------------------------- G4FieldManager *pFieldMgr; // G4MagIntegratorStepper *pStepper; //Field grid in A9.TABLE. File must be in accessible from run urn directory G4MagneticField* MuonMagField; G4MagneticField* MuonMagField1; G4MagneticField* MuonMagField2; MuonMagField= new MuonField3D("front_field_original.Table", zOffset); MuonMagField1= new MuonField3D("transport_file1.Table", zOffset); MuonMagField2= new MuonField3D("transport_file2.Table", zOffset); pFieldMgr=G4TransportationManager::GetTransportationManager()->GetFieldManager(); pFieldMgr1=G4TransportationManager::GetTransportationManager()->GetFieldManager(); pFieldMgr2=G4TransportationManager::GetTransportationManager()->GetFieldManager(); G4ChordFinder *pChordFinder = new G4ChordFinder(MuonMagField); G4ChordFinder *pChordFinder1 = new G4ChordFinder(MuonMagField1); G4ChordFinder *pChordFinder2 = new G4ChordFinder(MuonMagField2); pFieldMgr->SetChordFinder( pChordFinder ); pFieldMgr->SetChordFinder( pChordFinder1 ); pFieldMgr->SetChordFinder( pChordFinder2 ); pFieldMgr->SetDetectorField(MuonMagField); pFieldMgr->SetDetectorField(MuonMagField1); pFieldMgr->SetDetectorField(MuonMagField2); ------------------------------------------------------------- But this doesn't seem to work at all (none of the fields register in the simulation). However, this does work when I use only one field map. Is it possible to make G4FieldManager accept multiple maps, or do I need to combine them into one file? Thanks in advance, Kaz

insert Electric fileld to logical volume Keywords: insert Electric fileld to logical volume
by Lee, Hyun-Seung <sherufa@naver.com>, 20 Feb, 2007

With reference guide, I tried to make an uniform electric field and attach that to a logical volume(detector) However, when it is building, error is occured.

("singleGap_log" is the logical volume of detector)

--------***code***---------------------------

G4UniformElectricField* fUniformElectricField = new G4UniformElectricField(G4ThreeVector(0.,0.,100.0*kilovolt/cm));

singleGap_log->SetFieldManager(fUniformElectricField->GetLocalFieldManager(),allLocal);

--------***error message***-----------------------------

src/MyDetectorConstruction.cc: In member function `virtual G4VPhysicalVolume* MyDetectorConstruction::Construct()':

src/MyDetectorConstruction.cc:366: error: 'class G4UniformElectricField' has no member named 'GetLocalFieldManager' ---------------------------------------------------------

below, there is the text of "Geant4 User's Guide For Application Developers Detector Definition and Response" (4.3.2 Practical Aspects)

---------***text of user`s guide***------------------------------------

Creating a Field for a Part of the Volume Hierarchy

It is possible to create a field for a part of the detector. In particular it can describe the field (with pointer fEmField, for example) inside a logical volume and all its daughters. This can be done by simply creating a G4FieldManager and attaching it to a logical volume (with pointer, logicVolumeWithField, for example) or set of logical volumes.

G4bool allLocal = true; logicVolumeWithField->SetFieldManager(fEmField->GetLocalFieldManager(),allLocal);

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

what class is "fEmField" is instance of? I can`t find "GetLocalFieldManager()"method in reference guide..

how to add non-uniform M-field and rf EM field Keywords: non-uniform field, rf field, by long <long>, 08 Jan, 2007 Dear Friends, I want to tranport eletron beam through a non-uniform magnetic field, then pass through a cavity filled with rf field. How to use these two fiels type? I have not found them in the manual. Could anybody give some details? Thanks a lot!

How to view helical trajectories in a solenoid Keywords: helical trajectories, visualization, magnetic field, solenoid by Ken Teh <teh@anl.gov>, 05 Dec, 2006 I am unable to "see" my helical trajectories in a solenoid with a constant B field unless I put in cylindrical slices of vacuum in my solenoid. With these slices in place, the trajectory crosses several "volumes" of vacuum and I can see the helical trajectory. This is rather hokey. Is there a way of drawing the trajectories without resorting to these slices of vacuum? Thanks! Ken

Rotating a field & obtaining the EM field in a certain point by Giovanni Marchiori <giovanni.marchiori@pi.infn.it>, 26 Sep, 2006 I have two unrelated questions on electromagnetic fields: 1) when I associate a field to a logical volume with SetFieldManager, when I then rotate the logical volume and place it inside the world, the field is not rotated at all: is this behaviour expected? Do I have to rotate the field by hand? What I do is: G4double fieldValue = 1.5*tesla; G4UniformMagField* intField = new G4UniformMagField(G4ThreeVector(0.,0.,fieldValue)); G4Mag_UsualEqRhs* iEquation = new G4Mag_UsualEqRhs(intField); G4MagIntegratorStepper* iStepper = new G4ClassicalRK4(iEquation); G4ChordFinder* iChordFinder = new G4ChordFinder(intField,1.0e-6*mm,iStepper); G4FieldManager* fieldMgr = new G4FieldManager(intField,iChordFinder); G4RotationMatrix* RotPos = new G4RotationMatrix( G4ThreeVector( 0., 0. , 1 ), G4ThreeVector( 0., 1. , 0.), G4ThreeVector(-1., 0. , 0. ) ); G4Tubs* solidInnerSol = new G4Tubs("sInnerSolenoid", 0., rmin, length/2.0, startphi, deltaphi); G4LogicalVolume* logicInnerSol = new G4LogicalVolume(solidInnerSol, CentralVacuum, "lInnerSolenoid", fieldMgr); G4VPhysicalVolume* physiInnerSol = new G4PVPlacement(RotPos, G4ThreeVector(), logicInnerSol, "pInnerSolenoid", logicWorld, false, 0); What I obtain is a cilinder with axis along x, but the field inside it is still parallel to z. Isn't there any connection between the orientation of a volume and that of its associated field? 2) What is the easiest way to know, once I have setup the geometry of the fields, what is the total electromagnetic field - in global coordinates - in a generic point in space? Does Geant4 provide such a functionality? I am using Geant4 8.1.patch01 on a Linux machine. Thanks Giovanni

Electrons tracking in high magnetic fields with LowEn. el/m physics Keywords: electron, magnetic field, low-energy el/m physics. by Ilya <ilya.kraev@fys.kuleuven.ac.be>, 16 May, 2006 Hi everybody, I am busy with a simulation of 60Co beta-decay (energies up to 320 keV) in a set-up with magnetic field B = 13 T. In my program I used low-energy electromagnetic processes for this purpose. The final spectrum in a detector that I obtained in sumulations has events that are above end-point energy of 60Co (above 320 keV) and number of these events can not be explained by physics (the detector is too thin to stop two gamma-quanta emitted together with a beta-particle and also the previous simulations in a test set-up did not show such a behaviour). To check whether it is not related to some bugs in my program I switched to the Standard el/m processes. The spectrum that I see is OK! Then I tried to simulate monoenergetic electron (300 keV). With LOW ENERGY el/m processes I again get events with energy above initaial energy of the particle while for the STANDARD el/m physics the spectrum is fine. In previous simulations in absence of the magnetic field I do not see such effect. Did somebody encounter such a problem and is there a bug in LOW ENERGY el/m physics when it has to deal with magnetic fields? Thanks a lot for any help, Ilya.

Problems with Tracking in Vacuum Keywords: tracking, magnetic field by Jens Hasper <hasper@ikp.tu-darmstadt.de>, 27 Mar, 2006 Hi, I'm using a magnetic field inside a vacuum box and having problems to get proper particle tracks. I've already tried to set the UserLimits with the methods below, which has already been suggested in several threads: G4UserLimits* userLimits=new G4UserLimits(1.*mm); expHall_log->SetUserLimits(userLimits); However, this didn't improve the simulation at all. The tracks look better when using Air instead of Vacuum (I guess because the TrackingCuts are different). Am I doing something wrong with the assignment of the UserLimits or do you have any suggestion what else to do? Thanks a lot, Jens

Electrons bouncing on the volume boundary in pure magnetic field Keywords: Magnetic field, electrons, ions, tracking
by Ilya <ilya.kraev@fys.kuleuven.ac.be>, 20 Feb, 2006

(GEANT 4.7.0.p1)

Dear GEANTers,

I have encountered a problem with tracking of the electrons in magnetic field in a simple set-up. I have a source of electrons (radioactive 60Co) located in 20 mum thick foil which is made of VACUUM. Mother volume - WORLD (also vacuum) Electron emitted in a random direction hits the boundary of the foil and gets reflected into the opposite direction. It can even leave the volume and then it is reflected again into oposite direction in vacuum at some point (that does not have any specific properties) in the WORLD volume. It continues to loop like this for a huge number of steps and then it finaly leaves the volume and reaches the detector The same happens to the recoil ion.

The energy of electron is typical beta-spectrum with end-point energy of 320 keV. Recoil ion: 60Ni (energy is about several eV). I'm using the low-energy physics processes.

The processes defined for electron: G4MultipleScattering (with FacRange = 0.01) G4LowEnergyIonisation G4LowEnergyBremsstrahlung

For ion: G4MultipleScattering G4ionIonisation

The magnetic field is user-defined: I have a field profile with 13T central field and decreasing to approx. 1T over 20 cm. The field does not have any sharp points in profile. In the field definition I customize following parameters:

//////////////////////////////////////////////// fEquation = new G4Mag_UsualEqRhs(this); fMinStep = 0.01*mm; // minimal step of 1 mm is default fMaxStep = 500.*mm; fStepperType = 4 ; // ClassicalRK4 is default stepper fFieldManager = G4TransportationManager::GetTransportationManager() ->GetFieldManager(); G4TransportationManager::GetTransportationManager()->GetPropagatorInField()->SetMaxLoopCount(500); G4TransportationManager::GetTransportationManager()->GetPropagatorInField()->SetLargestAcceptableStep(fMaxStep); //////////////////////////////////////////////////

Please can somebody point out the problem (why it bounces like this) and possible solution (it takes ages to simulate few events or sometimes it stucks forever)!!!

Thanks a lot, Ilya.

Below is a part of output of tracking for one event:
********************************************************************************************************* * G4Track Information: Particle = Co60[0.0], Track ID = 1, Parent ID = 0 *********************************************************************************************************

Step# X Y Z KineE dEStep StepLeng TrakLeng Volume Process 0 -620 mum -1.18 mm 7.08 mum 0 eV 0 eV 0 fm 0 fm Foil initStep 1 -620 mum -1.18 mm 7.08 mum 0 eV 0 eV 0 fm 0 fm Foil RadioactiveDecay :----- List of 2ndaries - #SpawnInStep= 5(Rest= 5,Along= 0,Post= 0), #SpawnTotal= 5 --------------- : -620 mum -1.18 mm 7.08 mum 0.959 eV Ni60[0.0] : -620 mum -1.18 mm 7.08 mum 1.33 MeV gamma : -620 mum -1.18 mm 7.08 mum 1.17 MeV gamma : -620 mum -1.18 mm 7.08 mum 263 keV anti_nu_e : -620 mum -1.18 mm 7.08 mum 55.4 keV e- :----------------------------------------------------------------- EndOf2ndaries Info --------------- Track (trackID 1, parentID 0) is processed with stopping code 2 A new track 0x928f760 (trackID 2, parentID 1) is passed to G4StackManager. A new track 0x928f808 (trackID 3, parentID 1) is passed to G4StackManager. A new track 0x928f8b0 (trackID 4, parentID 1) is passed to G4StackManager. A new track 0x928f610 (trackID 5, parentID 1) is passed to G4StackManager. A new track 0x9291030 (trackID 6, parentID 1) is passed to G4StackManager. ### pop requested out of 5 stacked tracks. Selected G4StackedTrack : 0x928fa68 with G4Track 0x9291030 (trackID 6, parentID 1) Track 0x9291030 (trackID 6, parentID 1) is passed to G4TrackingManager.

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

Step# X Y Z KineE dEStep StepLeng TrakLeng Volume Process 0 -620 mum -1.18 mm 7.08 mum 55.4 keV 0 eV 0 fm 0 fm Foil initStep 1 -611 mum -1.18 mm 10 mum 55.4 keV 0 eV 9.28 mum 9.28 mum Foil Transportation 2 -671 mum -1.1 mm 10 mum 55.4 keV 0 eV 49.3 cm 49.3 cm World Transportation 3 -668 mum -1.15 mm -10 mum 55.4 keV 0 eV 61.2 mum 49.3 cm Foil Transportation 4 -561 mum -1.11 mm -10 mum 55.4 keV 0 eV 48.9 cm 98.2 cm World Transportation 5 -599 mum -1.07 mm 10 mum 55.4 keV 0 eV 59.4 mum 98.2 cm Foil Transportation 6 -609 mum -1.18 mm 10 mum 55.4 keV 0 eV 48.1 cm 1.46 m World Transportation 7 -566 mum -1.15 mm -10 mum 55.4 keV 0 eV 57.7 mum 1.46 m Foil Transportation 8 -639 mum -1.07 mm -10 mum 55.4 keV 0 eV 47.7 cm 1.94 m World Transportation 9 -674 mum -1.11 mm 10 mum 55.4 keV 0 eV 57.4 mum 1.94 m Foil Transportation 10 -559 mum -1.12 mm 10 mum 55.4 keV 0 eV 47.4 cm 2.41 m World Transportation 11 -583 mum -1.08 mm -10 mum 55.4 keV 0 eV 55.7 mum 2.41 m Foil Transportation 12 -619 mum -1.07 mm -10 mum 55.4 keV 0 eV 46.8 cm 2.88 m World Transportation 13 -662 mum -1.09 mm 10 mum 55.4 keV 0 eV 54.4 mum 2.88 m Foil Transportation 14 -622 mum -1.18 mm 10 mum 55.4 keV 0 eV 46.8 cm 3.35 m World Transportation 15 -576 mum -1.17 mm -10 mum 55.4 keV 0 eV 53.6 mum 3.35 m Foil Transportation 16 -667 mum -1.1 mm -10 mum 55.4 keV 0 eV 46.4 cm 3.81 m World Transportation 17 -668 mum -1.15 mm 10 mum 55.4 keV 0 eV 53 mum 3.81 m Foil Transportation 18 -578 mum -1.08 mm 10 mum 55.4 keV 0 eV 46 cm 4.27 m World Transportation 19 -624 mum -1.07 mm -10 mum 55.4 keV 0 eV 52.5 mum 4.27 m Foil Transportation 20 -572 mum -1.16 mm -10 mum 55.4 keV 0 eV 46.1 cm 4.74 m World Transportation .................. 524 367 mum -1.32 mm 10 mum 55.4 keV 0 eV 46.6 cm 113 m World Transportation 525 372 mum -1.32 mm -10 mum 55.4 keV 0 eV 20.7 mum 113 m Foil Transportation 526 300 mum -1.38 mm -10 mum 55.4 keV 0 eV 37.3 cm 113 m World Transportation 527 301 mum -1.38 mm 10 mum 55.4 keV 0 eV 20.4 mum 113 m Foil Transportation 528 21.8 mum 660 mum 19.3 cm 55.4 keV 0 eV 20.7 cm 114 m World Transportation 529 21.6 mum 660 mum 19.3 cm 54.9 keV 434 eV 292 nm 114 m FrontDeadLayer msc

HERE IT REACHED DETECTOR............................ (then it goes fine) next part is for ion

********************************************************************************************************* * G4Track Information: Particle = Ni60[0.0], Track ID = 2, Parent ID = 1 *********************************************************************************************************

Step# X Y Z KineE dEStep StepLeng TrakLeng Volume Process 0 590 mum 257 mum 5.63 mum 3.47 eV 0 eV 0 fm 0 fm Foil initStep 1 593 mum 260 mum -10 mum 3.47 eV 0 eV 29.9 mum 29.9 mum Foil Transportation 2 593 mum 260 mum -10 mum 3.47 eV 2.74e-16 eV 49.9 cm 49.9 cm World Transportation 3 589 mum 256 mum 10 mum 3.47 eV 0 eV 42.4 mum 49.9 cm Foil Transportation 4 588 mum 266 mum 10 mum 3.47 eV 2.73e-16 eV 49.7 cm 99.6 cm World Transportation 5 592 mum 264 mum -10 mum 3.47 eV 0 eV 41.8 mum 99.6 cm Foil Transportation 6 586 mum 265 mum -10 mum 3.47 eV 2.72e-16 eV 49.6 cm 1.49 m World Transportation 7 592 mum 264 mum 10 mum 3.47 eV 0 eV 43.5 mum 1.49 m Foil Transportation 8 588 mum 266 mum 797 mum 3.47 eV 2.74e-16 eV 50 cm 1.99 m World Transportation 9 593 mum 261 mum 10 mum 3.47 eV 1.03e-18 eV 1.76 mm 1.99 m World Transportation 10 589 mum 256 mum -10 mum 3.47 eV 0 eV 44.9 mum 1.99 m Foil Transportation 11 593 mum 261 mum -6.38 mm 3.47 eV 2.74e-16 eV 50 cm 2.49 m World Transportation 12 585 mum 257 mum -10 mum 3.47 eV 7.86e-18 eV 1.42 cm 2.51 m World Transportation 13 584 mum 264 mum 10 mum 3.47 eV 0 eV 44.6 mum 2.51 m Foil Transportation 14 593 mum 260 mum 10 mum 3.47 eV 2.71e-16 eV 49.4 cm 3 m World Transportation 15 589 mum 256 mum -10 mum 3.47 eV 0 eV 42.4 mum 3 m Foil Transportation 16 589 mum 266 mum -10 mum 3.47 eV 2.74e-16 eV 49.9 cm 3.5 m World Transportation 17 594 mum 261 mum 10 mum 3.47 eV 0 eV 44.1 mum 3.5 m Foil Transportation 18 588 mum 256 mum 4.26 mm 3.47 eV 2.74e-16 eV 50 cm 4 m World Transportation 19 583 mum 261 mum 10 mum 3.47 eV 5.38e-18 eV 9.68 mm 4.01 m World Transportation 20 589 mum 267 mum -10 mum 3.47 eV 0 eV 45.6 mum 4.01 m Foil Transportation 21 584 mum 259 mum -1.79 mm 3.47 eV 2.74e-16 eV 50 cm 4.51 m World Transportation 22 588 mum 267 mum -10 mum 3.47 eV 2.27e-18 eV 4.03 mm 4.51 m World Transportation 23 593 mum 261 mum 10 mum 3.47 eV 0 eV 45.2 mum 4.51 m Foil Transportation 24 584 mum 265 mum 1.59 mm 3.47 eV 2.74e-16 eV 50 cm 5.01 m World Transportation 25 585 mum 266 mum 10 mum 3.47 eV 1.86e-18 eV 3.41 mm 5.02 m World Transportation 26 591 mum 265 mum -10 mum 3.47 eV 0 eV 43.1 mum 5.02 m Foil Transportation 27 583 mum 261 mum -1.46 mm 3.47 eV 2.74e-16 eV 50 cm 5.52 m World Transportation .......................... and so on

Problem with tracking low energy ions in magnetic field in GEANT 4.7.0.p.1 Keywords: magnetic field, low energy ion, GEANT4.7.0.p1, looping
by Ilya <ilya.kraev@fys.kuleuven.ac.be>, 20 Jan, 2006

Dear GEANTers,

I have a problem with tracking of the low energy ions in the magnetic field. In my program I simulate the beta-decay of 60Co which is at rest. As a secondary particles (decay products) I obtain one electron (energies < 318 keV), two gammas (1173keV, 1332keV) anti-neutrino and recoil ion (60Ni). When the tracking of these decay products starts electron, gammas and anti-neutrino are tracked without problems but with the recoil ion which has an energy typically about 1 eV the program starts looping. With "/tracking/verbose 2" I see that after few (2-3) steps the ion stops to change it's z-coordinate. The process responsible for the tracking is transportation. (part of the output is in the end of the message.) The field value is 13 tesla but it does not work for 0.1 tesla as well. In zero magnetic field everything works fine. In my definition of the magnetic field I apply constraint for the maximum of the loop count = 1000 but it does not help. The 60Ni ion propagates in copper. The stepper that is used for the tracking is G4ClassicalRK4.

Could somebody help how to solve this problem or point out a reason why it happens?

Thanks a lot, Ilya.

Below I give the part of the output:
********************************************************************************************************* * G4Track Information: Particle = Ni60[0.0], Track ID = 2, Parent ID = 1 *********************************************************************************************************

Step# X Y Z KineE dEStep StepLeng TrakLeng Volume Process 0 -12.6 mum -1.16 mm 0 fm 0.912 eV 0 eV 0 fm 0 fm Foil initStep 1 -9.97 mum -1.16 mm -5 mum 0.912 eV 0 eV 11.8 mum 11.8 mum Foil Transportation particle being tracked is...Ni60[0.0] 2 -9.99 mum -1.16 mm -5.5 mum 0.912 eV 0 eV 1.13 mum 12.9 mum World Transportation particle being tracked is...Ni60[0.0] 3 -12 mum -1.16 mm -7.5 mum 0.912 eV 0 eV 3.48 mum 16.4 mum Solder Transportation particle being tracked is...Ni60[0.0] 4 -12.1 mum -1.16 mm -8 mum 0.912 eV 0 eV 1.14 mum 17.5 mum World Transportation particle being tracked is...Ni60[0.0] 5 -62.9 mum -1.16 mm -3.01 mm 0.912 eV 0 eV 6.41 cm 6.41 cm SourceHolderBottom Transportation particle being tracked is...Ni60[0.0] 6 23.4 mum -1.21 mm -3.01 mm 0.912 eV 0 eV 99.8 cm 1.06 m World Transportation particle being tracked is...Ni60[0.0] 7 23.4 mum -1.21 mm -3.01 mm 0.912 eV 0 eV 0 fm 1.06 m SourceHolderBottom Transportation particle being tracked is...Ni60[0.0] 8 -2.86 mum -1.13 mm -3.01 mm 0.912 eV 0 eV 99.8 cm 2.06 m World Transportation particle being tracked is...Ni60[0.0] 9 -23.8 mum -1.21 mm -3.01 mm 0.912 eV 0 eV 2.01 mm 2.06 m SourceHolderBottom Transportation particle being tracked is...Ni60[0.0] 10 -43.5 mum -1.25 mm -3.01 mm 0.912 eV 0 eV 99.9 cm 3.06 m World Transportation particle being tracked is...Ni60[0.0] 11 -35.7 mum -1.2 mm -3.01 mm 0.912 eV 0 eV 2.46 mm 3.06 m SourceHolderBottom Transportation particle being tracked is...Ni60[0.0] 12 -102 mum -1.15 mm -3.01 mm 0.912 eV 0 eV 99.6 cm 4.06 m World Transportation particle being tracked is...Ni60[0.0] 13 -134 mum -1.22 mm -3.01 mm 0.912 eV 0 eV 2.03 mm 4.06 m SourceHolderBottom Transportation particle being tracked is...Ni60[0.0] 14 -57.9 mum -1.19 mm -3.01 mm 0.912 eV 0 eV 99.9 cm 5.06 m World Transportation particle being tracked is...Ni60[0.0] 15 -140 mum -1.19 mm -3.01 mm 0.912 eV 0 eV 1.99 mm 5.06 m SourceHolderBottom Transportation particle being tracked is...Ni60[0.0] 16 -163 mum -1.26 mm -3.01 mm 0.912 eV 0 eV 99.9 cm 6.06 m World Transportation particle being tracked is...Ni60[0.0] 17 -106 mum -1.2 mm -3.01 mm 0.912 eV 0 eV 2 mm 6.06 m SourceHolderBottom Transportation particle being tracked is...Ni60[0.0] 18 -27.7 mum -1.16 mm -3.01 mm 0.912 eV 0 eV 99.7 cm 7.06 m World Transportation particle being tracked is...Ni60[0.0]

Local Electric Field Segmentation Fault Keywords: local electric field by <mcgeac00@uvic.ca>, 12 Jan, 2006 Hello, I have been trying to set up a local electric field inside an enclosed volume. I followed the example for creating a local magnetic field from the geant4 application developer's manual. It compiles fine but the simulation exhibits strange behaviour. The gun can shoot particles parallel to the field with no problems but when I try and shoot a beam in any other direction the simulation crashes with a segmantation fault. Changing the strength of the field changes the behaviour of the program. If it's 250volts/cm it runs fine (although I don't see it affecting the system at all). If the strength is 250 kilovolts/cm the program segfaults again. If the strength is 100250 kilovolts/cm the program just hangs. Can anyone suggest a solution to this problem? Below is how I'm creating the local EField Thanks, Jason McGeachie // Electric Field for the mother volume G4ElectricField* motherEField; G4FieldManager* motherFieldManager; G4EqMagElectricField* EFieldEq; G4MagIntegratorStepper* fStepper; G4ChordFinder* fChordFinder = 0; G4MagInt_Driver* fIntgrDriver; motherEField = new G4UniformElectricField(G4ThreeVector(0.,0.,0.)); EFieldEq = new G4EqMagElectricField(motherEField); //motherFieldManager = G4TransportationManager::GetTransportationManager()->GetFieldManager(); motherFieldManager = new G4FieldManager(); fStepper = new G4ClassicalRK4(EFieldEq,8); motherFieldManager->SetDetectorField(motherEField); if(fChordFinder) delete fChordFinder; fIntgrDriver = new G4MagInt_Driver(0.010*mm, // minimum step of 0.01mm fStepper, fStepper->GetNumberOfVariables() ); fChordFinder = new G4ChordFinder(fIntgrDriver); motherFieldManager->SetChordFinder(fChordFinder); TPCmotherLogical->SetFieldManager(motherFieldManager, true); // do daughter volumes inherit this field?

Crazy Point in G4Field::GetFieldValue() by Tom Roberts <Tom Roberts>, 17 Dec, 2005 In Geant4 7.1, my program occasionally crashes with a segment fault in my GetFieldValue(). This is caused by its argument Point[] being an array of 4 NaN-s. That's crazy -- why should the Geant4 tracking ever generate a Point that is four not-a-number? This is quite rare, occuring a few times out of 400 million events (800 500k-event jobs on a cluster). I can trace it to tracking a pi+ inside an Al beam pipe (much of the rarity is because most particles don't hit the beam pipes). As I am not interested in particles that hit beam pipes, I have a workaround by killing any particle inside a beam pipe. But soon I will be looking at backgrounds from that.... I am using the physics use case LHEP_BIC. When I compile and run with G4DEBUG=1, the problem does not occur. This implies that Point[] is probably not initialized when this fault happens; that is deep inside Geant4 code. My program seeds the random number generator with the event# and resets RanGauss(), so I can reliably re-run specific events. I put check code in GetFieldValue() to print "NaN" and force a coredump whenever Point[0] != Point[0] (i.e. Point[0] is NaN); the backtrace below did that. With G4DEBUG=0 all I can get is the stack traceback from the core file (levels 0,14,15 are mine): (gdb) backtrace #0 0x080ad57e in BLGlobalField::GetFieldValue () #1 0x08a29768 in G4ClassicalRK4::DumbStepper () #2 0x08a2a65f in G4MagErrorStepper::Stepper () #3 0x08a2c764 in G4MagInt_Driver::QuickAdvance () #4 0x08a28881 in G4ChordFinder::FindNextChord () #5 0x08a2826b in G4ChordFinder::AdvanceChordLimited () #6 0x08a3a9c4 in G4PropagatorInField::ComputeStep () #7 0x08327e17 in G4Transportation::AlongStepGetPhysicalInteractionLength () #8 0x082fda88 in G4SteppingManager::DefinePhysicalStepLength () #9 0x082fbded in G4SteppingManager::Stepping () #10 0x082f027d in G4TrackingManager::ProcessOneTrack () #11 0x082e3ee6 in G4EventManager::DoProcessing () #12 0x082cd9ee in G4RunManager::DoEventLoop () #13 0x082cd4c1 in G4RunManager::BeamOn () #14 0x080c239e in BLManager::trackBeam () #15 0x0805ee07 in main ()

cold neutron spin tracking Keywords: spin, neutrons, magnetic field by Emil Frlez <Emil Frlez>, 22 Nov, 2005 Dear GEANT-ers, I would appreciate if people who have a better insight into the GEANT4 tracking could help me increase my productivity ;8-) My problem is the cold neutron spin tracking in the non-homogeneous magnetic field. I am using geant4.6.2.p01. Reading the exchange between Bertalan and Peter it appeared to me (at the first sight) that this problem is (basically) solved in G4. So I used the Peter's recipe with "G4Mag_SpinEqRhs.cc". First thing I notice is that the anomaly is hard-wired for muons. Second issue, the code will only change the spin of the charged particles because dSpin is multiplied by particle charge. I checked that code compiles and works for electrons, it does run, and does the spin procession, though I have not checked that the results are OK. So, I thought that for cold neutrons only thing necessary is to copy and rename "G4Mag_SpinEqRhs.cc" into, say, "G4Mag_Neutron_SpinEqRhs.cc", change "anomaly = 1.165923e-3;" into "anomaly = 2.913;" and set "ParticleCharge = -1;" to reflect the negative neutron magnetic moment and get non-zero dSpin ... But then I noticed that my "GetFieldValue" is not called at all for neutron, so there will be no tracking for (presumably) any neutral particle. Does that means that the G4 FieldManager checks the charge of the tracked particle and quits if it is dealing with neutral particle? Can this behavior be changed in an elegant way? And are the simple changes I was thinking of, outlined above, only ones necessary for the neutron spin tracking? (With a rush of cold neutron experiments I find google-ing that a number of people are working on the spin tracking simulations. If the full machinery already exists in G4 and an experienced C++ programmer can make the fixes in 10 mins, what are those people working on ...;8-?) Or is the whole problem more complicated and I am missing something? Best Regards, Emil Frlez

Problem with Quadrupole Magnetic Field!! by S.Fonseca UERJ/Brazil <sfonseca@uerj.br>, 24 Oct, 2005 Hello people, I'm trying to simulate 4 low beta quadrupole magnets that are being used in the Tevatron beam line. For this I used G4QuadrupoleMagField method for simulate the Quadrupole Magnetic Field. However particles that enter in contact with this field disappear and I get the following message during Event: "G4Transportation is killing track that is looping or stuck. This track has XXX MeV energy" best regards, Sandro Fonseca Graduate student of the State University of Rio de Janeiro (UERJ/Brazil)

Trajectory in dipole field independent of energy ! by Tim Chambers <Tim Chambers>, 13 Jul, 2005 So I have my Earth with its dipole working, and running pretty speedily. Now comes the big problem: the paths of charged particles in the field are independent of energy! I have gone through the following steps, changing no code except the GetFieldValue() function... First, uniform B-field along z axis. As expected, the radius of curvature of the particle's path increases with energy. As a side note, I found that above a certain energy, about 8.5MeV for an electron in a 3 nT field, the particle would go absolutely straight, zero curvature. Then, a B-field along the z-axis where field strength is a function of the particle's z coordinate. Again, radius of curvature increases with energy. Now, a more complicated function, looking like Bfield[0] = y Bfield[1] = z Bfield[2] = x And still the path depends on energy. Adding another layer of complexity: Bfield[0] = y*z Bfield[1] = z*x Bfield[2] = x*y And as always, more energy makes the particle take larger loops with less curvature. So then I implemented my dipole field: Bfield[0] = 3*coeff*z*x Bfield[1] = 3*coeff*z*y Bfield[2] = coeff*(3*z*z - r*r) and suddenly, the trajectory becomes independent of energy. For the same starting position and direction, an electron ranging anywhere from 10 eV to 10 TeV will take exactly the same path. The initial direction has a small effect; it determines whether the particle travels forward or backward along the field line trapping it but otherwise does not matter. For example, these two run macros: /gps/position -8000. -8000. -8000. km /gps/energy 100 eV /gps/direction 1. 0. 0. and /gps/position -8000. -8000. -8000. km /gps/energy 10 MeV /gps/direction 1. 0. 1. produce identical output. What is the cause of this problem?

program hang on in magnetic field by Zhongdong Zhang <zh.zhang@fz-juelich.de>, 11 Jul, 2005

Dear all,

In my magnetic field, the world has global magnetic field zero and a cylinder in world has local magnetic field 3 Tesla along z-axis. When I run my programme, the verbose output as follows:

21 -1.9 mm 29.9 cm -67.6 cm 17.1 MeV 0 eV 2.69 cm 74 cm physiBore LElastic :----- List of 2ndaries - #SpawnInStep= 1(Rest= 0,Along= 0,Post= 1), #SpawnTotal= 1 --------------- : -1.9 mm 29.9 cm -67.6 cm 966 keV N14[0.0] :----------------------------------------------------------------- EndOf2ndaries Info --------------- 22 -1.53 cm 28.6 cm -70 cm 17.1 MeV 0 eV 3.04 cm 77 cm physiBore Transportation 23 -15.6 cm 14.8 cm -95 cm 17.1 MeV 0 eV 31.8 cm 1.09 m OutOfWorld Transportation ********************************************************************************************************* * G4Track Information: Particle = N14[0.0], Track ID = 190, Parent ID = 132 *********************************************************************************************************

1 -1.73 mm 29.9 cm -67.6 cm 958 keV 7.53 keV 275 mum 275 mum physiBore hIoni :----- List of 2ndaries - #SpawnInStep= 1(Rest= 0,Along= 0,Post= 1), #SpawnTotal= 1 --------------- : -1.73 mm 29.9 cm -67.6 cm 150 eV e- :----------------------------------------------------------------- EndOf2ndaries Info --------------- 2 -1.31 mm 29.9 cm -67.6 cm 939 keV 18.5 keV 664 mum 939 mum physiBore hIoni :----- List of 2ndaries - #SpawnInStep= 1(Rest= 0,Along= 0,Post= 1), #SpawnTotal= 2 --------------- : -1.31 mm 29.9 cm -67.6 cm 147 eV e- :----------------------------------------------------------------- EndOf2ndaries Info --------------- 3 -1.21 mm 29.9 cm -67.6 cm 935 keV 3.85 keV 151 mum 1.09 mm physiBore hIoni :----- List of 2ndaries - #SpawnInStep= 1(Rest= 0,Along= 0,Post= 1), #SpawnTotal= 3 --------------- : -1.21 mm 29.9 cm -67.6 cm 147 eV e- :----------------------------------------------------------------- EndOf2ndaries Info --------------- 4 -1 mm 30 cm -67.6 cm 927 keV 8.68 keV 323 mum 1.41 mm physiBore hIoni :----- List of 2ndaries - #SpawnInStep= 1(Rest= 0,Along= 0,Post= 1), #SpawnTotal= 4 --------------- : -1 mm 30 cm -67.6 cm 145 eV e- :----------------------------------------------------------------- EndOf2ndaries Info ---------------

Then the program seems enter a infinite loop and did nothing (no exit, no killing loop).

Is anything wrong or should I setup some parameter to control the field?

Thank you.

Zhongdong

Large system, very slow field tracking... how to improve? by Tim Chambers <Tim Chambers>, 27 Jun, 2005 I have built a full-size Earth (~6400km radius) with its ~10^22 J/T dipole, and I'm having a bit of trouble with run speed. I know the field is the cause of the slowness because when I set the field =0, the simulation runs quickly and with about the results I expect. I also tested a small dipole with a 1m sphere and got the usual behavior one expects from a dipole magnet, with a short run time. I currently have the field initialized in the DetectorConstruction class: SolarField* theField = new SolarField(); G4FieldManager* fieldMgr = G4TransportationManager::GetTransportationManager() ->GetFieldManager(); fieldMgr->CreateChordFinder(theField); fieldMgr->SetDetectorField(theField); like so. I figured there were two things I could do to speed up the performance: use a lower-order integrator, and increase step size. When I tried to use the following code, the program compiles and runs... somewhat. It works fine until I command /run/beamOn at which point it says "Run Start" and then locks up. It doesn't crash, it simply doesn't do anything after that. The code: SolarField* theField = new SolarField(); G4FieldManager* fieldMgr = G4TransportationManager::GetTransportationManager() ->GetFieldManager(); G4EqMagElectricField* theEqn = new G4EqMagElectricField(theField); G4MagIntegratorStepper* theStepper = new G4SimpleHeum(theEqn); G4double MinStep = 10*m; G4MagInt_Driver* theDriver = new G4MagInt_Driver(MinStep,theStepper, theStepper->GetNumberOfVariables() ); G4ChordFinder* theFinder = new G4ChordFinder(theDriver); fieldMgr->SetChordFinder(theFinder); fieldMgr->SetDetectorField(theField); Can anybody help me figure out why this refuses to run, or give me any other advice for speeding up the program? In the time it's taken me to write this, one electron has managed to travel a whole centimeter in vacuum... Thanks, Tim Chambers

G4MagIntegratorDriver::OneGoodStep error by John Carter <John Carter>, 13 Jun, 2005 Hi all, I'm having problems with a user-defined solenoid field. I have set up the field and tested it with a few dry runs and it seems to work ok. However, some events produce the following 'error' output: G4MagIntegratorDriver::OneGoodStep: Stepsize underflow in Stepper Step's start x=16376 and end x= 16376 are equal !! Due to step-size= 2.5e-13 . Note that input step was 2.5e-06 This is something that randomly happens and I call it an 'error' because it doesn't cause the program to crash, merely locks it up. I have tried changing my MaxAllowedStep for my volume and I don't seem to get the error if I reduce the step length to something on the order of 10mm. However, this vastly reduces the speed of the tracking (18 hours to track 1000 events compared to a few seconds...) Has anyone seen this error and know the cause or a workaround? Cheers, John

magnetic field in a vacuum box Keywords: magnetic field in a vacuum box by <maryam@jlab.org>, 08 Jun, 2005 Dear all, I have a 3 tesla uniform magnetic field in a box of vacuum which is rotated 30 degrees with respect to my beamline. The field properly bends the beam but sharply not like a smooth curve. But the e- beam also gets bent another 30 degrees sharply, when it exits the volume. Could anyone help me figure out why this is happening? Many thanks, Maryam

Simultaneous E and B Fields??? Keywords: electric magnetic field simultaneous by Daniel McDevitt <Daniel McDevitt>, 07 Jun, 2005 I�m trying to create an electric AND magnetic field, simultaneously inside a portion of my geometry into which I will be shooting positrons. I�m using a global magnetic field (cannibalized from /novice/exampleN02) and a local electric field. // For global mag field G4double fieldValue = 0.5687*tesla; fpMagField = new ExN02MagneticField(G4ThreeVector (0.,0.,fieldValue)); // Local Electric Field G4double pfieldValue = 0.001*volt/cm; G4UniformElectricField* myElectricField = new G4UniformElectricField(G4ThreeVector(pfieldValue,0,0)); G4EqMagElectricField *myeEquation= new G4EqMagElectricField(myElectricField); G4int nvar = 8; G4MagIntegratorStepper* myStepper = new G4ClassicalRK4(myeEquation,nvar); G4MagInt_Driver* myIntgrDriver=new G4MagInt_Driver(1.0e-3*mm, myStepper, myStepper->GetNumberOfVariables()); G4ChordFinder* myChordFinder = new G4ChordFinder(myIntgrDriver); G4bool fieldChangesEnergy = true; G4FieldManager* pFieldMgr = new G4FieldManager(myElectricField,myChordFinder,fieldChangesEnergy); When the electric field is turned on inside the geometry (ie pFieldMgr is inserted into the Logical volume as shown below), the magnetic field no longer works. However, the electric field functions. // Aerogel Hi solidAerogelhi1 = new G4Box("Aerogel_hi1Box", aerogelx,aerogely,aerogelz); logicAerogelhi1 = new G4LogicalVolume(solidAerogelhi1 , AerogelhiMater, "Aerogel_hi1",0,0,0); physiAerogelhi1 = new G4PVPlacement(0, // no rotation positionAerogelhi1, // at (x,y,z) logicAerogelhi1, // its logical volume "Aerogel_hi1", // its name logicWorld, // its mother volume false, // no boolean operations 0); // copy number // Aerogel hi replicated solidAeroghi1Column = new G4Box("Aeroghi1ColumnBox",1.0*cm,0.25*cm,0.025*cm); logicAeroghi1Column = new G4LogicalVolume(solidAeroghi1Column,AerogelhiMater,"logicAeroghi1Column",pFieldMgr,0,0); physiAeroghi1Column = new G4PVReplica("physiAeroghi1Column",logicAeroghi1Column, logicAerogelhi1, kZAxis,100,0.05*cm); It appears that the electric field pre-empts the magnetic field and I am left with the options of either one or the other, depending on which one I do not implement. How does one create both a magnetic and electric field, simultaneously in a geometry? Thanks, Daniel

How to make custom magnetic field class? by Tim Chambers <Tim Chambers>, 25 May, 2005 I am building a simulation that has a static magnetic field that is a function of the x,y,z coordinates; B[0] = cos(x); //just examples, the real functions are uglier B[1] = y*y; that sort of thing. I have gathered that for a non-uniform magnetic field it is necessary to create your own magnetic field class. By looking at the source code for G4UniformMagField I get the general idea of how this works, but I can't figure out how to make the magnetic field values depend on position. Any advice will be greatly appreciated! -Tim Chambers

Different radii for the 'same' electron in B-field Keywords: GEATN4 magnetic field electrons curve by Valentin <Valentin.Kozlov@fys.kuleuven.ac.be>, 10 May, 2005 Dear GEANT4ers, I have the following situation: there are 3MeV electrons in a homogenious magnetic field (in vacuum). The field is defined via GetFieldValue() function setting B[0]=0.; B[1]=0.; B[2]=9*tesla; (in 'real' case there is a fieldmap, but for the test the field is described as above). Electrons start from the (0,0,0) point in direction (0,1.,0), i.e. perpendicular to the magnetic field. For this configuration I calculate the radius of e- motion as 1.3mm. To store the "trajectory" of electrons in GEANT4, (x,y,z) position is saved in GetFieldValue() function. Now, when these positions are plotted, one can see different circles of different radii. The major part of events is on the right radius of ~1.3mm but there are more circules from ~1.6mm to 1.1mm radius and some individual events far from the center. Going from fMinStep of 1mm to 0.1mm changed the situation so that the structure of circles became more 'fine', i.e. more visually different circles appeared near the right radius. As I do not see any physics (it has to be only one curve, isn't it?!), it should be some settings of GEANT4 which are used or something else from how it is calculated. Could you tell me, where to look for the solution? Thank you, Valentin P.S. GEANT4 version: 6.1

I am working on multiwired proportional counter, how can i impliment electric field. Keywords: electric field by M.V.Amaresh Kumar <amar@rri.res.in>, 30 Apr, 2005 hai everyone, i am trying to simulate a multiwire proportional counter , how can i use the electric field feature in geant. thanks a lot amaresh

Problems with a local magnetic field Keywords: local magnetic field logical volume by Lewis Dartnell <l.dartnell@ucl.ac.uk>, 22 Apr, 2005 I am having problems getting a local magnetic field assigned to a logical volume to work correctly, as per the examples given in answer to Questions 33 and 10 in this forum. No error messages are thrown up when I compile my files, and the program executes without complaint. But in the visualisation of the output the proton tracks pass straight through the 'MagAnomaly' region, blissfully unaware of any magnetic field... All of the appropriate header files are included at the top of my DetectorConstructor.cc file: #include "G4TransportationManager.hh" #include "G4UniformMagField.hh" #include "G4Mag_UsualEqRhs.hh" #include "G4ClassicalRK4.hh" #include "G4MagIntegratorStepper.hh" #include "G4ChordFinder.hh" #include "G4FieldManager.hh" ~~~~~~~~~ The Runge Kutta, ChordFinder, and field manager are then all set up further down in my DetectorConstructor.cc : static const G4double fieldValue = 1.*tesla; MagField = new G4UniformMagField(G4ThreeVector(0., fieldValue, 0. )); iEquation = new G4Mag_UsualEqRhs(MagField); iStepper = new G4ClassicalRK4(iEquation); iChordFinder = new G4ChordFinder(MagField, 0.01*mm, iStepper); fieldMgr = new G4FieldManager(MagField, iChordFinder); all of these pointers are initialised in DetectorConstructor.hh ~~~~~~~~~ This fieldMgr is then assigned to a hemi-spherical logical volume which I then place as a physical volume within the WorldVolume: G4Sphere* MagAnomaly = new G4Sphere("MagAnomaly", innerRadiusOfTheSphere, outerRadiusOfTheSphere, StartPhiAngle, DeltaPhiAngle, StartThetaAngle, DeltaThetaAngle); MagAnomaly_log = new G4LogicalVolume(MagAnomaly, MartianAir, "MagAnomaly_log", fieldMgr, 0, 0); MagAnomaly_phys = new G4PVPlacement(0, G4ThreeVector(MagAnomalyPos_x, MagAnomalyPos_y, MagAnomalyPos_z), MagAnomaly_log,"MagAnomaly", WorldVolume_log, false, 0); This WorldVolume was originally given a localised magnetic field with the method used in Exercise#2 - ie. a global field restricted to co-ordinates within a hemi-sphere (x^2 + y^2 +z^2 < 1 && y>1). This worked fine, so I know that the problem lies in the attribution of a local magnetic field to the MagAnomaly volume, and not problems with particle definitions, trackers, etc. Can anyone help me out with this please...?

Help with "Unit category <Electric flux density> is not defined." by Jifeng Han <Jifeng Han>, 21 Apr, 2005 Hello, everyone. I add an electric field for my use, and when running got an message "Unit category <Electric flux density> is not defined." I don't understand what is it, need I define the unit? Could anybody help to fix it? Many thanks!

field01 example takes 1 tiny step ? Keywords: field01 question by R. Michaels <rom@jlab.org>, 19 Apr, 2005 I am wondering about the example field01 in the /examples/extended/field. If I plot the tracks, or use verbose output, it appears the tracks only progagate a very tiny amount and only one step. I had this problem with my own code, then when I tried field01 and saw the same behaviour it seems reasonable to ask. Shouldn't the particles in field01 propagate somewhere ? I would like to verify that they curve in the field. Thanks. I'm a "newbie".

Bug with "G4Transportation is killing track" ? by Andrey Elagin <elagin@nusun.jinr.ru>, 05 Apr, 2005 Hello, I have found that in geant4.7.0.p01 looping particles are not really killed. I tracked electron of 1 GeV in a uniform magnetic field in Vacuum: density = 1.e-25*g/cm3; pressure = 1.e-19*pascal; temperature = 0.1*kelvin; G4Material* Vacuum = new G4Material(name="Galactic", Z=1.,A=1.01*g/mole, density, kStateGas,temperature,pressure); ............................... magField = new G4UniformMagField(G4ThreeVector(0.,0.,4.*tesla)); fieldMgr->SetDetectorField(magField); fieldMgr->CreateChordFinder(magField); ................................ gun->SetParticleMomentumDirection(G4ThreeVector(0.,1.,0.)); gun->SetParticleEnergy(1.*GeV); The message "G4Transportation is killing track that is looping or stuck This track has 1000 MeV energy." appears AD INFINITUM. It looks like in G4Transportation.cc fParticleChange.ProposeTrackStatus( fStopAndKill ); does not work. The same code works properly in geant4.6.2. What changes in new version? What is the difference between ProposeTrackStatus() method in G4.7.0 and SetTrackStatus() method in G4.6.2 ? Best regards, Andrey

the application of your own field.help me. Keywords: field
by <yelongchun2005>, 03 Mar, 2005

Hi,i think i can get your help

my question is how to use my own field.

class radialEfield is my own electic field,it is not UniformElectricField the below is my own field application ******* myDetconstruct.cc .... #include "radialEfield.hh" #include "G4RunManager.hh" .... Detconstruct::Construct() { ... G4VSolid* counterSolid = new G4Tubs("counterTubs",0.,Radius,HalfWidthOfDec,0.,360.*deg); radialEfield* myElectricField =new radialEfield(650*volt,4.5*mm,0.02*mm); G4EqMagElectricField *myEquation = new G4EqMagElectricField(myElectricField); G4MagIntegratorStepper* myStepper = new G4ClassicalRK4(myEquation,8); G4MagInt_Driver* myIntgrDriver = new G4MagInt_Driver(1.0e-3*mm, myStepper, myStepper->GetNumberOfVariables()); G4ChordFinder* myChordFinder = new G4ChordFinder(myIntgrDriver); G4FieldManager* pFieldMgr = new G4FieldManager(myField,pChordFinder,true); G4LogicalVolume* counterLogical = new G4LogicalVolume(counterSolid,He4,"counterLogical",pFieldMgr,0,0); ... } when compine, the error message: ... compiling Detconstruct.cc... in file included from...\geant4\geant4.6.0.p01\source\run\include\G4RunManager.hh :69 :error:semicolon missing after declaration of'radialEfield'

in file included from...\geant4\geant4.6.0.p01\source\run\include\G4RunManager.hh :69:error:multiple types in one declaration thank you,everyone!

Charge, momentum and mass are not enough to compute the force by Bertalan Juhasz <Bertalan.Juhasz@cern.ch>, 03 Mar, 2005 Dear GEANTers, (Maybe I should sent this to the bug report system, but since strictly speaking this is not a bug but a limitation, I send it here. Hopefully the developers will read it.) The problem is the following: when one wants to calculate the force acting on a particle in an electomagnetic field, one has only the charge, momentum and mass of the particle to use (through the SetChargeMomentumMass(G4double charge, G4double momentum, G4double mass) method of G4EquationOfMotion). However, in case of a neutral particle (in my case on antihydrogen atom) in an inhomogenous magnetic field, there is a force acting on the particle's magnetic moment (which in turn sometimes depends on the magnitude of the field). But since the equation of motion calculation method doesn't know about the magnetic moment, it cannot calculate the force. I solved this problem the following quick-and-dirty way: I modified the SetChargeMomentumMass(G4double charge, G4double momentum, G4double mass) methods of all classes to SetChargeMomentumMass(G4double charge, G4double momentum, G4double mass, G4ParticleDefinition *pDef) i.e. now my equation of motion calculator knows the particle type and thus can access all properties of the particle including its magnetic moment. This way everything works fine. However, I made the modifications in the GEANT classes themselves i.e. I did not derive my own classes (I tried it but failed), so now I should do the modifications every time a new GEANT version comes out. Of course, there could be other workarounds like encrypting the magnetic moment in e.g. the charge (e.g. q = 1.000001 would mean mu = 1 Bohr magneton), but this is not the way it should be. It would be very useful not only for me but for future users as well if SetChargeMomentumMass() would also pass the particle type as a G4ParticleDefinition* pointer (see above) or some other, more elegant way. Maybe this could be implemented in a future release. Thanks, Bertalan

G4Transportation is killing track (Q#45!!!) Keywords: electrons, magnetic field, transportation by Ilya <ilya.kraev@fys.kuleuven.ac.be>, 28 Feb, 2005 Dear GEANTers, I have the same problem as in QUESTION 45. For electrons with energies up to 300 keV in a user defined magnetic field for some events I get a message "G4Transportation is killing track that is looping or stuck. This track has XXX MeV energy" How to treat it and what happens with such events? (e.g. how to calculate the efficiency?) Thanks a lot, Ilya.

Use of Electric Fields in GEANT Keywords: Electric Field - for gases only? by Jason Hayward <jasohayw@umich.edu>, 26 Feb, 2005 I am using a constant electric field in GEANT within solids like silicon and germanium. Was this feature designed for use with solids or gases?

Diapole Magnatic field by <hsanjeewa1@gsu.edu>, 17 Feb, 2005 I am trying to set a diapole magnatic field arround a globe.(Same as Earth's Mag field. Anyone of you can help me on this? Thanx

G4Transportation is killing track... by Valentin Kozlov <Valentin.Kozlov@fys.kuleuven.ac.be>, 02 Feb, 2005 Deal All, using a user magnetic field profile, I frequently get the following message: "G4Transportation is killing track that is looping or stuck" (roughly in 10% cases for 1MeV electrons and 9T central field). - First of all, can one explain a bit more, what can be a reason of such "looping etc"? - Secondly, what exactly happens to this tracks? is the whole event killed or only at certain point this event is stopped? I want to understand it because if, for instance, one needs to estimate the efficiency, how to interpret these type of events? For example, I have 100 initial events, 15 of them are registred in a detector but for 10 I get above mentioned error message, so is the efficiency of registration 15 over 100 or over (100 - 10) = 90 or something else? Thank you, Valentin P.S. Is there any ability to "mark" such cases in order to "look them back" in stored data file?

Electric field array from a TOSCA simulation Keywords: electric field
by G.A.P.Cirrone <G.A.P.Cirrone>, 16 Dec, 2004

Dear All, in order to simulate in all its detail a ionisation chamber I decided to insert in a GEANT4 simulation anot a simple uniform field but an array calculated from a TOSCA simulation. The TOSCA output is an array specifing the electric field value in each point of a given volume.

Inside the GEANT4 examples, the advanced Purg_Mag shows how read and insert a TOSCA file, but in that case the field is a magnetic field.

I tried to insert the TOSCA electric field but with bad results.

** When I run the code with electrons they show a very strange behaviour and this warning are reported:

---> Begin Of Event: 0 G4MagIntegratorDriver::OneGoodStep: Stepsize underflow in Stepper Step's start x=0.470003 and end x= 0.470003 are equal !! Due to step-size= 1.00213e-20 . Note that input step was 0.0100213 G4MagIntegratorDriver::OneGoodStep: Stepsize underflow in Stepper Step's start x=0.0600006 and end x= 0.0600006 are equal !! Due to step-size= 1.04199e-21 . Note that input step was 0.0104199 G4MagIntegratorDriver::OneGoodStep: Stepsize underflow in Stepper Step's start x=0.0800005 and end x= 0.0800005 are equal !! Due to step-size= 1.07168e-21 . Note that input step was 0.0107168 G4MagIntegratorDriver::OneGoodStep: Stepsize underflow in Stepper

** When I run with proton a segmentation fault is produced.

This is my DetectorConstruction.cc in which the TOSCA file (data1.table) is read and then the electric field "should be" activated:

G4ElectricField* myField= new PurgMagTabulatedField3D("data1.table", zOffset);

G4FieldManager *pFieldMgr;

G4MagIntegratorStepper* pStepper;

G4ChordFinder* pChordFinder;

G4EqMagElectricField* fEquation = new G4EqMagElectricField(myField);

G4MagInt_Driver* pIntgrDriver;

G4TransportationManager* pTransportMgr = G4TransportationManager::GetTransportationManager();

G4PropagatorInField* pFieldPropagator;

pFieldPropagator = pTransportMgr -> GetPropagatorInField();

pStepper = new G4ClassicalRK4(fEquation, 8);

pFieldMgr = pTransportMgr -> GetFieldManager();

pFieldMgr -> SetFieldChangesEnergy(true);

pFieldMgr -> SetDetectorField(myField);

pIntgrDriver = new G4MagInt_Driver(0.01 *mm, pStepper, pStepper -> GetNumberOfVariables());

pChordFinder = new G4ChordFinder(pIntgrDriver);

pFieldMgr -> SetChordFinder(pChordFinder);

The code function perfectly if I substitute the line

G4ElectricField* myField= new PurgMagTabulatedField3D("data1.table", zOffset)

with

G4UniformElectricField* myField = new G4UniformElectricField(G4ThreeVector(0,900 *kilovolt/cm, 0));

for an uniform electric field.

Can someone give me some indication on this problem? Thank you very much Pablo Cirrone

A little step to solve my problem Keywords: A little step to address the problem with the Electri Field by G.A.P.Cirrone <G.A.P.Cirrone>, 17 Nov, 2004 Dear all, thanks to the help of Gumplinger and Apostolakis I am in the root to solve my problem. I was able to set an Uniform Electric Field inside the detector construction class of my application but I am not yet able to set a LOCAL electric field. In fact I use the line code below to define the field but I want define the field only in the absorber and not in all the world volume. So I inserted the pointer in the logical volume of the absorber but still the field is in all the world. Here I post all my detectorConstruction with the field definition and the pointer to it in the local absorber. It run but the FIELD IS IN ALL THE WORLD. G4VPhysicalVolume* DetectorConstruction::ConstructVolumes() { // -------------------------------- FIELD --------------------------------- G4UniformElectricField* myField = new G4UniformElectricField(G4ThreeVector(0,900 *kilovolt/cm, 0)); G4FieldManager *pFieldMgr; G4MagIntegratorStepper* pStepper; G4ChordFinder* pChordFinder; G4EqMagElectricField* fEquation = new G4EqMagElectricField(myField); G4MagInt_Driver* pIntgrDriver; G4TransportationManager* pTransportMgr = G4TransportationManager::GetTransportationManager(); G4PropagatorInField* pFieldPropagator; pFieldPropagator = pTransportMgr -> GetPropagatorInField(); pStepper = new G4ClassicalRK4(fEquation, 8); pFieldMgr = pTransportMgr -> GetFieldManager(); pFieldMgr -> SetFieldChangesEnergy(true); pFieldMgr -> SetDetectorField(myField); pIntgrDriver = new G4MagInt_Driver(0.001 *mm, pStepper, pStepper -> GetNumberOfVariables()); //if(pChordFinder) delete pChordFinder; pChordFinder = new G4ChordFinder(pIntgrDriver); pFieldMgr -> SetChordFinder(pChordFinder); //----------------------------------------------------------------- G4GeometryManager::GetInstance()->OpenGeometry(); G4PhysicalVolumeStore::GetInstance()->Clean(); G4LogicalVolumeStore::GetInstance()->Clean(); G4SolidStore::GetInstance()->Clean(); // World // G4Box* sWorld = new G4Box("World", //name worldSizeX/2,worldSizeYZ/2,worldSizeYZ/2); //dimensions G4LogicalVolume* lWorld = new G4LogicalVolume(sWorld, //shape worldMaterial, //material "World"); //name G4VPhysicalVolume* pWorld = new G4PVPlacement(0, //no rotation G4ThreeVector(), //at (0,0,0) lWorld, //logical volume "World", //name 0, //mother volume false, //no boolean operation 0); //copy number // // Absorber // G4Box* sAbsor = new G4Box("Absorber", //name absorSizeX/2,absorSizeYZ/2,absorSizeYZ/2); //dimensions lAbsor = new G4LogicalVolume(sAbsor, //shape absorMaterial, //material "Absorber", pFieldMgr, 0, 0); //name new G4PVPlacement(0, //no rotation G4ThreeVector(), //at (0,0,0) lAbsor, //logical volume "Absorber", //name lWorld, //mother volume false, //no boolean operation 0); //copy number

Insert a local electric field inside GEANT4 Keywords: Local Electric Field insode a simulation
by G.A.P.Cirrone <G.A.P.Cirrone>, 16 Nov, 2004

Dear All, I am tring to add an uniform elctric field inside an element in my detector construction. I read some example and now I am tring inserting in the detectorConstruction class the dollowing lines:

G4double fieldValue = 0.0*kilovolt/cm;

// create electric field

G4UniformElectricField* myField = new G4UniformElectricField(G4ThreeVector(0,fieldValue,0));

// equation of motion G4EqMagElectricField* myEquation = new G4EqMagElectricField(myField);

// stepper for equation of motion G4MagIntegratorStepper* myStepper = new G4ClassicalRK4(myEquation);

// chordfinder G4ChordFinder* myChordFinder = new G4ChordFinder(myField, 1.0e-3*mm, myStepper);

// field manager G4FieldManager* fieldMgr = new G4FieldManager(myField, myChordFinder);

then, during the compilation this error is generated :

Compiling DetectorConstruction.cc ... src/DetectorConstruction.cc: In member function `G4VPhysicalVolume* DetectorConstruction::ConstructVolumes()': src/DetectorConstruction.cc:190: error: no matching function for call to ` G4ChordFinder::G4ChordFinder(G4UniformElectricField*&, double, G4MagIntegratorStepper*&)' /home/cirrone/geant4/geant4.6.2.p01/source/geometry/magneticfield/include/G4ChordFinder.hh:155: error: candidates are: G4ChordFinder::G4ChordFinder(const G4ChordFinder&) /home/cirrone/geant4/geant4.6.2.p01/source/geometry/magneticfield/include/G4ChordFinder.hh:57: error: G4ChordFinder::G4ChordFinder(G4MagneticField*, double, G4MagIntegratorStepper*) /home/cirrone/geant4/geant4.6.2.p01/source/geometry/magneticfield/include/G4ChordFinder.hh:53: error: G4ChordFinder::G4ChordFinder(G4MagInt_Driver*) gmake: *** [/home/cirrone/geant4/workdir/tmp/Linux-g++/TestEm7/DetectorConstruction.o] Error 1

Can anyone help me? I sow other people with the same error related to the G4Finder with an electric field.

Should be a good idea put an example with the simulation of an

LOCAL ELECTRIC FIELD

what about?

cheers

Pablo

Electric Field does not change electron energy? Keywords: Electric Field does not change electron energy? by Emil Frlez <Emil Frlez>, 26 Oct, 2004 Dear GEANT4 practitioners, I have a question about charge particle tracking in a combined magnetic and electric field. Two years ago, with the GEANT4.4.2 version I was using the code to track 1 MeV electron in a uniform magnetic field. Problem then was that e- was (nonphysically) changing energy while tracked in the B field. Now, I am using GEANT4.6.2.p01, and, after studying Fermilab Beam Tools classes and their MuCool example, think that I know how to write a user code to track a particle in the combined EM field. When I examine the visualized electron track and dump the coordinates, energies, global times, etc at the each step into a file and study it offline, it seems that my code now does the proper tracking. Except for one thing: the kinetic energy is now always unchanged, even with the sizable electric field! I used the modified examples/extended/electromagnetic/TestEm5 as a template. Beam Tools correspond to GEANT4.5 version, but my code compiles without any warning. I set explicitly fieldMgr->SetFieldChangesEnergy(true), as is done in Beam Tools, even though I cannot find SetFieldChangesEnergy function anywhere in the current sources ;8-( I will try to compile and run some Electric field examples in ~/geant4.6.2.p01/examples/extended/field/*, but maybe there is someone out there who can point to my obvious mistake and save me some time in debugging ;8-) Why 30 kV/cm electric field has no effect on the energy of 1 MeV e- over several meters path? Best Regards, Emil Frlez Here is the summary, 1 MeV e- in E & B fields: In DetectorConstruction.cc I define: G4VPhysicalVolume* DetectorConstruction::Construct() { //------------------------------------------------------------------------- // AbBA ElectroMagnetic field //------------------------------------------------------------------------- G4double newValue = 2.5E-1*mm; static G4bool fieldIsInitialized = false; if(!fieldIsInitialized) { abBAField* myField = new abBAField; G4EqMagElectricField *fEquationE = new G4EqMagElectricField(myField); // Get transportation, field, and propagator managers G4TransportationManager *pTransportMgr= G4TransportationManager::GetTransportationManager(); G4FieldManager* fieldMgr = pTransportMgr->GetFieldManager(); G4PropagatorInField *pFieldPropagator= pTransportMgr->GetPropagatorInField(); G4double newEpsMin=2.5e-7; G4double newEpsMax=0.05; pFieldPropagator->SetMinimumEpsilonStep(newEpsMin); pFieldPropagator->SetMaximumEpsilonStep(newEpsMax); // Need to SetFieldChangesEnergy to account for a electric field fieldMgr->SetFieldChangesEnergy(true); G4MagIntegratorStepper *pStepper = new G4ClassicalRK4(fEquationE,8); // Set the field fieldMgr->SetDetectorField(myField); // Create a cord finder providing the (global field, min step length, // a pointer to the stepper) G4ChordFinder* pChordFinder = new G4ChordFinder( myField, 0.01*mm,pStepper); fieldMgr->SetChordFinder(pChordFinder); //fieldMgr->CreateChordFinder(myField); fieldMgr->GetChordFinder()->SetDeltaChord(newValue); fieldIsInitialized = true; } } I define field derived from G4MagneticField class in abBAField.cc, namely abBAField::abBAField() {;} abBAField::~abBAField() {;} void abBAField:: GetFieldValue(const double Point[4], double *Bfield) const { for (G4int kk=0; kk<6; kk++) Bfield[kk]=0.; // initialize field to zero Bfield[0] = 2. * tesla; Bfield[1] = 0.; Bfield[2] = 0.; Bfield[3] = 30.*kilovolt/cm; Bfield[4] = 0.*kilovolt/cm; Bfield[5] = 0.*kilovolt/cm; }

Local magnetic field with geant4.6.2 Keywords: local magnetic field by Laihem <Laihem>, 19 Oct, 2004 Hi, I still have my magnetic field global and not local... is there any bug or conflict somewhere. I did all what I can do to figure out and to set a magnetic field locally into a specific volume by following example "extended/field/field03" which is the only one showing how to relate a magnetic field locally to a specific logical volume but still it does not work.... my magnetic field is global to the world. I working on it since 2 weeks and I can not see what is missing. Any help ?? klaihem.

Setting a local magnetic Field Keywords: local magnetic field by Laihem <Laihem>, 11 Oct, 2004 Hi, I would like to set a magnetic field into a specific Volume of my setup but it seems that the magnetic field is everywhere in the World volume, I have followed in the exact way as done in the example: example/extended/field03 by setting for example: G4bool allLocal = false ; LogicalSpectroBoxInMag02->SetFieldManager( fEmField->GetLocalFieldManager(), allLocal ) ; even in I put the boolean variable to True it does not work.... and the rest is like example example/extended/field03 So, the result is that my magnetic field is not local but global and applied to the whole world. Is there any problems in this example or something is missing in my code. thanks a lot in advance for any help. klaihem

ElectricField ? Keywords: electric field chordfinder by Daniel Barna <Daniel Barna>, 28 Sep, 2004 Hi I want to use a pure electric field in my detector. This should be pretty straightforward, and in fact, there is also an example code in the tutorial. However, it does not compile. I quote this code below (http://geant4.web.cern.ch/geant4/G4UsersDocuments/UsersGuides/ForApplicationDeveloper/html/Detector/electroMagneticField.html) The problematic line is 'pChordFinder=new G4ChordFinder(&myElectricField,...)' because G4ChordFinder's constructor (to my greatest surprise) expects a G4MagneticField* as its first argument. That is, if my electric field is derived from G4ElectricField (as I assume it should be), then the code does not compile. So did I do something wrong (should I derive my electric field from G4MagneticField), or is the tutorial bad? Thanks Daniel #include "G4EqMagElectricField.hh" #include "G4UniformElectricField.hh" ... { // Part of detector description code G4FieldManager *pFieldMgr; G4MagIntegratorStepper *pStepper; G4EqMagElectricField *fEquation = new G4EqMagElectricField(&myElectricField); pStepper = new G4ClassicalRK4( fEquation ); // or = new G4SimpleHeum( fEquation ); // Set this as a global field pFieldMgr= G4TransportationManager::GetTransportationManager()-> GetFieldManager(); pFieldMgr->SetDetectorField( &myElectricField ); pChordFinder = new G4ChordFinder( &myElectricField, 1.0e-2 * mm, // Minimum step size pStepper); pFieldMgr->SetChordFinder( pChordFinder ); }

Electric Field does not work... Keywords: Electric Field by Dai ho Ko <kodainim@hotmail.com>, 29 Aug, 2004 Hello! I've tried to set e-field to local area. So I've made next 2 files(Shown in part).. --------------------------------------------------------------------------- #include "ExN03Field.hh" ExN03Field::ExN03Field() { Bz = 3000*kilovolt/cm; } ExN03Field::~ExN03Field() {;} void ExN03Field::GetFieldValue(const double Point[3],double *Bfield) const { Bfield[0] = 0.; Bfield[2] = 0.; if(Point[2]>0.0 ) { Bfield[1] = Bz; } else { Bfield[1] = 0.; } } ---------------------------------------------------------------------- ExN03Field* myField = new ExN03Field; //G4UniformElectricField* myField //= new G4UniformElectricField(G4ThreeVector(0,90000*kilovolt/cm,0)); G4FieldManager *pFieldMgr; G4MagIntegratorStepper *pStepper; G4ChordFinder* pChordFinder; G4EqMagElectricField *fEquation = new G4EqMagElectricField(myField); G4MagInt_Driver* pIntgrDriver; pStepper = new G4ClassicalRK4(fEquation,8); pFieldMgr=G4TransportationManager::GetTransportationManager()-> GetFieldManager(); pFieldMgr->SetDetectorField(myField); pIntgrDriver = new G4MagInt_Driver(0.001*mm,pStepper,pStepper-> GetNumberOfVariables()); //if(pChordFinder) delete pChordFinder; pChordFinder = new G4ChordFinder(pIntgrDriver); pFieldMgr->SetChordFinder(pChordFinder); ------------------------------------------------------------------ Whenever I use 'ExN03Field* myField = new ExN03Field;' statement, exe file doen't work. No error occurs, compiling is OK, but does not work. It stops when it deals with first particle. But when I use 'G4UniformElectricField* myField = new G4UniformElectricField(G4ThreeVector(0,90000*kilovolt/cm,0));' statement exe file works. Did I miss some statements? It's been making me crazy fot 3 days... Thanks in advance.

Setting up a gravity field Keywords: field gravity motion chord by <Julian.Bunn@caltech.edu>, 23 Aug, 2004 I'm trying to build a Geant4 application that will track small dust particles under the influence of (Martian) gravity. To do this I have first created a G4GravityField class that inherits from G4Field. Then I have created a G4Gravity_EqRhs class that inherits from G4EquationOfMotion, and which will eventually take care of computing the motion. Next I wanted to set up the Chord Finder for use with my new gravity field. fChordFinder = new G4ChordFinder( fGravityField, fMinStep, fStepper); but G4ChordFinder does not like my field argument: it expects a G4MagneticField, perhaps not unexpectedly (?) Am I now faced with creating a new G4ChordFinder class, or am I approaching this the wrong way? Any tips or advice are most welcome. I am a complete novice with Geant4 so please be gentle :-) Julian

Volume name inside magnetic field class by Zarko Pavlovic <zarko@mail.hep.utexas.edu>, 10 Aug, 2004 Hi, I want to find the volume in which the particle is in from within the magnetic field class, so I can find how far from the boundary is the particle. My magnetic field depends on that. When I try to do that using: G4ThreeVector pos(Point[0],Point[1],Point[2]); G4Navigator* theNavigator=G4TransportationManager::GetTransportationManager()-> GetNavigatorForTracking(); G4VPhysicalVolume* current_pos_Vol=theNavigator->LocateGlobalPointAndSetup(pos); something is not working properly. For example I have the step size limit set to some small value inside the same volumes that have field attached. With the above code inserted I see that my step size limit is not restricted only to the volumes that it is assigned to anymore. Also, if I output the volume name from the stepping action class and from magnetic field class they don't match. I consider only the first volume outputed from magnetic class after the step output. Is there any other way I could find the distance from boundaries? Thanks, Zarko PS I'm using g3tog4 to build geometry.

Step size in Magnetic Tracking by Dvorak <Dvorak>, 03 Aug, 2004 Hello, I'm trying to track an electron in an magnetic field. I use the following code in the DetectorConstrction class to set the magnetic field: G4UniformMagField* magField = new G4UniformMagField(G4ThreeVector(0.,1.*gauss,0.)); G4FieldManager *pFieldMgr; G4MagIntegratorStepper *pStepper; G4EqMagElectricField *fEquation = new G4EqMagElectricField(magField); pStepper=new G4ClassicalRK4(fEquation); pFieldMgr=G4TransportationManager::GetTransportationManager()->GetFieldManager(); pFieldMgr->SetDetectorField(magField); // pFieldMgr->CreateChordFinder(magField); G4MagInt_Driver* fIntgrDriver; G4double fMinStep = 0.010*mm; fIntgrDriver = new G4MagInt_Driver(fMinStep, pStepper, pStepper->GetNumberOfVariables() ); G4ChordFinder *pChordFinder = new G4ChordFinder(fIntgrDriver); pFieldMgr->SetChordFinder(pChordFinder); AND the following code for an incoming electron in PrimaryGeneratorAction: G4ParticleTable* particleTable = G4ParticleTable::GetParticleTable(); G4String particleName; G4ParticleDefinition* particle = particleTable->FindParticle(particleName="e-"); particleGun->SetParticleDefinition(particle); particleGun->SetParticleMomentumDirection(G4ThreeVector(1.,0.5,0.)); particleGun->SetParticleEnergy(5.*MeV); G4double position = 0; //-0.5*(ExN03Detector->GetWorldSizeX()); particleGun->SetParticlePosition(G4ThreeVector(position,0.*cm,0.*cm)); particleGun->GeneratePrimaryVertex(anEvent); I'm expecting a spiral track but I always get errors. When the fMinStep is small, I get: G4MagIntegratorDriver::OneGoodStep: Stepsize underflow in Stepper Step's start x=0.22 and end x= 0.22 are equal !! Due to step-size= 5e-18 . Note that input step was 0.05 G4MagIntegratorDriver::OneGoodStep: Stepsize underflow in Stepper Step's start x=0.23 and end x= 0.23 are equal !! Due to step-size= 5e-18 . Note that input step was 0.05 ... ... When the fMinStep is big(>10cm), or I use the FieldManager->CreateChordFinder instead of the manual ChordFinder, it tells me that the Track Was killed becasue it is loop or stucked. What's wrong with my program? Thanks. -Dvorak

Tracking in magnetic field Keywords: tracking by Jens Hasper <hasper@ikp.tu-darmstadt.de>, 19 Jun, 2004 Hi, I'm using Geant4 to track electrons in a magnetic field, which I implemented in the GetFieldValue-funtion. I'm having kind of a strange problem now. Below a certain energy of the electrons, these electrons are not tracked any more. I have visualized my setup and it looks as if the electrons are reflected by an invisible wall before they even get into the magnetic field. To analyse this problem I wrote down the field values, Geant4 asks for when the GetFieldValue-Function is used. The funny thing is, that these value look perfect and they fit quite nicely to the track of the electron I expect. That's strange because the electrons on the other side never enter the magnetic field. I prooved that by giving an output, whenever the electrons enter the magnetic field. But in that case, I received no output. Any idea, where there could be a conflict and how to solve this problem? Thanks a lot, Jens Hasper

BlineTracer use Keywords: magnetic field lines BLineTracer
by Valentin Kozlov <Valentin.Kozlov@fys.kuleuven.ac.be>, 25 May, 2004

Dear All,

Recently I installed G4 6.1 where there is an utility BLineTracer to visualize the magnetic field lines. To implement it I simply copied the header files and source files in the directory of my program and included following strings:

#include "G4BlineTracer.hh" G4BlineTracer* theBlineTool = new G4BlineTracer(); (last one in the constructor of my B-field class)

but during compilation I get the following error message:

Compiling G4BlineTracer.cc ... src/G4BlineTracer.cc: In method `G4BlineTracer::~G4BlineTracer()':

src/G4BlineTracer.cc:74: invalid use of undefined type `class G4ChordFinder'

include/G4BlineTracer.hh:54: forward declaration of `class G4ChordFinder'

src/G4BlineTracer.cc: In method `void G4BlineTracer::ComputeBlines(int)':

src/G4BlineTracer.cc:143: invalid use of undefined type `class G4ChordFinder'

include/G4BlineTracer.hh:54: forward declaration of `class G4ChordFinder'

src/G4BlineTracer.cc: In method `void G4BlineTracer::ResetChordFinders()':

src/G4BlineTracer.cc:269: invalid use of undefined type `class G4ChordFinder'

include/G4BlineTracer.hh:54: forward declaration of `class G4ChordFinder'

src/G4BlineTracer.cc:292: `G4MagInt_Driver' undeclared (first use this function)

src/G4BlineTracer.cc:292: (Each undeclared identifier is reported only once

src/G4BlineTracer.cc:292: for each function it appears in.)

src/G4BlineTracer.cc:292: `pIntgrDriver' undeclared (first use this function)

src/G4BlineTracer.cc:293: parse error before `('

src/G4BlineTracer.cc:294: invalid use of undefined type `class G4ChordFinder'

include/G4BlineTracer.hh:54: forward declaration of `class G4ChordFinder'

src/G4BlineTracer.cc:291: warning: unused variable `class G4CashKarpRKF45 * pStepper'

src/G4BlineTracer.cc:318: parse error before `('

src/G4BlineTracer.cc:319: invalid use of undefined type `class G4ChordFinder'

include/G4BlineTracer.hh:54: forward declaration of `class G4ChordFinder'

src/G4BlineTracer.cc:316: warning: unused variable `class G4CashKarpRKF45 * pStepper'

gmake: *** [/home/valentin/tmp/Linux-g++/exampleN03/G4BlineTracer.o] Error 1

*** failed ***

What can be wrong and did somebody succefully use this nice utility already? Thank you!

Valentin

Implementation of magnetic field from a table of values Keywords: field, table by Jens Hasper <hasper@ikp.tu-darmstadt.de>, 20 May, 2004 Hi, I would like to implement a magnetic field I have simulated so far. That means I'm having a table of field values and would like to use them for tracking particles in Geant4. What is the best way to do so? Do I have to implement the interpolation between the points myself and then use GetFieldValue() or is there a more elegant way, Geant4 supports? Thanks for your help, Jens Hasper

Field definition and its relation to geometry Keywords: GEANT, fields definition, geometry by Ilya <ilya.kraev@fys.kuleuven.ac.be>, 10 May, 2004 Dear GEANT team, I have a following problem in understanding how the defenition of a magnetic (or any other) field is connected with real detector's geometry. Let's say I have to define a magnetic field from an existing field map. In my MyField class derived from G4MagneticField I create e.g. two arrays (one for axial and one for radial field) that define the particular field. After that I create in MyDetectorGeometry class that field as it's shown in the examples. But where do I define how the field read from field map relates to real geometry? If the reference point is (x=0,y=0,z=0) then how GEANT knows what elements of arrays defined by me in MyField class correspond to the (r,z)-point in real geometry? Or is there some convention of the defining filed maps? I did not find any explanation in the Documentation and there is no simple example in the GEANT Examples, Thanks, Ilya

What are y and dydx in the equation of motion? by Bertalan Juhasz <Bertalan.Juhasz@cern.ch>, 07 Apr, 2004 Hi GEANTers, Can someone tell me what are the y and dydx vectors _and what are their units_ in the EvaluateRhsGivenB method of the equation of motion classes? The toolkit developers guide and the comments in the source code seem to contradict each other, if they specify something at all. I need to know these because I have to send neutral antihydrogen atoms through sextupole magnetic fields where the force acts on the magnetic moment so I have to create new equations of motion. Thanks in advance, Bertalan

Need help implementing a radial electric field Keywords: radial electric field by Andrew Dummer <Andrew Dummer>, 18 Mar, 2004 I am interested in simulating a Geiger-Mueller Tube but that means that I need to implement a radial electric field. All I can find are discussions of uniform electric fields. Mine is a nonuniform field. The solution for the electric field within the detector is easily determined to be: E(r)=V/(r*ln(b/a)) Where V is the voltage applied, b and a are the inner radius of the tube and the outer radius of the anode wire respectively. What is not at all obvious to me is how to implement this within the constructs of GEANT4. Are there any good examples of something like this? Can anyone give me some pointers? Thanks. drew

Low energy electrons in electric field Keywords: electric field, low energy electrons by Emmanuel Moulin <Emmanuel Moulin>, 19 Jan, 2004 Hi Geant4 users, I would like to track low energy electrons (500 eV or less) in an uniform electric field. Is it possible? Which stepper do I use? Thanks in advance.

Cosmic Ray Flux Keywords: Cosmic Rays by annamaria <annamaria>, 17 Nov, 2003 Hi! I'm working on a simulation of a magnetic spectrometer composed by six layers of silicon detectors in a magnetic field. I need to simulate the cosmic ray flux generated on a plane parallel to the layers, with a given distribution in energy (uniform in logaritmic scale) and in a solid angle. Can you help me please? Thanks a lot Annamaria Galante

Magnetic Field in a volume Keywords: magnetic field volume by Nuno Fiuza de Barros <Nuno Fiuza de Barros>, 08 Jul, 2003 I want to create a magnetic field inside a volume. How can i do this? All examples only show how to make a "global" magnetic Field. Thanks in advance Nuno Barros

tracking in magnetic field by michel maire <michel maire>, 30 May, 2003 tracking in magnetic field violates the energy conservation. See problem reporting #495

How to specify the volume applied an uniform electric field? by Toru Kawashima <Toru Kawashima>, 13 Mar, 2003 Hi GEANT4 users, I'm trying to specify the volume applied an uniform electric field using the G4UniformElectricField class object. First, I saw an example code, "extended/field/field02". And I think I know how to introduce an uniform electric field into the whole of "World" volume. But, I don't know to specify the volume which applied the field. Thanks for your help!

Appendix of Geant 3 for medical purposes by Nik Y. Karaseff <arisgrup@comail.ru>, 15 Nov, 2002 I wonder if the appendix for Geant 3 to calculate medical energies exists in nature? Please help me: i don't want install Geant 4 , but wish use already installed Geant 3 to make calculations with medical energies.

Why electron increases in energy when traveling in uniform magnetic field? by Emil Frlez <Emil Frlez>, 30 Aug, 2002 Dear GEANT4 experts, before trying a simulation of detector in a combined electromagnetic field, I tried a simpler case I am interested in: Particle: 1.0 MeV e- Field: Uniform magnetic field along x axis, 4.0 tesla Detector: 2mm silicon I modify somewhat Em5 example, and also have a look at N04 novice example for the magnetic field definition. My problem: the energy deposited in Si detector is greater then the starting kinetic energy of electron. I print out the kinetic energy of e- and its position at every step and see the electron gains energy in the uniform magnetic field. Is this a bug? I get the same behavior using void Em5Field::GetFieldValue(const double Point[3],double *Bfield) const to set a field value (as in N04), and void Em5DetectorConstruction::SetMagField(G4double fieldValue) to set a field value (as in Em5 example). The increase in energy apparently depend on the initial momentum direction of e-. I am trying to see what is a reason for (unphysical) boost in kinetic energy. Is this due to rounding errors in tracking or ...? Should I set some step size to a smaller value to increase a tracking precision? Because I will be eventually interested in simulating the neutron beta decay electron (with a maximum energy 0.8 MeV) detected in a Si counter after traveling ca. 1.5 meters in ~4 tesla magnetic field, this behavior obviously renders the simulation unusable... Am I missing something? Cheers, Emil frlez@virginia.edu P.S. Here is kinetic energy in MeV in first column followed by position of e- in mm, until e- stops in 2 mm of Si centered at x=150 cm Initial energy: 1.0 MeV, deposited energy: 1.08308 MeV ---> Begin of Event: 0 1 KinEn e- (0.70713,0.62626,0.28086) mm 1.0001 KinEn e- (1.4142,0.83297,0.93536) mm 1.0001 KinEn e- (2.1213,0.48164,1.525) mm 1.0002 KinEn e- (2.8284,-0.1924,1.6548) mm 1.0002 KinEn e- (3.5354,-0.73762,1.2377) mm 1.0003 KinEn e- (4.2424,-0.78879,0.55319) mm 1.0003 KinEn e- (4.9494,-0.31162,0.059663) mm 1.0003 KinEn e- (5.6564,0.37432,0.087722) mm 1.0004 KinEn e- (6.3634,0.80963,0.6186) mm 1.0004 KinEn e- (7.0703,0.70277,1.2968) mm 1.0005 KinEn e- (7.7772,0.12529,1.6681) mm 1.0005 KinEn e- (8.4841,-0.53615,1.484) mm 1.0005 KinEn e- (9.191,-0.83866,0.86757) mm 1.0006 KinEn e- (9.8978,-0.57967,0.23164) mm 1.0006 KinEn e- (10.605,0.067433,0.0019294) mm 1.0007 KinEn e- (11.311,0.66946,0.33224) mm 1.0007 KinEn e- (12.018,0.82339,1.0015) mm 1.0008 KinEn e- (12.725,0.42617,1.5617) mm 1.0008 KinEn e- (13.432,-0.25635,1.6379) mm 1.0008 KinEn e- (14.138,-0.76736,1.179) mm 1.0009 KinEn e- (14.845,-0.76485,0.49222) mm 1.0009 KinEn e- (15.552,-0.25048,0.037082) mm 1.001 KinEn e- (16.258,0.43157,0.11819) mm 1.001 KinEn e- (16.965,0.82489,0.68129) mm 1.001 KinEn e- (17.672,0.66631,1.3496) mm 1.0011 KinEn e- (18.378,0.061903,1.676) mm 1.0011 KinEn e- (19.085,-0.58398,1.4421) mm 1.0012 KinEn e- (19.791,-0.83925,0.80435) mm 1.0012 KinEn e- (20.498,-0.53312,0.18935) mm 1.0013 KinEn e- (21.204,0.12966,0.0084996) mm 1.0013 KinEn e- (21.911,0.70578,0.38279) mm 1.0013 KinEn e- (22.617,0.8099,1.0619) mm 1.0014 KinEn e- (23.324,0.37237,1.5917) mm 1.0014 KinEn e- (24.03,-0.31423,1.6178) mm 1.0015 KinEn e- (24.736,-0.79077,1.1228) mm 1.0015 KinEn e- (25.443,-0.73858,0.4376) mm 1.0015 KinEn e- (26.149,-0.19254,0.020422) ..... deleted ..... 1.0831 KinEn e- (1498.4,0.51728,1.6226) mm 1.0831 KinEn e- (1499,-0.11084,1.7409) mm 0.83218 KinEn e- (1499.7,-0.36039,1.6732) mm 0.6459 KinEn e- (1499.9,-0.80863,1.2929) mm 0.43104 KinEn e- (1499.7,-0.49025,1.396) mm 0.27809 KinEn e- (1499.8,-0.70194,1.4364) mm 0.13182 KinEn e- (1499.9,-0.79351,1.544) mm 2.6926e-11 KinEn e- (1499.9,-0.8145,1.5381) mm Run terminated. Run Summary Number of events processed : 1 User=0.23s Real=0.29s Sys=0s ================== run summary ===================== end of Run TotNbofEvents = 1 mean charged track length in absorber=2.83012 +- 0 mm mean energy deposit in absorber=1.08308 +- 0 MeV

tracking in general electric and magnetic field by Emil Frlez <Emil Frlez>, 28 Aug, 2002 Dear GEANT4 practitioners, I wander if anybody has a complete example of the GEANT4 simulation of the detector in the combined electric and magnetic fields. The default GEANT4 examples provide cases with either electric or magnetic fields, but not both. I think it would be very useful to have a general example available to the public. I would like to simulate the tracking in a constant electric and variable magnetic field. The short write-up/design philosophy under " Geant4 User's Guide - For Toolkit Developers: Tracking" is just not detailed enough for me to see how is tracking in an E-M field implemented in practice. Thanks in advance, Emil frlez frlez@virginia.edu

Segmentation fault (core dumped) happened in different material and more beams Keywords: Segmentation fault (core dumped) happened in different material and more beams
by Lam Yihua <Lam Yihua>, 19 Jun, 2002

dear programmer, How's your life there? Sorry, for disturbing you all... My experimental detector named as "innerchamber" and it can be filled in with either one of them: 1) Aluminum 2) Deuterium 3) Plumbum 4) Uranium 5) ArgonGas Then I used neutron as the initial particle to shoot on the target "innerChamber". Neutrons will fly from a volume named as "vacumm" to "innerChamber". The physics processes are neutron inelastic, elastic and capture. These 3 processes I added in as "discreteprocess". Below is the code from class "detector construction". ooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo G4VPhysicalVolume* ExN01DetectorConstruction::Construct() { .. .... G4Material* Vacuum = new G4Material("Vacuum", 1.0 , 1.01*g/mole, 1.0E-25*g/cm3, kStateGas, 2.73*kelvin, 3.0E-18*pascal ); ...... ......... //Plumbum a = 207.19*g/mole; density = 11.35*g/cm3; G4Material *Plumbum = new G4Material(name="Lead", z=82., a, density); //Argon gas a = 39.95*g/mole; density = 1.782e-03*g/cm3; G4Material *ArgonGas = new G4Material(name="ArgonGas", z=18., a, density); //Aluminum a = 26.98*g/mole; density = 2.7*g/cm3; G4Material Aluminum = new G4Material(name="Aluminum", z=13., a, density); ... // Deuterium G4Material* Deuterium = new G4Material(name="DeuteriumGas", density, ncomponents=2, kStateGas,temperature,pressure); Deuterium->AddElement(D, natoms=1); Deuterium->AddElement(D, natoms=1); .... ... ... G4LogicalVolume* innerChamber_log = new G4LogicalVolume (innerChamber_tub, //Pb, //U, Aluminium, //ArgonGas, //Deuterium, // CondensedPlasmaDeuterium, "innerChamberLog", 0, 0, 0); ... ... return experimentalHall_phys; } ooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo MY PROBLEM IS: when I used ArgonGas the material of "innerChamber", I can successfully simulated 1 neutron to penetrate into "innerChamber". But I'll get the segmentation fault error below if I used 20 neutrons... :( ooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo A new track 0x8085d60 (trackID 2, parentID 1) is passed to G4StackManager. ### pop requested out of 2 stacked tracks. Selected G4StackedTrack : 0x8090c60 with G4Track 0x8085d60 (trackID 2, parentID 1) Track 0x8085d60 (trackID 2, parentID 1) is passed to G4TrackingManager. ********************************************************************************************************* * G4Track Information: Particle = K39[0.0], Track ID = 2, Parent ID = 1 ********************************************************************************************************* Step# X(mm) Y(mm) Z(mm) KinE(MeV) dE(MeV) StepLeng TrackLeng NextVolume ProcName 0 147 2.59 0.461 0.337 0 0 0 innerChamber initStep >>DefinePhysicalStepLength (List of proposed StepLengths): Segmentation fault (core dumped) ooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo Before the program go in core dumped, it can plot "yz position graph" (like XrayTel), but once the neutron start to go into "innerChamber", Segmentation fault happened... :( The below is the segmentation fault error, when I change ArgonGas to Aluminum, Plumbum, Uranium. The program can't even simulate 1 neutron. And segmentation fault error prompt our when neutron go in "innerChamber"... :( The program can run without any error, If I used "Deuterium" as the material filled in the "innerChamber". ooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo A new track 0x8085d60 (trackID 2, parentID 1) is passed to G4StackManager. ### pop requested out of 1 stacked tracks. Selected G4StackedTrack : 0x8090c40 with G4Track 0x8085d60 (trackID 2, parentID 1) Track 0x8085d60 (trackID 2, parentID 1) is passed to G4TrackingManager. ********************************************************************************************************* * G4Track Information: Particle = alpha, Track ID = 2, Parent ID = 1 ********************************************************************************************************* Step# X(mm) Y(mm) Z(mm) KinE(MeV) dE(MeV) StepLeng TrackLeng NextVolume ProcName 0 60 -0.944 -2 0.463 0 0 0 innerChamber initStep >>DefinePhysicalStepLength (List of proposed StepLengths): Segmentation fault (core dumped) Is it due to Swap Area??? http://erpc1.naruto-u.ac.jp/~geant4/betadocs/inst2linux/node2.html I'm using 500 Mb as my Linux Swap, and 192 Mb memory. the core dump is almost 130 Mb, or perhaps, some other problems. Please Help me... :) kindly regards, yihua

Field profile in GEANT4 Keywords: magnetic field profile field non-uniform field in certain volume by Valentin Kozlov <Valentin.Kozlov@fys.kuleuven.ac.be>, 18 Jun, 2002 Hello everybody, I know that in GEANT it is possible to put the real field profile (measured points) but how to do it? Does somebody have a nice example? The way which I see for a moment is to use GetFieldValue() function and to make the interpolation between the points. For that I am going to look on Example N04. The second question. I can describe a uniform magntic field for whole set-up. In my ideal case I have a combination of two uniform magnetic fields: one 9T and one 0.1T. The first is in one cylindre and second in other one, connected to the first one. ________ | | | | | | | | 0.1T | | | | | | -- -- | | | | 9T | | ---- So, can I define magnetic field for certain volumes and can GEANT calculate the field between these volumes itself? Best regards, Valentin

Magnetic Field in Volume filled with 'Galactic' Keywords: tracking vacuum galactic by Gumplinger Peter <Gumplinger Peter>, 23 Apr, 2001 I concur with problem report #210 in that GEANT4 seems unable, at present, to track in regions filled with vacuum (i.e.'Galactic'). Is this a problem in the code, or are we simply ignorant in how to initialize G4 in such circumstances with 'user step limits' etc.? Help!

Add Message

to: "Fields: Magnetic and Otherwise"