Accessing GPS parameters in run action

[nicconflo]

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!

[ctwhite]

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.

[atolosad]

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

[nicconflo]

Thanks for your input! I’m able to access GPS info in EndOfRunAction, but there seems to be a segmentation fault after executing EndOfRunAction that I can’t quite figure out.

I accessed GPS in my run action via:

auto rMan = G4RunManager::GetRunManager();
auto pg = rMan->GetUserPrimaryGeneratorAction();
auto source = dynamic_cast<const SimPrimaryGenerator*>(pg);

Which doesn’t throw any errors unless accessing info like below:

G4cout << source->GetGPS()->GetCurrentSource()->GetNumberOfParticles() << G4endl;

which will execute, but lead to a seg fault. The relevant code in the generator action is:

public:
auto GetGPS() const { return gps; }
private:
G4GeneralParticleSource *gps = nullptr;

Does anyone have suggestions on how to solve this?

[mkelsey]

Which thread is throwing the segfault? Unless you included your PrimaryGeneratorAction in ActionInitialization::BuildForMaster(), the master thread isn’t going to have a primary generator action.

You can protect your code against this using if (source).

[nicconflo]

You were exactly right! The master thread was throwing the fault, and adding that snippet of code fixed it. Thanks a bunch!