Recent posts
#1
Particles, Track & Event / Influence of OneDrive on simul...
Last post by mwj12 - Jan 25, 2026, 01:27 AMMy simulation scripts and outputs live in a OneDrive folder. I find that when I suspend OneDrive syncing, simulation speed triples. This seems to suggest that performance is dominated as much by fie I/O as particle tracking. Does this make sense?
#2
Geometry, Material & Navigation / Are detector rotations applied...
Last post by mwj12 - Jan 23, 2026, 06:30 PMDoes anyone have the exact formula for the location (in world coordinates) of the center of a flat CT detector as a function of its 8 pose parameters (rx,ry,rz,tx,ty,tz,SDD,SID)
I am trying to position a CBCT detector perpendicular to the world y-axis and with a translational offset of -160 mm along the world x-axis. I am having difficulty doing this, partly because I am not sure in what order the translations and rotations are executed. The transformation might have the form,
B = Rz*Ry*Rx * ( A - [tx;ty;tz ])
or it might be,
B = Rz*Ry*Rx*A - [tx;ty;tz]
Here is what I have done currently:
Code Select
cbct_system = GGEMSCTSystem('detector')
cbct_system.set_ct_type('flat')
cbct_system.set_source_detector_distance(SDD)
cbct_system.set_source_isocenter_distance(SID)
cbct_system.set_rotation( rx,ry,rz)
cbct_system.set_global_system_position(tx,ty,tz);
I am trying to position a CBCT detector perpendicular to the world y-axis and with a translational offset of -160 mm along the world x-axis. I am having difficulty doing this, partly because I am not sure in what order the translations and rotations are executed. The transformation might have the form,
B = Rz*Ry*Rx * ( A - [tx;ty;tz ])
or it might be,
B = Rz*Ry*Rx*A - [tx;ty;tz]
Here is what I have done currently:
Code Select
detectorNavigator_1 = GGEMSCTSystem('L1')
detectorNavigator_1.set_ct_type('flat')
detectorNavigator_1.set_number_of_modules(1, 1)
detectorNavigator_1.set_number_of_detection_elements(191, 255, 1)
detectorNavigator_1.set_size_of_detection_elements(1.5520, 1.5520, 0.7000, 'mm')
detectorNavigator_1.set_material('CsI')
detectorNavigator_1.set_source_isocenter_distance(1000.0, 'mm')
detectorNavigator_1.set_source_detector_distance(1500.0, 'mm')
detectorNavigator_1.set_global_system_position(-160.0, 0.0, 0.0, 'mm')
detectorNavigator_1.set_rotation(0.0, 0.0, 90.0, 'deg')
detectorNavigator_1.set_threshold(20.0, 'keV')
detectorNavigator_1.save(r'mhdData\PELVIS_001_NoMetal\DLI L1\proj_0001')
detectorNavigator_1.store_scatter(True) #3
Output Data / Re: CBCT simulation output ex...
Last post by zhenguo - Dec 18, 2025, 05:09 AMDear Administrator,
Thank you very much for your detailed explanation! Your reply clearly pinpoints the core of the issue — the geometry engine of GGEMS v1.3 does not support hierarchical parsing of nested meshes. The outer centrifuge tube intercepts the rays first, causing the inner soil cylinder to fail detection. This has fully clarified the experimental phenomena I observed earlier and saved me from making futile attempts at STL positioning adjustments.
Learning that the upcoming GGEMS v2 will introduce a unified geometric framework with support for hierarchical structures and overlap handling, I am truly looking forward to it! Accurate representation of nested meshes is crucial for my experiments involving the co-simulation of centrifuge tubes and their internal samples. I believe the new version will perfectly resolve the current limitations and make the simulation results more consistent with real-world scenarios.
May I take the liberty to ask if there is a tentative release timeline for GGEMS v2? For instance, will a beta or official version be launched in the near future?
Thank you again for your prompt response and professional insights. I sincerely anticipate the release of GGEMS v2 and will keep a close eye on all updates of the software.
Thank you very much for your detailed explanation! Your reply clearly pinpoints the core of the issue — the geometry engine of GGEMS v1.3 does not support hierarchical parsing of nested meshes. The outer centrifuge tube intercepts the rays first, causing the inner soil cylinder to fail detection. This has fully clarified the experimental phenomena I observed earlier and saved me from making futile attempts at STL positioning adjustments.
Learning that the upcoming GGEMS v2 will introduce a unified geometric framework with support for hierarchical structures and overlap handling, I am truly looking forward to it! Accurate representation of nested meshes is crucial for my experiments involving the co-simulation of centrifuge tubes and their internal samples. I believe the new version will perfectly resolve the current limitations and make the simulation results more consistent with real-world scenarios.
May I take the liberty to ask if there is a tentative release timeline for GGEMS v2? For instance, will a beta or official version be launched in the near future?
Thank you again for your prompt response and professional insights. I sincerely anticipate the release of GGEMS v2 and will keep a close eye on all updates of the software.
#4
Geometry, Material & Navigation / Source axes conventions
Last post by mwj12 - Dec 17, 2025, 11:52 PMIn the doc on CBCT xray sources, it says "The direction of the generated photons always point to the center of the world. The source has its own local axis." and an accompanying diagram (also attached) shows the source axes (x'-y'-z') in green. Is one of these axes (x', y', or z') meant to represent the "direction of generated photons"?
In the diagram, it looks like the local axis is to be understood as always oriented with x' parallel to the world z-axis, y' parallel to world y-axis, and z' parallel (and antipodal) to the world x-axis. If that is the case, then it would seem that there is no plane in the local axis that is always perpendicular to the direction of photon propagation. And if that's the case, it seems hard to understand how to set the focal spot size dimensions.
In the diagram, it looks like the local axis is to be understood as always oriented with x' parallel to the world z-axis, y' parallel to world y-axis, and z' parallel (and antipodal) to the world x-axis. If that is the case, then it would seem that there is no plane in the local axis that is always perpendicular to the direction of photon propagation. And if that's the case, it seems hard to understand how to set the focal spot size dimensions.
#5
Geometry, Material & Navigation / Re: Is navigator order suppose...
Last post by mwj12 - Dec 10, 2025, 05:58 PMOK, but if that's the case, it sounds like if I list the bowtie first, then a primary photon will propagate correctly, but back-scatter from the CBCT detector can never propagate correctly. A back-scattered photon should encounter the phantom first, but if the bowtie is constructed first in the .py script, it will encounter the bowtie first, based on what you are saying.
#6
Geometry, Material & Navigation / Re: The x'-y'-z' origin for vo...
Last post by mwj12 - Dec 10, 2025, 05:50 PMThanks, but to be clear, If I want the center of the voxel grid at world coordinates (tx,ty,tz), then,
Code Select
set_position(tx, ty, tz, 'mm') is the right thing to do? #7
Output Data / Re: Improving histogramming ef...
Last post by didier.benoit - Dec 10, 2025, 01:41 PMThanks for the suggestion — you are correct that the code in v1.3 performs two atomic additions when a scattered detection occurs, and that this can be reduced to a single atomic operation. However, in GGEMS v1.3 the two histogram buffers have different semantics:
- histogram stores all detected events (primary + scatter)
- scatter_histogram stores only scattered events
Therefore, even when an event is scattered, the total histogram must still increment, because it represents the full projection image as detected by the system. The two buffers are not redundant; they encode different physical quantities. The alternative implementation you propose (only incrementing one buffer and reconstructing the total histogram afterwards) is technically possible, but it would move part of the tally logic outside the kernel and slightly change the meaning of the intermediate results produced during a run. For the design of v1.3, we kept the histogram semantics explicit inside the kernel, even at the cost of an additional atomic operation.
- histogram stores all detected events (primary + scatter)
- scatter_histogram stores only scattered events
Therefore, even when an event is scattered, the total histogram must still increment, because it represents the full projection image as detected by the system. The two buffers are not redundant; they encode different physical quantities. The alternative implementation you propose (only incrementing one buffer and reconstructing the total histogram afterwards) is technically possible, but it would move part of the tally logic outside the kernel and slightly change the meaning of the intermediate results produced during a run. For the design of v1.3, we kept the histogram semantics explicit inside the kernel, even at the cost of an additional atomic operation.
#8
Output Data / Re: CBCT simulation output ex...
Last post by didier.benoit - Dec 10, 2025, 01:34 PMWhat you are observing is expected behaviour in GGEMS v1.3. The geometry engine in this version does not support hierarchical or nested mesh volumes (no mother/daughter relationship, no enclosure detection, and no overlap resolution). All meshed objects are treated as independent top-level volumes. During transport, GGEMS v1.3 evaluates navigators in a flat list, and the first navigator that intercepts the ray "wins". If a mesh volume is fully enclosed inside another mesh volume, the outer volume will always intercept the particle before the inner one. As a result, the enclosed mesh is never queried, and it effectively disappears from the simulation.
This explains why:
- When the cylindrical soil is fully inside the centrifuge tube, it does not appear in the projection.
- When you move it slightly so that it protrudes outside the tube, it becomes visible again (because it can now be the first object intersected by the ray).
This limitation is inherent to the v1.3 geometry system and cannot be resolved by STL positioning alone.
The upcoming GGEMS v2 introduces a unified geometry framework with proper hierarchy and overlap handling, in which nested or enclosed meshes will be correctly represented.
This explains why:
- When the cylindrical soil is fully inside the centrifuge tube, it does not appear in the projection.
- When you move it slightly so that it protrudes outside the tube, it becomes visible again (because it can now be the first object intersected by the ray).
This limitation is inherent to the v1.3 geometry system and cannot be resolved by STL positioning alone.
The upcoming GGEMS v2 introduces a unified geometry framework with proper hierarchy and overlap handling, in which nested or enclosed meshes will be correctly represented.
#9
Geometry, Material & Navigation / Re: Is navigator order suppose...
Last post by didier.benoit - Dec 10, 2025, 01:30 PMIn GGEMS v1.3, the order in which navigators are defined does affect the simulation, especially when volumes overlap or one volume lies inside the bounding box of another. This is expected behaviour for the v1.3 geometry system.
The reason is that v1.3 does not implement a hierarchical geometry (no mother/daughter volumes) and does not perform overlap resolution. All navigators are stored in a simple linear list, and during particle transport the engine queries them in the order they were created.
The first navigator that reports an intersection is taken as the active geometry for that step.
As a consequence:
- If a meshed navigator (bowtie, collimator) is defined before the voxelized phantom, the meshed object is encountered first, and the projection looks correct.
-If the voxelized phantom is defined before the meshed navigators, the phantom intercepts the particles earlier, effectively masking the mesh geometry and producing artifacts.
So the results you observe (Mesh→Vox giving correct projections, Vox→Mesh producing strong artifacts) are consistent with the internal design of v1.3.
This behaviour will be redesigned in GGEMS v2, which will introduce a unified geometry system with proper hierarchy and overlap handling, so that navigator ordering will no longer affect physics results.
The reason is that v1.3 does not implement a hierarchical geometry (no mother/daughter volumes) and does not perform overlap resolution. All navigators are stored in a simple linear list, and during particle transport the engine queries them in the order they were created.
The first navigator that reports an intersection is taken as the active geometry for that step.
As a consequence:
- If a meshed navigator (bowtie, collimator) is defined before the voxelized phantom, the meshed object is encountered first, and the projection looks correct.
-If the voxelized phantom is defined before the meshed navigators, the phantom intercepts the particles earlier, effectively masking the mesh geometry and producing artifacts.
So the results you observe (Mesh→Vox giving correct projections, Vox→Mesh producing strong artifacts) are consistent with the internal design of v1.3.
This behaviour will be redesigned in GGEMS v2, which will introduce a unified geometry system with proper hierarchy and overlap handling, so that navigator ordering will no longer affect physics results.
#10
Geometry, Material & Navigation / Re: Creating geometry componen...
Last post by didier.benoit - Dec 10, 2025, 01:25 PMIn GGEMS v1.3, Python is intentionally minimalistic. It does not manage the geometry, nor introspect lists or containers. Its only role is to create a few objects and pass them to the C++ engine, which performs all simulation work.Therefore, components must be exposed as simple top-level variables so that the C++ core can register them.