detected photon nscat distribution shows abnormalities

[fangq]

This issue was reported by Robin van Zutphen in the following mailing list post

https://groups.google.com/g/mcx-users/c/AUv9jgCX5RQ

the following test code shows an abnormal bump in the nscat distribution; we confirm that this result is reproducible.

cfg.nphoton = 1e7;
cfg.vol = uint8(ones(60, 60, 60));
cfg.gpuid = 1;
cfg.autopilot = 1;
cfg.tstart = 0;
cfg.tend = 5e-9;
cfg.tstep = 5e-9;
cfg.unitinmm = 1;

 

% Source
cfg.issrcfrom0 = 1;
cfg.srctype = 'disk';
cfg.srcparam1(1) = 1;
cfg.srcpos=[30 30 0];
cfg.srcdir=[0 0 1];
cfg.isreflect = 0;

% Medium
cfg.prop = [0 0 1 1; 0.1 25 0.9 1.37];

 

% Detector
cfg.savedetflag = 'dspvx';
cfg.maxdetphoton = 1e7;
cfg.detpos = [30 30 0 1];

% cfg.bc = 'aaaaaa001000';
cfg.bc = 'aaaaaa000000';

[fluence,det,vol,seeds,traj] = mcxlab(cfg);

figure;
subplot(211)
histogram(det.nscat)
subplot(212)
histogram(det.nscat)
xlim([2.6e4 3e4])
ylim([0 2.5e4])

[fangq]

We have identified that this abnormal distribution was introduced in this commit (198cd34) on Aug. 3, 2023. All releases since then, including v2023 and v2024.2 contains this defect

specifically, this behavior was caused by this single line of code change

198cd34#diff-a7174ac70bbab6b4d406c2a4ee9adc2c277c27d91c5eb874537219ea62145ddaL1015-R1016

-   if (p->w >= 0.f) {
+   if (fabsf(p->w) > 0.f) {

what happened was that the above commit excludes photon-packets that had numerically dropped its weight to 0 after many many scattering/long paths. In the above sample code, there are about 82 photons out of 3811706 detected photons were excluded. Because of this truncation, somehow the distribution became skewed - it is interesting to plot the nscat histogram in log-y scale, and this shows strange histogram structures, see

despite that this looks strikingly incorrect, in practice, I do not believe this is a big issue (as long as the data are properly analyzed).

First of all, the affected photon packets are small - they are extremely long path photons and float32 weight drops to numerical zero after over 20000 times of scattering calculations;

secondly, when a user analyze such long path or large-scattering-count photons, they should use the corresponding weight to properly weight the contribution; because these packets have nearly zero weight, they literally do not contribute to any of the statistical quantities.

regardless, reverting this line back to >= 0.f fixed the strange nscat distribution shape.

after fix, now it looks like this (in log-y scale)