"a new method of finding the element of a tracer that is too close to an element boundary. Up to now such a tracer was shifted by a constant epsilon theta and phi. If the element boundary is parallel to this theta/phi direction it is not guaranteed to work well (thus the number_of_tries check), and additionally I got the problem that sometimes all elements refuse this tracer. Eh checked in a workaround for this (r15742), deleting orphan tracers in Tracer_setup.c. Because I did not know this, I created my own bugfix moving the tracers an epsilon amount orthogonal to all boundaries that are too close. In order to save computing time I use the already computed vectors for the element boundaries (this assumes that the element boundaries are nearly orthogonal to each other, but unless somebody tries to change CitcomS elements that should work fine). The shift happens now in cartesian coordinates since the boundary-vectors are cartesian and the radius-coordinate of the tracer is normalized prior to this check anyway, so I just need to re-normalize it after the shift. For now I did not touch all the now (hopefully) useless security checks but as far as I can see they do no harm either, so we can remove them later."
To reference or cite the objects present in the Software Heritage archive, permalinks based on SoftWare Heritage persistent IDentifiers (SWHIDs) must be used instead of copying and pasting the url from the address bar of the browser (as there is no guarantee the current URI scheme will remain the same over time).
Select below a type of object currently browsed in order to display its associated SWHID and permalink.
Implemented improved tracer fix by Rene.
Computing file changes ...