BUGFIX: Initialize `constraints` in `read_castep_castep`

Closes #1524 (closed)

This MR solves the issue above by initializing constraints in read_castep_castep.

Since the change is minor, I would like to merge this soon.

Checklist

• I am familiar with ASE's contribution guidelines.
• Doc strings in code changed in this MR are up to date.
• Unit tests have been added for new or changed code.
• Issue is resolved via "closes #XXXX" if applicable.

changed the description

merged

mentioned in commit fe53425c

Thanks for getting this fixed so quickly - would this be an issue if there was a constraint on the atom (just they haven't been written to the castep file yet?)

The issue was not related to the existence of constraints in the castep file. The issue was because, as I partly wrote in #1524 (closed),

• In one-atom case + GeometryOtimization, the force block is not written for most SCF steps.
• In the castep file, constraints (regardless if they exist or not) are written together with forces, and therefore, if the force block does not exist, constraints are not read as well.
• Nevertheless, read_castep_castep tries to set constraints, and when it is not initialized, then the error is raised.

So for the atoms object to be initialized with the correct constraints wouldn't it be necessary to look ahead to find the forces block in the single atom case? Or is "constraints" always guaranteed to be [] in this case. I'm obviously not very familiar with CASTEP - so happy with this fix if you are.

I believe that, in most cases, GeometryOptimization (and maybe MolecularDynamics) is meaningful only for systems with more than one atom, where the issue does not happen anyway.

If you have some actual problem, it would be again helpful to open the issue with a minimum complete example :)