Skip to content

Logarithmic macrostep schedule for wall intersections #313

@krystophny

Description

@krystophny

Problem\n\n- STL wall intersections are currently checked once per macrostep, using a single segment from the previous macrostep endpoint to the current endpoint.\n- For early losses, the macrostep can be large enough that the toroidal phase advances noticeably after the wall hit, so wall_hit_cart and the stored zend/xend_cart can differ in toroidal angle (the hit is mid-step).\n\nRequest\n\nAdd an option to distribute macrosteps logarithmically in time (more, shorter steps early; longer steps late), while keeping the microstep resolution and rounding to an integer number of microsteps per macrostep. The actual time axis written to outputs must use the rounded microstep counts.\n\nImplementation (branch feat/log-macrosteps)\n\n- New config options:\n - macrostep_time_grid = 'linear' | 'log' (default linear)\n - macrostep_log_ratio = <ratio last/first> (default 1e3)\n- Precompute per-macrostep microstep counts (ntau_macro) and cumulative microstep counter (kt_macro) such that sum(ntau_macro(2:)) == (ntimstep-1)ntau.\n- Drive stepping with the per-macrostep counts (macrostep takes ntau_local).\n- Write confined_fraction.dat time axis using kt_macrodtaumin/v0 (so the output time grid matches the rounded schedule).\n\nFollow-ups\n\n- Consider also storing the macrostep time grid in results.nc (for plotting without relying on confined_fraction.dat).\n- Consider optional per-microstep wall checking for maximum accuracy (costly).\n

Metadata

Metadata

Assignees

Labels

bugSomething isn't workingenhancementNew feature or request

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions