Open rkurchin opened 4 years ago
Re: Ionic Transport
I haven't been able to work with this paper's data, here's a summary of what I've run into:
cif data is formatted as non-ASE compliant JSON, and Xtals.jl processing on a manual conversion is unable to convert to P1 space group.
I am not comfortable with space groups, so I have no idea where conversion is going wrong. Also, I do not believe ase specifies their exact JSON format.
I've looked at the HTGW paper, and I am more confident in getting something working, I just need to wrap my head around the wavefunctions and formulas. I may just work off its parent database (C2DB).
Wow, thanks for taking a crack at this! I visualized your manually converted CIF in VESTA, and I can't see any major red flags so I think the structure conversion is working fine. I'd have to spend a bit more time than I have right now to troubleshoot the conversion issues, but two questions:
manual = ase.io.read("LiNdP4O12_manual.cif") # I 1 2/c 1
type(manual) == ase.atoms.Atoms
ase.io.write("LiNdP4O12_ase.cif", manual) # P 1
This is a non-issue: ase uses the "updated" cif spec that uses the 'space_group' category instead of 'symmetry', _space_group_symop_operation_xyz
. So for Xtals to read properly, need to sub these fields in, ex: sed -i "s/_space_group_symop_operation_xyz/_symmetry_equiv_pos_as_xyz/" LiNdP4O12_ase.cif
.
However, ase produces a 4x unit cell version of this compound for some reason, Nd4 P16 O48 Li4 (due to P1 conversion?). I will need to test with more compounds.
Both Xtals and AtomGraphs are able to read this in: Concerning the unit cell duplication, would GNNs care about excess nodes/edges? I assume not really, as its kind of a crude analog of periodicity.
I was also wondering why space groups weren't being utilized here, as I feel they could be nice when dealing with crystal prototypes or anisotropic properties. But I guess dealing with P1 only is easier, and space group info should be embedded in the graph already.
Also, I tried to change the manual cif to xyz, but Xtals can only read in cif and cssr. And oops, I forgot that crystals have to be symmetric...
Concerning the unit cell duplication, would GNNs care about excess nodes/edges? I assume not really, as its kind of a crude analog of periodicity.
This multiplication of the unit cell is not really ideal, although in principle you're right that it shouldn't matter. At the moment, in practice, it does, because the pooling operations aren't smart enough, so you'd still get different results from a primitive cell graph vs. one of these supercelll-type graphs. All the more motivation for structurally aware pooling, cf #10...
I was also wondering why space groups weren't being utilized here, as I feel they could be nice when dealing with crystal prototypes or anisotropic properties.
They would definitely be nice, and I would love it if there were a Crystal
-like object that supported that rather than having to explicitly store all the coordinates! Unfortunately, to my knowledge, there isn't at present...would be a fun project to build one...🤔
But I guess dealing with P1 only is easier, and space group info should be embedded in the graph already.
The first part is true, but I disagree with the second part...you do strictly lose information going from 3D coordinates to an adjacency matrix representation, e.g. you don't know anything about angles, which are crucial to symmetries...
Also, I tried to change the manual cif to xyz, but Xtals can only read in cif and cssr.
Xtals can read xyz, you just need a different function because it reads to an Atoms
object rather than a Crystal
(then you can build a Crystal
object from it).
Saving these here because a DM Slack thread with @venkvis is not the ideal archival solution, also in case others want to comment/discuss...