Messenger for PrimaryGeneratorAction class

Dear all,

I tried to add a Messenger class for my Primary Generator Action, in the same way i did for other classes, like Detector Construction.

The code compile and run. In the left tree of the Qt GUI I can see the commands of the messenger in the right folder and I can call them from the GUI.

But when i call a command of this messenger nothing happens! (the others work fine)
To debug it, I tried to add a “cout” statement in the “setNewValue” method but nothig is printed out, so this method is not executed when i call the command and no errors occours!

Could you confirm that it is possble to create a Messenger for the Primary Generator class?
What could be the problem?

Thank you for your help!


Yes, it’s of course possible. It’s best if you have a look at the examples provided with G4, maybe they will suggest what is the problem (do you create a messenger in your primary gen. action class?). Many examples include a primary generator messenger (you can run find <G4_SOURCE>/examples/ -name *PrimaryGeneratorMessenger.hh) but I suggest you start with those dedicated to the event generation:

  • examples/extended/eventgenerator/particleGun
  • examples/extended/eventgenerator/HepMC


Thank you for your answer!
I took a look at the examples and I tried to compile the eventgenerator/particleGun.

If I put a G4cout or an std::cout in the method setNewValue of the PrimaryGeneratorMessenger of the example, no output is printed when the method is called!
And also if I put these statements in the function of the PrimaryGenerator that is called in the setNewValue…

But the method is called because the value is correctly set.

And this also happens in my application. I don’t know why I haven’t seen that, but the values are correctly set.

Do you know why the cout doesn’t works for this messenger?

Thanks a lot

Can you post the code that you added and doesn’t work? Otherwise, it’s hard to tell. Maybe it’s after the return statement, or inside one of the if loops?

I have modified the code in this way:


void PrimaryGeneratorMessenger::SetNewValue(G4UIcommand* command, G4String newValue) {
std::cout << “Set New Value” << std::endl;
if (command == fSelectActionCmd)

And in PrimaryGenerator.hh

void SelectAction(G4int i) {
fSelectedAction = i;
G4cout << “\nPGAction\n”;
std::cout << “\nPGAction\n”;

I have used cout statements like these in other messenger classes to give feedback on the value set and they work fine. Only in the primary generator messenger doesn’t work.

You’re missing G4endl and std::endl to flush the buffer (besides adding a newline character). If they are never flushed after that, they won’t be printed.

I am not sure why you wouldn’t see that. Are you sure you do not miss it in a usually busy sim output? And since you are using std::cout and not G4cout, are you sure you do not look for it e.g. in the visualisation window?

And as a general tip, the best way to check what happens inside your application is to use debugging tools like gdb (instead of cout statements). You’d need to compile your application in debug mode and run it telling where do you want to set a “breakpoint”.
For the example particleGun:

$ cmake -DCMAKE_BUILD_TYPE=Debug ..
$ make
$ gdb --args particleGun run1.mac
(gdb) break PrimaryGeneratorMessenger::SetNewValue(G4UIcommand*, G4String) 
(gdb) run

Once it pauses your simulation you can do many things, like print newValue to see the arguments of that function, etc. Or just be satisfied it reached that function. For more have a look at the documentation of gdb.

About the G4cout you are right, but it should be printed when the next G4cout is called and this not happens.
About the std::cout, the string is printed on the shell also without the std::endl.

I have tried to use both G4 and std cout to be sure that the issue wasn’t with the type of cout and i have checked both the Qt GUI and shell window.

There are no output from the simulation because i only called the messenger command.

I use the cout not only for debug but also to have feedback during the execution of the application, but I full agree that for debugging, use a debugger is a better choise…