-
Notifications
You must be signed in to change notification settings - Fork 9
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
Issues with Rectangular Light Source (mcml.mcsource.*Rectangular) #10
Comments
Seems that the code of the rectangular source was not updated to reflect the common type definitions. There were also a couple of typos in the OpenCL & Python source. I am attaching a modified source file of the rectangular source along with an example. Let me know if there are further issues with the source. The bug will be fixed with the next commit. |
Yes, it worked just fine! Many thanks for your prompt assistance. Many thanks for your great work. |
As explained in the documentation, the simulator assumes SI units (m) and normalizes the reflectance by the detector surface area. All detectors come with a raw property that yields the accumulated weight of the photon packets. This raw property can be used for custom normalization. I am attaching an example that uses an optical fiber probe as the source and two Cartesian detectors to collect the reflectance and transmittance of a 0.5 mm thick slab. Note that the photon packets that exit the top or bottom surface of the slab outside of the detectors are accumulated into the nearest outer pixel of the detector (similar to the radial detector). |
The problem noted in the question above is also happening with UniformRectangularLut, which could not be used. |
In addition to the typos in the OpenCL code and related Python structures the size of the source was not correctly passed to the OpenCL kernel. A fix will be included with the next commit. In the meantime, you can replace the original file with the attached one. |
I was able to confirm that UniformRectangularLut works with the rectanglar modification file you provided. Thanks. I wrote the following code to create a rectangular light source that emits light only in the 0~60° direction using this UniformRectangularLut, but it does not work as expected and the light seems to be emitted over the entire circumference. code###from xopto.mcml import mc cl_device = clinfo.gpu() layers = mc.mclayer.Layers([ filter = mc.mctrace.Trace( fluence = mc.mcfluence.Fluence( Define the angles in radianstheta = np.linspace(0, np.pi/3, 1000) Define the sensitivity as a function of the anglesensitivity = np.sin(theta)**2 Create a new lookup table with the sensitivity values limited to 0~60 degreescostheta_limited = np.cos(np.linspace(0, np.pi/3, 601)) Print the lookup tableprint(costheta_limited) light_source = mc.mcsource.UniformRectangularLut( mc_obj = mc.Mc( trace_res, fluence_res, detector_res = mc_obj.run(nphotons=100000, verbose=True) #plot code end###I would appreciate your advice on how to make a rectangular light source that emits light only in the direction of 0~60°. |
EmissionLut needs to be used instead of CollectionLut. The documentation is suggesting the wrong class (CollectionLut) and in some cases, the wrong class was also used in the code. The latest commit fixed the issue. Pull the master branch and do the following modifications: First, import the EmissionLut: Then replace CollectionLut with EmissionLut: |
As an observation, the source from your example is located inside the sample (10 mm under the sample top surface). It is very difficult if not impossible to assess the initial propagation directions of the packets from the trace plot. The initial direction should be extracted directly from the trace results as: I am attaching a minimal example that does a trace and shows the distribution of the initial/launch propagation directions (with respect to the z-axis) of 1000 packets. The source is using angular intensity distribution from your code. Do not forget to update the pyxopto code from the master branch before running the example. The histogram produced by the example should look similar to: |
Hi,
I am trying to perform a simple Monte Carlo simulation with rectangular light source and detector. I built the MC object as follows:
`from xopto.mcml import mc
from xopto.cl import clinfo
cl_device = clinfo.gpu()
layers = mc.mclayer.Layers([mc.mclayer.Layer(d=0.0, n=1.0, mua=0.0, mus=0.0, pf=mc.mcpf.Hg(1)), # Surrounding medium
mc.mclayer.Layer(d=2.0e-3, n=1.34, mua=0.2e+3, mus=(3/(1-0.9))*1e+3, pf=mc.mcpf.Hg(0.9)), # tissue
mc.mclayer.Layer(d=0.0, n=1.0, mua=0.0, mus=0.0, pf=mc.mcpf.Hg(1))]) # Surrounding medium
filter = mc.mctrace.Trace(maxlen=250, options=mc.mctrace.Trace.TRACE_ALL, plon=True)
fluence = mc.mcfluence.Fluence(xaxis=mc.mcfluence.Axis(-5e-3, 5e-3, 500),
yaxis=mc.mcfluence.Axis(-5e-3, 5e-3, 500),
zaxis=mc.mcfluence.Axis(0, 2e-3, int(2.0e-3/2e-5)))
detector = mc.mcdetector.Detectors(top=mc.mcdetector.Cartesian(xaxis=mc.mcdetector.Axis(-4.5e-3, -4e-3, 1),
yaxis=mc.mcdetector.Axis(-3.5e-3, -3e-3, 1),
direction=(0.0, 0.0, 1.0)))
light_source = mc.mcsource.LambertianRectangular(position=(-0.5e-3,-0.2e-3, 0), width=0.3e-3, height=0.3e-3, n=1.5, na=0.9)
mc_obj = mc.Mc(layers=layers, trace=filter, fluence=fluence, source=light_source, detectors=detector, cl_devices=cl_device)
output = mc_obj.run(nphotons=100000, verbose=True)`
When I try to run the simulation, I receive the following error:
I traced the error and realized there was a typo! Instead of "Structure", "Stucture" was used. I fixed the typo in the code and tried to re-perform the simulation. I received another error as follows:
When I traced the source of error again, I came to this part of the LambertianRectangular class definition code:
`class LambertianRectangular(UniformRectangular):
@staticmethod
def cl_type(mc: mcobject.McObject) -> cltypes.Structure:
T = mc.types
class ClLambertianRectangular(cltypes.Structure):
'''
Structure that is passed to the Monte carlo simulator kernel.
When I compared it with the Fiber class code, I realized in the cl_type function, the input types are different. The same can be observed if you compare the input types declared in the cl_type function with those in the cl_declaration function -> "join" segment. So I tried to adjust the input types of cl_type function according to those specified in the cl_declaration function. I performed the simulation and received the following error.
I would say similar thing must happen for other classes of rectangular sources; however, I didn't check all of them except the UniformRectangular class. I would appreciate it if you could please let me know how I can fix this issue.
The text was updated successfully, but these errors were encountered: