fangq / mcx Goto Github PK

We need a comprehensive MCX manual for both the users and developers.

Need to

• Define a set of benchmark problems,
• Automatically compile MCX and run the benchmark and upload the results.
• Summarize the testing matrix in a dashboard page.
• Provide downloads to the nightly-build binaries for selected platforms. (done, 2016/06/11 http://mcx.space/nightly )

Hi,

When using make I have an error for the file mcx_utils.c at the line 688. It seems to be a problem with the curly bracket befor the for . It close the function mcx_prepdomain too early.

If I delete it, it compile with no problem.

By the way thanks for sharing your code!

This feature has been supported in MMC, but not MCX.

fangq/mmc@86df1f4

needs to be ported to MCX.

I want to copy the methods from Minsu Kim's paper（Development of a laboratory spectral
backscattering instrument: design and simulation）and to simulate a photon from the incident beam hits the cuvette. Then I want to determine the optimal design of the backscattering measurement system. Please you give me some sugguestions if I use your software.

clear cfg;

cfg.unitinmm=0.1; %set the grid to 100um
cfg.nphoton=3e7;%3e7 Photons

prop=[ 0.019 7.8   0.89 1.37     % medium 1: skin & skull 7-8mm
   0.02  9.0   0.89 1.37     % medium 3: gray matter the rest
   ];

cfg.prop=[0 0 1 1];
%define layer structure
cfg.vol=ones(300,200,100);
j=1;
for h=1:70 % define 150 layers with random brain optical properties
cfg.vol(:,:,j:j+1)=h;
j=j+1;
cfg.prop=[cfg.prop;prop(1,:)];
end
for h=71:99 % define 150 layers with random brain optical properties
cfg.vol(:,:,j:j+1)=h;
j=j+1;
cfg.prop=[cfg.prop;prop(2,:)];
end
cfg.vol=uint8(cfg.vol);

% define the source position
cfg.srcpos=[150,100,0]+1;
cfg.srcdir=[0 0 1];

% time-domain simulation parameters
cfg.tstart=0;%time start
cfg.tend=10e-6;%time end
cfg.tstep=100e-9;%time step

% GPU thread configuration
cfg.autopilot=1;
cfg.gpuid='1111';

cfg.issavedet=1; % enable recording partial pathlength of detected photons
cfg.detpos=[51 101 1 2];%define the detector position(S-D= 100*0.1mm= 1cm)

fprintf('running simulation ... this takes about 20 seconds on a 4* TITAN X (Pascal) \n');

for i=1:15 %run the simulation 15 times
tic;
[f(i),det(i),vol(i),seeds(i)]=mcxlab(cfg);
toc;
clear f;
fprintf(sprintf('simulation number: %d is done..............................',i));
end

I ran this code on Ubuntu 16.04.2 LTS server with 4 TITAN X (Pascal)
and it worked.
a few days later I tried to run it again and the Matlab crashed with this error

---

   Segmentation violation detected at Wed Nov 14 10:33:05 2018

---

Configuration:
Crash Decoding : Disabled - No sandbox or build area path
Crash Mode : continue (default)
Current Graphics Driver: Unknown software
Current Visual : None
Default Encoding : UTF-8
Deployed : false
GNU C Library : 2.23 stable
Host Name : ZigZagDL
MATLAB Architecture : glnxa64
MATLAB Entitlement ID: 5144975
MATLAB Root : /usr/local/MATLAB/R2017a
MATLAB Version : 9.2.0.556344 (R2017a)
OpenGL : software
Operating System : Linux 4.4.0-77-generic #98-Ubuntu SMP Wed Apr 26 08:34:02 UTC 2017 x86_64
Processor ID : x86 Family 6 Model 79 Stepping 1, GenuineIntel
Virtual Machine : Java 1.7.0_60-b19 with Oracle Corporation Java HotSpot(TM) 64-Bit Server VM mixed mode
Window System : No active display

Fault Count: 1

Abnormal termination:
Segmentation violation

Register State (from fault):
RAX = 00007f07ef4d06c0 RBX = 00007f07ad2f4010
RCX = 00000000000009c0 RDX = 00000000000059b0
RSP = 00007f08651272c8 RBP = 00007f0865128570
RSI = 00007f07ad2f9000 RDI = 00007f07ef4d56b0

R8 = 00007f07fbb59720 R9 = 0000000000000002
R10 = 0000000000000822 R11 = 00007f087e414b50
R12 = 00007f0865128c78 R13 = 0000000000000000
R14 = 00000000000059b0 R15 = 000000000000000c

RIP = 00007f08827fe566 EFL = 0000000000010283

CS = 0033 FS = 0000 GS = 0000

Stack Trace (from fault):
[ 0] 0x00007f08827fe566 /lib/x86_64-linux-gnu/libc.so.6+01365350
[ 1] 0x00007f07b752f132 /home/student1/Eidan/mcxlab/mcx.mexa64+00168242 mexFunction+00002858
[ 2] 0x00007f0873a716a7 bin/glnxa64/libmex.so+00186023 mexRunMexFile+00000439
[ 3] 0x00007f0873a694a3 bin/glnxa64/libmex.so+00152739
[ 4] 0x00007f0873a6a295 bin/glnxa64/libmex.so+00156309
[ 5] 0x00007f0872d5c1f3 bin/glnxa64/libmwm_dispatcher.so+00782835 ZN8Mfh_file16dispatch_fh_implEMS_FviPP11mxArray_tagiS2_EiS2_iS2+00000947
[ 6] 0x00007f0872d5cabe bin/glnxa64/libmwm_dispatcher.so+00785086 ZN8Mfh_file11dispatch_fhEiPP11mxArray_tagiS2+00000030
[ 7] 0x00007f086f0814a0 bin/glnxa64/libmwm_lxe.so+11719840
[ 8] 0x00007f086f081a2b bin/glnxa64/libmwm_lxe.so+11721259
[ 9] 0x00007f086f15ba7c bin/glnxa64/libmwm_lxe.so+12614268
[ 10] 0x00007f086f106fc1 bin/glnxa64/libmwm_lxe.so+12267457
[ 11] 0x00007f086ea01a00 bin/glnxa64/libmwm_lxe.so+04905472
[ 12] 0x00007f086ea03c84 bin/glnxa64/libmwm_lxe.so+04914308
[ 13] 0x00007f086ea00224 bin/glnxa64/libmwm_lxe.so+04899364
[ 14] 0x00007f086e9fbb21 bin/glnxa64/libmwm_lxe.so+04881185
[ 15] 0x00007f086e9fbfb9 bin/glnxa64/libmwm_lxe.so+04882361
[ 16] 0x00007f086e9ffa10 bin/glnxa64/libmwm_lxe.so+04897296
[ 17] 0x00007f086e9ffadf bin/glnxa64/libmwm_lxe.so+04897503
[ 18] 0x00007f086eaf9a1c bin/glnxa64/libmwm_lxe.so+05921308
[ 19] 0x00007f086eafe083 bin/glnxa64/libmwm_lxe.so+05939331
[ 20] 0x00007f086ef80b0e bin/glnxa64/libmwm_lxe.so+10668814
[ 21] 0x00007f086f0730ce bin/glnxa64/libmwm_lxe.so+11661518
[ 22] 0x00007f0872d5c1f3 bin/glnxa64/libmwm_dispatcher.so+00782835 ZN8Mfh_file16dispatch_fh_implEMS_FviPP11mxArray_tagiS2_EiS2_iS2+00000947
[ 23] 0x00007f0872d5cabe bin/glnxa64/libmwm_dispatcher.so+00785086 ZN8Mfh_file11dispatch_fhEiPP11mxArray_tagiS2+00000030
[ 24] 0x00007f086f0814a0 bin/glnxa64/libmwm_lxe.so+11719840
[ 25] 0x00007f086f081a2b bin/glnxa64/libmwm_lxe.so+11721259
[ 26] 0x00007f086f0eb9b1 bin/glnxa64/libmwm_lxe.so+12155313
[ 27] 0x00007f086ea01a00 bin/glnxa64/libmwm_lxe.so+04905472
[ 28] 0x00007f086ea03c84 bin/glnxa64/libmwm_lxe.so+04914308
[ 29] 0x00007f086ea00224 bin/glnxa64/libmwm_lxe.so+04899364
[ 30] 0x00007f086e9fbb21 bin/glnxa64/libmwm_lxe.so+04881185
[ 31] 0x00007f086e9fbfb9 bin/glnxa64/libmwm_lxe.so+04882361
[ 32] 0x00007f086e9ffa10 bin/glnxa64/libmwm_lxe.so+04897296
[ 33] 0x00007f086e9ffadf bin/glnxa64/libmwm_lxe.so+04897503
[ 34] 0x00007f086eaf9a1c bin/glnxa64/libmwm_lxe.so+05921308
[ 35] 0x00007f086eafe083 bin/glnxa64/libmwm_lxe.so+05939331
[ 36] 0x00007f086ef80b0e bin/glnxa64/libmwm_lxe.so+10668814
[ 37] 0x00007f086ef4cdd4 bin/glnxa64/libmwm_lxe.so+10456532
[ 38] 0x00007f086ef4d14a bin/glnxa64/libmwm_lxe.so+10457418
[ 39] 0x00007f086ef4e919 bin/glnxa64/libmwm_lxe.so+10463513
[ 40] 0x00007f086efd0155 bin/glnxa64/libmwm_lxe.so+10994005
[ 41] 0x00007f086efd079d bin/glnxa64/libmwm_lxe.so+10995613
[ 42] 0x00007f0872d09ede bin/glnxa64/libmwm_dispatcher.so+00446174
[ 43] 0x00007f0872cf0628 bin/glnxa64/libmwm_dispatcher.so+00341544 ZN13Mfh_MATLAB_fn11dispatch_fhEiPP11mxArray_tagiS2+00000616
[ 44] 0x00007f086f0814a0 bin/glnxa64/libmwm_lxe.so+11719840
[ 45] 0x00007f086f081a2b bin/glnxa64/libmwm_lxe.so+11721259
[ 46] 0x00007f086f0eb9b1 bin/glnxa64/libmwm_lxe.so+12155313
[ 47] 0x00007f086ea01a00 bin/glnxa64/libmwm_lxe.so+04905472
[ 48] 0x00007f086ea03c84 bin/glnxa64/libmwm_lxe.so+04914308
[ 49] 0x00007f086ea00224 bin/glnxa64/libmwm_lxe.so+04899364
[ 50] 0x00007f086e9fbb21 bin/glnxa64/libmwm_lxe.so+04881185
[ 51] 0x00007f086e9fbfb9 bin/glnxa64/libmwm_lxe.so+04882361
[ 52] 0x00007f086e9ffa10 bin/glnxa64/libmwm_lxe.so+04897296
[ 53] 0x00007f086e9ffadf bin/glnxa64/libmwm_lxe.so+04897503
[ 54] 0x00007f086eaf9a1c bin/glnxa64/libmwm_lxe.so+05921308
[ 55] 0x00007f086eafe083 bin/glnxa64/libmwm_lxe.so+05939331
[ 56] 0x00007f086ef80b0e bin/glnxa64/libmwm_lxe.so+10668814
[ 57] 0x00007f086ef4cdd4 bin/glnxa64/libmwm_lxe.so+10456532
[ 58] 0x00007f086ef4d14a bin/glnxa64/libmwm_lxe.so+10457418
[ 59] 0x00007f086ef4e919 bin/glnxa64/libmwm_lxe.so+10463513
[ 60] 0x00007f086efc32be bin/glnxa64/libmwm_lxe.so+10941118
[ 61] 0x00007f086efc364a bin/glnxa64/libmwm_lxe.so+10942026
[ 62] 0x00007f087112441b bin/glnxa64/libmwbridge.so+00189467
[ 63] 0x00007f08711250cd bin/glnxa64/libmwbridge.so+00192717 _Z8mnParserv+00000829
[ 64] 0x00007f0873022df3 bin/glnxa64/libmwmcr.so+00552435
[ 65] 0x00007f0873024f9e bin/glnxa64/libmwmcr.so+00561054
[ 66] 0x00007f0873025619 bin/glnxa64/libmwmcr.so+00562713 _ZN5boost6detail17task_shared_stateINS_3_bi6bind_tIvPFvRKNS_8functionIFvvEEEENS2_5list1INS2_5valueIS6_EEEEEEvE6do_runEv+00000025
[ 67] 0x00007f0873023f06 bin/glnxa64/libmwmcr.so+00556806
[ 68] 0x00007f08737f1739 bin/glnxa64/libmwiqm.so+00857913
[ 69] 0x00007f08737de06c bin/glnxa64/libmwiqm.so+00778348 _ZN5boost6detail8function21function_obj_invoker0ISt8functionIFNS_3anyEvEES4_E6invokeERNS1_15function_bufferE+00000028
[ 70] 0x00007f08737ddd4c bin/glnxa64/libmwiqm.so+00777548 _ZN3iqm18PackagedTaskPlugin7executeEP15inWorkSpace_tagRN5boost10shared_ptrIN14cmddistributor17IIPCompletedEventEEE+00000428
[ 71] 0x00007f08737bbfba bin/glnxa64/libmwiqm.so+00638906
[ 72] 0x00007f08737aa15f bin/glnxa64/libmwiqm.so+00565599
[ 73] 0x00007f08737ac609 bin/glnxa64/libmwiqm.so+00574985
[ 74] 0x00007f088415201a bin/glnxa64/libmwservices.so+02469914
[ 75] 0x00007f08841535cf bin/glnxa64/libmwservices.so+02475471
[ 76] 0x00007f0884153d7a bin/glnxa64/libmwservices.so+02477434 _Z25svWS_ProcessPendingEventsiib+00000186
[ 77] 0x00007f087302356e bin/glnxa64/libmwmcr.so+00554350
[ 78] 0x00007f0873023901 bin/glnxa64/libmwmcr.so+00555265
[ 79] 0x00007f0873011206 bin/glnxa64/libmwmcr.so+00479750
[ 80] 0x00007f0882a816ba /lib/x86_64-linux-gnu/libpthread.so.0+00030394
[ 81] 0x00007f08827b782d /lib/x86_64-linux-gnu/libc.so.6+01075245 clone+00000109
[ 82] 0x0000000000000000 +00000000

This error was detected while a MEX-file was running. If the MEX-file
is not an official MathWorks function, please examine its source code
for errors. Please consult the External Interfaces Guide for information
on debugging MEX-files.

I tried to reduce the number of photons but even 1e6 won't work. any suggestions?

Here is an implementation of the momentum transfer by Stefan, we will port it to MCX and MCXCL

fangq/mmc@3d22c05

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)
  

