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
Right the user is able to define the world in the config file.
Symmetries can be used there. For example mirror symmetries.
The issue is that the symmetries might differ for different things to simulate.
For example, the example coax detector has in general a periodicity of 60° in φ.
In addition, within this period, it has a mirror symmetry.
Thus, the electric potential only needs to be calculated on the interval [0°, 30°] (with reflecting boundary conditions in φ).
However, this is not possible for the weighting potentials of individual segments. Those, in this case, have
only a mirror symmetry but not a periodicity. Thus, they are calculated over 360°.
It could be reduced to [x°, x°+180°].
For this we need to add support for defining those symmetries in the configuration files for each individual contact.
The text was updated successfully, but these errors were encountered:
Concerning this: can we handle stuff like ConeMantle going from -30° to 30°? The angle in CylindricalPoint always goes from 0° to 360°, so I guess a point at 350° will return false when checking if it is in [-30°, 30°].
Right the user is able to define the world in the config file.
Symmetries can be used there. For example mirror symmetries.
The issue is that the symmetries might differ for different things to simulate.
For example, the example coax detector has in general a periodicity of 60° in φ.
In addition, within this period, it has a mirror symmetry.
Thus, the electric potential only needs to be calculated on the interval [0°, 30°] (with reflecting boundary conditions in φ).
However, this is not possible for the weighting potentials of individual segments. Those, in this case, have
only a mirror symmetry but not a periodicity. Thus, they are calculated over 360°.
It could be reduced to [x°, x°+180°].
For this we need to add support for defining those symmetries in the configuration files for each individual contact.
The text was updated successfully, but these errors were encountered: