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.

Saving the constraint fields gave wrong output, because the write statement was outside of a loop it belongs to.

The torque used to update the constraint fields was always the one calculated over the full cell, never the one calculated only up to the muffin tin radius, regradles of the setting.

Changing the name of variable torque(:) to the right one storing the two possible value, either mt_f or mt_t

They are written in a file bconstr_out.dat similar to KKRhost,
in the subroutine where also nonco_angle_out.dat and
nonco_moment_out.txt are written.

As some calculations use the muffin tin index (of the new mesh),
this was calculated in calculateDensities in ProcessKKRresults_mod,
so before checking if a nonco calculation is done. However, in a
collinear calculation, the pointer to the new mesh is not associated,
which gave an error in that case.

blocks containing information on all atoms, as before.

Instead of one record per atom (which would get to complicated with
more output settings), write several records per atom.
For more details, see comments in the code.

In my calculation, the file got larger by about a factor 2, but as
it is one of the smaller output files this should be fine. In the
long term, all of this will hopefully replaced by MPI communication
anyway...

Moved the open of the bin.results1 file to the write subroutine,
introduced a subroutine to calculate the record length and used
in for both reading and writing.

I want to incorporate this in the routines where the nonco_angle_out.dat
is written, which is done in a somewhat complicated way. In
ProcessKKRresults (which is called for inMasterGroup, so once per
atom), calculateDensities is called. This subroutine calls
writeResults1File, in which some results are written to a binary file
at an atom-specific position.

As a first step, I moved the call to this subroutine out of
calculateDensities to ProcessKKRresults.

Compiles, does not crash, and gave the same bin.results1 file in
a simple test run I made. Together with what I read in the code
I'm quite confident it did not change anything.

This is more instructive as the interger is not a simple
switch anymore.

Mode 4 was supposed to fix the direction using constraint magnetic
fields but allowing the moment to change direction as far as the
constraint field does not fullfill this yet. While this is in principle
possible, the current implementation was wrong, as the goal angles
are not stored separately, so a changed moment would also change the
goal.
This mode could be added in the future, but as it converges slower
than mode 2 and to the same result, there is not much reason for that.

Mode 5 was supposed to fix the direction by cancelling the torque,
but allowing the moment to move. This does not depend at all on the
given goal directions and does thus not make any sense.

This keeps the array of bfields consistent with other atom-wise
quantites.

The subroutine calc_torque() in bfield/torque.f90 calculates the
magnetic torque and iterates the selfconsistency loop for the
constraint magnetic fields, based on torque or on the fields alone.

The routine is called from rhovalnew() as in KKRhost. Adapted the
inputs and included the call. Adapted wrappers_mod, where this
routine is called.

I had to move another subroutine from NonCollinearMagnetism_mod.F90
to the helpers module to avoid circular dependencies. Did not change
the routine otherwise.

Included the new dependencies in the Makefile.

Compiles and did not crash in a short test run,
but not completely tested.

The muffin tin index was taken from the old mesh, which is not correct
and can even give errors if it is larger than the total size in the
new mesh.

Introduced a function in the Chebyshev mesh module that calculates
the index of the muffin tin radius. Formula for this is taken from
KKRhost.
Used this function where before the muffin tin index of the old mesh
was used. Added the dependency on this function to the Makefile.

Calls to add_bfield() whereever the spin-orbit hamiltonian is added to the potential.
Adjusted arguments to the surrounding subroutines and dependencies in the Makefile.

I had to move two subroutines from NonCollinearMagnetism_mod.F90 to a separate
module in NonCollinearMagnetism_Helpers_mod.F90 to avoid circular dependencies.
(They did not change apart from that move.)

Explained in comments, documentation will be adjusted..

Written an add_bfield subroutine for KKRnano based on the implementation
in KKRhost by Sascha Brinker.

Also some notes on where to use it.

In CalculationData, the bfield is read for every atom and then initialized
only for the locally treated atoms. Thus, the bfield has to be accessed
differently from the other quantities that are only allocated for the
local atoms.

Also, I restructured and commented lots of code while looking for the bug.

The data is now stored at appropriate places and loaded in the
corresponding part of the code.
It is not used for any calculation yet.

Code compiles, but is not tested in any other way.

The parameters are taken from Sascha Brinkers presentation and should
match what is implemented in KKRhost.
The names are kept as close as possible to the inputcard keywords in
KKRhost, thus they might differ from what they are called in the
KKRhost code.

Added the parameters to datastructures/InputParamsNew.txt and
generated a new datastructures/InputParams_mod.F90 using
the generate.sh skript.

In generate.sh, the inputgenerator.py is now called as a local script.

In inputgenerator.py, use /usr/bin/env to be independent of actual python installation dir.
Explicitly use python2, which is needed by the skript and not always the default anymore.

The parameter enable_quad_prec was introduced in InputParams_mod.F90,
but not in InputParamsNew.txt, so it did not appear when recreating
the Fortran module from the list of parameters.

Merge latest KKRnano version into develop

See merge request kkr/jukkr!12