Users have reported occasions where MCX produced a streak of high-intensity pixels along the forward scattering direction, likely caused by the failure of the built-in LL5 RNG.

If Logistic-lattice based RNG is not stable for productivity purposes, need to consider other alternative RNGs, such as cuRAND

https://developer.nvidia.com/cuRAND

or revive the MT RNG included in MCX

MCX has been using atomic operations for fluence accumulation by default since a few years ago. However, a drop in fluence intensity in large photon simulations has been observed. For example, running the below script using the current MCX github code, you can get the below plot

clear cfg
cfg.vol=uint8(ones(60,60,60));
cfg.srcpos=[30 30 1];
cfg.srcdir=[0 0 1];
cfg.gpuid=1;
cfg.autopilot=1;
cfg.prop=[0 0 1 1;0.005 1 0 1.37];
cfg.tstart=0;
cfg.tend=5e-9;
cfg.tstep=cfg.tend;

figure
hold on;
for i=6:9
    cfg.nphoton=10^i;
    flux=mcxlab(cfg);
    plot(log10(abs(squeeze(flux.data(30,30,:)))),'-','color', rand(1,3));
end

The reason for the drop in intensity was not due to data racing, like the case when non-atomic operations were used, but the accumulations of the round-off errors. In the region near the source, the energy deposit quickly increases to a large value. When adding a new energy deposit (which is a very small value) on top of a large value, the accuracy becomes a problem.

