Potential bug: castep geometry optimisations

[VladCarare]

I'm reporting this in regards to doing CASTEP geometry optimisations thorough workflow, and having issues with the output structures. Specifically, it seems the output structures do not fully correspond to the last structures in castep.castep file, as they should. While the forces do correspond, the lattice parameters of the workflow output structures are identical to those of the starting structures, which I suspect are used to hash the structures.

I mention that I am using the workflow on the old repository, but I checked the log here and cannot see that any changes have been made, so I think the problem may still stand. I could follow up once I move to the new workflow. This may be actually more of an ASE feature that needs implementing, but I thought I'd flag this up just in case.

[bernstei]

Are you using CASTEP's internal minimizer, or the workflow's wrapper around PreconLBFGS? If the latter, that's almost impossible, so I hope not. If the former, it could be an ASE bug, or something slightly messed up in the way we are using the ASE CASTEP calculator.

[VladCarare]

I'm using CASTEP's internal minimizer.

[bernstei]

OK - that's probably an ASE bug, but may be the way we call it. Ideally someone who knows CASTEP better can check, but I'll take a look as well.

[bernstei]

wfl just calls Castep.calculate(). From what I can tell calculate calls read, and read updates the atomic positions. I don't see any reason why it shouldn't be working. I don't have access to CASTEP, so someone who does would need to dig into it. First thing is probably to add print(...) statements to wfl's calculator wrapper, and confirm that at is actually getting updated in the at.calc.calculate() call. If it's not, then add print(...) to the ase/calculators/castep.py, starting with calculate() and probably also read() to figure out why the object isn't getting updated. If it is getting updated in the wfl wrapper but that's just not propagating back out, I can try to take a look.

[bernstei]

@VladCarare has anyone confirmed that what you're trying to do, namely updating positions using the underlying DFT code, even works with the ASE calculator? I've been looking into the ASE calculator structure a bit more carefully, and I'm not even sure it's possible. The whole thing is rather messy. Castep.set_atoms() makes a copy of the atoms object in self.atoms, which means that any changes it makes to the internal atoms object won't be reflected in the original atoms object.

I'd like to see a pure python/ASE example of it working before digging into whether workflow is messing it up.

[VladCarare]

Yes I think it's an ASE issue actually. I found a workaround for now, will just be manually reading (using ase.io.castep.read_castep_geom) the last config from the castep.geom file. Could we put this issue on hold for now?

(By the way, I'm sorry for not being very responsive, on multiple issues. The reason for it is that I began my current PhD project rather late (spent the first year doing something else), and I'm constantly a bit stressed and mostly focused on the main work, in order to be able to finish in 1.5 years. )

[bernstei]

No problem, and no rush from my point of view - I just want to help, so if any of these issues are what's limiting your progress, it's in both our interests to get them resolved.

[VladCarare]

Thanks! Yes, from my side I'd put this on hold for now.

[bernstei]

OK. I think we'll end up closing it, because it's an ASE issue, but I'm happy to leave it here until we make a firmer conclusion about that.

[bernstei]

not likely to need to be addressed in wfl, since it's an ASE issue