Core: add input and features for generating large, inhomogenous systems

[GPMueller]

The config-parser could read in a number of different files/sections, one being the "host" lattice and the others being defects etc.

When a large system is used, but only a few defects are placed on the surface, the desired workflow would be:

• a large single basis cell is created, determined by the "host" lattice and the "defect" extra atoms
• the input of the clean "host" lattice is read in
• the inputs of the defect interactions and moments are read in and for each
  • the corresponding atoms' moments are set (and potentially the atom types)
  • the corresponding atoms' pair lists are set

Note: the "corresponding atoms" include the atoms of the "host", with which a "defect" interacts, as their interactions (also among "host" atoms) may be modulated.
Thereby, long-range modulations in interaction parameters could be efficiently input into the code, without the need to generate a file containing the list of all pairs (which may become very large, depending on system size, while in this case the list size remains constant).

It would probably be best to implement #420 first, as having one list of pairs per basis cell atom would greatly simplify this procedure.
Also, #340 (see PR #416) is related to this and should probably be implemented first.

[JPchico]

One way in which I solved this in the UppASD code was by creating two types of geometries, a "host" geometry (which would be equivalent to the used now) and a "impurity" geometry.
This allows one to generate the "host" with a minimal set of inputs (equivalent of what would be used now), which is locally modified by the impurities.

The idea is the following

1. Read the minimal data set for host and impurity
2. Generate dummy geometry for host, and generate the geometry of the cluster (allowing for the cluster to be repeated along a given set of lattice vectors a certain number of times)
3. Check if the atoms in the cluster belong to the dummy host. If not generate an auxiliary list with these atoms (this allows to have adatoms and deposited clusters in the system in a simple manner)
4. Generate the full host geometry and add any atoms that belong to the special list.
5. Mount the Hamiltonian for both systems
6. Locally overwrite the Hamiltonian of the host that belong to the impurity cluster.
7. Free resources.

[GPMueller]

The options are:

• use atom types to define an impurity cluster and, if adatom on a lattice site, use an extra layer of almost only of vacancies
• setup the system as one big basis cell
• change Spirit to accept more complex input as a convenience layer

---

The main issue with impurity clusters is to add one or more additional atoms, which are not a part of the lattice.

Issues with adding it to the list of spins and positions:

• some loops use the size of these lists

Issues with creating a separate list:

• the calculation of number of spins might become broken in some places
• this would have to be done also for Hessian matrices etc...

This is my current draft for the documentation description, after which the implementation should be modeled:

Impurity Clusters

This describes how to embed impurity clusters in a host medium.
Note: this only works with the Heisenberg Hamiltonian.

Geometrically, a cluster is defined by the structure of the host lattice.
Interaction pairs are interpreted relative to the center of each cluster.
The cluster bravais vectors define the relative position of two
clusters in the corresponding host bravais vector directions.

# The clusters are repeated along translation vectors
n_clusters 3 1 1
# The position of the "first" cluster in host lattice translations
cluster_position 50 50 0
# The translation vectors for the cluster "lattice"
# Note: in units of the host bravais vectors
cluster_bravais_vectors
20 0 0
0  1 0
0  0 1

The interactions inside each cluster are specified analogous to interaction_pairs,
and will override the interactions specified for the host lattice.

# i, j, relative position i, relative position j, Jij, ...
# translations are relative to the cluster_position
n_cluster_interaction_pairs 2
i j  dai dbi dci  daj dbj dcj Jij
0 0   1  0  0    1  0  0    1.0
0 0   0  1  0    1  0  0   1.0

In order to physically describe impurity clusters correctly, it may be
necessary to place a few additional atoms on top of each cluster.
These can be specified by positions and require an additional list of interactions.

# dx  dy  dz   mu_s
# the position can be anywhere (also non-integer translations)
# and is specified relative to cluster_position
cluster_additional_atoms 1
   0   0  0.5   2.0

How to specify interactions with this additional atom

# note that i here means something different:
# it is the index of the adatom
n_cluster_interaction_pairs 2
i j  da db dc   Jij
0 0   1  0  0   1.0
0 0   0  1  0   1.0

[GPMueller]

Did some work towards this on feature-impurity-cluster (starting with 60d0406).

However, I am currently not sure that it wouldn't be better to simply write a Python script, which generates the input, creating a single large basis cell for the whole system. To get a performant parallelisation, #420 would have to be implemented (parallelisation over all atoms, not just over basis cells.

The input described above is so complex that generating it requires some scripting anayways, at which point the only advantage of the above would be that the host lattice and its interactions could be changed at runtime.

[GPMueller]

Another idea to simplify the creation of a large, inhomogeneous system might be to allow some scripting in the input file(s). https://github.com/ChaiScript/ChaiScript seems a very good candidate for a lightweight scripting language, which is additionally typesafe and well-integrated with C++.