This is a serious problem because, with the increase of GPU computing capacity, most people would choose to run large photon simulations. We must be able to run large photon numbers without loosing accuracy.

There are a few solutions to such problem.

The easiest solution is to change the energy storage to double. However, consumer GPUs have extremely poor double performance, so moving to double precision addition can likely lead to drop in speed.

The standard way to sum a small values with a large floating point value is the Kahan summation. This is what we used in MMC. However, this requires multiple step operations with additional storage space. When combining with the atomic operation, atomic Kahan summation is very difficult to be implemented in the GPU.

Another idea is to use repetitions (-r) to split a large simulation into smaller chunks, and sum the solutions together. For example, for 1e9 photons with 10 respin, we run 10x 10^8 photon simulations. This can reduce the round-off error, but the repeated launch of the kernel causes a large overhead, sometimes, significantly higher than the kernel execution itself. In addition, even simulate at 1e8 photons, from the above plot, the drop in intensity remains noticeable.

A robust method is needed to obtain stable and converging solution especially at large photon numbers.

Dr. Fang,

Thank you for this software. I'd like to know if there is a way to configure the photon fluence rate of the source?

Thanks,
Chaitanya

I was looking at your code and I found this line:
https://github.com/fangq/mcx/blob/master/src/mcx_core.cu#L1332

