Magnetic moments property

[eimrek]

There is interest in including magnetic moments in the OPTIMADE specification (also mentioned in #426). The purpose of this issue is to discuss this and collect relevant data.

What probably makes sense is to look at what formats are already used in

• ase
• pymatgen
• magCIF/mCIF

Points to consider:

• In dft (and probably other approaches), there are two ways to handle spin:
  • collinear - magnetic moments are described via a single scalar per atom
  • non-collinear - magnetic moments are described via vectors per atom
• the magnetic moment vectors could be represented either in crystal or cartesian coordinates.

pinging people who have expressed their interest: @giovannipizzi @oke464 @JPBergsma @unkcpz @mxjk851

[unkcpz]

mCIF uses section atom_site_moment to represent the magnetic info of a site, the vector can be either crystal coordinates, cartesian coordinates or polar coordinates.

Pymatgen when reading the mCIF, it uses only crystal coordinates https://github.com/materialsproject/pymatgen/blob/caf71ff9a9df6b061cf91d1645a462f45f957ab2/pymatgen/io/cif.py#L485-L488

[blokhin]

In ase, magnetic moments can be either a single value for each atom for collinear calculations or three numbers for each atom for non-collinear calculations.

NB they are stored as a numpy array, and syncing them with the atomic positions upon re-ordering seems not to be supported (cf. a similar issue with the fractional occupancies).

[MXJK851]

In atomistic spin dynamic codes, e.g., UppASD or Spirit, I think both 'Collinear' and 'Non-Collinear ' are useful, but in most cases, the user is interested in 'Non-Collinear' case.

The formats used in those kinds of code are similar, i.e., using a simple array-like Plain text, which is also human-readable.

One example from UppASD could be:

1 1 2.0 0.0 0.0 1.0

The first entry is the site indicator which should be the same in posfile (file that stores cartesian coordinates of magnetic atoms), the second entry shows the chemical type (always 1 for non-random systems), and the third entry indicates the magnitude of the magnetic moment in the unit of Bohr magneton which should be calculated from DFT. The last three entries indicate the direction of the spin which is a normalized vector.

Note that in Spirit code they also use the same atomic moments that are specified in units of the Bohr magneton. More detail can be find here:

https://uppasd.github.io/UppASD-manual/input/#momfile

https://spirit-docs.readthedocs.io/en/latest/core/docs/Input.html

As what we discussed with @giovannipizzi, except that cite-based information, there are also pair-like data may be interesting for users to get from the database.

One example could be a Jij, this interaction can be store explicitly as:

1 2 -0.500 -0.500 -0.500 1.359407144 0.866(UppASD )

The first two entries indicate the site types. The third, fourth, and fifth entries specify the interaction vector between the atoms, and depending on the choice of the maptype(this keyword only works in UppASD), it has a different meaning. The last entry indicates the exchange energy in mRy, and the last entry (not read and optional) is the distance between atoms.

Another example from Spirit is

i j da db dc Jij Dij Dijx Dijy Dijz 0 0 1 0 0 10.0 6.0 1.0 0.0 0.0

which also stores pair-wise interaction parameters for energy per unique pair . But here in this example, DMI also includes as Dij.

There are two possible ways, from my thinking, that users of spin dynamic code want to use OPTIMADE. The first one is to find the input parameters from DFT, which could be initial magnetic moments, interaction parameters, or others. the second one can store their result, e.g., predicted magnetic ground state (spin configurations) or Magnon spectra (array-like data).

We will back to this issue with more detail after the discussion this week.

[mkhorton]

Pymatgen when reading the mCIF, it uses only crystal coordinates

I'm responsible for this... at the time of implementation, the magCIF standard had actually not yet been finalized. We requested a scalar magnetic moment (for computational use) but I don't know if that ever made it into the spec; I think it did not. In any case, the pymatgen code is only implementing a subset of the final specification.

I apologise for being slightly out of the loop; I have two thoughts that may not be useful, (1) that following naming conventions from the magCIF standard wherever possible would be nice (indeed, a general mapping for going from CIF dictionary specification into OPTIMADE could be reasonable), and (2) that properties associated with a site may be one of several data types (e.g., axial vector, polar vector, some matrix/tensor, string or categorical information, etc.), any solution for storing magnetic moments maybe could consider the broader question of how to store vector-like site properties.

[ml-evs]

Just to cc @rartino about some of the messages above, I've found that bohr magneton is not currently listed under https://schemas.optimade.org/defs/v1.2/unitsystems/optimade/optimade.html What would be the process to go about adding it (should we decide to)?