raysect
MeshCamera for point-like source
This issue to ask about the possibility to have a customized MeshCamera-like class for the detection of the power emitted by a point-like source. This small source lies in a much bigger volume empty volume. This new MeshCamera could exploit the information about the position of the source to adjust the distribution of the launched rays to have it peaked in the direction of the source. A much smaller number of rays will be wasted.
Thank you very much in advance.
Thanks @matteomoscheni, this sounds like a needed feature, especially for applications with small point like sources. We already have the required functionality in the TargettedPixel() observer.
https://raysect.github.io/documentation/api_reference/optical/observers.html#raysect.optical.observer.nonimaging.targetted_pixel.TargettedPixel
This observer basically allows a single pixel to use targeted sampling towards small sources. So for your application you basically need an array/mesh version of this observer. It should be fairly easy to add based on our existing code. We will implement this feature as a new observer class for Raysect.
Dear @mattngc,
I would like to ask you few questions about the procedure followed by TargettedPixel.
(i) Given that the TargettedPixel only targets a given input list of primitives (say one single small source of radiation A), is it able to detect the possible presence of other "external" primitives? For example, if an absorbing wall is placed between the TargettedPixel and that source, is its presence taken into account?
(ii) If (i) is true, then I have this further doubt. If TargettedPixel targets the source primitive A but another source primitive B lies in between them, B should be detected as well ((i) is true). Then, TargettedPixel will directly target B only: is the source contribution B detected twice?
(iii) Let's say TargettedPixel is oriented in such a way that it can not see the source. For example, this can be the case for a TargettedPixel placed on the divertor region: the complicated geometry can lead to such a situation. I got the error message 'Ray direction probability is zero. The target object extends beyond the pixel horizon.' (I suppose line 281 in 'targetted_pixel.pyx') and the simulation stopped. It should be that 'pdf <= 0' because of the orientation of the normal to the TargettedPixel with respect to the vector from a point of the TargettedPixel to the source position. The angle between these two vectors is greater than 90 degrees ('beyond the pixel horizon'), is that right? If this is the case, then I should need a zero result for that TargettedPixel instead of the error. Maybe it is sufficient to assign a zero-weight if the condition 'pdf<=0' is met. I believe that 'pdf <= 0' is a sort of sanity-check command: if a source is placed, say, outside the tokamak chamber then it should not be detected.
I am sure you can shed some light on this.
Regards,
Matteo Moscheni
Hi @matteomoscheni,
(i) and (ii): The primitives in the target list are simply used to guide the selection of solid angle over which to sample. Each primitive specified is converted into a cone of solid angle as seen by the pixel. If you have a list of multiple primitives it leads to a list of multiple overlapping cones in solid angle space. For scenes with small light sources this is efficient because you don't waste time sampling rays over the whole hemisphere.
Once ray launch vectors have been chosen, the ray-tracing proceeds normally. So normal intersection rules apply. If something is in the way, occluding the trajectory to the target primitive, the ray will never reach that primitive and terminate normally. So the results should always turn out as you expect, it just improves the ray efficiency if you know your problem.
(iii) hmm... this is a physically occurring scenario and for a single pixel might make sense. If a user has specified a single target, but that target is behind the observing surface, then its impossible for the rays to target that source. So in this case an error is returned. But for a camera with many more pixels, some will see it, others won't. In that case it makes more sense to return 0 for rays that can't see the target. Let's think more about this, if it seems better to return 0 we could fix this issue.
Matt
Thank you very much for the clear explanation! I look forward to hearing from you soon about point (iii).