You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There is one common way in McStas to increase the number of rays during the simulation, which is called SPLIT, it just divides the weight of one ray into a number of rays with identical state but smaller weight. This is usually used late in the instrument, so most rays won't reach a SPLIT statement. It means that for example changing the wavelength simulated, the number of neutrons reaching the SPLIT statement can change wildly, and so can the number of rays reaching the component that saves to openPMD. Even to more rays than originally simulated. So my bet is that it will happen, the question is how to handle it well.
If starting a new file is too much work (completely fair) I think throwing an error would be best, as taking a subset of the simulated rays would provide a wrong overall intensity, which is one of the more important aspects of the simulation.
The text was updated successfully, but these errors were encountered:
shervin86
changed the title
There is one common way in McStas to increase the number of rays during the simulation, which is called SPLIT, it just divides the weight of one ray into a number of rays with identical state but smaller weight. This is usually used late in the instrument, so most rays won't reach a SPLIT statement. It means that for example changing the wavelength simulated, the number of neutrons reaching the SPLIT statement can change wildly, and so can the number of rays reaching the component that saves to openPMD. Even to more rays than originally simulated. So my bet is that it will happen, the question is how to handle it well.
Maximum number of rays fixed at init
Sep 20, 2021
There is one common way in McStas to increase the number of rays during the simulation, which is called SPLIT, it just divides the weight of one ray into a number of rays with identical state but smaller weight. This is usually used late in the instrument, so most rays won't reach a SPLIT statement. It means that for example changing the wavelength simulated, the number of neutrons reaching the SPLIT statement can change wildly, and so can the number of rays reaching the component that saves to openPMD. Even to more rays than originally simulated. So my bet is that it will happen, the question is how to handle it well.
If starting a new file is too much work (completely fair) I think throwing an error would be best, as taking a subset of the simulated rays would provide a wrong overall intensity, which is one of the more important aspects of the simulation.
Originally posted by @mads-bertelsen in #1 (comment)
The text was updated successfully, but these errors were encountered: