Remove rounding during FEFF writing

[matthewcarbone]

pymatgen/io/feff/inputs.py lines 504-506 rounded the FEFF geometry to 6 decimal places by default. This also occurs in 518-520. Other writers (such as the one for EXCITING) do not appear to do this. This commit makes a simple change and removes the ":f" from the string representation in the lines formatting. Thus FEFF clusters will now be saved with default precision (or whatever self._cluster uses).

I'm implementing this fix because it's actually causing me some precision issues when testing save spectroscopy input files for FEFF against other codes, and also because this would make the FEFF writers consistent.

I'm also happy to use this PR to help make the other codes consistent. Thoughts?

Checklist

• Google format doc strings added. Check with ruff.
• Type annotations included. Check with mypy.
• Tests added for new features/fixes.
• If applicable, new classes/functions/modules have duecredit @due.dcite decorators to reference relevant papers by DOI (example)

Note I don't think that there are any new tests to run here.

[janosh]

I'm also happy to use this PR to help make the other codes consistent. Thoughts?

Thanks @matthewcarbone. Which other codes are you referring to?

[matthewcarbone]

@janosh

Thanks @matthewcarbone. Which other codes are you referring to?

Well, selfishly the ones I use here: FEFF, EXCITING, Xspectra, OCEAN and VASP. But that can just be a starting point!

[janosh]

I think I can see both sides. Why not write geometries as is, as you're suggesting.

On the other side, there's usually no point in recording higher float precision than what your data has i.t.o. significant digits. Is yours more accurate than 1e-6? If not, maybe a rounded equality check or using something like np.allclose would be a better option for you?

[matthewcarbone]

I think I can see both sides. Why not write geometries as is, as you're suggesting.

It's more just write them at the precision specified by self._cluster instead of constraining the precision in a way that seems arbitrary.

On the other side, there's usually no point in recording higher float precision than what your data has i.t.o. significant digits. Is yours more accurate than 1e-6? If not, maybe a rounded equality check or using something like np.allclose would be a better option for you?

Certainly true. This is really a nitpick, but when doing some sanity checks on my end, the problem is that the precision differences cause sorting issues which scramble the order of atoms! I can give you the long story "long", if you want, but that's the long story short.

Is it a big deal? No absolutely not. But why not be consistent!

[janosh]

But why not be consistent!

Sure, I'm happy to go ahead with this. I'm also not a user of these parts of pymatgen myself so just trying to get an idea on what's the best course of action. The other option that comes to mind is to add an explicit fmt: str = '' keyword. So the old behavior could still be retained when users pass fmt=".f".

[matthewcarbone]

Sure, I'm happy to go ahead with this. I'm also not a user of these parts of pymatgen myself so just trying to get an idea on what's the best course of action. The other option that comes to mind is to add an explicit fmt: str = '' keyword. So the old behavior could still be retained when users pass fmt=".f".

Yes we definitely could do that too! What would you like to do? If you want I can implement this. We'd have to have a lot of passthroughs from the FEFFDictSet -> Atoms -> etc. so it will take another commit or two.

[janosh]

Please go ahead.

[janosh]

merging as is now since it went stale and seems like a small improvement