-
Notifications
You must be signed in to change notification settings - Fork 71
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Estimation of the pathlengh #132
Comments
you can use one of 3 ways to run a simulation with a desired photon number N:
the above approaches are ranked in the order of most robust/fastest/most convenient to the least order. also, approach 1 has the least overhead - in approach 2, kernels have to be called multiple times, adding overhead of host-gpu data exchange; for approach 3, additional overhead such as file IO are added. Approach 2 is supposed to automatically taking care of the data normalization, while in 3, you will have to take care of averaging by yourself. I added 2 as a workaround to the "kernel launch timed out error" that commonly seen in mcx, so a single kernel execution won't exceed the watchdog time limit. Mode 3 is largely used in distributed systems. if your GPU is set up to run more a longer simulation, I would avoid using 2/3. The only downside is that when you are running a single session with very high photon number, say 10^10, then, there is a risk of floating-point overflow (see #41) near your source region, if you observe that, you should split into smaller sessions, which avoids the overflow problem.
yes, it is normal. Each partial path follows different distributions - I had previously hypothesized Erlang distribution of different parameters, but I have never had chance to prove it. It makes the most sense to me because summation of multiple exponential distribution (which the unitless scattering length follows) follows Erlang distrbution: https://en.wikipedia.org/wiki/Erlang_distribution#Related_distributions
yes, people use total pathlengths to estimate DPF (diferential pathlength factor), see https://www.nature.com/articles/pr19962544 partial path is tricky because it depends on the geometry.
yes, you can use either replay or adjoint, see replay sample script here the adjoint is even simpler - you just run forward at your source, and also at your detector, then multiply the two solutions, see our replay paper Eq 14
I would like to see the error message (and your GPU model), https://github.com/fangq/mcx/blob/master/mcxlab/examples/demo_colin27_atlas.m#L40-L43 |
@Edouard2laire, let me know if I can close this ticket or you have additional questions. |
Hello,
I am not sure if this is the correct place to ask questions. I just wanted to check if what I was doing with mcxlab was correct. Here I am trying to use it to estimate the pathlength that should be used in the modified beer lambert law.
My questions are:
To increase the reliability of the estimation of the mean pathlength is it better to increase the number of photons used, or increase the number of respin (or is it equivalent)? Does the duration of the simulation (tstart, tstep,stend affect this estimation?)
if I look at the distribution of pathlength in detphoton.ppath i get the following:
Is it normal to have photons traveling in the white matter? The estimate of the mean pathlengh isn't really aligned with the peak of the distribution, is that normal? i guess it is related to the weighting applied when computing the mean or because the distribution isn't a gaussian distribution but maybe more a log-normal one?
If I want to compare the pathlengh estimated by mcxlab to a fixed value, I guess it could be easier to have access to not only the mean pathlengh but the full distribution, is it possible? ( i guess detphoton.ppath isn't directly what I am interested in since we need to apply some weighting ie mcxdetweight ). Or would you have some suggestions to see if the estimated value is different from a fixed value?
is it possible to visualize the 'banana' shape going from the source to the detector? similarly to this image
Is it possible to use multiple channels in one simulation 9eg 1 source and 2 detectors for example?) When I tried it, as soon as I have more than one detector, I get an error saying out of memory.
Sorry for the very long message :)
PS:
I am using the following configuration to start the simulation?
The text was updated successfully, but these errors were encountered: