Parameterisations with material changes are silently ignored

[sethrj]

Although we support some simple parameterised/replicated volumes (see #25, #26, #27) we only copy the placements; we do not check that the solids or materials have changed. We also do not explicitly check for the use of built-in parameterisations versus user-defined. We might need another dispatch mechanism like we have for G4VSolid that allows us to exclude user definitions.

@michele-colle

See this parameterisation which is taken from an official Geant4 example:
https://github.com/michele-colle/CBCTSim/blob/main/ICRPinclude/ICRP110PhantomNestedParameterisation.hh

[sethrj]

I talked with @jonapost and it seems G4VNestedParameterisation is indeed the standard way of performing this functionality, and there is no "standard" class to do this. There are a few pros for this method as opposed to providing a specific voxelized volume:

• Greater customizability of course
• Having multiple nested "volumes" representing each axis makes the volume stack (nav history) easier to understand
• Other projects specialized for medical physics already have custom voxelization volumes

A few cons I can think of:

• User-level subclassing makes adapting to other geometry representations (vecgeom, orange) impossible
• Nested volumes, each with thread-local data, will not be as performant as a single parameterization
• Performance improvements that could be shared across implementations have to be rediscovered by each user

[michele-colle]

So for adapting to other geometry it will be sufficient to translate the nested parametrization to a series of basic voxels with the correct materials, dimensions and position. Right?

[sethrj]

I haven't taken a look at the constructed geometry yet (that will be a follow-on) but it's possible that the physical layout of the geometry works with what's in there, although only by chance if all voxels have the same dimensions.

However there is no ability at present for Celeritas or AdePT to get the correct material composition since ComputeMaterial modifies a single LogicalVolume's material so that it changes based on the CPU navigation state. To adapt this to GPU we would have to process additional metadata while converting the geometry, and we would have to add runtime code to use the volume instance/copy number, rather than the logical volume.

If the parameterised volume's solid does change shape (e.g., if your voxels are nonuniform), there is additional work to be done.

As a temporary workaround you could manually construct separate g4 volumes for each voxel of a different material and shape. This would likely have an adverse effect on performance. 😞

[michele-colle]

I think the voxels are all cubes, but in fact for the whole phantom (i need just pieces of it) is about 245x127x220 ~= 7M voxels, they are not that many, I don't know how big a G4Material can be but i doubt that the whole GPU memory is going to be filled easily.
If I may ask, why do you think separate volumes will cause a slowdown?

[sethrj]

The worst case is having to create a new vecgeom LogicalVolume and solid for every voxel; those are not lightweight objects and in fact are quite expensive to construct on GPU due to an implementation choice in VecGeom. (ORANGE doestn't have the same limitaiton.)

The performance impact would come from having to use general geant4 navigation (or vecgeom BVH or orange BIH) rather than specialized navigation for the parameterised volumes.

Is it possible with the paramterisation to have a separate logical volume for each different material? This case might work without any code changes to vecgeom/celeritas/adept.

[michele-colle]

So thinking about the skeleton as an example do you mean taking only it's voxels and place it all together in a skeleton logical volume (doable) or "merging" the voxels into one single complex structure (scary)? Il mer 22 ott 2025, 18:17 Seth R. Johnson ***@***.***> ha scritto:

…

*sethrj* left a comment (celeritas-project/g4vg#39) <#39 (comment)> The worst case is having to create a new vecgeom LogicalVolume and solid for every voxel; those are not lightweight objects and in fact are quite expensive to construct on GPU due to an implementation choice in VecGeom. (ORANGE doestn't have the same limitaiton.) The performance impact would come from having to use general geant4 navigation (or vecgeom BVH or orange BIH) rather than specialized navigation for the parameterised volumes. Is it possible with the paramterisation to have a separate *logical* volume for each different material? This case might work without any code changes to vecgeom/celeritas/adept. — Reply to this email directly, view it on GitHub <#39 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BRQ4U33IDY52T3RYCO6XFN33Y6UYDAVCNFSM6AAAAACJ4XNXWGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTIMZTGE4TQOJVGE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[sethrj]

Haha the first option: you'd have O(100K) placements of the same skeleton "logical volume", for example.

[michele-colle]

I'll try, tanks as always for your time. By the way I can't find much information about orange surfaces, maybe the second option can be an interesting speedup due to less boundaries in the volume, can you please point me to some documentations/examples? Il giorno mer 22 ott 2025 alle ore 19:30 Seth R. Johnson < ***@***.***> ha scritto:

…

*sethrj* left a comment (celeritas-project/g4vg#39) <#39 (comment)> Haha the first option: you'd have O(100K) placements of the same skeleton "logical volume", for example. — Reply to this email directly, view it on GitHub <#39 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BRQ4U32544I7DLEHKKCTZWT3Y65JRAVCNFSM6AAAAACJ4XNXWGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTIMZTGQ2DEMRZGU> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[sethrj]

ORANGE is constructed automatically if you have the CELERITAS_CORE_GEO cmake variable set to ORANGE (you can do with or without having vecgeom enabled), so you don't really have to know much about how it works. However the ORANGE geo page of the celeritas docs have some level of detail about the construction.

[sethrj]

@michele-colle I've thought of a couple ways we could circumvent this issue for vecgeom (and ORANGE). Are you comfortable submitting a pull request with a minimal example of a voxelized geometry with multiple materials built in the same way as your CTBT sim? (Minimal means having all the necessary complications but on a smaller scale. So you might for example have 2 x 3 x 5 voxel levels with 7 materials that might just be different densities of water. Using prime numbers for the dimensions can help make sure we're getting the placement and conversion correct.)

You'd basically apply the following patch, add the necessary includes, and move a highly simplified version of your detector construction into VoxelTestBase::build_world.

diff --git a/test/Custom.test.cc b/test/Custom.test.cc
index 0233736..60016e2 100644
--- a/test/Custom.test.cc
+++ b/test/Custom.test.cc
@@ -104,6 +104,27 @@ TEST_F(DisplacedTestBase, default_options)
     result.expect_eq(ref);
 }
 
+//---------------------------------------------------------------------------//
+class VoxelTestBase : public CustomTestBase
+{
+  protected:
+    std::string basename() const final { return "voxel"; }
+    G4VPhysicalVolume* build_world() final;
+};
+
+G4VPhysicalVolume* VoxelTestBase::build_world()
+{
+    // Add more code here!
+}
+
+
+TEST_F(DisplacedTestBase, default_options)
+{
+    auto result = this->run(Options{});
+
+    result.print_ref();
+}
+
 //---------------------------------------------------------------------------//
 }  // namespace test
 }  // namespace g4vg