why some UI commands must be put after /run/initilize ?
if I want to put it before /run/initilize, what should I do?
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();
}
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.
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.
HelloďźWhat if i want to change the position while changing the thickness?