Rayleigh, Optical Photon

So my question: this means in my case the material not being water would create problem?

No. If you specify the the attenuation lengths they will be used, no matter what material. Geant4 will calculate them if they are not specified and the material is G4_WATER. The “not yet implemented” comment is in the wrong place (and long since moved.)

So I am wondering if thePhysicsTable is pointing to a NULL pointer maybe that is why I am getting seg fault?

Maybe. Ideally you’d be able to compile Geant4/Gamos/your code in debug mode, then you’d be able to see exactly where the problem is. But:

#5 0x00007f3a9d1d57ab in G4PhysicsVector::Value(double, unsigned long&) const () from /home/ra/GAMOS61/external/geant4/geant4.10.05.p01.gamos/lib/Linux-g++/libG4globman.so

Makes me think (still) the vector of attenuation lengths has only one value.

Also how do I figure out what is DBL_MAX?

G4cout << DBL_MAX
or write a small standalone C++ program. It’s in std::numeric_limits

Doesn’t explain why I am getting step length of exp-322 though

Try DBL_MIN (Not on my machine but the values depends on architecture, at least.)

Thanks,

I will try to sketch in pieces over two emails my code.

Let me start with .in file first. Generally, in GAMOS one first sets the parameters, then calls the useraction. I can provide more details on the UserAction code below if needed…

"

/run/verbose 2
/control/verbose 2
/event/verbose 4
/tracking/verbose 4

/gamos/verbosity GmGenerVerbosity 2
/gamos/verbosity GmPhysicsVerbosity 2
/gamos/verbosity GmAnalysisVerbosity 2

#Generates random seed n1 for n2 repeats
/gamos/random/setSeeds 22 2

#Geometry file
/gamos/setParam GmGeometryFromText:FileName atm_bkscatter_aperture_noMie3.geom
/gamos/geometry GmGeometryFromText

#Physics list
/gamos/physicsList GmEMPhysics

#This is required and works for Rayleigh. But here a special GAMOS useraction is doing that (see below)
#/gamos/generator GmGenerator

/gamos/setParam MySource:Polarization 1. 0. 0.

/run/initialize

################This below is breaking code for opticalphoton - do not use it or if you use it take out RAYLEIGH

#This code is a special useraction in GAMOS to provide cross section and interaction length for the materials and particle of interest which can be used then to generate histograms for angle scattering. It figures out or even builds basic dummy geometry if not provided, launches the particles and figures out cross-section for each geometry and material for all the particles in the selected energy range (it probably links these energies to RI and other coefficients from geom file? not clear). It does so by generating particles and then calling the run manager. It however, is not exact replica of /generator such as it does not assign weight and/or polarization but relies on Geant4 default?

/gamos/setParam GmGeneratorChangeEnergyAndMaterial:nEventsPerRun 20
/gamos/setParam GmGeneratorChangeEnergyAndMaterial:minE 1.17e-6
/gamos/setParam GmGeneratorChangeEnergyAndMaterial:maxE 1.18e-6
/gamos/setParam GmGeneratorChangeEnergyAndMaterial:nStepsE 4
#Linear step or lograrithmic step
/gamos/setParam GmGeneratorChangeEnergyAndMaterial:logE 0
/gamos/generator GmGeneratorChangeEnergyAndMaterial
#####################################

#Ok here is a problem. I have to use /gamos/generator to generate polarization
#But GmGeneratorChangeEnergyAndMaterial does not accept that because it generates its own source i.e., it provides a call to GmGenerator. So it complains that two instances are open.

#And it shows seg fault at generateEvent. I thought it was because of polarization not getting defined! But looks like it is not. It’s something else…weight? But why only Rayleigh gets affected and not OpAbsorption?

/gamos/generator/addSingleParticleSource MySource opticalphoton 1.17e-6*MeV

