Heisenberg Hamiltonian structure

[GPMueller]

General

Maybe re-establish homogeneous and inhomogeneous hamiltonians, fusing neighbours and pairs together. The homogeneous model can assume a single set of constants for the first basis cell and translate this across the lattice, while the inhomogeneous model could e.g. generate full lists of interactions on creation, with a set of interaction pairs/neighbours for each single spin (or cell?).

This issue could also be related to the Geometry: When the geometry is not a regular lattice, things need to be done differently. This is currently not supported, but under development - a full neighbour list for the entire lattice could in principle be calculated in such a case, but the question is how the interaction parameters should then be set...

How to deal with pinned spins and atom types consistently and efficiently? - especially if no spins are pinned and all atoms have the same type?

Interactions

What needs to be covered:

• homogeneous interactions via neighbour shells
• inhomogeneous interactions via neighbour shells
• homogeneous interactions via pairs
• inhomogeneous interactions via pairs
• interaction depending on atom types
• regular distribution of atom types (fixed basis cells on a regular lattice)
• irregular/inhomogeneous/random distribution of atom types
• nontrivial or irregular Geometries

Examples:

• homogeneous interactions in center, smooth variation towards boundary
• strictly atom-type dependent interactions between spins, e.g. to respect vacancies
• vacancy modeled by variation of interaction parameters (inhomogeneous distribution)

Suggestions:

• unify pairs and neighbours again
• take two sets of input: homogeneous and (optionally) inhomogeneous modulations. According to these two, the full list of pairs/neighbours is built (potentially one list per spin?), potentially under consideration of the Geometry. This takes more memory, but should be most general and maybe most efficient (the nested arrays may be a problem)

Points to consider:

• one might have a system where everything is homogeneous, but there is one vacancy, i.e. a single atom of different type or a small region where the interaction strenghts are modulated
• having a optimized hamiltonian which is more simple but can be used for the most common cases might be worth implementing. special stuff can then still be done in the complex implementation

Fields

What may need to be covered:

• homogeneous field
• localized extra field
• multiple anisotropy axes per spin -> maybe split into multiple lists, make one pass per list for parallelization without atomics etc.
• statically inhomogeneous distribution of field or anisotropy

Examples:

• locally applied field pulse
• anisotropy variation at open system boundaries

Suggestions:

• have one single field vector (homogeneous field) plus a list (as is currently implemented) for the inhomogeneous component, which may be localized

Points to consider:

• an extra index list for a localized second field could have less entries, but if the field is extended the indexing procedure would add some cost

Energy functions

• each energy contribution for a single spin (calculate either for all spins or just a single one)
• energy contributions in total
• energy in total

Points to consider:

• monte carlo is not implementable in cuda for the general hamiltonian anyways
• using inline cuda kernels for single spin energy calculations, calling them from the generalized function does not do away with the kernel overhead... how can we avoid code duplication here??

[GPMueller]

Concerning the fusion of neighbours and pairs:

• The neighbour-shell-wise interactions could just be a wrapper to automatically generate pairs. Note that certain cases may produce non-symmetry-equivalent neighbours in the same shell. this would be inefficient when using OpenMP or CUDA
• The pair input could conversely be translated into neighbours per atom, where a pairs_least_symmetry flag could switch between mirroring (when interactions are symmetric, i.e. J_ij = J_ji). this would be inefficient when using single-threaded

The inhomogenous interactions should (at least for now) exclusively be done by creating a correspondingly-sized single basis cell.

[GPMueller]

Note: it would be advisable to retain information on whether interactions were provided in the form of neighbour shells or pairs etc.

[GPMueller]

• The generalized Hamiltonian_Heisenberg should have two constructors, one with exchange and DMI shells and one with pairs. All other interactions etc. should not be affected.
• The heisenberg_pairs and heisenberg_neighbours flags can stay in place in order to discriminate between the two ways of setting up.
• The UI should only have one panel for the Hamiltonian. When pairs are used, the shells should be set to zero. If shells are used, the shells are visible but the pairs are also displayed.
• When the geometry is changed, the Hamiltonian uses the number of shells to determine if he should use neighbour-shells to set up the lists. If they are zero, pairs are used (i.e. nothing needs to happen).
• When the neighbour shells are changed, a new pairs list for the basis cell is generated.
• We should add functions to warn the user
  • if changing the geometry had an influence on the pairs (some symmetry changed)
  • if there are non-symmetry equivalent neighbours in the same shell

Creating a list of pairs

• from neighbours: generate full list of neighbours and list of shell indices
  • on single-threaded: then filter out the symmetry-redundant neighbours (and corresp. shell indices)
  • on openmp/cuda: take full list of neighbours Then, set the list of exchange magnitudes/dmi vectors according to shell indices
• from pairs:
  • on single-threaded: just take list of pairs
  • on openmp and cuda: mirror all the pairs and write them into long lists

Functions:

• two constructors for Hamiltonian_Heisenberg
• single Configparser Hamiltonian_Heisenberg_from_Config, with two extra functions for pairwise interactions
• Neighbours::Remove_Equivalent_Neighbours which takes a list of Pairs and a list of shell indices and removes from both the redundant entries
• add #ifdef part to Dataparser, which mirrors the Pairs if openmp or cuda version
• Neighbours:: Get_Pairs_in_Shells, Get_Pairs_in_Radius, Get_Neighbours_in_Shells, Get_Neighbours_in_Radius should be reduced to two functions:
  • Get_Pairs_in_Radius, which simply produces a list of pairs
  • Get_Neighbours_in_Shells, which produces a list of pairs and a list of corresp. shell indices (using the remove-equivalent function)
• Rewrite Heisenberg Energy to be calculated as scalar product from gradient*spin

[GPMueller]

Implemented on PR #395, merged with 3531992673e1bd4da1a043dea50e1f2994d79bde. TODO:

• rewrite Heisenberg Energy as scalar product of gradient and spin
• Energy calculation for single spins (for Monte Carlo)