mcxsvmc is not supported on Octave

[Josef Probst]

Hi,

mcxsvmc unfortunately does not work in Octave because the function discretize (line 207) is not (yet) supported by Octave.

I tried to implement it myself with functions available in Octave.

So i replaced:

%% discretize nn and nc vector components to 0-255 gray-scale numbers
edge_c = linspace(0,1,256);
edge_n = linspace(-1,1,256);

nc=nc-floor(nc);
nc=discretize(nc, edge_c) - 1;

nn=discretize(nn, edge_n) - 1;

with:

%% discretize nn and nc vector components to 0-255 gray-scale numbers
edge_c = linspace(0,1,256);
edge_n = linspace(0,1,256);

nc=nc-floor(nc);
nc(:,1) = lookup (edge_c, nc(:,1), "l");
nc(:,2) = lookup (edge_c, nc(:,2), "l");
nc(:,3) = lookup (edge_c, nc(:,3), "l");
nc = nc - 1;
nn = nn * -1;
nn = (nn+1)/2;
nn(:,1) = lookup (edge_n, nn(:,1), "l");
nn(:,2) = lookup (edge_n, nn(:,2), "l");
nn(:,3) = lookup (edge_n, nn(:,3), "l");
nn = nn - 1;

and well it seems to work (at least for the volume I used).

Could you maybe try to "convert" other volumes with this code?

If you think that this works fine then feel free to use it as the implementation for Octave.

Greetings

Josef

[Qianqian Fang]

On 11/2/21 10:02 AM, Josef Probst wrote:

Hi,

mcxsvmc unfortunately does not work in Octave because the function discretize (line 207) is not (yet) supported by Octave.

hi Josef,

we updated the discretize function call with something more portable

https://github.com/fangq/mcx/commit/59768110d98ca46ec1aa132fe9a3f627d76bc10f

please test again and let us know if this works for you.

Qianqian

--
You received this message because you are subscribed to the Google Groups "mcx-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mcx-users+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/mcx-users/a496d886-3637-48cc-9704-a372c38b86f5n%40googlegroups.com.

[Josef Probst]

Hi Qianqian,

unfortunately not. I get this error when the simulation is started:

MCXLAB ERROR -700 in unit mcx_core.cu:2732: an illegal memory access was encountered
Error from thread (0): an illegal memory access was encountered
C++ Error: mcx: MCXLAB Terminated due to an exception!

Well I analyzed this a bit more.

I think the problem is that the nn array already differs between matlab and octave before this code segment. (see attached ..._before.mat files, which are in the next mail, because of attachment restrictions)

Thats why I used "nn = nn * -1;" in the first place. And indeed, if I add "nn = -nn;" before your new code it does work.

But I don't know why Matlab still works after I replaced the original code segment with my version.

I appended a zip with the volume I used as input, and different nn/nc arrays.

nn.mat and nnfang.mat are the output of this code segment:

edge_c = linspace(0,1,256);
edge_n = linspace(0,1,256);

nc=nc-floor(nc);

ncfang=floor(nc*255);
nnfang=floor((nn+1)*255/2);

nc(:,1) = lookup (edge_c, nc(:,1), "l");
nc(:,2) = lookup (edge_c, nc(:,2), "l");
nc(:,3) = lookup (edge_c, nc(:,3), "l");
nc = nc - 1;
nn = nn * -1;
nn = (nn+1)/2;
nn(:,1) = lookup (edge_n, nn(:,1), "l");
nn(:,2) = lookup (edge_n, nn(:,2), "l");
nn(:,3) = lookup (edge_n, nn(:,3), "l");
nn = nn - 1;

save -7 'nn.mat' nn nc;
save -7 'nnfang.mat' nnfang ncfang;

I hope this helps

Josef

[Josef Probst]

more attachements

[Qianqian Fang]

should be fixed with this new commit

https://github.com/fangq/mcx/commit/25854710bcc34fa81755ba5937445f191b3a2e58

