I am looking to build a 110 slab of albite, something I have been stuck on for a while. One of the benefits on avogadro seems to be that is aligns the cut surface with one of the major axis.
I import an albite cif unit cell, and then build a slab with 110, as per the tutorial. The 110 slab is cut, but it does not align with any axis. Thus when I move it into ovito or LAMMPS I run into major issues. The big thing needed is to have that 110 surface aligned along a major axis. Is this possible?
@liammo29 I lack experience to pymatgen and hence perceive the provision of eight decimals for the lattice vectors and angles as a bit too many. See e.g. the typical precision on single crystal XRD and PXRD for comparison (COD has a couple of entries if you search by albite, too). Two questions though:
the .cif shared states P1 as space group symmetry, and thus table 1 of the International Tables for Crystallography. The three different lattice vectors and angles are consistent with this triclinic setting. But I miss an entry in line of _symmetry_cell_setting triclinic in the same loop of the cif file. Does pymatgen regularly omit this line (which, in case of higher symmetry, can end with the other family like monoclinic all way up to cubic)?
The cif shared states _chemical_formula_structural NaAlSi3O8 but then reports _chemical_formula_sum 'Na2 Al2 Si6 O16'. Is there a particular reason for this multiplication by a factor of two? See, for comparison the example of COD 2107372 (which equally describes albite in a triclinic setting, though different lattice parameters, and different space group symmetry P-1, i.e. including a centre of inversion): both entries stay with Al Na O8 Si3 . Because this database allows free share of data, the .cif (with an additional .txt file extension) is attached below.
So I did some testing on a few options. There are two different types of cif files, symmetrized and computed. In MD I typically have working with the conventional standard/symmetrized and had no issues.
It seems avogardo does not like these though. If I run with a computed cif things behave as expected! I wonder why? I am getting the computed from materials project/pymatgen as well.
Can you be a bit more specific on what you mean by that?
By default, Avo2 will show only the symmetry unique atoms for a unit cell - happy to have continued discussions about the defaults, but several people asked for this instead of the heuristics used in Avo1 to detect “inorganic” vs “molecular” CIF files.
As a follow up, I am able to make the surface but see an odd issue exporting it as a pdb. I have tried this with a couple of different cif files, the attached is for the 2107372.cif file given earlier in the thread. I am taking this file, opening in Avogadro and then saving as a pdb.
If saved as a PDB (attached for just a single albite from the cif) and then opening in ovito it thinks there are 14 different atom types. If in ovito I then write a lammps data file it again thinks there are 14 different atom types. I can go in and fix this by defining 4 atom types (1-4) instead of the 1-14 it thinks there are. But this is too tedious for anything larger. Is there any way to overcome this in Avogadro? 2107372.data.txt (4.2 KB) 2107372.pdb.txt (7.4 KB)
I don’t know why Ovito is deciding on 14 different atom types - I don’t use the program. (Seems like a better question over there.)
One question would be to use a different file format, since perhaps Ovito is not parsing the PDB correctly?
Avogadro 1.97 has a LAMMPS input builder contributed by a user. It could be useful instead of going to Ovito. Certainly, it’s easier for me to fix issues with Avogadro than with Ovito.
(As to the "can I generate surfaces with Avogadro 1.97 … let me write the appropriate pymatgen plugin script this weekend. It’s been on my TODO for a long time.)
