Creating non-uniform electric field

Morning Chris. Thanks for replying.

I managed to edit the PurgMagTabulatedField.cc and .hh appropriately and change them from magnet field to electric field and import them into field02 and successfully compile and link them.

I’ve called F02TabulatedField (formerly PurgMagTabulatedField) from F02ElectricField by substituting it for the G4UniformElectricField constructor. Using the field map from the Purge_Magnet example (PurgMag3D.TABLE. I know that the physics will be wrong) I was hoping to see some of the field when I set /vis/scene/add/electricField. However nothing is apparent. I also see the dreaded " No Electric field in this extent" warning.

Assuming that my modified code is working how do you go about finding the imported field (whether E-field or Magnetic field)? The majority of the extent of the field in PurgMag3D is within the “world” as defined in my modified field02 example. Need all the field be in the world for it to be displayed?

I’ve attached my files.
F02ElectricFieldSetup.cc (9.6 KB)
F02TabulatedField3D.cc (10.4 KB)
F02ElectricFieldSetup.hh (4.0 KB)
F02TabulatedField3D.hh (2.8 KB)

It seems I have to investigate the parsing of the COMSOL generated file. I hate parsing :frowning:

Don’t fuss for the moment. I’ll tweak F02TabulatedField so it can read my COMSOL file and, hopefully, the field will be visible in G4.

Hi Tim,
I won’t fuss for the moment, but I did help a chap with setting up electric fields a while ago. The message exchange might be of help. This link should take you there:
https://geant4-forum.web.cern.ch/t/re-creating-non-uniform-electric-field/4691

Best Wishes
Chris

Thanks Chris. Unfortunately that thread has either been wiped or is private.

Hi Tim,
I too got that message, but once I logged in I could see the thread. Anyway, I will copy and paste the thread below. If you want to see the files, let me know and I will try to locate them again.
Chris

Dear Chris Walker,

I read your post “Creating non-uniform electric field” becouse I have your same problems. In details, I create with Comsol an electric field map in my geometry and I use purging magnet example to implement the field, also I modify the purging magnet code to introduce the electric field using hadrontheray example. When I use /vis/scene/add/electricField command I get the message: No Electric field in this extent.
Could you please explain me how you modify your code to solve this problem?
thank you in advance.
Kind regards

Luigi Rinaldi

Hi Luigi,
Sorry, but I got mixed up in how to reply to your message.
I have seen your message, but I am struggling to remember what I did. I note the error message originates here:

modeling/src/G4VFieldModel.cc: G4cout << “No " << fTypeOfField << " field in this extent.” << G4endl;

Basically what happens is that each defined point is checked to make sure that it is inside the current extent. If no points are located within the extent, that message appears. I forget the command, but you can zoom out, and maybe that is all you need to do to increase the size of the extent.

I created a simple model starting with the B1 example and then added an electric field to that. I could dig out that example and send it to you if that helps ?

Best Wishes
Chris

Hi Chris,
thank you for your answer and your advice, now I’ll check the extent’size. Also I created my model starting from example B1. I would be very grateful if you could send me your example.
Best regards

Luigi

Hi Luigi,
I discovered that I put a whole load of other code in my program before I added the electric field. I would guess that you wouldn´t want that, so I just send you the stuff to do with the electric field. It´s possible that I left something out, so get back to me if you have more questions. I note that in order to view the field I used the command
/vis/scene/add/electricField
also there are some commands added via the Messenger class (taken from the F02 example), but when I tried the getField command, my program crashed ! So don´t expect perfection - it´s just for you to get some ideas. The data files for the electric field were generated in COMSOL. I needed several files to generate electric fields at different scales from nm to mm or cm.
By the way, I got to a point where I had some errors telling me that a routine had been called which should only be called when the electron is at a boundary. However, a warning was given as the electron was not at a boundary when the routine was called. I wasn´t sure what caused the problem, but I never got past that issue. If it occurs for you - let me know.
Best Wishes
Chris

