mfherbst / atomsio.jl Goto Github PK

https://github.com/schneiderfelipe/Cclib.jl

There seems to be an issue with saving quantum espresso input files, making the tests currently fail.

Concrete examples or pointers appreciated.

https://github.com/libAtoms/ExtXYZ.jl

Document better:

• Supported file formats
• Caveats with some parsers
• Advanced tricks, such as specifying kwargs (e.g. to select specific readers / writers in ASE)

This issue is used to trigger TagBot; feel free to unsubscribe.

If you haven't already, you should update your TagBot.yml to include issue comment triggers.
Please see this post on Discourse for instructions and more details.

If you'd like for me to do this for you, comment TagBot fix on this issue.
I'll open a PR within a few hours, please be patient!

Hi @mfherbst,

I'm still running into errors when parsing a simple .xyz file. The xyz file was generated from LAMMPS at the end of an MD trajectory and can be obtained here

Running

using AtomsIO 
sys1 = load_system("./dump_final.xyz")

generates the following error:

Failed to parse string at pos 7
ERROR: BoundsError: attempt to access 0-element Vector{Any} at index [0]
Stacktrace:
 [1] getindex
   @ ./array.jl:924 [inlined]
 [2] last
   @ ./abstractarray.jl:479 [inlined]
 [3] load_system(::ExtxyzParser, file::String, index::Nothing)
   @ AtomsIO ~/.julia/packages/AtomsIO/gPmVc/src/extxyz.jl:17
 [4] load_system(file::String, index::Nothing; kwargs::Base.Pairs{Symbol, Union{}, Tuple{}, NamedTuple{(), Tuple{}}})
   @ AtomsIO ~/.julia/packages/AtomsIO/gPmVc/src/saveload.jl:43
 [5] load_system (repeats 2 times)
   @ ~/.julia/packages/AtomsIO/gPmVc/src/saveload.jl:42 [inlined]
 [6] top-level scope
   @ ~/cesmix/exploratory/public/interpot_comparisons/lj/atomsio_tests/new_version_nopluto/new_atomsio_tests.jl:3

I've tried using both the tagged 0.2.0 release, as well as with the most recent commit (#aac46e8).

Thanks!

Because I forgot to push a deploy key.

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.

Chemfiles seems to be a very nice library for reading and writing a variety of common atomic structure file formats (although not nearly as many as ASE).

Notably, it has a Julia interface which would avoid the need for a python dependency (which is always nice).

Is there a preferred method / approach to extending this package?
In particular, I would a HDF5 reader for VASP, but I don't really know whether it makes most sense to write a (HDF.jl depending) function in AtomsIO.jl; or write a vasp_HDF5.jl package elsewhere and wrap here, or ... ?

https://wiki.fysik.dtu.dk/ase/