Fluence artifact / bug when using gaussian source type

[bernhardkaplan]

when using a homogeneous block absorber (without scattering) with a gaussian-type light source, the fluence distribution shows two artifacts:

• concentric circles are visible
• the voxels in the center (along the beam axis) have lower fluence (see attached figure)
  

[fangq]

@bernhardkaplan

are you using the latest (from git) mcx code or a previous release? last year, I fixed a bug related to forward-scattering due to floating point round-off tests, see

cd8f134

if you are using an older release, it would be great if you can try the git version and let me know if this issue still presents.

by the way, what visualization software did you use for the 3D renderings? they look great!

[bernhardkaplan]

@fangq
I'm using the latest version (SHA1 103ab04) from 2015-11-11, so the behavior is still present.
For visualization I use Amira (for hand-guided inspection): http://www.fei.com/software/amira-3d-for-life-sciences/
but I plan to use Python for automated analysis scripts.

[fangq]

can you provide your input file and full command line? also the domain settings.
I will look into this.

[bernhardkaplan]

The mcx command is:
time mcx -A --gategroup 1 --input parameterfile.json -s mcx_output_F1_nphotons5.0e+07_nx100_ny100_nz100_cnt0 --array 0 --reflect 1 --reflectin 0 --normalize 1 --skipradius -2 --outputtype F --seed 0 -H 50000000 --repeat 1 -G 1

the parameter file is here:
https://www.dropbox.com/s/jv4pdd973qsprwf/parameterfile.json?dl=0

and the volume file here:
https://www.dropbox.com/s/v3zuqami2pqcv0z/phantom_volume_F1_nphotons1.0e%2B07_nx100_ny100_nz100_cnt0.raw?dl=0

The parameterfile includes some entries that MCX does not require (but my Python framework around it). I hope that's all you need to reproduce the fluence artifacts - let me know otherwise!

Thanks for looking into this!

[fangq]

@bernhardkaplan, I recently made some significant updates to MCX. One of the updates is to include two new RNGs - POSIX erand48 (period: 2^48-1) and xorshift128+ (2^128-1).

b14ccf1

If you compile mcx with "make", it will now use xorshift128+ RNG as the default.

can you update your software and rerun your test?

Be aware, if you compile MCX with CUDA 7.5 and run the simulation on a Maxwell GPU (9xx), you will get 10x slow-down because of a CUDA bug. We have reported this bug to NVIDIA and it will be fixed with the next driver update. To get MCX work at full speed with a Maxwell GPU, you need to use CUDA 7.0 or CUDA 6.5. Please see this discussion for details

https://devtalk.nvidia.com/default/topic/925630/cuda-programming-and-performance/cuda-7-5-on-maxwell-980ti-drops-performance-by-10x-versus-cuda-7-0-and-6-5/1

Please let me know if this pattern remains when using the new RNG.

[bernhardkaplan]

The updated code has fixed the buggy source pattern - thanks for the fix!

[fangq]

terrific. I am closing this issue for now.

still, we need to figure out what's wrong with the LL5 RNG.

[fangq]

@bernhardkaplan, can you recompile mcx with "make fermi" and rerun your tests?

just want to see if the artifact was caused by the RNG or by the ray-tracer algorithm. thanks

[bernhardkaplan]

when compiled with "make fermi" the buggy pattern reappears

[fangq]

I see. this seems to pinpoint to the old RNG. I have a student who is doing some rigorous RNG tests. will update.

[fangq]

this bug seems to be related to Issues #31, #29 and #26; it is particularly similar to #26.

my guess was that 3 these issues were caused by the same problem that was fixed in #31. The varied shapes of the artifact was a result of the low-quality host (CPU) RNG on Windows on different RNGs:

the hollow center and a line artifact like in #17 and #26 seems to be the logistic-lattice RNG influenced by poor initial RNG states on Windows.

the 4-dot structures like in #31 and #29 are the result of the xorshift128+ RNG influenced by the same bug on Windows.

as a result, this bug actually impacts all previous releases of mcx/mcxlab on windows. When running large photon numbers, the influence of the initial RNG states seems to get smoothed, there is still a bias in the solution that should have been fixed. I apologize for capturing this only now.