Is this correct? Shouldn't this be (v->y > 0.f)-(v->y < 0.f)? The same also for L1333.

I downloaded the mcx binary for Linux 64-bit and I get this error on running mcx:
mcx: relocation error: mcx: symbol __get_cpu_features, version GLIBC_PRIVATE not defined in file libc.so.6 with link time reference

I am running on RedHat7.

Do I need to compile mcx from source?

MCX supports Fresnel reflection (--reflect 1) or total absorption (--reflect 0) and total reflection (setting n of media 0 to less than 1) boundary condition for all 6 facets of the domain (+x/-x/+y/-y/+z/-z). It will gain much more flexible to allow users to specify BC on a specific axis direction.

Also, a cyclic boundary could be potentially useful, although it is not very obvious when it will be used.

tMCimg expands volume by 1-voxel in each direction to store transmittance. Need to come up with something, similar or more efficient, to store reflectance and transmittance.

submitted by @yaoruoyang:

In mcxlab, the output angle of a small number of photons (along z direction) have the wrong sign, we need to fix that (not sure about the cause).

Also, there's a small possibility that the angle of z is NaN (when the sum square of x angle and y angle is close to 1), this is very likely caused by the rounding number issue.

Please use the attached scrip to reproduce the issue and for debugging.

% In mcxlab, the output angle of a small number of photons (along z direction)
% have the wrong sign, we need to fix that (not sure about the cause)

