Direction Bias With Using Ion To Generate Primary Particle In GPS

[Odera-Dim]

Hi all,

I am trying to bias the direction of particles generated from a Co60 source. I have something like this:

# ----------------

# Particle definition
/gps/particle ion
/gps/ion 27 60 0 0
/gps/energy 0.0 eV

# Angle direction
/gps/ang/type iso
/gps/ang/maxTheta 5. deg  # using the default thetaMin, minPhi & maxPhi
/gps/ang/rot1 1 0 0
/gps/ang/rot1 0 1 0

# ----------------

However, when I run the simulation it seems particles are emitted in an isotropic fashion based on tracks shown on Qt Viewer. Please I will appreciate any help I can get in this regard. Thanks.

[mkelsey]

So you’ve told GPS to use an ion at rest, while RadioactiveDecay is doing the generation of the decay secondaries. Since the ion is at rest, the GPS angle direction is irrelevant.

If you want to bias the decay secondaries, you may need to use a biasing wrapper process around RadioactiveDecay.

[Odera-Dim]

Thanks so much for your response.

That makes a lot of sense. I am not familiar with the G4ProcessWrapper or how to use it for my application. Please do you have any examples you can direct me to which implements something similar? I am assuming that this will be done in my physics class?

[mkelsey]

Hmmm. There are only two places I found in all of the examples where a G4WrapperProcess is used: advanced/ChargeExchangeMC and extended/medical/dna/splitting.

There is documentation for it in the Biasing section of the App Guide: Event Biasing Techniques — Book For Application Developers 11.0 documentation

[Odera-Dim]

Thanks for the reference examples. They will be very useful. Cheers.

[Odera-Dim]

Actually, I have one more related question.

The G4WrapperProcess seems to be implemented strictly with the G4VUserPhysicsList.hh class. Is there a way to use the wrapper class with G4VModularPhysicsList and if so how? Thanks.

[mkelsey]

G4VModularPhysicsList is a subclass of G4VUserPhysicsList. There’s no constraint on what kind of physics list you’re building. In our experiment, we use G4WrapperProcess within a physics builder, which is independent of the final physics list.

[Odera-Dim]

Yes thats accurate. I am just unable to define a particle iterator in the ConstructProcess() method of my Physics class. Each time I write a ParticleIterator to facilitate accessing the gamma particle and attaching the G4WrapperProcess to it, I get a segmentation fault. The segmentation occurs right at the start of the while statement:

while((*particlIterator)())
{
}

However, since there are no examples done with G4VModularPhysicsList I am not experienced enough to tell where my approach is failing. Any additional help in this regards will be appreciated. Cheers.

[mkelsey]

Ah, I see! Yes, the G4VModularPhysicsList provides that as a predefined shortcut. If you write a physics builder (subclass of G4VPhysicsConstructor), you can call GetParticleIterator() to get the iterator you need (store it in a local variable, and use that variable in the while() loop).

You can also get the particle iterator yourself, directly from the particle table:

auto* pdIter = G4ParticleTable::GetParticleTable()->GetIterator();
while ((*pdIter)())

[Odera-Dim]

Thanks for this suggestion. I tried it and still got a segmentation at that same line. I had tried something similar previously from the examples which looked something like:

which is what I think you suggested above as the first way

 auto particleIterator=GetParticleIterator();
 particleIterator->reset();

 while( (*particleIterator)() )
 {

    G4ParticleDefinition* particle = particleIterator->value();
    G4ProcessManager* pmanager = particle->GetProcessManager();
}

However,

it seems the iterator behaves as some sort of vector and needs to be reset on each function call. The moment I added the particleIterator -> reset() I didn’t receive the segmentation fault anymore.

Summary is any of the methods you suggested would have worked but that iteration reset call must be fired on each call. Thanks again.