jgreener64
commented
1 year ago Looks like a good start, this would be useful functionality. I wonder if it could be its own package though? This would let people use it in generic contexts other than Molly, and Molly could depend on it for setup functions or examples.
One issue would be whether you require Molly types, in which case you would have to depend on Molly. It might be easier to use types from AtomsBase.jl as required or define types that are compatible with AtomsBase.jl, for example they have support for boundaries. Short conversion code could then be written in Molly to convert to Molly types.
ejmeitz
codecov[bot]
Hello,
I've been working on some code to generate crystal structures and get back a list or coordinates, atoms and the boundary needed to run the simulation. The code is more or less untested and I just wanted to discuss the implementation of the interface. There are many types in this file, but the only ones I intend to export are the functions at the bottom of the file which are not fully implemented. When complete these functions should cover all possible Bravais lattices in 3D and provide sufficient coverage of crystal structure for as a starting place. As it stands, the functions at the bottom of the file (e.g. FCC, Diamond) are just functions that return a crystal type for you. Then you'd have to call replicate_unit_cell to get back the atoms, coords and boundary. I'd prefer this just be one call to FCC() that gives you atoms, coords and boundary,
Some background:
A crystal is defined by a lattice (repeating grid of points) and a basis (atomic pattern at each lattice point). As such the crystal type takes a BravaisLattice, and Vector of BasisAtoms in its constructor. The way in which the Bravais lattice is initialized specifies whether it will be FCC or BCC etc. and the basis atoms allow for more complicated structure like Diamond or Wurtzite to be constructed.