runXRayBenchmark.cxx File Reference

X-ray / geantino transport benchmark: ordered crossing lists, by stepping. More...

#include "RepresentationBench.h"
#include "XRayTransport.h"
#include "CADSupport/O2SolidHarness.h"
#include "CADSupport/O2BVHSurfaceSolid.h"
#include "DetectorsBase/O2Tessellated.h"
#include "CADSupport/O2FlatCSG.h"
#include "CADSupport/O2SurfaceSolidIO.h"
#include "TGeoBBox.h"
#include "TGeoManager.h"
#include "TGeoMaterial.h"
#include "TGeoMatrix.h"
#include "TGeoMedium.h"
#include "TGeoNavigator.h"
#include "TGeoNode.h"
#include "TGeoSphere.h"
#include "TGeoTube.h"
#include "TGeoVolume.h"
#include <nlohmann/json.hpp>
#include <algorithm>
#include <array>
#include <cctype>
#include <chrono>
#include <cmath>
#include <cstdio>
#include <fstream>
#include <iostream>
#include <memory>
#include <set>
#include <sstream>
#include <string>
#include <vector>

Go to the source code of this file.

Typedefs
using	json = nlohmann::json

Functions
int	main (int argc, char **argv)

Detailed Description

X-ray / geantino transport benchmark: ordered crossing lists, by stepping.

Author

Sandro Wenzel sandr.nosp@m.o.we.nosp@m.nzel@.nosp@m.cern.nosp@m..ch

Since

2026-08

Built as o2-bench-cadsupport-xray.

WHY THIS EXISTS, in one paragraph. Everything the oracle gate measures is a single-shot query: from a sampled point, how far to the surface. A transport loop is different in kind – step, land on the boundary, step again from there – and that is where geometry navigation actually fails: zero-length steps, ping-ponging on a face, a particle that enters and never exits, a crossing found twice, a step that overshoots into the next volume. None of those can be expressed as a disagreement on distout from an interior sample, so the existing gate is structurally blind to all of them. This benchmark shoots a structured parallel-beam raster through a part and produces, per ray, the ORDERED CROSSING LIST – the sequence of entry/exit distances – by stepping, two independent ways, and compares the lists (not aggregates) against OpenCascade.

TWO STEPPING MODES, and the reason both exist: (a) shape – a direct shape-API loop: Contains() to establish the starting state, then alternating DistFromOutside()/DistFromInside(), advancing the point, until the ray leaves the raster window. Depends on nothing but the shape. (b) nav – the real TGeoNavigator: the part placed in a TGeoVolume inside a minimal world, transported with FindNextBoundaryAndStep(). The production path. If (a) and (b) disagree, that isolates the shape from the navigator immediately; with only (b) one cannot tell which of the two lied. Both are always reported.

THREE-STAGE ROUND TRIP, mirroring the oracle gate:

1. --dump-rays D writes D/xrays_<part>.json: the raster window and every ray.
2. xrayOracle.py answers exactly those rays from the part's .brep, in OpenCascade, into D/crossings_<part>.json.
3. --ref-crossings D steps both modes over the same rays and scores the lists. The rays are written and read rather than regenerated on both sides for the same reason the sample sets are: a comparison is only evidence if both sides answered the same question.

NOT REQUIRED: a tessellated mesh. The raster is structured and deterministic, so unlike generateSamples() nothing here rejection-samples through O2Tessellated. That is what makes this instrument runnable on a model whose meshing does not fit in memory.

Definition in file runXRayBenchmark.cxx.

Typedef Documentation

json

using json = nlohmann::json

Definition at line 87 of file runXRayBenchmark.cxx.

Function Documentation

main()

int main	(	int	argc,
		char **	argv
	)

Definition at line 1586 of file runXRayBenchmark.cxx.