This is the user forum of the DFT FLAPW code FLEUR. It is meant to be used as a place to asks questions to other users and the developers, to provide feedback and suggestions. The documentation of the code can be found at the FLEUR homepage.
I assume you refer to figure 2 of that paper. I don't know how exactly they visualized this data, but I can tell you how to obtain it. I attach some simple example input for such a Cr layer that I once used for some tutorial. This is not converged with respect to parameters. With that input you first have to obtain a self-consistent density. Then change the iplot parameter in the inp.xml file to 2 and run FLEUR again. This will generate several XCrySDen structure output files containing data on the density, the magnetization density, the direction of the magnetization and so on. In detail you obtain the files denIn_A1.xsf denIn_A2.xsf, denIn_A3.xsf which contain the magnetization in the three directions, denIn_Aabs.xsf for the absolute value of the magnetization, denIn_Aphi.xsf for the in-plane magnetization direction in units of pi, and denIn_Atheta.xsf for the out-of-plane magnetization direction. The visualized data from figure 2 is available in the denIn_Aphi.xsf (for the arrows) and denIn_Aabs.xsf (for the gray-level coding) files. I attach an image with a separate visualization of the data in two plots. The direction here is color-coded on a linear scale and the absolute value of the magnetization density on a logarithmic scale. These are simple visualizations that you can obtain with XCrySDen. The figure in the paper is probably hand-crafted and not just output from some visualization tool. To create a similar plot you might want to look at the Python library matplotlib or even try to create something with Povray or a similar tool allowing a lot of user control. Interpreting the data in an xsf file is not too difficult. This is a simple and well-documented text format and thus directly readable.
I think, you went in the right direction in your tries to overcome this problem. When you have a plane-wave basis set all basis functions are orthogonal with respect to each other. We don't have such a PW basis set, but LAPWs. This means we replace the plane waves by some augmentation in some augmentation regions like the MT spheres or the vacuum regions. In unfortuitous calculation setups this may lead to a numerically linearly dependent basis and I believe that this is what is happening in your calculations, at least you seem to be near such a situation. As you already mentioned, the strategy in such a situation is to decrease the volume of the augmentation regions and thus make the interstitial region larger. Another thing you can try is to increase the lmax cutoffs in the MT spheres. I attach an input that is a modification of your input, in which the vacuum boundary is pushed a little bit away, the MT spheres are a little bit reduced (though still larger than in your setup) and the lmax cutoffs are slightly increased. With this I don't get the warning you get. I cannot guarantee that everything is completely fine already, but I guess these are modifications that go in the right directions.I didn't check the electronic structure, so please be skeptical (as you probably already are and should be when performing DFT calculations) and do so yourself. The new parametrization might not be perfect for your application, but now you know the important knobs you can play with. :)
1. What version of FLEUR are you using? 2. Could you attach (with some renaming) out.xml files for calculations with and without LOs for the same finite q point?
Sorry, I was on vacation, so it took a bit of time until I could look at your issue.
There are a number of issues in your inp.xml file. For example you define multiple local orbitals with the same parameters and you also define local orbitals for states that you actually treat as core electron states. But even beyond these aspects you seem to have a tricky system you want to describe. I created a new Input file for the same system that seems to work. Maybe you still have to perform a few adjustments for that input, but it may be a good starting point for you. I attach it. Right now I'm unsure whether there is also some problem on the code level present. It may be that there are issues with local orbitals for your system. The input I provide does not use any local orbitals.
NOTE: The input I provide has a newer version number than what you used. You might have to adapt it also with respect to this.
The most probable guess on what went wrong is that probably the wrong compiler was detected and used. If you want to use MPI, you have to use the MPI compiler wrappers. You probably have to write something like
FC=mpif90
or similar just at the very beginning of the command line in which you call the configure script: In front of the configure script.
The error message indicates that the vacuum energy parameter is above the vacuum potential at an infinite distance from the film. In the old FLEUR this parameter is set in the enpara file.
If you, however, calculate a metallic film of such a thickness, it is probable that this is due to charge moving around in the film. This can often be overcome by performing some scf iterations with linear mixing and a very small mixing parameter in the beginning. A more elegant and efficient solution would be the use of the Kerker preconditioner, which is available in newer FLEUR releases, but not yet in version v0.26.
The "Too low eigenvalue detected" error actually indicates that the potential in your calculation got messed up. Typically this is related to an issue in the input, like a very high kmax or too small lattice constants or similar. These exact points don't seem to be an issue in your setup, maybe it is something else. Could you try reducing the MT radii by 3%?
I am aware that you already reported this issue a long time ago. Meanwhile we worked a lot on related parts of the code. Could you test whether the problem still occurs with the newest development version of the code?
Please be aware that we will have an in-person hands-on tutorial on Fleur from May 8th to May 12th in Jülich (Germany)
If you are interested in participating please consult the following page to obtain more information and a link to the registration page. Registration will be open till April 14.
I now rephrased the error message in the development version to "Number of atom groups in Fleur input file and in the charge density file don't match.". I hope in future this will be more understandable.
Just for clarification: This error message occurs when the number of atom groups (types) in an old (non hdf5) charge density file is inconsistent with the number of atom groups in the Fleur input file. Such a file inconsistency typically occurs when a Fleur input file is regenerated with slight modifications, but an already existing charge density file in the directory is not removed.
There shouldn't be any limits like that. Actually it looks like an error message no user should get. Could you attach the inp.xml file so that I can investigate this?
In the out.xml file you find tags "mtCharge" that show the s-, p-, d-, and f-projected charges in the MT spheres of each atom type. Furthermore if you calculate a band structure or a density of states, there are weights in the banddos.hdf file showing these projections energy- or even state-resolved. Does this already answer your question or do you need more?
At the moment this is an experimental feature. Therefore it can only be activated in the code. This is done by setting "lResMax" to 3 or something similar in fleurinput/types_input.f90. I totally forgot how the output of this feature looks like. You will have to look into the code to reverse engineer the output. Also: If I remember correctly there probably is a factor of 2 missing in the output, though you can interpret this in terms of "What are the units?".
Feel free to check it out and give feedback. If this feature is needed I make using it more comfortable. Note that at the moment I don't know whether this is compatible to MPI parallelization.
When you invoke the input generator one thing that is done is the detection of symmetries in the unit cell. Symmetries may spped-up and stabilize calculations. But most of the time, you also don't rely on them. You have two optione:
1. You adapt your input such that all values in it are provided with higher precision, which may result in more symmetries detected. 2. You ignore the warning and go on with your calculation. To do this you can either invoke inpgen with the additional command line option "-warn_only" or, as explained in the terminal output, put a file "JUDFT_WARN_ONLY" in the directory of the calculation. If you proceed in this way the warning is still written out, but the program proceeds and writes out the Fleur input.