the difference between discretize and the floor replacement was the handling of 1 - in discretize call, 1 is mapped to 254, but floor converts it to 255 (which I think is more appropriate - I will ask my student Shijie to check why 255 crashed mcxlab in svmc, which it shouldn't)

I also updated a few other lines to make them compatible with octave. tested all 3 svmc scripts on Ubuntu 20.04 with Octave 5.2, all worked fine.

Qianqian

To view this discussion on the web visit https://groups.google.com/d/msgid/mcx-users/5e8a2460-1210-1fdd-2140-73cd26b8494d%40gmail.com.

[Qianqian Fang]

a side note on sending attachments:

because there are nearly 300 subscribers to this mailing list, if you have to send large attachments (>1MB), please upload those to a file sharing site (dropbox, google drive, file.io ...) and only send the link to your file in the email.

thanks

Qianqian

To view this discussion on the web visit https://groups.google.com/d/msgid/mcx-users/46043aca-5f14-1be1-2a6a-b2e65d9fc4e1%40gmail.com.

[Vincent]

Hello Qianqian, 

I'm trying to port my code over from Matlab to Octave and have run into an issue with the mcxsvmc funciton described in this thread.  I've verified I'm running the mcxsvmc with the changes you described above, in the Nov 4 commit, but am seeing the same symptom as Josef where the nn matrix of the svmc volume is inverted in Octave.

In the image below, I call the MATLAB engine to run svmc in the left image, and oct2py to call the Octave engine then visualize the [7]th (zero indexed) element of the 8 x n x n x n volume returned to python.  We see that there is still an inversion.

This creates issues in the photon path evaluation

Solid contours in the plot below are with non-svmc evaluation, dotten lines show svmc on Matlab (left plot) and Octave (right plot).

Are you able to reproduce this issue with the latest Octave version?   I could try a patch fix described above, but don't want others to run into the same issue. 

Best,

Vincent

[Qianqian Fang]

hi Vincent and Josef,

thanks for following up on this issue. I was able to reproduce the reported problem, and understood why Josep flipped the normal direction.

I created a ticket for this issue, see details here

https://github.com/fangq/mcx/issues/221

basically, the isosurface.m function in matlab and octave produced triangles of opposite directions. matlab isosurface points from low-to-high value across the isovalue, but octave is flipped.

I was able to fix this bug by flipping the normal direction in mcxsvmc, and now svmc examples run correctly in octave (tested on 6.4 on Ubuntu 22.04)

please wait for the github CI builds to complete and you can try those under

https://mcx.space/nightly/github/

let me know if you still see problems.

Qianqian

To view this discussion on the web visit https://groups.google.com/d/msgid/mcx-users/a37302e3-7e60-4211-840d-cd1e84e9b499n%40googlegroups.com.

[Vincent]

Hi Quanqian, 

Thanks for the quick work and response.  This fixed the problem and MATLAB (right) and Octave (left) give the same svmc results.  

Best, 

Vincent

[Vincent]

I just want to document an issue that I spent a lot of time troubleshooting- 

I am locally running Octave v 6.4.0 because that's the highest supported version for Ubuntu 22.04 LTS.  That works as-intended for the SVMC and gives the results i show in the post above.  However-  i was running in a docker container that used the python 3.10 base image (3.11 shows the same) which runs on a different linux base system and installs Octave 7.3 by default.  These two versions of octave show a different output from the mcxsvmc!  These changes are seen in the loop over unique labels in the svmc function, and occurs either at the smooth3 step, or the isosurface step.  My solution was to just use the ubuntu base image like I am running locally and move on. But- Beware to future svmc users!

[Qianqian Fang]

hi Vincent,

I installed octave 9.1 using this ppa on 22.04

https://launchpad.net/~ubuntuhandbook1/+archive/ubuntu/octave

from a quick test, svmc seems to work ok, see my attached screenshot -

was the issue that mcxsvmc does not produce exactly the same volume, or there is also something wrong with the simulation?

Qianqian

To view this discussion on the web visit https://groups.google.com/d/msgid/mcx-users/9462cc62-0e8c-4b67-8e80-d17ad27509c6n%40googlegroups.com.