Dear Terry,

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?

Best, Gregor.

PS: For the data in the banddos.hdf file see that part of the documentation: https://www.flapw.de/MaX-6.0/documentation/banddosPlotting/

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.

This is a rather new warning in the code.

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.

The Fermi energy should actually be written out in the lines following the

fermi energy and band-weighting factors:
 

output. If this is not the case it must somehow have gotten lost in the output. But there is another
point where it definitly is written out: In the out.xml file.

Please do a

grep -i Fermi out.xml
 

to extract that output.

You compiled Fleur correctly, don't worry. It is just that at runtime it also has to be known where to find the library you want to link to. For this there exists an environment variable LD_LIBRARY_PATH. You have to also put the path for the HDF5 library into that environment variable. If I see it correctly this means that you should invoke a command like

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/hdf5/lib
 
 

if you are using a bash shell or a z shell. In other terminal shells this will look slightly differently. I suggest to put that line into your .bashrc or .zshrc file if you use one of these shells. With this you don't have to type it in each time before you want to start FLEUR.

Dear Jiaqi,

To see these results it is not needed to switch on l_noco. Leave it set as "F". If the l_noco switch is set to "T", the calculationSetup/coreElectrons/@ctail switch also has to be set to "F". That is what the error message tells you.

You actually have to do the following things to see the spin-polarization in the band structure:

1. In the inpgen input you have to select a spin-quantization axis, for which you actually expect to see the effect. For the BiTeCl example you wouldn't see anything interesting if this is the z-axis, as it is set in the tutorial. For that case it would be more reasonable to set both angles to 1.570796327=0.5*Pi, i.e., the y-axis.
2. In the fleur input file you have to set jspins to 2, just as you did.
3. When you execute fleur, you obtain a warning because you run a spin-polarized fleur calculation without having a magnetic moment in the setup. Just ignore that warning by invoking fleur with the command-line switch -warn_only.

With the new inpgen input the input generator will find less symmetries in the system, which means that you get more k-points for the calculation. Also in the fleur calculation you have to set up and solve the problem for both spins. These two aspects imply that the calculation will take much longer than in a non-spinpolarized calculation.

I attach for the BiTeCl example inputs for the self-consistent field calculation (inp1.xml) and the band structure calculation (inp2.xml) and a slightly modified python script from the fleur website, adapted to visualize the respective effect (plotBands.py). The attached image bandstructure.png shows the visualization you obtain from this. In cases of degenerate bands it may happen that there are sudden color-changes, because the other band comes to the foreground.

Please note that the band structure plot follows a path from -M over gamma to +M, but both, -M and +M, are denoted as M in the plot.

I hope this clarifies how to obtain the visualization you want to have.

Dear sureshravi,

Could you also attach the kpts.xml and sym.xml files? I try to reproduce the problem and have not yet
succeeded in doing this. Maybe there is an issue in those files and I just don't see that.

Best, Gregor.

This is really strange. I actually use a newer Fleur version. Maybe it is an issue with your older version.
The inp.xml file validates, so I don't understand why Fleur complains about a "Closing xml element inconsistency".
I don't see that.

Besides that your unit cell definition stays wrong. The first idea was that you use the wrong units, but maybe
that was the wrong cause. You want to define a two-atom unit cell of an fcc crystal, correct? But such a unit cell
does not have the shape of a single-atom fcc unit cell. I think you construct a primitive fcc unit cell, but put two
atoms in it.

Just have a look at the MT radii of the Fe atoms. Those are only 1.31 Bohr in your inp.xml file. You can safely assume
that every Fe MT sphere with a MT radius below 2.0 Bohr belongs to a pathologic setup.

EDIT: Maybe the XML error is related to the out.xml file. But if there was an error in this older Fleur version
it is fixed by now.

EDIT2: I think if you want to have a 2-atom fcc unit cell, the shape would typically be a tetragonal unit cell ('tP').
The lattice parameter 'a' would be the distance between an atom at a corner and the nearest atom at a face center
in a conventional fcc unit cell. The lattice parameter 'c' would be the lattice constant of the fcc unit cell.

@sureshravi: I had a look at the inp.xml file you attached. With that I don't obtain an xml inconsistency as you do. But I obtain

************juDFT-Warning*****************
Error message: You lost too much charge
Error from PE:0/1
*****************************************
 
 

That is probably due to a way too small lattice constant. I guess you specified the unit cell in terms of Angstrom, but you need to define it in Bohr radii.

Are you sure you actually used the correct input files? Could you show me the output of invoking

xmllint --xinclude --valid --schema FleurInputSchema.xsd inp.xml
 
 

In the directory in which you have the inp.xml file?

Dear Zhiwei,

Of course, this depends on which electrons are treated as core electrons. Could you attach the inp.xml file for which you obtain an error? I will have a look at it.