Analytic chopper acceptance: include the beam's width on the disc (perhaps via chopcal)

Start in ess/reduce/unwrap/lut.py at compute_frame_sequence, which builds the analytic chopper table from time_offset_open/time_offset_close, and at chopper_distance_along_beam. The open question is which option to take: widen the windows by the beam's angular aperture in scippneutron, or convert DiskChopper to chopcal's Chopper and replace chopper_cascade. Done means a maintainer has chosen the approach and where the beam width comes from; the issue does not yet settle either point.

Now

compute_frame_sequence (ess/reduce/unwrap/lut.py) cuts the source pulse with each chopper's time_offset_open/time_offset_close. Those are the times a slit edge passes beam_position, which treats the beam as a point. radius and slit_height are carried on DiskChopper but don't affect the timing.

The problem

A real beam has a finite width where it crosses the disc. Neutrons start passing when the opening edge reaches the near side of the beam, and keep passing until the closing edge clears the far side. So every window opens half the beam's angular width early and closes half of it late, with transmission ramping up and down rather than switching. The analytic table's support is therefore too narrow.

For BIFROST, the beam subtends 5.65° on the pulse-shaping and frame-overlap discs (a 29.53 × 47.51 mm window on 350 mm discs) and 13.38° on the bandwidth discs (60 × 90 mm). Including it widens the transmitted band from 1.77 Å to 1.91 Å. McStas DiskChopper simulates the finite beam, as does a real instrument, so a table built for a point beam misses part of the band at both ends.

Proposal: use chopcal for the cascade

chopcal (pip install chopcal) is a nanobind binding of mcstas-chopper-lib, a C library McStas instruments can use for the same calculation. It already does what this issue needs, so the Python wouldn't have to be written again:

• Its chopper description maps one-to-one onto DiskChopper. chopcal.lib.Chopper(speed, delay, beam, edges, path, aperture) follows NXdisk_chopper: edges in degrees from the disc's zero, beam the beam's angle. An edge at angle a is on the beam at delay + (beam − a)/(360·speed). That is scippneutron's Δt(θ) = (θ̃ + φ − θ)/ω with delay = φ/ω, speed = f, beam = beam_position, edges = slit_edges, and path the flight distance.
• It models the beam width. aperture is the beam's angular width on the disc, and widens each window by half of it at each end. 0 gives today's point beam. chopcal.lib.beam_aperture(radius, slit_height, window_width, window_height) computes it. The conversion isn't a plain division: the largest angle is at the window's inner corners, nearest the spindle. Dividing the width by the beam-crossing radius gives 11.4° where the true value is 13.4° for BIFROST's bandwidth discs.
• It computes the exact transmitted region. Region.from_wavelengths(...).transmit(choppers) returns the region a chopper train passes as a union of convex polygons in (inverse velocity, emission time). It is the same object chopper_cascade builds, with no projection or binning. For BIFROST's six discs it is a single polygon with five vertices. transmit also takes an optional extra path per chopper, for guides where neutrons travel further than the straight line. A RegionSampler and wavelength_windows come with it.
• It has no runtime dependencies. numpy is needed only for sampling. Wheels are on PyPI.

ess.reduce could convert each DiskChopper to a chopcal.lib.Chopper and let Region replace chopper_cascade's chop. Or, more modestly, it could adopt the aperture widening in scippneutron and keep chopcal as an independent check. I'm happy to help with either, and to change chopcal's interface where that makes it easier to use from ess.reduce.

Where the beam width comes from

NXdisk_chopper has radius and slit_height but nothing for the beam's size at the disc.
Options:

• a workflow parameter per chopper;
• the window or guide that the chopper's inputs field names, if it carries its dimensions;
• a new NXdisk_chopper field, if NeXus or ECDC would take one.

A smaller point: flight distance along the beam path

chopper_distance_along_beam takes the flight distance as the z component of (axle − source). An alternative is to follow the inputs/outputs chain from the source and sum the segment lengths. That follows the beam through bends, and doesn't depend on the world frame's z being along the beam.

For BIFROST it makes no practical difference. BIFROST has a curved guide, but in ECDC's template (0.3.0) and in niess the chain is only 0.3–0.7 mm longer than z at the six choppers. That is also true in the 0.2.0 template's slightly rotated frame. It would matter for instruments with stronger bends, or with choppers downstream of a kink. One trap if it is adopted: a chopper group's origin is its axle (0.32 m off the beam for BIFROST's bunker discs), so the chain has to pass through the beam crossing. Chaining through the axles adds 0.1–1.7 m of spurious path to BIFROST's choppers.