Problems using the collimator component with GROUP keyword

[DanielPotashnikov]

I am trying to simulate a double axis diffractometer with an array of monitors (0D detector) after the sample. This array includes a collimator in front of every monitor. I used the GROUP keyword to create a group of collimators which work in parallel, and a separate group of detectors. This setup gave very strange results (fig 1, GROUP). The origin of the problem turned out to be the propagation routine in the collimator code, as for some reason it removed all neutrons due to negative propagation times or rounding errors. I have found two solutions to this problem: 1) Add an ALLOW_BACKPROP statement before the propagation routine in the collimator code. This allows neutrons to pass and gives the results labeled as Backprop in fig 1. It is implemented as the Collimator_debug component. 2) I created a component named multicollimator which functions as an array of collimators. It checks if the neutron will pass through one of the collimators in the array, and then uses the usual collimator code. The results of using this method are shown as Multidetector in fig 1. It is much easier to use than a group of collimators, since it allows one to set any number of collimators without having to copy the code many times. To check for consistency, I have also performed the same simulation with a single detector which is shown in fig 1 as Single Det.

I have also noticed strange behavior of the GROUP keyword in ver 2.1. When compiling the same code, having a group of detectors, in ver 2.1 the resulting simulation gives unphysical peak shapes (fig 2). It seems that this issue was fixed in 2.4, but I have not seen anything regarding this in the changelogs. Was this fixed unintentionally or was this known?

Please find the tested .instr and .comp files here. McStas.zip

[willend]

@DanielPotashnikov it seems I unfortunately completely overlooked this issue before releasing 2.5 yesterday! I have marked it on a new project board for an 2.5.1 expected during spring '19

[willend]

Hi again.

Having looked at the issue from time to time and thought of the issue more deeply, the problem is rather related to the way GROUP works than to the Collimator_linear per se.

The group works by a logic of "trying again on the next" if the neutron was not scattered, not including any state-restoration. This in fact means that if two components in a group don't have a common entry-plane and the first component does not RESTORE non-scattered rays (e.g. the ABSORB'ed ones), there will be a kind of shadow-effect.

The best general solution would be that the redefined ABSORB within the GROUP contained an implicit RESTORE_NEUTRON(INDEX_CURRENT_COMP, x, y, z, vx, vy, vz, t, sx, sy, sz, p) before any attempt to scatter on the next component.

Otherwise, the next-best solution in these situations is indeed to write a new, more complex component like your multicollimator or use an approximation, e.g. by using Collimator_radial.

The general solution will likely not come in place before next (v.2.6) McStas release, so let us keep this issue alive to remind ourselves that the problem exists.

[DanielPotashnikov]

Hi Peter,

Thanks for the update. I though that GROUP already included automatic restoration. Having an automatic restoration point might fix the issue with components that are located in different directions relative to the neutron beam. I am wondering whether it will cause problems when a neutron should be ABSORB'ed in a component (e.g. hits the wall of a collimator), but will instead restore and pass through a different collimator.

[willend]

@DanielPotashnikov I see your point, but on the other hand, that restored neutron should be able to make it through the opening aperture of the "other" collomator. GROUP is really only for real XOR scenarios.

An alternative approach will be arriving within the Union component set where @mads-bertelsen to my knowledge is introducing collimators.