Skip to main content

Hi,



I am simulating an intense source in NSC, and I therefore need to use a lot of Analysis Rays. However, I the maximum number of rays that I can set is 4E+09. Is this a general threshold, or is it related to my computer? Is there a way I can simulate more rays than that?



Also, when I try to run it with the Saving Rays function turned on, I get the error 'Failed to write ZRD file: the temp folder may be full!'. How do I avoid it?



Thanks in advance,



Michele

Hi Michele,



Thanks for your question here!



There is a hard limit of 4E+09 on the number of analysis rays per source.



If you would like to simulate more than 4E+09 rays, one workaround could be to place multiple identical sources at the same location. Alternatively, you can run multiple ray traces one after the other without clearing detectors between the traces, so the resulting number of rays traced and the power will be summed.



If you have further questions, please let us know!



Best,



Csilla



 


The limit on the number of Analysis rays is because it is of the Long Unsigned integer type, capable of containing integers in the [0, 4,294,967,295] range. I think the limit may have been set at 4e09 instead of 4.294e+09, but you get the point. However you look at it,4e+09 is a LOT of rays, especially when each ray can generate child rays through reflection or scattering. I suspect the reason your Save to ZRD is failing is that the file is too big. You should look at the maximum allowed size for your TEMP folder as well as for any final resting place for the output file: these things can be huge!



One thing you can do to limit the size of the ZRD is to use a filter so that you only save rays that meet a particular condition, but otherwise you'll just need a disk system that's able to handle the file size.



To get multiples of 4e+09 then just use multiple sources or repeat the ray trace multiple times, as Sandrine said. OS uses a Mersenne Twister type of pseudo-random number generator, which is sufficiently random for many multiples of 4E+09. But this is a real brute-force solution. If you can tell us more about what you're trying to achieve, there may be smarter ways of getting the result you need.



- Mark


Dear Mark,



Thank you for the thorough answer. My current problem is the following: I am trying to optimize an illumination system that uses a laser-driven light source (this one), which, because of geometrical restrictions on the track of the system, is composed by first a converging lens, then a diverging one. This strongly reduces the number of rays that reach the detector, which is very small. However, the source is quite strong (it has an average spectral radiance of 10 mW/mm^2*sr*nm, according to its datasheet), therefore the experimental setup works, and we can see the image of the source on the image plane. Calculating how many photons are generated by the source each second, I got something in the order of 10^15 (approximately) in the solid angle of the source. Do you have any suggestion on how to deal with a system like this?



Thank you again for the help,



Michele


Dear Michele,



I strongly agree with Mark and Csilla.



4e9 rays is already a very large number of rays. I have never used a simulation with more that 10e9 rays so far in my life, and that was for extrem photometric simulations.



Truth is you most certainly don't need to model each photon! As with everything in life, physical simulations are a balance between speed and accuracy.



Let's think about tracing 1e16rays for a minute. if 1e9 takes 1 minute [it won't by the way], then you'll need 20years to finish the ray trace...



I would advice you to try with less rays and to simplify your system, always start small, like 10,000 and see what is your noise, and only then start increasing and refining your model until you can live with the amount of noise.



As Mark said, there are probably smarter ways of getting the results you need.



If you are new to non-sequential, I can only suggest you to have a look at our learning plan here.



Best,



Thomas


Reply