mfherbst / AtomsIO.jl

Standard input/output package for AtomsBase-compatible structures
MIT License
17 stars 5 forks source link

Possible bug of `Chemfiles` parser for saving CIF files #31

Closed jywu20 closed 11 months ago

jywu20 commented 11 months ago

When the default Chemfiles parser is used to save a system to an CIF file, the CIF file generated doesn't agree with the input file that defines the system.

We use the following Julia script as a demonstration

using AtomsIO
using AtomsIOPython

system = load_system("TaSe2.pwi")

save_system("TaSe2-chemfile.cif", system)
save_system(AtomsIOPython.AseParser(), "TaSe2-ase.cif", system)

Below is the content of a Quantum ESPRESSO input file TaSe2.pwi:

&CONTROL
/
&SYSTEM
   ntyp             = 2
   nat              = 3
   ibrav            = 0
/
&ELECTRONS
/
&IONS
/
&CELL
/

ATOMIC_SPECIES
Ta 180.94788 None
Se 78.96 None

K_POINTS gamma

CELL_PARAMETERS angstrom
3.50960000000000 0.00000000000000 0.00000000000000
-1.75480000000000 3.03940275712187 0.00000000000000
0.00000000000000 0.00000000000000 6.24110000000000

ATOMIC_POSITIONS angstrom
Ta 0.0000000000 0.0000000000 0.0000000000 
Se -0.0001754800 2.0263698182 1.5602750000 
Se 1.7549754800 1.0130329389 4.6808250000 

After running the Julia script, we find that the file TaSe2-ase.cif produces the expected crystal structure (illustrated by VESTA):

捕获

The file TaSe2-chemfile.cif however is completely nonsense:

捕获

Currently I don't have any idea about whether it's an upstream bug caused by something wrong in Chemfiles.jl, or it's due to an incorrect function call in AtomsIO.jl.

mfherbst commented 11 months ago

Thanks for reporting. At the moment I'm also not sure whether this is an issue and where it arises. Since the Chemfiles interface is very little code, my suspicion would be to look in Chemfiles.jl.

Could you go a little more into details what you tried to ensure the two structures are different ? E.g. could they not be just a different representation of the unit cell ? On that note can you post / compare some geometry details, such as interatomic distances or similar? Also with the QE input if possible ?

Thanks!

jywu20 commented 11 months ago

Thanks for your reply. I double checked and it seems the two structures are indeed different: it's possible to find a viewpoint from which the atoms in TaSe2-chemfile.cif look as if they are on the same line:

3

while this is wrong for a 1T-TMD (transition metal dichalcogenide) and is never possible for TaSe2-ase.cif.

Below is a further piece of evidence: this is the expected structure from TaSe2-ase.cif:

1

And this is the wrong structure in TaSe2-chemfile.cif, from the same perspective: you can see that the two Se atoms (green balls) are all below the Ta atoms, which is wrong.

2

The lattice constants of the two structures as well as the angles between the edges are the same in the two structures.

The QE input file is already in my first post.

mfherbst commented 11 months ago

I see, but if I do the following, after running your code:

position(load_system(AseParser(), "TaSe2-chemfile.cif")) .- position(load_system(ChemfilesParser(), "TaSe2-chemfile.cif"))
bounding_box(load_system(AseParser(), "TaSe2-chemfile.cif")) .- bounding_box(load_system(ChemfilesParser(), "TaSe2-chemfile.cif"))

position(load_system(AseParser(), "TaSe2-ase.cif")) .- position(load_system(ChemfilesParser(), "TaSe2-ase.cif"))
bounding_box(load_system(AseParser(), "TaSe2-ase.cif")) .- bounding_box(load_system(ChemfilesParser(), "TaSe2-ase.cif"))

The differences are tiny, suggesting to me that they both represent the same structures. Also viewing both cif files in ASE's builtin viewer they look exactly the same to me. Maybe this is actually a bug in the viewer you are using?

jywu20 commented 11 months ago

I tried your test and on my machine it also seems that the two files represent the same structures. I haven't checked whether VESTA (the viewer I'm using) works as expected here ... this then seems to be a problem of incorrect CIF parsing in VESTA. Thanks for looking into the issue!