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.

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.

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.

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.