% Also, there's a small possibility that the angle of z is NaN (when the
% sum square of x angle and y angle is close to 1), this is very likely
% caused by the rounding number issue.

%% test 1, reflection mode

clear cfg cfgs
cfg.nphoton=1e9;
cfg.vol=uint8(ones(60,60,60));
cfg.srcpos=[29.5, 29.5, -0.01];
cfg.srcdir=[0 0 1];

cfg.gpuid=1;
cfg.autopilot=1;

cfg.prop=[0 0 1 1;0.005 1 0 1.37];

cfg.tstart=0;
cfg.tend=5e-9;
cfg.tstep=5e-9;

cfg.issrcfrom0=1;
cfg.isreflect=1;
cfg.issaveexit=1;

cfg.detpos = [29.5, 39.5, -0.01, 3];

% calculate the flux distribution with the given config
[flux1,detp1,~,~] = mcxlab(cfg);

count1 = length(find(detp1.v(:,3)>0));
count2 = sum(isnan(detp1.v(:,3)));

%% test 2, transmission mode

clear cfg cfgs
cfg.nphoton=1e9;
cfg.vol=uint8(ones(60,60,20));
cfg.srcpos=[29.5, 29.5, -0.01];
cfg.srcdir=[0 0 1];

cfg.gpuid=1;
cfg.autopilot=1;

cfg.prop=[0 0 1 1;0.005 1 0 1.37];

cfg.tstart=0;
cfg.tend=5e-9;
cfg.tstep=5e-9;

cfg.issrcfrom0=1;
cfg.isreflect=1;
cfg.issaveexit=1;

cfg.detpos = [29.5, 29.5, 20.01, 3];

% calculate the flux distribution with the given config
[flux2,detp2,~,~] = mcxlab(cfg);

count3 = length(find(detp2.v(:,3)<0));
count4 = sum(isnan(detp2.v(:,3)));

This is an issue reported by Sean Huang (sean.huang at aut.ac.nz). MCXStudio completes the simulation, but the output file are not located in the desired folder, see the below email exchange, and the screen capture.

the output from MCX Studio output windows shows

unknown verbose option: --root

On 03/11/2018 05:22 PM, Sean Huang wrote:

Hi Qianqian,

Yes, after the simulation is completed in the mcxstudio, I right clicked the icon and selected ‘open output file’, I only saw ‘windows batch file, JSON file and SH file’, not the results files.

Regards,

Sean

From: Qianqian Fang [mailto:[email protected]]
Sent: Monday, 12 March 2018 10:17 AM
To: Sean Huang [email protected]
Subject: Re: MMC or MCX

On 03/11/2018 04:49 PM, Sean Huang wrote:

Hi Qianqian,

I tried the nightly build software, but the results are not saved in the output file for ploting after the run has completed?

are you saying mcx simulation is completed in mcxstudio, but it could not find the output file?

if you right click on the icon to the left panel (session icons), and select "open output folder", do you see the output files?

Qianqian

Regards,

Sean

Hi, I seem to have problems with using respin, in that, the reflectance obtained with Nphotons = 1E7, respin = 1, is different from say, Nphotons = 1e7, respin = 10.

In your readme file, you mentioned that "the 2nd command above will launch 2048 GPU threads (-t) with every 64 threads a block (-T); "

The 2nd command is:
mcx -t 16384 -T 64 -n 1e7 -f input.inp -s test -r 2 -g 10 -d 1 -b 1 -G 1

The thread number is 16384, not 2048.
I am confuse about it.

Thanks

