Recent posts
#1
Evolution Proposals & Ideas / Re: Phase space I/O
Last post by didier.benoit - Jun 16, 2026, 09:24 AMThank you for the suggestion. This is planned for GGEMS 2.
We want to support phase-space output for individual photons, and also allow simulations to be launched again from saved phase-space data. This would make user-defined binning, energy-resolved detection, and custom post-processing much easier.
The implementation details are not fixed yet, but this use case is clearly part of the GGEMS 2 roadmap.
We want to support phase-space output for individual photons, and also allow simulations to be launched again from saved phase-space data. This would make user-defined binning, energy-resolved detection, and custom post-processing much easier.
The implementation details are not fixed yet, but this use case is clearly part of the GGEMS 2 roadmap.
#2
Evolution Proposals & Ideas / Phase space I/O
Last post by pryden - Jun 14, 2026, 07:18 PMIt would be nice to be able to have more I/O formats available for simulations, in particular an option to output the phase space of the individual photons, and to launch a simulation from the same. Among other things, that would in turn allow users to bin the final photon states as they please, and implement things like energy-resolved detection...
#3
Geometry, Material & Navigation / Re: Design the material of CT ...
Last post by didier.benoit - Jun 02, 2026, 12:41 PMHello,
You do not need to modify GGEMSCTSystem.cc. The detector material can be set directly from the Python interface using the set_material() method:
Replace 'GOS' with the name of the material you want to use from the GGEMS material database.
You can print information about the GGEMS material database using:
You do not need to modify GGEMSCTSystem.cc. The detector material can be set directly from the Python interface using the set_material() method:
Code Select
ct_detector.set_material('GOS')Replace 'GOS' with the name of the material you want to use from the GGEMS material database.
You can print information about the GGEMS material database using:
Code Select
ggems.material_database_verbose(True) #4
Geometry, Material & Navigation / Re: Setting source detector di...
Last post by didier.benoit - Jun 02, 2026, 12:35 PMIn GGEMS v1.3, the detector elements have a finite thickness, and the detector position is defined using the centre of the detection element along the source–detector direction.
Therefore, if the intended source–detector distance corresponds to the entrance surface of the detector, half of the detection element depth must be added in order to place the centre correctly.
For example, with a detector element depth of 1.0 mm and a desired distance of 1500.0 mm to the detector entrance surface:
This correction concerns the detector element depth along the source–detector axis, not its in-plane pixel dimensions.
Therefore, if the intended source–detector distance corresponds to the entrance surface of the detector, half of the detection element depth must be added in order to place the centre correctly.
For example, with a detector element depth of 1.0 mm and a desired distance of 1500.0 mm to the detector entrance surface:
Code Select
cbct_system.set_source_detector_distance(1500.0 + 0.5, 'mm')This correction concerns the detector element depth along the source–detector axis, not its in-plane pixel dimensions.
#5
Geometry, Material & Navigation / Design the material of CT dete...
Last post by julienzzzz - May 22, 2026, 06:54 PMHello, Does anyone know how to change the material of CT detector. I only found GGEMSCTSystem.cc, but it seems not the right one.
#6
Geometry, Material & Navigation / Setting source detector distan...
Last post by mwj12 - May 20, 2026, 12:07 AMWhy in the v1.3 instructions on CT/CBCT systems does it say to add half the size of a detector element when setting the source-detector distance? Why would there be a need to do that?
Code Select
# Do not forget to add half size of detection element !!!
cbct_system.set_source_detector_distance(1500.5, 'mm') #7
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?
#8
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) #9
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.
#10
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.