Hi all,
Is there a way to access GeneralParticleSource parameters (radius, etc) in my UserRunAction so that they can be written to the output file? I’ve been looking at the documentation and can’t seem to figure out an easy way, so wanted to inquire here if anyone has advice.
Thank you!
It seems that the G4GeneralParticleSource has a GetCurrentSource() member function that returns a G4SingleParticleSource*, which in turn has a GetPosDist() (as well as GetAngDist() and GetEneDist()) member function, which returns a G4SPSPosDistribution* that has a GetRadius() function, as well as other getters for different settings (HalfX, HalfY etc.).
I’ve never used this myself, but it should be possible in the BeginOfRunAction to access this information using these functions.
However I wouldn’t use this to write to the output file, instead I prefer to write a messenger class for the RunAction that can pass this (and more) information. The upside of this approach is that you can be more general in the information contained in the output. The downside is that you have to ensure you update all commands so that things don’t get misnamed, but if you use a script to generate your macro files this problem is alleviated.
Hi @nicconflo
Thank you for your post!
From the GPS object, you can retrieve the current single particle source with the method GetCurrentSource [1].
From the single GPS, you can access the objects that store the position distribution, angular distribution and energy distribution [2]:
inline G4SPSPosDistribution* GetPosDist() const { return posGenerator; }
// Return a pointer to the position distribution generator
inline G4SPSAngDistribution* GetAngDist() const { return angGenerator; }
// Return a pointer to the angular distribution generator
inline G4SPSEneDistribution* GetEneDist() const { return eneGenerator; }
// Return a pointer to the energy distribution generator
From the G4SPSPosDistribution for example, you may obtain the parameters that you were looking for [3]
const G4String& GetPosDisType() const;
const G4String& GetPosDisShape() const;
const G4ThreeVector& GetCentreCoords() const;
G4double GetHalfX() const;
G4double GetHalfY() const;
G4double GetHalfZ() const;
G4double GetRadius() const;
inline G4double GetRadius0() const { return Radius0; }
inline G4double GetParAlpha() const { return ParAlpha; }
inline G4double GetParTheta() const { return ParTheta; }
inline G4double GetParPhi() const { return ParPhi; }
inline const G4ThreeVector& GetRotx() const { return Rotx; }
inline const G4ThreeVector& GetRoty() const { return Roty; }
inline const G4ThreeVector& GetRotz() const { return Rotz; }
inline G4bool GetConfined() const { return Confine; }
inline const G4String& GetConfineVolume() const { return VolName; }
const G4ThreeVector& GetSideRefVec1() const;
const G4ThreeVector& GetSideRefVec2() const;
const G4ThreeVector& GetSideRefVec3() const;
const G4String& GetSourcePosType() const;
const G4ThreeVector& GetParticlePos() const;
There is however a corner case which I believe it is not contemplated in the current status: a GPS may be made up of several single GPS. One could configure the mother GPS to trigger all the single GPS at the same time. I will open a bugzilla ticket to crosscheck. I hope that is not your case.
Thank you for your time.
Best,
Alvaro
[1] geant4/source/event/include/G4GeneralParticleSource.hh at 20a218bbe1d8b4a78f819e396f8be615e6a38358 · Geant4/geant4 · GitHub
[2] geant4/source/event/include/G4SingleParticleSource.hh at 20a218bbe1d8b4a78f819e396f8be615e6a38358 · Geant4/geant4 · GitHub
[3] geant4/source/event/include/G4SPSPosDistribution.hh at 20a218bbe1d8b4a78f819e396f8be615e6a38358 · Geant4/geant4 · GitHub