Hi,
I am trying to set Attenuation lengths for my constructed material for Mie and Rayleigh scattering. I tried Rayleigh scattering but I am getting segmentation fault. Looking at .cc file for G4OpRayleigh.cc it says the attenuation length is only calculated for water.
I am confused! If I force an attenuation length shouldn’t it just work?
What is the format to provide the numbers?
I used ‘RAYLEIGH’ in *cm.
Should it be inverse cm? Don’t understand the reason for segmentation fault
Thanks
I think I found it …its called kRayleigh.
I also see that older scripts would calculate attenuationlengths based on energy and the new scripts use photon momentum?
I have additional question:
I am propagating an optical beam in air, and I have attached to it material property with RI and attenuation length and energy (in eV converted from nm) all defined. It then enters another geometry. I have also attached material properties to it but I am not seeing that volume doing anything. Its as if it isn’t there. I gave it a high absorption constant but the beam just propagates through it.
The question I have is
- What energy should I associate with that material. Optical photon does not changes its energy (unless absorbed and then re-emitted as fluorescence) but I do not have those processes.
- And Rayleigh attenuation also does not seem to do anything. I tried various magnitudes but to no effect. Do I have to provide in addition beta coefficient or compressibility index (I assume not!)…
Hi,
The names of the material properties are here:
https://geant4.kek.jp/lxr/source/materials/src/G4MaterialPropertiesTable.cc
(I don’t see them in the documentation.). The name string is RAYLEIGH. There is an enum, kRAYLEIGH, you can use instead of doing string comparisons during runtime.
You will want to specify the interaction length as a function of energy over the energy range of interest. There needs to be at least two data points. If your optical photons have energy outside this range, they will not see this process.
Dimension is length. Specify the units explicitly.
Look at example extendend/optical/OpNovice detector construction. The absorption length (ABSLENGTH) is defined. Do the same thing for RAYLEIGH.
https://geant4.kek.jp/lxr/source/examples/extended/optical/OpNovice/src/OpNoviceDetectorConstruction.cc#L117
If you specify the Rayleigh scattering length, Geant4 will not calculate it and there is no need to specify isothermal compressibility.
Hi dsawkey
Thank you for your response.
I am still confused by your statement ‘you need two data points’?
Would you mind clarifying for me?
In my example I have a monochromatic source e.g., 532 nm. So I use approx 2.2eV.
Are you suggesting I should be using two energy data points?
If that is correct may I understand why is that?
I did figure out my issue though. The problem was really trivial and I had to carefully read the GEANT4 user guide.
The problem was that I was not defining the polarization.
And the second problem was I was using kRAYLEIGH instead of RAYLEIGH
And then I did exactly what you have also suggested i.e provided attenuation length.
However, I only used one energy, so I am very confused.
Thanks again
I am still confused by your statement ‘you need two data points’?
Would you mind clarifying for me?
In my example I have a monochromatic source e.g., 532 nm. So I use approx 2.2eV.
Are you suggesting I should be using two energy data points?
If that is correct may I understand why is that?
Yes, that’s correct. The material properties are treated as binned histograms. At a minimum, you need to provide two values, a lower edge and an upper edge.
If your simulation spans a broad energy range, you may of course want or need to provide more bins, in order to have some energy dependence. But you need at least one bin (two values) for the code to function.
Thanks mkelsey
Not to belabor more but
- Is this true even if I only generate finally a histogram of e.g., hits in my detector at one energy?
- And do I really need to provide a polarization vector for Rayleigh or by default it associates a random vector. I know that earlier I wasnt providing a vector and nothing worked till I did. But just wanted to confirm that is the case.
-
The data you collect on output has nothing to do with the configuration you are required to provide to Geant4 as input. Material properties, such as the energy dependence for Rayleigh scattering, are part of that input.
-
If your optical photon doesn’t have a specific polarization, I am pretty sure it will be thrown randomly.
Hi mkelsey
Here (see below) is what manual says about Polarization for optical photons. It is a bit confusing!
Am I supposed to generate a random polarization or does Geant4 generates a random polarization if nothing is provided especially for Rayleigh? The reason is that I am getting a weird segmentation fault related to G4PhysicsVector after it tries to access G4OpRayleigh::GetMeanFreePath.
The last segment after OpRayleigh in the debug code shows G4PhysicsVector::Value(double, unsigned long&) const ().
I am unable to understand where this comes from in OpRayleigh getfreepath method. I am providing two energy values and for each energy value provide an RI, Rayleigh att, and absorption coeff.
However, as soon as I comment out the Rayleigh part the code in my geometry the process runs without any issues except I have not simulated Rayleigh scattering. I have been struggling for a while with it. So I was suspecting if this has to do with polarization - which I am not providing. If I do provide a polarization (but in a different script - the current script unfortunately isn’t yet amenable to be provided a polarization the way it is written otherwise I would have figured it out) I can simulate Rayleigh.
And here below is the paragraph from the manual…(please see the last sentence which says ‘may’ and I wonder that only under special circumstances Rayleigh is simulated)
Thanks
rajn
“for the simulation of optical photons to work correctly in GEANT4, they must be imputed a linear polarization. This is unlike most other particles in GEANT4 but is automatically and correctly done for optical photons that are generated as secondaries by existing processes in GEANT4. Not so, if the user wishes to start optical photons as primary particles. In this case, the user must set the linear polarization using particle gun methods, the General Particle Source, or his/her PrimaryGeneratorAction. For an unpolarized source, the linear polarization should be sampled randomly for each new primary photon.”
And then later
"A photon which is not assigned a polarization at production, either via the SetPolarization method of the G4PrimaryParticle class, or indirectly with the SetParticlePolarization method of the G4ParticleGun class, may not be Rayleigh scattered. "
I just debugged and found for some strange reason the Rayleigh scattering and transportation length at the beginning of a run comes out really small…
**PostStepDoIt (after all invocations):
++List of invoked processes
1) Transportation
2) OpRayleigh (Forced)
3) OpBoundary
++G4Step Information
Address of G4Track : 0x2f0a850
Step Length (mm) : 1.319155274396128e-321
Energy Deposit (MeV) : 0
-----------------------------------------------------------------------
StepPoint Information PreStep PostStep
-----------------------------------------------------------------------
Position - x (mm) : 05.928787750094959e-323
Position - y (mm) : 02.964393875047479e-323
Position - z (mm) : 01.319155274396128e-321
Global Time (ns) : 04.940656458412465e-324
Local Time (ns) : 04.940656458412465e-324
Proper Time (ns) : 0 0
Momentum Direct - x : 0.04645599023159565 -0.5415064637741983
Momentum Direct - y : 0.02373615269171397 0.6284388625343595
Momentum Direct - z : 0.9986382908876453 -0.5584221931005997
Momentum - x (MeV/c): 5.435350857096692e-08-6.33562562615812e-07
Momentum - y (MeV/c): 2.777129864930534e-087.352734691652007e-07
Momentum - z (MeV/c): 1.168406800338545e-06-6.533539659277017e-07
Total Energy (MeV) : 1.17e-06 1.17e-06
Kinetic Energy (MeV): 1.17e-06 1.17e-06
Velocity (mm/ns) : 299.1940698602795 299.1940698602795
Volume Name : world world
Safety (mm) : 0 1500000
Polarization - x : 0.8051393721694726 0.6177621878229921
Polarization - y : -0.5926250871362627 -0.1530789678770448
Polarization - Z : -0.02336872866213482 -0.7713214044027618
Weight : 5.179085725750343e+1605.179085725750343e+160
Step Status : Undefined PostStep Proc
Process defined Step: Undefined OpRayleigh
-----------------------------------------------------------------------
++List of secondaries generated (x,y,z,kE,t,PID): No. of secodaries = 0
[Note]Secondaries from AlongStepDoIt included.
#Step# X(mm) Y(mm) Z(mm) KinE(MeV) dE(MeV) StepLeng TrackLeng NextVolume ProcName
1 5.93e-323 2.96e-323 1.32e-321 1.17e-06 0 1.32e-321 1.32e-321 world OpRayleigh
*** Break *** segmentation violation
Anyone?
Is there something unique about Rayleigh that I should be worried about when applying to optical photon?
It seems to be randomly working - must have to do with the way its being called.
Whenever it faults its after the G4PhysicsVector and I do not find any reference for G4PhysicsVector::Value(double, long)…
The only thing I see from the GEANT4 type is G4PhysicsVector::Value(double).
Not sure what is happening!
There was a crash.
This is the entire stack trace of all threads:
#0 0x00007f3a9365e45c in waitpid () from /lib64/libc.so.6
#1 0x00007f3a935dbf52 in do_system () from /lib64/libc.so.6
#2 0x00007f3a9ad12584 in TUnixSystem::StackTrace (this=0x201d170) at /home/ra/GAMOS61/external/root/6.18.00/root/core/unix/src/TUnixSystem.cxx:2400
#3 0x00007f3a9ad14cbc in TUnixSystem::DispatchSignals (this=0x201d170, sig=kSigSegmentationViolation) at /home/ra/GAMOS61/external/root/6.18.00/root/core/unix/src/TUnixSystem.cxx:3631
#4
#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
#6 0x00007f3aace44bee in G4OpRayleigh::GetMeanFreePath(G4Track const&, double, G4ForceCondition*) () from /home/ra/GAMOS61/external/geant4/geant4.10.05.p01.gamos/lib/Linux-g++/libG4optical.so
#7 0x00007f3a9e927d4c in G4VDiscreteProcess::PostStepGetPhysicalInteractionLength(G4Track const&, double, G4ForceCondition*) () from /home/ra/GAMOS61/external/geant4/geant4.10.05.p01.gamos/lib/Linux-g++/libG4procman.so
#8 0x00007f3aa0a62b51 in G4SteppingManager::DefinePhysicalStepLength() () from /home/ra/GAMOS61/external/geant4/geant4.10.05.p01.gamos/lib/Linux-g++/libG4tracking.so
#9 0x00007f3aa0a6567e in G4SteppingManager::Stepping() () from /home/ra/GAMOS61/external/geant4/geant4.10.05.p01.gamos/lib/Linux-g++/libG4tracking.so
#10 0x00007f3aa0a6e03d in G4TrackingManager::ProcessOneTrack(G4Track*) () from /home/ra/GAMOS61/external/geant4/geant4.10.05.p01.gamos/
Thanks
Are you using GAMOS? It is mentioned in your stack trace. If so you should tell us. Have you tried to see if they have a mailing list or other way of getting help?
If you are using Geant4 directly, you’re doing something wrong. Try these:
- setting the polarization of the incident optical photon as done in the extended/optical/OpNovice and OpNovice2 examples
- use the G4OpticalPhysics constructor (see the examples)
- post the code where you define the Rayleigh interaction lengths
Sorry! Yes dsawkey
I am using GAMOS. And I did look up on their forum but found nothing to help me. Been asking questions in their forum too but got no leads yet.
So when I look up the errors the messages do relate to GEANT4 function calls suggesting that I am doing something obviously wrong in GAMOS that is not allowed by GEANT4. Tracing the code it turns out to be the Rayleigh script that determines cross-section or attenuation lengths. …So I am trying to understand the GEANT4 requirements for setting up Rayleigh physics.
In GAMOS its pretty simple to do that which is basically
:MATE_PROPERTIES_TABLE mpt1
:MATEPT_ADD_ENERGIES mpt1 1.17e-6MeV
:MATEPT_ADD_PROPERTY mpt1 RINDEX 1.002
:MATEPT_ADD_PROPERTY mpt1 RAYLEIGH 3703e3cm
:MATEPT_ADD_PROPERTY mpt1 ABSLENGTH 100000*cm
:MATEPT_ATTACH_TO_MATERIAL mpt1 AIR1
Maybe once I look up the examples you are referring to I will get an idea.
Thanks
It looks like you are adding single values for properties which are expected to be binned tables. All of the binned properties must be supplied with at least two values, and two energies: the lower edge and upper edge of the single bin.
Yes I did change it to three values after reading all the suggestions. I gave this just as an example of parameters that I input. But I gave three values for each of those but I still see the same issue i.e., at times the transportation length is few mm’s which is ok even though it does not match the Rayleigh numbers, while at other times it gives small values e-322 mm, and then when this happens, I see a segmentation fault.
I am now wondering if in the script that I am using I see some use of range cuts to get cross-sections. And that is affecting it (even though I am not simulating any secondary particles). Rayleigh is used in both gamma and optical photon. If I do not calculate cross-sections, I am not getting errors. I think it’s some physics feature that I am not simulating correctly …(not a GEANT4 issue other than are we following its protocols?)
Can someone please explain the circumstances for the above quote i.e, when does this happen? If a random polarization is assigned to the photon based on its momentum, why is that a problem for simulating Rayleigh scattering? I have simulated Rayleigh scattering without specifying a photon polarization - even for optical photon as the primary particle. And it has worked until I have started seeing some strange results that has been discussed on this topic in earlier posts. So I would like to know what makes GEANT4 fail to simulate Rayleigh scattering?
Thanks
Optical photons need to be polarized for optical Rayleigh to work. Look at your SteppingVerbose output–the photons are polarized but the particle weight is nonsense.
Just as in Geant4 optical photons are different from gammas, the Rayleigh process for optical photons is different from the Rayleigh process for gammas.
Rayleigh for optical photons works in Geant4. However, in any code that uses it, there are an infinite number of things that could go wrong. I don’t know anything about Gamos or your code/macro so it is not possible to troubleshoot. (You could help us help you by posting your macro. Likely there is a syntax error. (Why is your use of * with units inconsistent?))
Thanks dsawkey
That is a good clue - I was not looking at the weights. I really didn’t understand how the weights were assigned and so I disregarded it but I will look into it.
I can surely share the geometry and .in file.
The actual scripts which are UserActions are interlinked but there is one UserAction which my .in file calls and that is the one which is creating this issue. Maybe I can share it once I can present it in a explanatory format.
As for the units - I see that as long as I specify cms or mms or kms, for absorption the script runs fine. I was trying to see if the units were a cause of these issues especially when I saw the step lengths were so tiny. But I found that whatever value I put for Rayleigh attenuation - the code gives step values always on the order of e-322mm. But it does recognize that I have provided RAYLEIGH parameter because it clearly says the process is OpRayleigh. But why does it ignore my RAYLEIGH inputs are baffling…
When I experiment with just Absorption, it runs fine. High attenuation and low attenuation gets reflected in the step length appropriately. I should next look at the photon weights when that occurs.
Hi, Daren. That’s actually a bug with the forums text formatting. If you look very carefully, on the user’s second line “:MATEPT_ADD . . .”, right after “6”, the MeV is in italics, as is everything after it down to the “RAYLEIGH” line, where “cm” goes back to Roman. His first asterisk got interpreted as “start italic text”, and the second one as “end italic text”. To get everything literal with that bad formatting, he would have had to indent those lines:
MATE_PROPERTIES_TABLE mpt1
MATEPT_ADD_ENERGIES mpt1 1.17e-6*MeV
MATEPT_ADD_PROPERTY mpt1 RINDEX 1.002
MATEPT_ADD_PROPERTY mpt1 RAYLEIGH 3703e3*cm
MATEPT_ADD_PROPERTY mpt1 ABSLENGTH 100000*cm
MATEPT_ATTACH_TO_MATERIAL mpt1 AIR1
I think he used the leading colon on those lines for that purpose, which is a different markup system than the G4 forums uses.
Thanks Mike, good catch. Waiting for the optometrists to re-open here. 
I followed up the lead to ‘weight’=0. Still have not figured out.
I am working on sharing the macrocode. Its a bit complicated for me to distill what I want to show.
But in the meantime again following the above debug information this is what I find in the declaration of G4OpRayleigh:GetMeanFreePath.hh
G4double GetMeanFreePath(const G4Track& aTrack,
G4double ,
G4ForceCondition* );
// Returns the mean free path for Rayleigh scattering in water.
// --- Not yet implemented for other materials! ---
So my question: this means in my case the material not being water would create problem?
And in the definition
OpRayleigh.cc file I find
G4PhysicsOrderedFreeVector* rayleigh =
static_cast<G4PhysicsOrderedFreeVector*>
((*thePhysicsTable)(material->GetIndex()));
G4double rsLength = DBL_MAX;
if( rayleigh != NULL ) rsLength = rayleigh->Value( photonMomentum );
return rsLength;
}
So I am wondering if thePhysicsTable is pointing to a NULL pointer maybe that is why I am getting seg fault?
Also how do I figure out what is DBL_MAX?
Is it exp322 ? Doesn’t explain why I am getting step length of exp-322 though!
Thanks