Need to support 1D and 2D simulations. Only need to restrict the scattering operations and simplifications in hitgrid.

Matlab crashes when attempting to execute the mcxcl mex function when the debug level is set to 'M'. I am attempting to retrieve the photon trajectories and it is my understanding from the documentation that in order to do so the debug level must first be set to 'M'.

This is the line of code that calls the mcxlabcl function
[fluxs,detps,vol,seed,trajectory]=mcxlabcl(cfgs(2),'mcxcl');

I've attached the matlab dump file here.
I'm using the 09/26/2018 nightly build of MCXStudio for Windows.
matlab_crash_dump.17332-1.txt

I noticed that my Maxwell (980Ti) GPU occasionally drops to a low-clock state after running MCX for some time. I posted my question at the CUDA forum:

https://devtalk.nvidia.com/default/topic/917213/cuda-programming-and-performance/maxwell-suddernly-becomes-10x-slower/

someone pointed out the P2 state. More googling reveals a couple of similar incidences

http://www.overclock.net/t/1553214/lower-memory-clocks-and-locked-p2-power-state-on-the-gtx-970
https://www.reddit.com/r/nvidia/comments/3au46o/gtx_970_p2_memory_clock_drops/
http://www.prepar3d.com/forum/viewtopic.php?t=109003

I am not entirely sure if this is caused by MCX on a Maxwell, or it is a bug of Maxwell itself.

When using the source type "disk" the launched photon density has a dip in the center of the circle and along the radial axis.

The output has been generated using this json parameter file

The volume file is:
{ "Shapes": [ {"Name": "cubic300"}, {"Origin": [0,0,0]}, {"Grid": {"Tag":1, "Size":[300,300,60]}} ] }
and the run command:
mcx -A -f 8benchmark-disk_modified.json -r 100 -b 1 8benchmark-disk_modified "$@"

Python plot script is here

I'm using the vs project from mcx with vs2013.
I find that function "mcx_list_gpu" in mcextreme.c can't transport "mcxconfig" to mcx_core.cu because I print out value "mcxconfig.deviceid[0]" both sides and find they are different.
So, the program always report "No GPU device found".

Hi,
I think that there is a sqrt(2) missing in line 384 in mcx_core.cu:

  r=sqrtf(-logf(rand_uniform01(t)))*gcfg->srcparam1.x;
 // should be:
// r=sqrtf(-2 * logf(rand_uniform01(t)))*gcfg->srcparam1.x;

as the shape of the sampled Gauss curve has a smaller sigma as expected from the value given to srcparam1.x.
In other words: with the current code, the Gauss curve has a sigma of approx. 1 / sqrt(2) * srcparam1.x, which is contradicting the documentation which says that srcparam1.x is the sigma of the Gauss curve.
If you run example/srcbenchmark/run_3benchmark-gaussian.sh, you get:

However, I do not have a math reference supporting the missing sqrt(2) factor.

Currently, we use an unsigned char to represent a label of a medium label. Because the highest bit of the char is used to represent the detector label, so, the max number of tissues mcx can represent is only 2^7=128.

Since there is no storage benefit to use a char variable inside the cuda kernel because of byte alignment, it probably would not add any overhead, if not faster, to use an integer array to represent the domain.

If we expand the label to 32bit, we can use a subset of bits for special masking to speed up some of the calculations.

Currently, the "preview" function in the volume designer of MCXStudio could only visualize some of the different types of light sources, including Pencil, Disk, Gaussian, and etc. Some other types of source are either not shown or incorrectly represented.

Create and maintain an online GPU performance database by allowing users to submit timing info to a list of standardized benchmarks.

This requires:

[x] make MCXLAB aware of hardware configurations (similar to mcx -L)
[x] develop a CGI program on the MCX's web server to accept user contributed benchmark submissions
[x] write a matlab script to benchmark the GPU using MCX kernels and a standardized problem
[x] use urlread() to post the timing info and the hardware info to MCX's website
[x ] compile the results, rank by speed, and dynamically update

Hi, I have some issue with the make mex .

Because mex is also a LateX package I was not able to compile mcxlab.

I had to change this line:

by MEX=matlab-mex and it seems to work properly.

I am on linuxMint and I have the package matlab-support distro integration for local MATLAB installations so maybe it's the problem.

I just wanted to point out this problem so other people can avoid having the same problem. Because at first I didn't understand why you would need LateX to compile the code for matlab. It took me some time to find the problem and the solution....

See original report by Jingjing Jiang in this mailing list thread:

