Changelog entries for abTEM#556 (seven fixes, two changes in results, CuPy operands)

[pzeiger]

Changelog entries for abTEM#556, which is still open. The changelog lists only changes that are merged into dev, so this should merge after abTEM#556 does.

Entries

One bullet under Bugfixes:, after the multi-GPU hardening entry, with a sub-bullet per fix, as for abTEM#346 and in #36. The two changes in results come first and start with Behaviour change:.

• Images.integrate_gradient shifts each image of an ensemble so that its own minimum is 0; eager ensembles shared one constant before, and lazy results depended on the chunking. Single images are unchanged.
• DiffractionPatterns.block_direct() without a semiangle_cutoff blocks only the zero-angle pixel (radius half the smaller angular sampling) instead of also the neighbouring pixels, which are the first-order reflections of a one-cell pattern. The entry also states the margin=True case that blocks fewer pixels than before.
• Lazy Waves.normalize() raised AttributeError; it now gives the eager result for any chunking.
• Eager SMatrix.build() stored complex64 plane waves under float64; it now follows the configured precision. The entry notes the doubled memory of the eager S-matrix, on the device or on the host, under float64.
• Eager SMatrix.build() with store_on_host=True raised AttributeError on the CPU device.
• GPAWPotential of a single calculator with an AtomsEnsemble or EnergyResolvedAtomsEnsemble raises a ValueError at construction (abTEM#538). The open question of abTEM#538, whether to support it, is not in the entry.
• Arithmetic between CuPy data and a NumPy array, a dask array of NumPy chunks or an array object with CPU data moves the host operand to the device.

The arithmetic entry describes the CuPy operand handling as abTEM#556 builds it. abTEM#556 asks the maintainer whether host operands should be moved to the device or refused with an error naming copy_to_device, and it leaves open the asymmetry that a CPU measurement on the left of a GPU one still raises TypeError. The entry follows the outcome of that question and is changed here if the design changes.

Fixes without an entry

None: all seven fixes can be hit on v1.0.10 (EnergyResolvedAtomsEnsemble, named in the GPAWPotential entry, is new in 1.1.0 and has the same defect on dev). abTEM#556 also describes two behaviours it leaves as they are, so they have no entry: the dtype a lazy normalize() declares, and the float32 result of a NumPy-scalar operand on CuPy data.

The Bugfixes section ends at the same place in #35 and #36, so whichever of the three merges second needs a trivial rebase of the insertion point.

🤖 Written by Claude Code — Paul reviewed and posted it