#/gamos/generator/energyDist MySource GmGenerDistEnergyConstant 1.17e-6*MeV
/gamos/generator/positionDist MySource GmGenerDistPositionPoint 0. 0. 0.
/gamos/generator/directionDist MySource GmGenerDistDirectionConst 0 0 1

/gamos/physics/addPhysics opticalphoton
/run/beamOn 2
"

And here is my geometry file

"
:include …/…/data/NIST_elements.txt
:include …/…/data/NIST_materials.txt

//*****************Try to figure Rayleigh coefficients ***********************
:MATE_PROPERTIES_TABLE mpt0
:MATEPT_ADD_ENERGIES mpt0 1.17e-6*MeV 1.18e-6*MeV 1.19e-6*MeV
:MATEPT_ADD_PROPERTY mpt0 RINDEX 1.002 1.002 1.002
:MATEPT_ADD_PROPERTY mpt0 RAYLEIGH 10.0*cm 10.0*cm 10.0*cm
:MATEPT_ADD_PROPERTY mpt0 ABSLENGTH 1.0e2*cm 1.0e2*cm 1.0e2*cm
:MATEPT_ATTACH_TO_MATERIAL mpt0 G4_AIR

:MIXT AIR1 .00119 3
Argon 0.013
Nitrogen 0.754
Oxygen 0.233

:MATE_PROPERTIES_TABLE mpt1
:MATEPT_ADD_ENERGIES mpt1 1.17e-6*MeV 1.18e-6*MeV 1.19e-6*MeV
:MATEPT_ADD_PROPERTY mpt1 RINDEX 1.002 1.002 1.002
:MATEPT_ADD_PROPERTY mpt1 RAYLEIGH 37030e0*cm 37030e0*cm 37030e0*cm
:MATEPT_ADD_PROPERTY mpt1 ABSLENGTH 100000*cm 100000*cm 100000*cm
:MATEPT_ATTACH_TO_MATERIAL mpt1 AIR1

// BUILD GEOMETRY

//can we scale this to cm from kms?
:VOLU M0world BOX 10.*km 10.*km 10.*km G4_AIR
:VIS M0world OFF
:Colour M0world 0. 0. 1.
:ROTM RM0 0. 0. 0.

//subworld is located 100m off from the world in each direction after rotation
:VOLU M1world BOX .5*km 0.5*km 0.5*km AIR1
//:VIS subworld OFF
:PLACE M1world 1 M0world RM0 0.*km 0.*m 5.*km

Well there’s a lot going on. I would suggest making these simplifications for testing purposes (keeping in mind I don’t know about Gamos).

  • the minimum energy in the material property table is the same as the photon energy. Try setting the energies to 1eV 2eV 3*eV
  • remove the second box so that you just have the world
  • don’t define your own material
  • set the attenuation values small, like in mpt0, so there will be lots of them
  • define only ABSLENGTH in mpt0. I don’t think RINDEX is needed. Run with /tracking/verbose 3. Are the photons absorbed? Do they have polarization?
  • replace ABSLENGTH with RAYLEIGH and repeat. What happens?

Hi,
Here is a run just for abslength and no RAYLEIGH.
Logfile attached. Its clear that it is running well though it does start with a very low weight and zero polarization. But that does not seem to affect anything. Also increased number of runs for beam on to 10. That is the only change to the .in file and reduced number of energy steps from 4 to 3.

tracking verbose 3

Material file

:include …/…/data/NIST_elements.txt
:include …/…/data/NIST_materials.txt

//*****************Try to figure Rayleigh coefficients ***********************
:MATE_PROPERTIES_TABLE mpt0
:MATEPT_ADD_ENERGIES mpt0 1.00e-6MeV 2.00e-6MeV 3.00e-6MeV
:MATEPT_ADD_PROPERTY mpt0 ABSLENGTH 1.0e2
cm 1.0e2cm 1.0e2cm
:MATEPT_ATTACH_TO_MATERIAL mpt0 G4_AIR

// BUILD GEOMETRY