https://groups.google.com/forum/#!searchin/mcx-users/misaligned/mcx-users/LNv7iz6YYhk/gaX3P-zFEvAJ

Hello, first thanks for the source code and for all the work.

I was playing with the program and I just encounter an error using the python init.py file.

If I don't save the photons seed I encounter an error when I try to use the load_mch python function. It look like it come from the line 107 with the variable photon_seed

If I understand it correctly the line should be just after the line 85 photon_seed.append(np.asarray(seeds).reshape((seed_byte,saved_photon), order='F')) or after, just before return mch_data, header, photon_seed

There is also some problem (or misunderstanding) with the header variable. header.medium dose not exist therefore is M = header[""maxmedia"]+1

Need to update all wiki pages and code documentations. Create links on the wiki to utilize Github resources.

When using the 'planar' source with mcxlab I receive a non-uniform planar illumination. Here's a plot of the normalized fluence on the surface of a phantom close to the source:

For various parameter values, I get the same 4 defects. Changing photon number, size and shape of the planar source don't appear to make them go away, nor does adding a focal length for the source. Here's the code I use,

First the setup of the phantom:

unitinmm=.2; dim = (1/unitinmm)*[60,40, 30];
volume_center = [dim(1)/2+1;dim(2)/2+1;dim(3)/2+1];
% Defining simple rectangular phantom
object_data=uint8(ones(dim(1),dim(2), dim(3)));
object_props=[0.00001 0.0 0.9 1.33;0.003 5 0.9 1.33];
fluence=illuminate_PreXion(object_data,object_props,volume_center,unitinmm);

Matlab function that defines the illuminating geometry and calls mcx:

illuminate_PreXion.txt
(save as .m file to run)

The current website design has been used for 6 years. It is time to upgrade.

I installed cygwin with gcc packages and copied the header files from libgwc32/include/glibc to cygwin/usr/include according to instructions. I still get an error. Could you please help me ?

The DEVICE_EMULATION mode is no longer available, but printf is directly supported for all CC>=2.0 devices. Need to define a list of useful commands to help debugging.

Hey, I try to run this code:

clear cfg;
cfg.unitinmm=0.1; %set the grid to 100um
cfg.nphoton=1e7;

prop=[ 0.019 7.8   0.89 1.37     % medium 1: skin & skull
   0.004 0.009 0.89 1.37     % medium 2: CSF
   0.02  9.0   0.89 1.37     % medium 3: gray matter
   0.08 40.9   0.84 1.37    % medium 4: white matter
   ];

cfg.prop=[0 0 1 1];
% define layer structure
cfg.vol=ones(500,500,1500);
j=15;
for i=1:100 % define 100 layers with random brain optical properties
cfg.vol(:,:,j:j+1)=i;
j=j+15;
randomm=randi([1,4]);
cfg.prop=[cfg.prop;prop(randomm,:)];
end
cfg.vol=uint8(cfg.vol);

% define the source position
cfg.srcpos=[200,250,0]+1;
cfg.srcdir=[0 0 1];

% time-domain simulation parameters
cfg.tstart=0;
cfg.tend=5e-9;
cfg.tstep=5e-10;

% GPU thread configuration
cfg.autopilot=1;
cfg.gpuid=1;

%% running simulation with boundary reflection enabled
cfg.isreflect=1; % enable reflection at exterior boundary
cfg.isrefint=1;  % enable reflection at interior boundary too
cfg.issavedet=1; % enable recording partial pathlength of detected photons
cfg.detpos=[101 251 1 2];
for i=1:1
tic;
[f,det,vol,seeds]=mcxlab(cfg);
toc;
end
fprintf(sprintf('simulation number: %d is done..............................',i));

And I got this warning and error.

WARNING: GPU memory can not hold all time gates, disabling normalization to allow multiple runs
MCXLAB ERROR -2 in unit mcx_core.cu:1756: out of memory
Error from thread (0): out of memory
C++ Error: MCXLAB Terminated due to an exception!
Elapsed time is 2.533999 seconds.

I know my GPU is not that strong (GEFORCE 930MX) and I am willing to upgrade my GPU but what are the required specifications of the GPU to run simulations like this properly

Currently, MCX only supports Henyey-Greenstein phase function. Need to add more phase function options to make MCX a general MC simulator. Expect only simple changes.

Shijie and Morris reported this issue, and Shijie found it is related to the fact that mexPrintf does not work in a multi-threading environment in matlab, see

https://www.mathworks.com/matlabcentral/answers/237411-can-i-make-use-of-openmp-in-my-matlab-mex-files

https://www.mathworks.com/help/matlab/matlab_external/mex-api-is-not-thread-safe.html

need to restrict MCX_FPRINTF macro to only the master thread.

At the moment, it seems that within mcx_core.cu, cfg->exportdebugdata does nothing but saves the photon trajectories. After that, the user needs mcxlab to visualize and process the debug information. It would be good to have it directly within the mcx executable which creates a debug file with the necessary trajectory information.

the MMC commit is

fangq/mmc@ccdeb40

need to port this feature, i.e. converging and diverging beams via the 4th element of cfg.srcdir (focal length), from MMC to MCX.

Hello Dr. Fang,

I have noticed that I am having an artifact occur when running a low scattering, Beer's law validation on mcxlab using Windows 10, NVIDIA GTX 1060, cuda 9.1, MATLAB R2017a. This artifact shows a non-uniform distribution of photons from the source when using a disk or Gaussian source (and a planar-like source based on your own diagnostics). Below is your diagnosis of the problem:

I confirm that I was able to reproduce this issue on windows 10 with
CUDA 8 using the latest mcx code. I can also confirm that this does not
show on Linux based binaries.

with a little bit more investigation, I found the issue is more extensive
than just the disk source, this also seem to happen on Gaussian
source, or planar-like sources (4 equal-distant points along the edge,
see attached figure). yes, this only happens on windows, and is
only observable with low scattering.

just by looking at this figure, I think it suggests some random number
generator issue. It looks like one of the two random numbers determining
the x/y position of the photon tends to drop to 0 for some reason.
and there is a period associated with this drop, likely some sort of
self-correlation.

I will investigate this further. The current RNG used is a new one
(xorshift128+) compared to the one when this was initially reported.
so, I am not entirely sure why this issue persists. Because xorshift128+
also involves 64bit data structures to store RNG states, so, there might
also be a possibility of the Windows nvidia driver has some sort of bug
related to 64bit data processing.

In the attached .zip file is the MATLAB code I have been using, as well as the raw results generated and some images of the fluence distribution.

Thank you for looking into this problem.

Best regards,
Jeremy
testMCX.zip

MCX has been using a 1-grid advance step size since the beginning, derived from the tMCimg era. My previous argument regarding this inaccurate in-grid ray-tracing scheme is that after sufficient sampling of the paths, the solution will converge to the correct result. See this mailing list comment:

https://groups.google.com/forum/?hl=en#!searchin/mcx-users/precise$20/mcx-users/I7YCRf4aNnY/8qunTY6UPo4J

However, for this to converge, it may take a lot more photons than I originally expected. I recently compared MCX and MMC (which does precise ray-tracing) and found that the fluence distributions from the two solutions match very well for homogeneous solutions, but not for heterogeneous cases with scattering contrasts (inclusions with absorption contrast also matches very well). This suggested the problem of photon-path related inaccuracy exist in MCX.

Implementing precise and fast grid-space ray-tracing in MCX is expected to solve this problem.

Need to add detailed documentation in Doxygen format, and add make doc option in the Makefile, similar to MMC.

For a non-scattering medium, I expected the photons to travel in straight lines from their respective light source.
However, there seem to be some scattering events happening because of a non-zero g.
I appended one minimal example as a plot.

The file "test1.json" describes a pencil beam on the top of a non-scattering but absorbing medium heading straight into the medium (src_dir.z=-1).
The output showed photons mostly travelling in a straight line but some scattered deviations.

To launch MCX simulations on multiple GPUs to maximize computational throughput. This can be done similar to MCXCL, by creating multiple threads and launch kernels to multiple GPUs.

This will make recompilation much easier especially for Windows users.

MCX studio is running perfect on my machine in the lab with a GeForce GTX 745 Cuda enabled graphics card. However, when I attempt to run any example MATLAB script with MCX I receive the following error message:

MCXLAB ERROR -30 in unit mcx_core.cu:1756: unknown error
Error from thread (0): unknown error
C++ Error: MCXLAB Terminated due to an exception!

I'm using the the 10/01/18 nightly build version of MCX.

Thanks

In the mcx-users google group answer, I attached some scripts that should reproduce the errors as well as one script that should fix the mcxlab error.

First use 'test_script.m' to convert a cfg to a json and reproduce the mcxlab error.
Then, comment the line 36 in 'test_script.m' and run it again to use a modified version of 'json2mcx.m' that fixes this error.

In order to reproduce the mcx error, the 'test.sh' shell script has to be executed (with the mcx executable in the same directory) with the json file as input, that was created in the previous step by running 'test_script.m'.