Although still a novice, I achieved to implement @evc’s G4CutTubs-based solution
into my ‚world‘ for curve coordinates read from an external file. It works nicely for constant radii.
However, I need to simulate a worm-like structure with radii that vary along the curve. With G4CutTubs I get a very ragged object and I don‘t have a clue how to bevel the surface.
So I dream of a G4CutCons method that would allow to seamlessly stitch cone sections in the same way @evc stitched tube sections by specifying
a disk radius
the surface normal
the surface center coordinates
for the start and end surfaces of a cone cut.
The elliptic half axes of the two surfaces could then be calculated from the disk radius and the vector between the face centers and the surface’s normal vector.
Actually, I have no clue how complicate the implementation of such an G4CutCons method would be.
Can anybody give advice or knows of a simpler approach?
Thanks,
Asmus
Geant4 Version: 11.0.4
Operating System: Ubuntu and Ubuntu in WSL
Compiler/Version: g++
A relatively simple way to implement a cut cone is to use boolean operations. For example, a cut cone can be implemented as a G4IntersectionSolid object between G4CutTubs and G4Cons:
In another post you mentioned that boolean volumes are costly with respect to CPU time.
Sorry for being (still) so ignorant:
Do I have to pay this ‚price‘ only during geometry setup or during each single particle tracking step?
As I need to stitch a few hundred of these segments: Are there factors of higher CPU load to be expected compared to working with ‚native‘ volumes like G4CutTubs?
In another post you mentioned that boolean volumes are costly with respect to CPU time.
Yes, calculations in boolean solids take more time in comparison with ordinary simple solids, like a box or a tube. But implementation of a custom solid can be quite a complex task.
Do I have to pay this ‚price‘ only during geometry setup or during each single particle tracking step?
Geometry setup usually does not take much time, nothing to worry. Boolean solids can slow down the particle transposporation. For this reason boolean solids should be used only where it is really necessary and they should not have many constituents.
As I need to stitch a few hundred of these segments: Are there factors of higher CPU load to be expected compared to working with ‚native‘ volumes like G4CutTubs?
It depends. If all segments are built from Boolean solids with two constituents, then the CPU load can increase, I would expect, by 2 times. But if the boolean solid will be used only in few places, then the difference may be very small.
Modelling ‘few hundred segments’ should not be a problem in either case.
Here there is another issue, I’m afraid that in your case the cut cones will not work, since the elliptical sections at the turning points will not match each other.
A possible solution might be to use cut tubes at the turning points of the polyline, and cones along the straight sections.