//can we scale this to cm from kms?
:VOLU M0world BOX 10.*km 10.*km 10.*km G4_AIR
:VIS M0world OFF
:Colour M0world 0. 0. 1.
:ROTM RM0 0. 0. 0.

log2.txt (106.2 KB)

And now replaced ABSLENGTH with RAYLEIGH in the geom file…
Here is the log file.
Like I said, if I am lucky it will run and show few tables and then do a seg fault.
At times it just directly seg faults as in here. I have no control over this or rather haven’t figured out when to get at least few steps in this mode

Also can someone explain (probably not because this maybe GAMOS peculiarity) what is radlength and nucintlength for optical photon? I get this in the log file…
The UserAction does ask for it…
GmGeneratorChangeEnergyAndMaterial BuildMaterials material G4_AIR radlen 303921 nucintlen 710095.
How can optical photon have nuclear interaction length or radiation length of so many mms?
Thanks

log3.txt (43.1 KB)

And this case is when I comment out in my .in file everything related to GmGeneratorChangeEnergyAndMaterial UserAction
And
insert /gamos/generator

In the geom file I have now both ABSLENGTH and RAYLEIGH. If i have just Rayleigh then due to the att length being small and no abslength the log file turns out huge. It does process to the end. So i just added abslength to make it small and simulated only 2 runs.
Here is the log.

log4.txt (49.8 KB)

It looks like it works!

In log3.txt (doesn’t work) there is:

==== PDGcode 0  Particle name opticalphoton
 Assigned charge : 0
     Momentum ( 0[GeV/c], 0[GeV/c], 1.17e-09[GeV/c] )
     kinetic Energy : 1.17e-09 [GeV]
     Mass : 0 [GeV]
     Polarization ( 0, 0, 0 )
     Weight : 1.48576e-76

In log4.txt (seems to work) there is:

==== PDGcode 0  Particle name opticalphoton
 Assigned charge : 0
     Momentum ( 0[GeV/c], 0[GeV/c], 1.17e-09[GeV/c] )
     kinetic Energy : 1.17e-09 [GeV]
     Mass : 0 [GeV]
     Polarization ( 1, 0, 0 )
     Weight : 1

Weight and polarization, plus Rayleigh scattering, all as expected. The polarization was set explicitly to (1,0,0).

In Geant4 directly (I’m using the development version) if the polarization is not set in user code, we get the same warning you see in log3.txt:

-------- WWWW ------- G4Exception-START -------- WWWW -------
*** G4Exception : ZeroPolarization
      issued by : G4PrimaryTransformer::GenerateSingleTrack
Polarization of the optical photon is null.                     Random polarization is assumed.
*** This is just a warning message. ***
-------- WWWW -------- G4Exception-END --------- WWWW -------

and the polarization is indeed set randomly

G4WT1 >          Polarization - x    : -0.04411952225873567-0.04411952225873567
G4WT1 >          Polarization - y    :   0.3970757003286211  0.3970757003286211
G4WT1 >          Polarization - Z    :   0.9167247983796423  0.9167247983796423

and Rayleigh works as expected.

As as aside, it’s nice that Gamos tells you the weight in /tracking/verbose.

Hi dsawkey,
It works only in log2.txt (OpAbsorption) and log4.txt. But in log3.txt if Rayleigh is working why am I getting segmentation fault? And at times when it seems to work (please refer to my earlier posts) why is step length exp-322? And why is weight for log2 and log3 very small?
The difference between log2,3 and log4 is that in 2 and 3 I used a special useraction called GmGenerateChangeEnergyAndMaterials while in 4 I did not but instead used generator.
The only difference I can figure out is the former does not fix the weights and polarization while txt 4 does. Also the fact that log3.txt seems to get stuck after OpRayleigh GetmeanFreePath is weird
I do not get it.
Thanks

I don’t get it either but it must be related to this. What does it do, and do you need to keep it?

