Until now the program terminated with a segmentation fault which was not very user friendly...
* Got rid of a strange construction in the TRIM.SP handler (vector<pair> -> map)
* In the limit of thick films the result now is consistent with EHB: PRL 78 2208 (1997)
* B_z at the vortex-core has the correct values as a function of depth
* The calculation needs time...
* Any review is welcome
* The iterations converge now!
* B_z at the vortex-core has the correct values - as far as I can judge on it using EHB's work
* However, B in general might still be wrong by some factor, esp. B_x and B_y at the surface.
* There are many things left for optimization - e.g. there are (dependent on the grid size) thousands
to hundreds of thousands zero-assignments which could be removed after some careful checks
* Any review is welcome
- Fixed an error in the calculation of the gradient of the order parameter
This fixes the vortex-shape and the iterations behave a bit more converging
(not really but definitely better than before)
- The fields still disagree with EHB's calculation
- 3D iterations now keep the hexagonal symmetry (the irritating compiler warning was right after all...)
However:
- Iterations do not converge at all...
- The maximum of the field is slightly off the vortex core ;-(
- This problem is cursed!
It is not working at all in the current state and therefore also not included in the library.
- 2D calculation seems okay - at least the symmetry of the hexagonal lattice is kept through the iterations
- 3D iterations destroy this symmetry... I guess it is only a small problem, however I do not see it right now
- EHB's matlab code is available - however, it treats the problem quite differently
In case this is ever going to work, some things could probably be more optimal:
- Replace the numeric gradient calculation by the "analytical gradient"
- Use only every second Fourier coefficient in K-space and keep the number of points
This should reduce the factor of redundancy in real space from 8 to 2 and increase the spacial resolution by a factor of 4!
This has not been tested too much (so it might be better not to build the BMWlibs at the moment)
In case shared library support will become available from T. Hahn, this support will be dropped again.
* Added a few " " to musrgui (calls to musrview, musrt0 and msr<->mlog)
These are needed in the simple system commands to support paths with spaces and other strange things... :-(
The shared BMWlibs cannot be built at the moment since libcuba is built static only.
I am still thinking about including the C-part of Cuba into the BMWlibs
if T.Hahn would not add shared library support to it.
