Constraint magnetism in KKRnano

See merge request kkr/jukkr!15

A simple two-atom bcc Fe unit cell, constraint to some
non-groundstate configuration. Also uses external fields.

Note that the new test case needs two iterations so that the
updated constraining field effects the calculation and thus this
update is checked.

The run_test.sh script explicitly used python2.7, and the shebang
of the tests.py script was just python, which is normally also
python2, while the script was clearly a python3 script.

Also repalced the nonexistend ArgumentError with a ValueError.

Sets the spin-flip terms of the SOC Hamiltonian to zero in spinorbit_ham.
Usage: Set '<soc_no_spinflip>= True' in the inputcard

Was not consistend with "constraint", "constrained", and "constraining".

The constraining fields were only updated in the master group, so not on
all ranks. Some ranks kept applying the initial constraining fields.

To fix this, the constraining fields are now communicated similarly to
the potential.

calc_onsite_only testflag for KKRimp

Add write_double_precision run option for KKRhost and read_doubleprecision testflag for kkrimp to use doble precision kkrflex_green files instead of single precision files

also add test option write_tmat_all
and make KKRimp and KKRhost compile simultaneously

The magnetic torque can be defined either as the derivative of the
total energy with respect to the magnetic moment direction
(T = dE/de) or as the perpendicular part of the derivative of the
total energy with respect to the magnetic moment (T = P dE/dm).
As de = 1/|m| P dm, the two definitions have the same directions
and differ by the factor 1/|m|.

So far, the first definition was used.
However, we decided to switch to the second, as it is easier comparable
to the constraint magnetic field (same units) and thus also makes it
easier to use the torque in scripts or as an initial guess for constraint
magnetic fields.

!! Note that his commit might BREAK COMPATIBILITY with previus scripts !!

Store the constraint fields from last iteration, write them to the
result file, and from that calculate the change of the fields.
Writes the maximum change and corresponding atom to output in each
iteration.

The loop calculates the difference in angles before and after they are fixed.
This should always be zero for non-constraint moments (apart from a small deviation
that we not fully understand right now) and converge to zero for constraint moments
(at least approximately, with the torque-based calculation there will be some remaining
difference). For angles constraint only with the old method however, this will converge
to a non-zero value that is not of interest and hides the information on the constraint
moments. Thus, after this commit, they are skipped in the calculation of what is called
"Largest change of angle for constraint moment".

Calculates the angle of the magnetic moment before the fixing of the direction
is applied. This is compared to the directions, the maximum written to stdout.
It does not directly tell you whether the constraining fields converge,
but whether they currently achive what they should eventually do.

If noncollinear magnetic fields are enabled (noncobfield=t) but
noncollinear magnetism is not (korbit=0), the program will print
an error message and halt.

The constraint magnetic field that is calculated based on the torque
is now muliplied by the sign of the magnetic moment in the local
frame of reference.
The torque has to be understood as an energy related to a change in
the direction of the local frame of reference. This can differ from
the direction of the magnetic moment by a sign. For the constraint
fields, the energy related to a change of the direction of the moment
is needed, so this sign has to be put at this point.
(This is probably somewhat confusing, I'll add a better explanation
and probably some sketch to the documentation of these features.)

The mean xc bfield is calculated together with the torques as a quantity
that is needed to update the constraining fields. It is stored in the
bfield_data type.
The calculation is not a physically meaningfull thing as it ignores
the underlying mesh details, but good enough for this application.

This fixes the suprisingly small mixing needed for the constraint method
based only on the moments. As pointed out by Eduardo, comparing with the
definition in literature (e.g. Journal of Applied Physics 85, 4824 (1999)),
there was some magnetic field missing to get the update loop to the
right units (i.e. the right order of magnitude).
Tested only for bcc Fe so far, this constraint mode now works well
with a mixing factor of around 1 (0.9 is now default).

The sign can apparently not be printed by every terminal or text editor.

the constraint magnetic fields.

The mixing is used for modes 2 and 3, so also for the torque based
method, different from KKRhost, which does not have a mixing parameter
(different from 1) in that case.

If calculated, the torques are now also stored in the binary results
file. Depending on the verbosity parameter, they are written to
an ASCII file and an overview is written to stdout.

Calculating torque and magnetic moment only inside the muffin tin
region, the point at the muffin tin radius was set to zero. This was
not consistent with the convention on this in the rest of the code
and introduced a (small) deviation from the desired result.

Remove some inputs that were moved to atom-wise switches in
nonco_angle.dat and some for functionality that was not implemented.

Changed the rest to form a more consistent interface.
Keeping a switch to turn everything off. If that switch is turned on,
this implies calculating the torque and constraint magnetism in general.
The fields are calculated for all atoms where that is specified in
the nonco_angle.dat.
It does not anymore imply external fields: There is a new switch for that.
If that is turned on, a file with external fields must be provided.
Introduced a verbosity parameter for bfields, select between no output,
summary and detailed information.

See comments and documentation for details.

Changed output depending on the new input parameter.

The external field in spherical coordinates is only used for reading
the input file, there is no need to store it next to the same field
in cartheisan coordinates.

Also renamed external bfield from "bfield" to "bfield_ext".

The bfields are now always allocated, as they are passed around to
some subroutines even if they are not used. The types are small if
they are not initialized, so that doesn't matter.
Actually, I never got an error from this bug, but I think this
might depend on the compiler.