In log3.txt the track information is not displayed (seg faulted before). In log2.txt the polarization is also strange, because it has no component in the Z direction.

         Polarization - x    :  -0.5461269702135862 -0.5461269702135862
         Polarization - y    :   0.8377024127966498  0.8377024127966498
         Polarization - Z    :                    0                   0

I don’t see exactly what is causing the crash. I think to understand the error you’ll want to compile Gamos and your code in debug mode.

Hmm! Ok I can try that.
As for why polarization is 0 along z? That is because the direction for the beam that I have set is along z (in my .in file). I thought that is why its doing that.
One thing is certain - the weight. Its certainly not implemented in that special UserAction. I can try to insert it and recompile. However, despite that the OpAbsorption seems to run (log2.txt). The weight being low does not bother it…
But for Rayleigh it seems like a different story!
I feel that I should delve a bit more into differences between this UserAction and the normal way if I do not use it. There is a critical difference that is causing this issue.

Also it would help to understand why Rayleigh needs (or does it?) weight. It would also help to know what happens in Geant4 when step length is as small as exp-322. At some point it should kill the process or something isn’t it?
And thank you for your help and guidance on this.

I haven’t figured this out yet but questions abound!
What is Production cut table for optical photon? I cannot find information on how that is calculated? The UserAction I am referring to above (GmGenerateChangeEnergyAndMaterials) seeks Production cuts…Below is a piece of that code…

//- runMgr->DefineWorldVolume( (*ite).second );
//G4TransportationManager::GetTransportationManager()->GetNavigatorForTracking()->GetWorldVolume()
// geomMgr->CloseGeometry(true,1,world);
geomMgr->CloseGeometry(true,1);
G4RunManagerKernel::GetRunManagerKernel()->RunInitialization();
// G4RunManagerKernel::GetRunManagerKernel()->UpdateRegion();
G4StateManager::GetStateManager()->SetNewState(G4State_GeomClosed);
G4ProductionCutsTable::GetProductionCutsTable()->DumpCouples();

Hi dsawkey and mkelsey
I have resolved the issue though I cannot exactly say what solved it yet. First stage , I made two changes

  1. In the UserAction referred above in my previous post - I inserted a line that initialized theWeight =1.0
  2. And I replaced the new G4OpRayleigh.cc and .hh (Geant 10.6) with the older version (Geant 10.0) because I figured the issue was mostly related to G4PhysicsFreeVector.

This worked! For both absorption and Rayleigh together.

Next I commented out #1 i.e., went back to the case where weight was =0 by default. (see my previous log2 and log3.txt files). Again it worked! Even though the weights were zero.

While I thought it may have nothing to do with #2 but I was also not sure what weight has to do with all this because I thought by default the weight should be 1 but then I see that its 1 only for biased distribution (isn’t it mainly used for variance reduction? Sorry, this is all very difficult and I am still learning!).

I also did not include in the UserAction code a way to initialize polarization. I figured Geant4 already does that even if its random, which for now is Ok for my application. I wish I could but I am not yet familiar how it is done in Geant4 i.e., if it’s a method in particle generator?

So, at this point I am at a complete loss to say why #2 with newer version of the code created an issue. Both are doing same evaluations. My sense is kRAYLEIGH is not getting defined (maybe missing header by the useraction?) and so it tries to evaluate meanfreepath using the method wherein you have to input isothermal compressibility value. And if you don’t then that results in a ‘NULL’ pointer. (Although, I swear I tried replacing the G4_AIR with G4_WATER and it did not resolve anything but I could be imagining it).
What I may do next is to back to version 10.6 and replace kRAYLEIGH in the code with ‘RAYLEIGH’ and compile and test it.
Thanks

