Laser element 2:: fix #349

[aaadelmann]

Closes #349

The TestLinearBreitWheelerSpectrum timeout was caused by running 22 CAIN-backed regression cases at full statistical resolution. Each case used 250000 Monte Carlo samples, and the joint spectra used full 80 x 80 histograms. The finite photon beam cases were especially expensive because they rebuild the sampling kernel for each event. In practice, the baseline run exceeded the 30 second unit-test budget and was killed after about 280 s.

The fix keeps all 22 regression cases enabled, but converts them to a unit-test-scale resolution. The per-case sample count is reduced to 10000, and the histogram resolution is reduced from 80 bins to 20 bins. For joint spectra,
this changes the grid from 80 x 80 to 20 x 20.

The CAIN reference CSV files remain stored at the original 80 bin resolution. The test now rebins those references down to the 20-bin unit-test resolution before comparison. This rebinning preserves integrated probability density, so the comparison remains a normalized shape regression rather than a pointwise high-resolution benchmark.

Doxygen comments were added to document the low-resolution validation strategy. The fixed TestLinearBreitWheelerSpectrum now passes through CTest in about 23 s, and the related TestLinearBreitWheeler kernel test also passes.

Missing CAIN reference CSV files are added

[aliemen]

Regarding unit test timings, we see the following. GitHub runner:

53/54 Test #19: TestLinearBreitWheelerSpectrum .....   Passed   74.20 sec
54/54 Test #17: TestLinearComptonSpectrum ..........   Passed  223.74 sec

These tests alone increase total GitHub actions runtime on CPU by roughly 30%. My own debug CPU test gives:

On GH200:

Here, TestLinearComptonSpectrum fails probably because a device view is accessed on host:

[ RUN      ] TestLinearComptonSpectrum.FiniteBeamOverlapAngularSpectrumMatchesCainReference
Kokkos::View ERROR: attempt to access inaccessible memory space (label="")
Backtrace:
[0x596b78] 
[0x557538] 
[0x41c100] 
[0x441a3c] 
[0x430f1c] 
[0x40c540] 
[0x40dd30] 
[0x40024badb404] 
[0x40024badb4d8] __libc_start_main
[0x409df0] 
unknown file: Failure
C++ exception with description "Failed to run finite-beam benchmark command: /capstor/store/cscs/pasc/c41/aliemen/data/opalx-regsuite/builds/laser-element-2/cuda-daint/build/unit_tests/Physics/LinearComptonSpectrumBenchmark /tmp/opalx-linear-compton-90deg-xi029-finite-beam-overlap-theta-histogram.csv --finite-beam --beam-particles 100000 --seed 13579 --overlap-weighting --beam-sigma-longitudinal 0.000299792 --laser-rayleigh 12.5 --laser-sigma-t 0.000299792 --angular" thrown in the test body.

[  FAILED  ] TestLinearComptonSpectrum.FiniteBeamOverlapAngularSpectrumMatchesCainReference (719 ms)

Apart from the error of the unit test on GPU, I suggest reducing the complexity of the unit tests quite a lot. All other unit tests are well under 0.5s (except the distribution tests). I would suggest, trying to get the tests to under 5s on the GitHub runner, otherwise it's probably not a unit test.

As I understand it (correct me if you want), unit tests should be ~ms to <1s and test small functions or interfaces. Integration tests would be max. $\simeq$ 10s. Everything else is a regression test. So if you can't reduce the runtime of these tests, we could also restructure our test folder into something like the following:

tests/
  unit/
    physics/
      ...
  integration/
    physics/
      ...

...and then only run unit/ tests in our GitHub CI pipeline (and put your tests under tests/integration/).

Optimization

If I understand correctly, then this test is a complete CLI system that parses and runs your tests. Every of your 50 or so Compton tests individually starts this program leading to 50 individual ippl::initialize calls and so on. This creates a significant overhead. The full blown CLI system - in my opinion - is not suitable for a unit test. The BreitWheeler test could probably be optimized with way less samples and larger tolerances. But I also see that this test is probably needed, that's why I would size it down as much as possible and then call it integration test? Anyways, I think that it should be possible to test the individual Laser Element functions (which is all unit tests need to do - otherwise it's a regression test) without full blown simulations. If you want, I could look into this.

[aaadelmann]

On my mac in Release mode I have

16/54 Test #16: TestLinearCompton .................. Passed 0.44 sec
Start 17: TestLinearComptonSpectrum
17/54 Test #17: TestLinearComptonSpectrum .......... Passed 17.45 sec
Start 18: TestLinearBreitWheeler
18/54 Test #18: TestLinearBreitWheeler ............. Passed 0.46 sec
Start 19: TestLinearBreitWheelerSpectrum
19/54 Test #19: TestLinearBreitWheelerSpectrum ..... Passed 23.69 sec

** Runtime **
I agree the majority of the tests should be around seconds. I have no problem with a few around 60. Will further
reduce the runtime but first I want to establish a kind of baseline test for the physics.

[aaadelmann]

Can you quickly check if on the A100 we have the same problem?

[aliemen]

I started a run on Gwendolen, but it probably takes some time.

In the meantime: I am pretty sure that it will also show the error, since lines like these cannot run on device when the default execution space/memory space is device. Here you would need an explicit deep_copy to a host mirror.

[aaadelmann]

yes agree will push a fix shortly

[aaadelmann]

Please run again

[aliemen]

(The run on Gwendolen before failed equally - a full build + unit tests + regression always takes well over 1h...)

I merged master into your branch and ran everything on Daint: unit tests and regression test all pass. However, this time the runtime for the unit tests was even worse (I suppose due to Daint-specific performance fluctuations):

[rammann]

Quick question, wouldn't this be better situated in the regression tests? There the long runtime would not be an issue.

[aaadelmann]

In this test we are checking a MC generator. IMO this qualifies to be a unit_test. Will look into ways further reduce the the runtime. In a regression test I would need to run an OPALX input file and test the MC generator, this is not possible at the moment but maybe later when all the pieces are ready.

[aaadelmann]

cscs-ci run cscs-ci-gh200, cscs-ci-mi300, cscs-ci-openmp