F02ElectricFieldSetup.cc (11.2 KB) F02ElectricFieldSetup.hh (3.9 KB) F02FieldMessenger.cc (5.6 KB) F02FieldMessenger.hh (2.8 KB) PurgMagTabulatedEField3D.cc (28.3 KB) PurgMagTabulatedEField3D.hh (3.3 KB) Topografiner1mm_v2b.txt (572.4 KB) Topografiner1um_v2b.txt (500.4 KB) Topografiner10mm_v2b.txt (538.3 KB) Topografiner10um_v2b.txt (526.2 KB) Topografiner25mm_v2b.txt (167.7 KB) Topografiner100um_v2b.txt (545.2 KB) TopografinerElectricField_10_1_v2b.txt (517.0 KB) TopografinerElectricField_10_2_v2b.txt (562.3 KB) TopografinerElectricField_10_3_v2b.txt (71.6 KB)

Hi Chris,
I really want to thank you for your help, I fixed my code and now I see the electric field. I use COMSOL to simulate my electric field, the lenght unit is meter and the field unit is V/meter. I have a question, after simulating the electric field you save the simulation’s result in a txt file and do you modify your data set before use it in Geant? becouse using debug in Geant I discovered my program reads correctly the positions but the Ex, Ey and Ez components are smaller than a 10^(-9) factor despite I use the same units in Geant, meter for lenght and V/meter for field.
Thank you in advance,
Best regards
Luigi

Hi Luigi,
Sorry for the delayed response. I have been busy with other things as well as not noticing your recent reply. My COMSOL model has data coordinates for the grid in the arrow volume as:
-.001 -.0009 -.0008 -.0007 -.0006 -.0005 -.0004 -.0003 -.0002 -.0001 0 .0001 .0002 .0003 .0004 .0005 .0006 .0007 .0008 .0009 .001
that should be in m
but the output file has -1e6 to +1e6, so 10^9 times larger. My Geant4 program has a length unit of nm, so it reads the data correctly, but I am currently not sure why COMSOL outputs in nm. I could send you the COMSOL file that was used to generate my files which define the electric field if that helps.

The maximum electric field should be somewhat less than 4E5 V/m for the file Topografiner1mm_v2b.txt and that is what I find.
So in my case I have the electric field correct, but the dimensions 10^9 times different !

Best Wishes
Chris

Hi Luigi,
I was just running the COMSOL model again just to check the output and all seems OK, so I think I generated the files I sent to you using an earlier version of the COMSOL model. If the output from the COMSOL model does not conform to what you expect, I would have though you would be able to get some support from COMSOL.

Best Wishes
Chris

Hi Chris,
thank you so much for your help and for your advices, they were very helpful. In Comsol I’ve introduced a volume of air surrounding my entire experimental setup and I’ve changed the field unit in Geant, in this way Geant reproduces the correct field’s value.
Thank you again for everything.

Best regards
Luigi

Hi Chris,

many thanks for sharing this.

I think I see my problem. Luigi’s COMSOL generated files are reasonably comprehensible and his meshes are regular, ditto for the PurgMag3d file. Whereas mine are generated from the COMSOL physics controlled mesh and quite higgledy-piggledy.

My problem seems to stem from my limited understanding of the COMSOL mesh options. I shall try to generate a regular and presumably rectangular mesh in COMSOL.

T

Hi all,

I’ve managed to export the e-field from COMSOL in a more sensible format and with a bit of tweaking of the header of that file the modified Geant4 field02 example is reading the file.

But I’m getting the dreaded “no electric field at this extent” message. Inserting a print statement in GetFieldValue and printing out the spatial coords and the vector components at that point reveals that the COMSOL spatial coords of, for example, [7.4 6.66 -1.48] are being displayed by Geant4 as [74 66.6 -14.8] . In other words COMSOL’s centimetres are being shown as millimeters, Geant might taking that millimetre value and “assuming” it’s centimetres and it’s quite possible that there is, indeed, no electric field at that extent. BTW, my COMSOL field was generated in a geometry that should be identical to that described in F02DetectorConstruction.

T

