MLatom 3.25.4

• Fixed: the default KREG model did not load in 3.25.3 on Linux older than about 2021 — RHEL/CentOS 7 and 8, Rocky 8, Ubuntu 20.04, Debian 11. Its compiled kernel had been rebuilt for the Hessian fix on a newer system and needed glibc 2.34, where the 3.25.2 kernel needed 2.14. It is rebuilt from the same sources on an older base and needs 2.14 again; its energies, gradients and Hessians are bit-identical to 3.25.3's.
• Fixed: KREG Hessians were still wrong for anyone running MLatom under NumPy 2 — the 3.25.3 fix rebuilt only the kernel MLatom loads under NumPy 1; the one it loads under NumPy 2 predated the fix, and its Hessians were wrong — in our test by about three quarters of their size. It is rebuilt with the fix, gives results bit-identical to the NumPy 1 kernel, and also loads on older Linux.
• Fixed: nudged-elastic-band and dimer searches failed in 3.25.3 on ASE older than 3.23 with No module named 'ase.mep', because 3.25.3 imported them only from ase.mep, where ASE moved them in 3.23. MLatom now falls back to ase.neb and ase.dimer. (ASE 3.22's own nudged-elastic-band module also needs SciPy older than 1.14.)
• Fixed: $mlatom input.inp still failed with Permission denied after installing from source or from GitHub (pip install ., pip install git+https://...); 3.25.3 fixed it only for the package on PyPI.
• geomeTRIC must now be older than 1.1.1 (pip moves an installed 1.1.1 back to 1.1). Version 1.1.1 changed the rule that ends an intrinsic-reaction-coordinate branch, so its paths no longer match the ones MLatom is tested against.
• MDtrajNet needs e3nn 0.5.0, and the README and the documentation now say so: with e3nn 0.5.1 or newer, 0.6 included, the published MDtrajNet model produces a different trajectory, and 0.4.4 does not load with PyTorch 2.6 or newer.
• Fixed: the version banner named a source commit 16 commits older than the release.
• Corrected four statements in the 3.25.3 notes. They said nudged-elastic-band searches died on current ASE with Atoms object has no calculator: 3.25.2 hit that only when a band method other than aseneb was chosen, because ASE asks the end images for their energies with every method except aseneb, its default up to 3.27 (and 3.25.2's NEB does not load on ASE 3.27 or newer at all). They said NEB and dimer searches failed on any recent ASE with No module named 'ase.neb': that holds from ASE 3.27 on. They said the move to ase.mep worked on old and new ASE alike: it required ASE 3.23 or newer. And they said a calculation could append to the trajectory of one run before it: only calculations running at the same time could share that state.