Core: make geometry variable at runtime

[GPMueller]

Three things must be considered:

• Geometry
• Hamiltonian_Anisotropic
• Hamiltonian_Isotropic (less important)

[GPMueller]

Requires: #101 and #117

[GPMueller]

To cite @SpiritSuperUser from #212:

It might be useful, to make the lattice dimensions adjustable on the fly by adding/deleting a given number of rows in each direction without changing the other parts of the lattice. with this, is would be easier to analyze the effect of boundary conditions and lattice dimensions on a structure.

if one adds rows, one might have to think about how and where to initialize the new ones.
My suggestion:
either

• ferromagnet in a definable direction
• copy of the neighboring already existing row and define number of rows to be added on both sides of each direction
• add a "centered" check box which averages when activated automatically the two input values to add the same amount of rows in each direction

[GPMueller]

Some considerations:

• the geometry's n_cells and spin positions need to be updated
• the spin_system's and the state-clipboard's spins need to be updated
• all other NOS-sized arrays need to be resized (for others the previous data should not matter)
• the Hamiltonian needs to check if all pairs/neighbours lie within the new system size (esp. DDI)

Probably it makes sense to only allow this change for the whole collection at once, as otherwise checks for fitting NOS between copy/paste, gneb etc. would have to be added.

In order to update spins we need to adequately copy over existing data to a larger (or smaller) array. The spin_positions can be easily re-generated.

[GPMueller]

Started work on this on feature-variable-geometry with 2f9690b.

[GPMueller]

#160 should be resolved in order for variable geometry to function properly.

[GPMueller]

With 3f2eb1c on feature-refactor-geometry, work on this has resumed. The Geometry construction mechanism has been significantly improved.

[GPMueller]

With f79f5d0 on feature-refactor-geometry, the Geometry has been made runtime-variable in a crash-free way. Both Geometry and Hamiltonian are now far less dependent on system size and instead are focused on a basis cell.

Except for the basis cell, everything in the Geometry can now be made variable via API functions.

What to do when the basis cell is changed? Especially the Hamiltonian would have to be treated accordingly - pairs would no longer be valid, but could be re-calculated if information is available in form of neighbour shells.

What to do with atom_types when the lattice is changed? See also issue #143 - how would disorder be treated in contrast to a fixed distribution of atom types in the basis cell?

[GPMueller]

The ground work was merged into develop with f36fea8.

TODO:

• API function to change n_cells
• Refactor parser and the Geometry class to contain more useful information and easier handle changes during runtime (see also Core: rewrite configparser and constructor for Geometry #117)
• API function to change the bravais vectors/lattice
• API function to change the lattice constant
• Add some more bravais lattice types
• Function to re-package vectorfields, scalarfields and intfields into new geometry, without changing the geometric ordering of the data (i.e. change the ordering in the std::vector accordingly)
• API functions to change the basis cell (either need to call other API functions to delete all interactions (preferable) or notify the user somehow) the function has been added, but it does not correctly deal with the Hamiltonians!

[GPMueller]

Implemented function to re-distribute vector-fields on new Geometries with ef70284.

[GPMueller]

I don't know when, but Geometry_Set_Cell_Atoms has been implemented and available bravais lattice types are:

• SC
• FCC
• BCC
• Hex2D (60deg)
• Hed2D (120deg)

I believe the QT UI can soon add the corresponding tab permanently and remove the "might break the code" remark (also as features are now more tested since c3422bc).