When you read in a text file of numbers, you either have to multiply by a G4 unit in your reading code, or the number will be interpreted in G4’s internal units. Geant4’s internal units are millimeters. See $G4INCLUDE/CLHEP/Units/SystemOfUnits.hh for all of the units multipliers.

I took a look at the original purging_magnet code, and I see that there’s a local variable there

  double lenUnit= meter;

It seems that you correctly modified this line to use centimeter to match your COMSOL model. You wrote:

printing out the spatial coords and the vector components at that point reveals that the COMSOL spatial coords of, for example, [7.4 6.66 -1.48] are being displayed by Geant4 as [74 66.6 -14.8]

That sounds correct: 7.4*centimeter would be printed as 74 if you didn’t divided by your own desired unit in the cout statement.


When you defined your COMSOL geometry, did you follow the Geant4 convention that (0,0,0) is at the center of the volume? We have repeatedly run into a problem in our experiment where someone will generate their COMSOL field model putting Z=0 at the bottom face of the detector, and in the G4 simulation, half the detector has no field, and the other half has a field model that extends out beyond the top face. Make sure that both the dimensions and the ranges of coordinates match between COMSOL and Geant4.

Is the volume associated with the field being placed at (0,0,0) in the world? If it’s offset (i.e., the global-to-local transform is not Identity), then you also need to take that into account.

Hi Mike,

thanks for replying. Yeah, my COMSOL model was set around the Geant4 convention of (0, 0, 0).

I’ve returned the Tabulated3d field to default by removing my multipliers and [7.4 6.66 -1.48] is now being displayed by Geant4 as [74 66.6 -14.8] and lenUnit is now centimetre.

I have previously plotted the COMSOL generated field field in Matlab and it looks sensible (see attachment, apologies for arrow heads).

The messages from TabulatedField3D (below) seem correct. So, the field should be visible.

T

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

  •  Electric field*
    

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

  • —> Reading the field grid from Cauldron_Ex_Ey_Ez_Circumscribed_Rectangle_cm.txt … *

  • [ Number of values x,y,z: 75 75 41 ] *

  • —> … done reading *

  • —> assumed the order: x, y, z, Bx, By, Bz *

  • —> Min values x,y,z: -7.2 -7.4 -4.5 cm *

  • —> Max values x,y,z: 7.4 7.4 3.5 cm *

  • —> The field will be offset by 0 cm *

After reordering if neccesary

  • —> Min values x,y,z: -7.2 -7.4 -4.5 cm *
  • —> Max values x,y,z: 7.4 7.4 3.5 cm *
  • —> Dif values x,y,z (range): 14.6 14.8 8 cm in z *
    -----------------------------------------------------------
  • F02ElectricFieldSetup: The minimal step is equal to 0.01 mm*
    G4ClassicalRK4 is called

Hi all,

progress report on my odyssey.

Some success. I have discovered that not invoking /vis/scene/add/electricField does not interrogate the field (understandably) and, thus does not raise the “no electric field at this extent” message implying, I assume, that the field is just sitting there waiting to be interrogated.

When I run the app the COMSOL generated field is loaded and the limits are set. These limits are as I’d expect from the COMSOL file.


  Electric field

—> Reading the field grid from Cauldron_Ex_Ey_Ez_Circumscribed_Rectangle_cm.txt …
[ Number of values x,y,z: 75 75 41 ]

—> … done reading
—> assumed the order: x, y, z, Bx, By, Bz
—> Min values x,y,z: -7.2 -7.4 -4.5 cm
—> Max values x,y,z: 7.4 7.4 3.5 cm
—> The field will be offset by 0 cm

After reordering if neccesary
—> Min values x,y,z: -7.2 -7.4 -4.5 cm
—> Max values x,y,z: 7.4 7.4 3.5 cm
—> Dif values x,y,z (range): 14.6 14.8 8 cm in z

I then /run/beamOn 1 it calls GetFieldValue and after the second step the initially unionised but now ionised particle is within the e-field limits and is captured by the e-field (you can see the e-field at that point):

