UI commands used in the .mac file

why some UI commands must be put after /run/initilize ?
if I want to put it before /run/initilize, what should I do?

1 Like

Some UI commands are only created (instantiated in the code) after the geometry is built, or after the processes are instantiated. Those are the actions that /run/initialize does. You cannot move them to before /run/initialize.

thanks,mkelsey. The problem that I faced is that I try to use the new UI command(such as /rotPhantom/angleDeg 60 deg) to change the geometry(in fact, it is a phantom) after the beamOn and then use the beamOn command again. However it doesn’t change, the two runs has similar results which told me the gemetry didn’t change.

it is the main file
exampleB3b.cc (2.8 KB)

If this is in one of the examples, can you be specific about which example you’re running and which macro file from the example you’re using?

Generally, geometry commands can be used before /run/beamOn or before /run/initialize, because the geometry constructor has been instantiated (it’s in your main()), and the macro commands set parameters to be used when building the geometry.

Other commands, like command to configure sensitive detectors, may not exist until after /run/initialize.

The problem you’re describing will require actually looking at the code. You can find where the macro command is defined by searching the .cc files of your application for the “angleDeg” string, then looking to see where and when that class is instantiated.

the class is instantiated in my detectorconstruction.cc, just like the example B5.

this is my code. I have debug it for a day. I searched many materials(your answers a lot) but I still cannot solve it. It’s my pleasure for get your help.
B3DetectorConstruction.cc (7.1 KB)

The it should work before /run/initialize. At this point, this is debugging your specific application. You can follow the code by looking at the source files directly, or you could use GDB or some other debugger for your platform.

See what the macro command triggers (it’ll be in the SetNewValue() function). Make sure that whatever that does actually affects your DetectorConstruction class, and that the parameter setting wasn’t already used before the Messenger class was instantiated.

void B3DetectorConstruction::SetAngle(G4double val)
{
  rotmAngle = val;
  // tell G4RunManager that we change the geometry
  G4RunManager::GetRunManager()->GeometryHasBeenModified();
}

this only tells the RunManager that it has changed something, without actually doing so…
I just have a snipped changing the thickness of someVolume, maybe this helps getting you on track:

void DetectorConstruction::setThickness(G4double thickness) {
    G4GeometryManager::GetInstance() -> OpenGeometry();
    auto sV = static_cast<G4Box*>(G4LogicalVolumeStore::GetInstance()->GetVolume("someVolume")->GetSolid());
    sV->SetYHalfLength(thickness);

    G4RunManager::GetRunManager()->GeometryHasBeenModified();
}
1 Like

Thanks, @weller. So does B3DetectorConstruction (or the user’s modified version) build the geometry before creating the messenger? In my simulation framework, we’ve got hundreds of macro commands like this, that can set or adjust various dimensions, materials, etc. in the geometry. They all behave just by calling a “SetParameter()” function somewhere. Those changed values don’t get used at all until /run/initialize, when the geometry actually gets built.

hm, good point. xia mentions to have used /run/beamOn before trying to change the geometry - at this point /run/initialize must have been called - and then /run/beamOn again.
I think it is not possible to /run/initialize twice!?

@mkelsey can you use all these commands both before and after the first beamOn, or how do you rebuild the geometry and everything that depends on it (sensitive detectors, biasing, …) after each command?

In our (CDMS) simulation framework, we don’t rebuild the geometry at each command; that would be ugly and slow down the setup substantially. Instead, we created a /CDMS/updateGeom macro command, which the user is required to use after doing all of their configuration stuff. It’s the command that calls “GeometryHasBeenModified()” and “ReinitializeGeometry()” to do the building. The code behind the command also takes care of the SDs, fields, etc.to avoid stale pointers or memory leaks.

The first time through, the updateGeom can be skipped, since /run/initialize will take care of the build itself on the first pass. But we can make as many changes to the geometry parameters as we want, so long as updateGeom is invoked after them. We can also change the geometry between runs in a single job.

1 Like

image
Hi, guys. I think I have found my code’s bug. In my second run, the global id is still 0, however the local id is 1. what should I do? thanks for all your replies.

I tried to use it twice, but failed.