Arbitrary ray source definitions
Taylor Hinsdale
I was working through the examples and saw that this could be done using the multi-source simulation. However, I ran into some problems...
- MMCLab would only allow 1000 sources before crashing.
- Making several (1000) separate sources and simulating those appears to be slower than tracing the equivalent number of photons from a single pencil source.
Qianqian Fang
hi Taylor,
are you using mcxlab or mmclab? the multi-source support was only added for mcx/mcxlab recently, and it is not supported in mmc/mmclab.
I have never used a "ray file" previously. I suspect that those rays described in these files are just discrete sampling of a continuous angular distribution - I am not sure literally simulating these discrete rays is the better way to model LEDs as rays should also be launched in between these discrete origins and angles.
I had previously approximating an LED emission profile using a 'zgaussian' source type by fitting the angular distribution with an angular Gaussian profile. It worked reasonably well. If the angular distribution probability density function (PDF) is provided or can be obtained from the spec sheet, you can also use the user-defined launch angle distribution feature in mcx v2024.2 (see https://github.com/fangq/mcx/issues/129) to do a more accurate simulation. In either of these two approaches, mcx continuously sample the launch angle distribution, which in my opinion is more close to realistic LEDs.
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/5572c0e3-6ee4-4034-9bd1-b91532667b96n%40googlegroups.com.
Qianqian Fang
if you use mcxlab with the multi-source feature, the maximum number of simultaneous source is limited the size of the GPU constant memory.
for a typical constant memory size of 64kB on NVIDIA GPUs, we can only fit around 1000 sources (1000x 16 float32/source ~= 64kB), you should get an out-of-memory error if you ask more than this limit. you will have to split it to multiple batches of 1000-sources and merge the outputs.
again, I am not familiar with the "non-sequential ray-tracing engine" you are working with - I just want to point out that mcx traces photons inside a voxel-rasterized domain, where the shape of the boundaries are typically cube-like. For many commercial optics ray-tracers, such as Zemax, using ray-files makes sense as those tools primarily handle non-scattering optics components; using a discrete subsample of the ray trajectories provide a computationally efficient representation of the beam profile.
ray-tracing wise, mcx differs from these tools in two ways:
1. its primary use is in random/turbid and highly scattering
media; the beam profile is often random and extremely torturous,
the concept of "beam profile" in such media is typically not
useful.
2) mcx can certainly perform ray-tracing like those ray-tracing
engines, but please bare in mind that the geometry it can handle
is limited - using rasterized boundary to model low-scattering
medium can often produce wrong beam profiles as you hoped. We have
mitigated this issue by suggesting users to 1) use mmc instead of
mcx, or 2) use the SVMC mode of mcx (see
https://www.osapublishing.org/boe/abstract.cfm?uri=boe-11-11-6262),
nonetheless, both methods uses piecewise linear approximation to
curved media boundaries, and can still present notable errors when
handling low-scattering domains with curved boundaries. One of my
students is working on further improving mcx/mmc to make those
behave more closely to commercial optics ray-tracers.
I hope you keep these in mind when interfacing your simulators
with mcx.
Qianqian
Hi Qianqian,
Sorry for the typo. I am using mcxlab. Thank you for your suggestions. I think that they would work for most scenarios, but my application is a bit different.
A use case for a ‘ray file’ as I am describing it is being able to easily interface with non-sequential ray tracing engineering software. Most of these let you launch photon weighted rays and save the position, orientation, and weight of those that hit some detector. Being able to load the output of that software into mcx is the goal.
This would be useful for designing devices that interface with scattering media.
Thanks
Taylor
Taylor Hinsdale
You're correct about Zemax; it typically requires only a few rays to adequately represent the system. The program I'm using, FRED, differs from Zemax and is primarily used for illumination design and tracing "rays" through 3D geometries with no predetermined order. The source definition in FRED is very similar to MCX, with the main difference being the nomenclature. In FRED, the number of "rays" traced represents a set of weighted trajectories, which I believe is equivalent to the number of "photons" in MCX. FRED also allows for volume scattering simulations (materials with mua, mus, g, etc..) , albeit at a much slower speed than MCX due to CPU limitations. My main interest lies in examining the fluence rates in the volume scattering material in my model, as well as the trajectories that exit after illuminating it.
What interests me about MCX is its potential to replace the slow CPU-bound volume scattering portion of my workflow with a GPU-accelerated version. For this to work, MCX needs to accept an arbitrary source definition where you can specify N photons, N origins (x, y, z), N direction vectors (l, m, n), and N weights.