Discussion: Crystal structure

[adrybakov]

Topic: Whether to include in the file? How to include?

[mducle]

I think that it would be good to have a poll of whether people want to have the crystal structure included or not - this can be done in a Discussion but discussions are not enabled on this repo.

I would personally prefer to have it included because it is necessary for linear spin wave calculations, and even where it is not needed, I think that most uses of this file format would be based on a real crystal structure so it would be useful to have that included in the format.

[adrybakov]

Hi, yes, the discussions are disabled as they are hosted in one repository of the organisation, but are organisation-wide by themselves. I find them a bit confusing, while the issues have a clear relation to the repository and are a bit more focused.

Moreover, the primal idea (that was raised in one of the meetings) is to provide arguments for or against and try to reach a consensus trough discussion, and use polls (i.e. votes) only as a last resort. In that way the rational design is be promoted and choices based on pure taste are demoted.

Said that, every member can choose the topics that are more relevant to them (or all) and express opinions, propose design choices, etc. (or support already expressed ones, for instance with the reactions to them). Therefore, the final design will be based on participation and silence simply results in the acceptance of the choices written down by others.

This approach lifts the burden of constantly reminding everyone to participate in everything, while still leaves a way for everyone to affect all decisions and keep track of the pivotal points, which will come with explicit notifications of everyone (acceptance of FDP's (see #9) during the design stage) or call for an explicit approval (i. e. sigh-off on the design document at the end of the implementation stage).

[adrybakov]

About crystal structure

Yes, I agree that the crystal structure shall be included. For LSWT and for atomistic spin dynamics (ASD) it is essential. The interaction parameters will be linked to the set of labels of magnetic sites in their specification, thus the minimal information to include would be a unit cell and set of relative coordinates of magnetic sites within unit cell.

In the abstract format something like:

1.0 0.0 0.0
0.0 1.0 0.0
0.0 0.0 1.0

and

MS1 0.0 0.0 0.0
MS2 0.5 0.5 0.5

If the crystal structure will be included as a link to the external file (.cif, POSCAR, etc), then the mapping between the labels and the atoms in the dependency file shall be included. In my opinion this is not optimal, as it increases the complexity both on the developer side (need to implement reading of other format) and on the user side (need to keep track of two files and their compatibility). Therefore, I propose to include at least minimal info about the real-space structure of the Hamiltonian directly in the file.

Other things to consider

At least in the context of LSWT the crystal structure can include atoms that "do not participate" in the spin Hamiltonian, i. e. there are no parameters that are linked to them, nor they have sizeable spin or magnetic moment. While those atoms are completely irrelevant to the spin Hamiltonian as to the model, they are used, for example, to choose the k-path in reciprocal space. If the k-path is based on the space group of the underlying crystal and not only on the space group that corresponds only to the "magnetic atoms".

[mducle]

I agree with including a minimum amount of crystal structure information in the file itself, rather than a link to a .cif or .poscar.

For ease of use, I would also like to have the option to specify the lattice parameters rather than the basis vectors, e.g.

1.0 1.0 1.0
90.0 90.0 90.0

Regarding the non-magnetic atom - we could have an extra (optional) column in the list of coordinates which could be the spin length and could be set to zero for non-magnetic atoms, e.g.

MS1 0.0 0.0 0.0 1.0
MS2 0.5 0.5 0.5 2.0
O1  0.5 0.5 0.0 0.0
O2  0.0 0.5 0.5 0.0
O3  0.5 0.0 0.5 0.0

Edit - if this optional column is omitted all the atoms are assumed to be magnetic.

[adrybakov]

Lattice parameters

This can be potentially problematic as the lattice parameters do not specify the orientation of the crystal.

I imagine the following example use case for an abstract code named "AC":

The file is given by the user together with some vector of magnetic flux density (B). The most typical way is to assume that B is given in the global xyz reference frame. Now, the orientation of the crystal, when computed from lattice parameters, is arbitrary. Assume that the user thinks that the AC orients the crystal in the the usual way: a1 ||x and a2 in x-y plane. Unfortunately, there is no guarantee that AC do it in that way. Then the user might think that the magnetic field is oriented along one direction, but in the actual calculations it will be oriented along some other one. This leads to confusion and possible incorrect results.

Moreover, the interaction parameters (for instance the 3x3 matrix of bilinear interaction) is given in the global reference frame xyz as well. Imagine the exchange matrix with anisotropy along z:

1 0 0
0 1 0
0 0 1.5

Now, if the unit cell is given by lattice parameters, then the orientation of this anisotropy with respect to the crystal structure depends on how AC orients the crystal, thus making the file with spin Hamiltonian tool-specific.

An explicit set of three vectors eliminate those problem at the level of the file format.

[adrybakov]

Non-magnetic atoms

I agree with the extra column for the spin value. Actually, I advocate to make it mandatory.

The LSWT theory requires the value of the spin moment (independently of the convention of the Hamiltonian, i. e. whether the interaction parameters absorb spin value or not). Without it the spin Hamiltonian can not be used by tools that implements LSWT.

The fact that the atom is magnetic or not will also stem from the set of parameters (whether there are any that connects to it or not).

Perhaps we should mandate spin equal exactly zero for the atoms that are not included in the Hamiltonian. Otherwise, the interpretation of the file will be tool specific: consider DFT-based spin Hamiltonian that have small non-zero magnetic moment on non-magnetic atoms. Then the tool shall decide whether to account for those when adding external effects as magnetic field or dipole-dipole interaction.

[mailhexu]

I also think the spin moment is mandatory in many cases.
For the non-magnetic atoms, I propose to put a label rather than setting the moment to 0, so that all values are consistent with DFT results. For example we can add another column with True for magnetic and False for nonmagnetic, or 1 and 0.

Another thing to consider is that sometimes the norminal spin moment is used in the Hamiltonian, often being a integer or half integer, which is different from the DFT one. Should both the nominal and DFT value be reported if the nominal spin is used?

For some methods, computing of the exchange parameters are based on a reference spin configuration, for example magnetic force theorem or four-state method. I think there not only the length is important, but also the directions. This information should be optional but can be perhaps put either in this section or an separate one.

[adrybakov]

For some methods, computing of the exchange parameters are based on a reference spin configuration, for example magnetic force theorem or four-state method. I think there not only the length is important, but also the directions. This information should be optional but can be perhaps put either in this section or an separate one.

In the context of computing the Hamiltonian from DFT - yes, the spin directions are important. Still, the spin direction outside of this context can have another meaning - the state of the system (ground state, or metastable state, or just a state).

In my understanding of your sentence the spin directions are tied to the context (i.e. to the method of how the Hamiltonian was computed). The main aim of the file format is to define the parametrisation of the physical system. The method (as a name, i.e "LKAG" or "four-state") of its computation can be included in the metadata. The details of the method (i. e. reference spin configuration in the case of LKAG or huge set of spin configs in the case of four-state method) should be treated on the same ground as the configurational parameters of any calculation (for example the pseudo-potential choice or convergence parameter in DFT, or set of k-points in LSWT, or supercell size in ASD). Therefore, in my opinion it is outside of the scope of the file format.

[adrybakov]

Another thing to consider is that sometimes the norminal spin moment is used in the Hamiltonian, often being a integer or half integer, which is different from the DFT one. Should both the nominal and DFT value be reported if the nominal spin is used?

How physically meaningful the DFT-based spin value, when it is not a half-integer?

If it is not, then as the methods, that I mention before, are essentially a total energy fitting, then only the interaction parameters when |S| = 1 are meaningful and the spin value should be decided on the user's side, perhaps using the DFT result as a guide if it is close to the half-integer value.

[richard-evans]

I'm also happy with the 3x3 matrix definition of crystal shape, and relative coordinates inside of that. Also happy with including moment lengths and unit vector directions. Nominal values (eg S=1/2) I think are a bit more complicated as they don't have an explicit meaning in metals, and are method/tool dependent. This is probably wandering off this discussion slightly, and how we include things is probably more dependent on the actual file format. A 1D row of numbers (Label, x, y, x, mu_s, Sx, Sy, Sz) is compact and easy to read/write and understand, so I would be in favour of that.

[lucas-wilkins]

Two things:

1. Where should g-factors live, they're naturally associated with each atom, so probably here
2. When it comes to naming, some thought should be put into how semantic the naming will be. For example, one might label an atom "Cu", and that could be understood to represent a copper. In packages that use can it inferences about it can then be used, and its particularly useful for rendering. This then leads to the notion that we might want the label of the atom to be restricted to a set of potential names, or some conventions applied. Or, it might make sense to have a label, and the atom type separate.

[richard-evans]

1. Where should g-factors live, they're naturally associated with each atom, so probably here

Yes, and also potentially Gilbert damping parameters/tensors, along with moments lengths. These are the only on-site parameters that spring to mind for now.

2. When it comes to naming, some thought should be put into how semantic the naming will be. For example, one might label an atom "Cu", and that could be understood to represent a copper. In packages that use can it inferences about it can then be used, and it's particularly useful for rendering. This then leads to the notion that we might want the label of the atom to be restricted to a set of potential names, or some conventions applied. Or, it might make sense to have a label, and the atom type separate.

I am in favour of generic labels, such as Fe1, Fe2 as it makes it easier to track natural groupings, eg for antiferromagnets. I am not sure there is any point in a direct elemental association, as the properties are very much material dependent. However, I agree this is useful for visualisation. In VAMPIRE we have an "element" parameter, which allows exactly this so you can easily visually inspect the structure.

[manueldsdias]

Non-magnetic atoms

I agree with the extra column for the spin value. Actually, I advocate to make it mandatory.

The LSWT theory requires the value of the spin moment (independently of the convention of the Hamiltonian, i. e. whether the interaction parameters absorb spin value or not). Without it the spin Hamiltonian can not be used by tools that implements LSWT.

The fact that the atom is magnetic or not will also stem from the set of parameters (whether there are any that connects to it or not).

Perhaps we should mandate spin equal exactly zero for the atoms that are not included in the Hamiltonian. Otherwise, the interpretation of the file will be tool specific: consider DFT-based spin Hamiltonian that have small non-zero magnetic moment on non-magnetic atoms. Then the tool shall decide whether to account for those when adding external effects as magnetic field or dipole-dipole interaction.

It might be simpler to have a mandatory list of magnetic atoms and a separate optional list of non-magnetic atoms. Would the non-magnetic atoms play any role other that completing the specification of the system and allowing for the correct symmetry determination?