Hi dsawkey
I am responding again to your response to my polarization question in Rayleigh scattering of ‘optical photon’.
I tried to look up the source code in Geant4 and found no connections between Rayleigh process photon polarization and weight of the particle. I also do not see any mention of ‘weight’ definition in the Geant4 manual except for the cases where distribution bias is described. For example in the entire ‘optical photon’ section nothing about weight parameter is mentioned.
Moreover, so far in all my examples I always find the polarization of the optical photon to be assigned correctly albeit random w.r.t photon momentum even if I fail to provide it. And this is irrespective of the weight of the particle. So I am really confused! Can you or someone please point out to me where can I look for a clear definition or understanding of how weight assignment is provided to an ‘optical photon’ and what happens if this weight is not provided? Does it affect the polarization?
Also the statement that "optical photons have to be assigned a polarization for Rayleigh scattering’ is not strictly correct unless one is simulating a specific case of a particular polarization. Unless someone provides an example otherwise (e.g., could it be that if one generates a optical photon in a metal then it cannot have any random polarization even though it may agree with momentum vector?) can we remove or clarify this statement with an example in the user guide because it is is extremely confusing?
Thanks

Hi,

In principle the optical processes should simply keep the weight unchanged, and assign the same weight to any secondaries. This is not likely the cause of your issue, although a weight of 1e-76 suggests to me that particles are not being initialized correctly.

G4OpRayleigh has
OldPolarization = aParticle->GetPolarization();
so the statement that the particle needs to be assigned a polarization sounds close to correct. Which entity should assign the polarization is another question. In your code and OpNovice2, it turns out that if a polarization is not assigned by the user, it is done automatically (differently in the two cases!) Given there are multiple ways of creating primaries, and I don’t know that all of them assign a polarization randomly, it is still up to the user to ensure the particles are polarized. Which you’ve done with /tracking/verbose.

I would approach your issue this way. The crash happens in G4PhysicsVector->Value(). That code is accessing physics tables or material property tables. There doesn’t look to be anything specific to the particle there, except the energy. I would try to access the relevant PhysicsVector at the point of the crash. Run in a debugger, or add G4cout statements. I do realize that 1) you’re using Gamos and 2) you don’t seem to be able to recompile the code, so this may not be a helpful suggestion. You might want to try one of the Geant4 examples and try to set the parameters the same as in your simulation.

One last thought is to check whether the optical parameters are defined before or after /run/initialize. I don’t know how this would cause your issue, exactly, but it is important to get correct.

Let me re-emphasize that, as far as I can tell, OpRayleigh works fine in Geant4, and you are using a modified version. Likely the problem originates downstream.

Hi dsawkey
Thanks for detailed explanation.
Yes I am trying both your suggestions i.e., recompiling with cout statements, its just I am trying to figure out at which point or rather in which .cc file this cout statement should go…
Will update if I find anything interesting

I think I am beginning to understand what is happening! Though I definitely need help from GAMOS or GEANT folks. Not sure where the problem lies. Here is a not so short (tried to be brief summary)

  1. If I use new version of G4OpRayleigh, I get segmentation fault
  2. If I use older version of G4OpRayleigh, I am not getting segmentation fault
  3. I inserted some G4Cout statements as suggested by dsawkey and recompiled the code

New Version of G4OpRayleigh (10.6)

GAMOS input file has a generator useraction. I think it runs the first initialize() that is needed.
It then builds the physics table from G4OpRayleigh method and outputs material property statements that I had inserted in and everything looks good as my geom file indicates for Energy and Rayleigh attenuation lengths
1.18e-6 100
2.18e-6 101
3.18e-6 102
However, the generate Useraction issues again a second build_table command (or maybe that is how GEANT works?) i.e., after processing one event it rebuilds the physicstable? This is where the problem appears
This second time, it does not put out properly the material property
22e-324 1.4e-322
2.18e-6 101
-1.9e-340 16e-322
And it is this that results in segmentation fault

Older Version of G4OpRayleigh(10.2)

