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

Move torque module to common

See merge request kkr/jukkr!11

Just the rename and two lines in the cmake files.

Changed some input arguments so that the module does not depend on any things specific to KKRhost anymore.

Activate running regression tests for KKRnano

See merge request kkr/jukkr!8

Merge improved chebychev solver

See merge request kkr/jukkr!9