Question about 4/Nx/Ny/Nz continuously varying media in MCXLAB

[Billy Vale]

Hi Dr Fang!

I'm working on simulations of a photochromic protein, so the optical properties of each voxel change depending on the concentration of proteins and the fluence. This involves simulating one laser pulse in MCX, then updating the optical properties, then simulating the next laser pulse with the new properties and so on. As such I need to use continuously varying media for my MCX simulation.

I was using the 2/Nx/Ny/Nz volume for my early runs, but based on my understanding, this only allows the use of g/n=prop(1, 3/4) for background voxels and of g/n=prop(2, 3/4) everywhere else. Where background voxels are specified by setting both mu_a and mu_s to zero, and non background voxels have mu_a and mu_s both non zero.

mu_a will vary continuously but for g/n it is sufficient to stick to a few values corresponding to a few different tissue types, so I would like to use more than just two values for g and n if possible. Based on the documentation I can use the 4/Nx/Ny/Nz volume input to achieve this but it says the values need to be uint8

"4 x Nx x Ny x Nz uint8 array: mua/mus/g/n gray-scale (0-255) interpolating between

prop(2,:) and prop(3,:)"

I can see this would be a lot more memory friendly than the same size array in single float precision, but does this limit me to 256 equally spaced values between prop(2,1) and prop(3,1) for mu_a? If so it will cause a rounding error between laser pulses which will propagate through consecutive pulses...

Would you be able to confirm whether my understanding of MCXLAB up to this point is correct?

How would you advise me to go about implementing the simulation I just described?

I couldn't find much info on the 4/Nx/Ny/Nz continuously varying media on this discussion board but do let me know if my question has already been answered somewhere!

Kind regards.

Billy.

[Qianqian Fang]

On 5/9/23 11:40, Billy Vale wrote:

Hi Dr Fang!

I'm working on simulations of a photochromic protein, so the optical properties of each voxel change depending on the concentration of proteins and the fluence. This involves simulating one laser pulse in MCX, then updating the optical properties, then simulating the next laser pulse with the new properties and so on. As such I need to use continuously varying media for my MCX simulation.

I was using the 2/Nx/Ny/Nz volume for my early runs, but based on my understanding, this only allows the use of g/n=prop(1, 3/4) for background voxels and of g/n=prop(2, 3/4) everywhere else. Where background voxels are specified by setting both mu_a and mu_s to zero, and non background voxels have mu_a and mu_s both non zero.

mu_a will vary continuously but for g/n it is sufficient to stick to a few values corresponding to a few different tissue types, so I would like to use more than just two values for g and n if possible. Based on the documentation I can use the 4/Nx/Ny/Nz volume input to achieve this but it says the values need to be uint8

"4 x Nx x Ny x Nz uint8 array: mua/mus/g/n gray-scale (0-255) interpolating between

prop(2,:) and prop(3,:)"

hi Billy,

your understanding of the format is correct.

all currently supported media formats can be found here

https://github.com/fangq/mcx/blob/b78c4e39b92dcad94abb62eadeffc5711a702a03/README.txt#L545C71-L554

and the mappings between the 1st dimension of the input array to the media types can be found here

https://github.com/fangq/mcx/blob/da495034fd7fd44606d203080b6088b8003bc279/src/mcxlab.cpp#L582-L597

except SVMC (split-voxel MC) and muamus_float, both use 8-byte per voxel, all other media types are internally converted to a 4-byte per voxel array to be used by the GPU kernel.

because of this limitation, we are only able to limited precision to represent continuous medium - you can either spatially varying 2 properties (mua/mus) with 2^16 gray-scale level, or varying 4 properties (mua/mus/g/n) with 2^8 gray-scale levels.

currently, we do not support 4 floats to individually tune mua/mus/g and n values, because that will require 16 bytes per voxel.

I can see this would be a lot more memory f,riendly than the same size array in single float precision, but does this limit me to 256 equally spaced values between prop(2,1) and prop(3,1) for mu_a? If so it will cause a rounding error between laser pulses which will propagate through consecutive pulses...

Would you be able to confirm whether my understanding of MCXLAB up to this point is correct?

How would you advise me to go about implementing the simulation I just described?

in the end, you will have to convince yourself why it is important (and necessary) to use higher previsions to adjust mua/mus/g/n values every voxel - for example, you can do a test by increasing from 128 level of gray-scale to 256 level of gray-scale and compare the result to see if there is any notable difference - you could go even further if you want to adjust mua/mus with even higher resolution (muamus_float). One thing to keep in mind is that using these complex media format will result in slower simulation speed - SVMC is about 50% slower than regular MC.

I do hope to implement the mua/mus/g/n float format at some point, but it is not a high priority task because the use case is very limited (and I don't feel strongly justified).

Qianqian

I couldn't find much info on the 4/Nx/Ny/Nz continuously varying media on this discussion board but do let me know if my question has already been answered somewhere!

Kind regards.

Billy.

--
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/54ccd705-846b-4aa3-9b16-7385c13fadc4n%40googlegroups.com.

[Qianqian Fang]

except SVMC (split-voxel MC) and muamus_float, both use 8-byte per voxel, all other media types are internally converted to a 4-byte per voxel array to be used by the GPU kernel.

one quick correction to my above comment:

muamus_float asks users to give a 8-byte per voxel input volume file, but internally converts such to two half-precision (2-byte float) for mua and mus, and still packed as a 4-byte per voxel buffer.

svmc is the only format that uses 8-byte per voxel both as input and as in the GPU memory buffer.

To view this discussion on the web visit https://groups.google.com/d/msgid/mcx-users/ba7bf6bc-f166-48b1-f3d5-3af5e8571ae9%40neu.edu.

[Billy Vale]

Hi Dr Fang,

Okay thanks for clearing that up for me, mua is by far the most important parameter in my simulation as I am trying to directly measure it, as well as how it changes so I am leaning towards the 2/Nx/Ny/Nz volume input over the 4/Nx/Ny/Nz but I will be sure to conduct some tests at some point. Lastly I am not too concerned with processing time as my optical simulations are coupled with k-wave which is probably taking up about 98% of the compute time at the moment, MCX is very fast in contrast.

Best wishes,

Billy.