GAMOS input file has a generator useraction. This runs the first initialize() that is needed.
It builds the physics table from G4OpRayleigh method and outputs material property statements that I had inserted in and everything looks good as my geom file indicates for Energy and Rayleigh attenuation lengths
1.18e-6 100
2.18e-6 101
3.18e-6 102
Then the generate Useraction issues again a second build_table command after the first event (my reading so far)
This second time, it does not do anything because the table is already built
And everything runs fine to the end

I think in new G4OpRayleigh.cc, when a buildtable command is issued, it destroys the old table and a new table is built based on particle definition using void G4OpRayleigh::BuildPhysicsTable(const G4ParticleDefinition&). So here immediately this method checks if physics table exists. If it does, then it destroys it. And in the next step it rebuilds it again from the particle definition.
But when it accesses the material property table it does not appear to do its job well for example a snippet from new G4OpRayleigh.cc in BuildPhysicsTable(&particledefinition) method

const G4MaterialTable* theMaterialTable = G4Material::GetMaterialTable();
const G4int numOfMaterials = G4Material::GetNumberOfMaterials();

thePhysicsTable = new G4PhysicsTable( numOfMaterials );

for( G4int iMaterial = 0; iMaterial < numOfMaterials; iMaterial++ )
{
G4Material* material = (theMaterialTable)[iMaterial];
G4MaterialPropertiesTable
materialProperties =
material->GetMaterialPropertiesTable();
G4cout << " Materialproperty: for numofMaterials " << numOfMaterials << G4endl;// by me
materialProperties->DumpTable();// by me

The output from the last G4cout is this:
Materialproperty: for numofMaterials 1
11: RAYLEIGH
1.3052e-316 9.72299e-317
2e-06 1050
1.10671e-321 9.48606e-322
14: ABSLENGTH
1e-06 1010
2e-06 1020
3e-06 1030
23: ENERGIES
1e-06 1e-06
2e-06 2e-06
3e-06 3e-06
rayleigh Materialproperty: 0x12c4890
1.3052e-316 9.72299e-317
2e-06 1050
1.10671e-321 9.48606e-322
So first column is energy and second is attenuation length. For some reason only Rayleigh has been affected. Also energy values have been stripped of their decimals. I have absolutely no idea what happened to the original table? Maybe during the first event the photon got absorbed? But first event was only for the first energy…It should have jumped to the next energy isn’t it? That does not appear to have been corrupted. And the third energy is also weird.

In the older version, it uses void G4OpRayleigh::BuildthePhysicsTable()
In that, the very first step is to check if there exists a table. If there is one then it just ‘returns’ but does not destroy anything or rebuild. Which is why it works!? For example the above G4cout statements are printed out only once and not twice. So it appears that it prints out the physicstable after one event, then it is supposed to change physicstable if things change as in cut values are adjusted though what are those cut values for optical photon (I am not familiar with the Geant logic here, really need help. Tried looking at examples but its not clear there too)? But the older version does not do this. It just returns with the table intact

However, notice this carefully. The two methods have a different name, one is BuildPhysicsTable and the older one is BuildthePhysicsTable. However, the latter does originate from the former so not an issue here.

Hi All
Looks like this is a Geant4 problem
So what the GAMOS useraction is doing is halting after one run and changing the geometry/material and then re-running.
The way it is doing this is by first generating the vertex, then changing the material (in my case there isn’t any change and then continuing the run using the

geomMgr->CloseGeometry(true,1);
G4RunManagerKernel::GetRunManagerKernel()->RunInitialization();
G4StateManager::GetStateManager()->SetNewState(G4State_GeomClosed);

So this RunInitialization calls BuildPhysicsTable() again a second time because it wants to know if production cuts have been changed. When was it called the first time? I think that is called in response to the /beamOn? I need to check that but my output does show that it first generates the physics table (see my previous posts), then it accesses the UserAction code whose snippet I have provided above.
And I see the proof that it is doing it twice because the set couples output gets printed twice along with the materialproperty output.
So the question of relevance is : why during this second time in buiiding the physics table does the Rayleigh parameters get so out of whack in comparison to what I input? This is now beyond me but seems like a Geant4 issue.
The only way to solve this was ignore building the physics table by reverting to older G4OpRayleigh.cc (v10.2).
I hope someone will shed some light here.
Thanks

Good sleuthing. But:

  1. I don’t see G4OpRayleigh::BuildthePhysicsTable() in Geant4 version 10.2. According to the History file it was removed for 10.1
    Geant4/processes/optical/History
    Are you still conflating Geant4 and Gamos? Is Gamos using an outdated file?

  2. This

geomMgr->CloseGeometry(true,1);
G4RunManagerKernel::GetRunManagerKernel()->RunInitialization();
G4StateManager::GetStateManager()->SetNewState(G4State_GeomClosed);

isn’t the recommended method of changing geometry and material. This is pretty low level and likely something is going wrong here. Try:

https://geant4-userdoc.web.cern.ch/geant4-userdoc/UsersGuides/ForApplicationDeveloper/html/Detector/Geometry/geomDynamic.html?highlight=geometryhasbeenmodified#dynamic-geometry-setups

Hi dsawkey

  1. My mistake and you are correct - it should be G4OpRayleigh::BuildthePhysicsTable() in Geant4 version 10.0 and I am using that.

  2. No Gamos isn’t using an outdated file. I had to replace version 10.6 with version 10.0 so as not rebuild the physicstable. Which is why now it is working. Just my stroke of luck! Though I confess, I do not know if that is the right way to do this.

  3. I looked up your link and I thought Gamos was doing that…please see below (I should have pasted the entire subroutine). So if I follow the step linked by you - how to restart the idle state of Geant4? Or are you suggesting with your linked method I do not have to put Geant4 in an idle state?

G4GeometryManager* geomMgr = G4GeometryManager::GetInstance();
geomMgr->OpenGeometry();

std::vector<G4Material*>::const_iterator item = theMaterials.begin();
for( G4int ii = 0; ii < theCurrentMaterial; ii++) item++;

G4StateManager::GetStateManager()->SetNewState(G4State_Idle);

for( std::vector<G4LogicalVolume*>::const_iterator itelv = theLogicalVolumes.begin(); itelv != theLogicalVolumes.end(); itelv++ ) {
(*itelv)->UpdateMaterial( *item );
}
geomMgr->CloseGeometry(true,1);
G4RunManagerKernel::GetRunManagerKernel()->RunInitialization();
G4StateManager::GetStateManager()->SetNewState(G4State_GeomClosed);
G4ProductionCutsTable::GetProductionCutsTable()->DumpCouples();
#ifndef GAMOS_NO_VERBOSE
if( GenerVerb(infoVerb) ) G4cout << " GmGeneratorChangeEnergyAndMaterial::ChangeMaterial to " << theCurrentMaterial << " = " << (*item)->GetName() << G4endl ;
#endif

And that’s it. Very soon after this last step it prints out the material name and then reruns with a new physics table (with weird Rayleigh parameters) and cuts and then I get the seg fault.
Btw, I also commented out the ‘for loop’ for UpdateMaterial(*item), thinking that is doing something oddand recompiled. But the problem still persists. So I put it back again.

Can you please clarify a bit more on the Geant4 state machine? I thought to change geom I have to put it in idle state?
Thanks

Thanks

RESOLVED!
Thanks dawkey
Your suggestion to follow the link guidelines worked! I just removed the statement

G4RunManagerKernel::GetRunManagerKernel()->RunInitialization();

But retained the rest. However, I am really not sure what implications will it have to this UserAction? Why or rather when is it required by user to use the above RunInitialization? For example what if for other physics such as scintillation and or emission the range cuts do get modified because of geometry change? Don’t I have to call the RunInitialization method? I would like to get some clarity (references to it?). The ‘book for Application Developers’ is too thin on explanation.
Are their tutorials? I couldn’t locate it in Geant4 download. How do I get access to it?
Thanks for all your support and help