Changelog entries for abTEM#556 (seven fixes, two changes in results, CPU–GPU arithmetic)

[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 CPU and GPU data gives the GPU result: the side on the host is moved to the device, in either operand order, a lazy one block by block at compute time; before, it raised CuPy's TypeError, for two lazy operands only at compute time.

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 behaviours it leaves as they are, so they have no entry: the float32 result of a NumPy-scalar operand on CuPy data, and the dtype a lazy normalize() or integrate_gradient() declares, which abTEM#506 corrects.

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 and posted by Claude Code on Paul's behalf