G4WT0 > *********************************************************************************************************
G4WT1 > Run Summary
G4WT1 > Number of events processed : 0
G4WT1 > User=0.000000s Real=0.000002s Sys=0.000000s [Cpu=0.0%]
G4WT0 > * G4Track Information: Particle = Ra224, Track ID = 1, Parent ID = 0
G4WT0 > *********************************************************************************************************
G4WT0 >
G4WT0 > Step# X Y Z KineE dEStep StepLeng TrakLeng NextVolu Process
G4WT0 > 0 -7.19 mm 1.04 cm 3.5 cm 114 keV 0 eV 0 fm 0 fm World initStep
G4WT0 > 1 -6.98 mm 1.06 cm 3.47 cm 64.5 keV 49.5 keV 999 um 999 um World ionIoni
G4WT0 > #######################################
G4WT0 > ######## Called GetFieldValue ########
G4WT0 > #######################################
G4WT0 > x = -6.9752 [minx = -72][maxx = 74]
G4WT0 > y = 10.6471 [miny = -74][maxy = 74]
G4WT0 > z = 34.7291 [minz = -45][maxz = 35]
G4WT0 > #######################################
G4WT0 > #######################################
G4WT0 > Ex = -3719.58 Ey = 100620 Ez = -364351

Unfortunately the particle gets “stuck” and eventually raises an exception but that’s a topic for another subform. Edit, perhaps it’s not being ionised?

But why, when I do a /vis/scene/add/electricField does it raise a “No Electric field in this extent.” when there is clearly an e-field present?

T

Interesting question. You might have found a bug, but first, let’s see what we can find out.

  • Have you looked at the command guidance (help /vis/scene/add/electricField)? It’s quite extensive. That might give a clue.
  • Have you (inadvertently?) set the extent for the field (/vis/set/extentForField or /vis/set/volumeForField, or similar under /vis/touchable)?
  • To see what extents are in operation, /vis/scene/showExtents. Does that tell you anything?

There are many ways of debugging. Have you tried stepping through the code with a debugger? The vis system provides many tools - see Debugging geometry with vis — Book For Application Developers 11.2 documentation.

John

Hi John,

how’s life in Hebden Bridge? I’ll admit I never got to visit there and it’s unlikely now I’m back in Aus.

I tried your suggestions with the exception of stepping through the code with a debugger but I’m none the wiser. However I did try using the uniform field that is default with the field02 example and some of the daughter product primaries (I expect about 30%) are “picked up” by the e-field and transported. So, in spite of my previous posting and the symptoms indicating that the particles are experiencing an electric field, it may be that they are not be experiencing that e-field hence them getting “stuck”. Perhaps there is a “disconnect” between the volume and the e-field.

To show my ignorance and rustiness of C++ I wonder whether it is possible to check the field from within F02SteppingVerbose?

Hi all,

I’ve managed to get my field02 example running in Xcode. I was expecting far worse but it wasn’t too bad at all. But I’m very rusty with debuggers and haven’t used them for over 20 years.

But it was the above quote by Chris that finally cracked the field visualization issue.

I’m now having tracking issues. With an e-field running (more-or-less) left to right the primaries should be making a beeline similarly :frowning:

Compare this to the track in G4UniformElectricField:

Thanks for all your help guys.

T

Hi Tim

Great. Glad we cracked that one.

Re electrons in an E-field. Generally, I would say electrons are extremely erratic. They bounce around a lot in matter. If your field value is moderate - not very high - all the more. Was the material the same in the two pictures?

Anyway, that’s my thoughts. It looks to me like it’s now a navigation issue, not visualisation.

John

Hi John,

not electrons but heavy (radon and radium) isotopes. The idea is to use gas ionisation (helium) as the daughters are emitted from a substrate (on left) and guide them to a collector (on right) using the e-field. He pressure is 3.7 bar (to avoid arc over - Paschens law) and HV is 80 KV (to “punch through” the He)!

Yip.

To fault find I’m using G4UniformElectricField as a control and adjusting the G4ElectricField to a similar uniform field. I’ll let you know how I get on.

Have a good weekend guys.

T