Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use geometry length scale to determine a minimum step #994

Open
sethrj opened this issue Oct 23, 2023 · 7 comments
Open

Use geometry length scale to determine a minimum step #994

sethrj opened this issue Oct 23, 2023 · 7 comments
Labels
external Integration with external components (VecGeom, Geant4, ROOT, HepMC3) orange Work on ORANGE geometry engine

Comments

@sethrj
Copy link
Member

sethrj commented Oct 23, 2023

The single-precision support added in #988 fails in many cases because the step size is small enough that the floating point position does not change over the course of a step. Celeritas requires all steps to be strictly positive to avoid stuck tracks, and all positive steps need to change the physical geometry state. What's happening is that the step length is small compared to the spatial position, where the inequality
$$\frac{s}{x} < \epsilon_\textrm{mach}$$
implies that with floating point arithmetic,
$$\tilde x + \tilde s = \tilde x$$
i.e., no change in position takes place. One way to counter this is to have a minimum step size based on the position in the local reference frame. I can think of a few ways to make a lower bound for the current step:

  • as a function of the current position (1-norm?) so it varies continuously in space
  • as a function of the width of the local volume's bounding box (we might not need as much precision in larger volumes)
  • as a function of the maximum local coordinate of the volume's bounding box (since a small bounding box far from the origin will still be susceptible to the roundoff error)

This minimum step size should also be accounted for in the field substeppers, since the accumulated additions in those will also be susceptible to roundoff error based on the position.

@sethrj sethrj added external Integration with external components (VecGeom, Geant4, ROOT, HepMC3) orange Work on ORANGE geometry engine labels Oct 23, 2023
@sethrj
Copy link
Member Author

sethrj commented Oct 23, 2023

@whokion happy for any comments you have here 😄
@paulromano have you done any exploration of single-precision geometry?

@whokion
Copy link
Contributor

whokion commented Oct 25, 2023

Where are these small steps happening (i.e. are they from the physics stepping or only inside the field propagator as segments of a step)? I assume latter (otherwise, the linear propagator should experience the same problem and/or it is a general tracking problem). If the problem is only from the field propagator, the relative tolerance (as a function of some length scale) may not be a good choice as the field integration should be controlled by the relative error and a small step over the tolerance should not be segmented further. Should the tolerance of geometry serve as the cut for entering the field propagator (i.e., s < tolerance, should use the linear propagator)? MSC is another potential place, but again the small step limitation should serve the same role.

@sethrj
Copy link
Member Author

sethrj commented Oct 25, 2023

@whokion The linear propagator is also seeing this (charged particles, no fields). I'm assuming it's due to the MSC step limiting or other range limits for low-energy particles. The field substepping is probably another issue on top of this 😅

@paulromano
Copy link
Contributor

@sethrj I haven't personally tried doing geometry in single precision as it becomes a lot harder. @pshriwise may be able to comment on his experience as I believe he has tried doing some single and/or mixed precision geometry work

@whokion
Copy link
Contributor

whokion commented Oct 25, 2023

Okay. If MSC is the primary source of the issue, we may adjust UrbanMscParameters::limit_min_fix (currently, 1e-9 * units::centimeter) for the single precision mode and test how it goes first. For the small returning range limit from low energy particles, we should limit the step (so, locally deposit energy and kill them) based on the tracking cut (absolute length, but relative energy) and the lowest electron energy (use in the energy loss calculation) which can be easily configurable and tested. Anyway, we may need to categorize where those small steps come from and investigate from there rather than introducing another ad hoc parameter for the single precision mode.

@sethrj
Copy link
Member Author

sethrj commented Nov 21, 2023

Interestingly when I ran CMS2018 with assertions (uniform field + msc) on I got an assertion failure on one of the two CPU wildstyle runs:

internal assertion failed: `track.make_geo_view().pos() != orig_pos` at `PropagationApplier.hh:116`

so we're even taking too-small steps for double precision to count. We definitely need some sort of minimum based on the local volume extents.

@sethrj
Copy link
Member Author

sethrj commented Dec 1, 2023

Another thing we should totally do in the propagators is to use the local coordinate system. Instead of operating on the global position and rotate/translate "down", which loses accuracy if local universe is smaller than the global, we should do propagation in the local coordinate system since we know we won't cross boundaries or exit the cell. The global position can be updated at the end of the propagator call.

This should vastly reduce loss of accuracy in the substepper.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
external Integration with external components (VecGeom, Geant4, ROOT, HepMC3) orange Work on ORANGE geometry engine
Projects
None yet
Development

No branches or pull requests

3 participants