This is kind of an extreme outcome of slight differences in the determination of the default parameters for film and for bulk calculations:

In the film case we make the MT radii slightly smaller, because of the practical experience with have with these setups. This has the consequence that the lmax parameters might also be smaller. In your case in the film calculation for Germanium you get an lmax of 8, while it is 10 in the bulk calculation. The kmax is then determined with:

input%rkmax = MAXVAL(atoms%lmax/atoms%rmt)
 

with some subsequent rounding.

So, nothing in the structure is wrong. You just get different defaults for the two cases.

When you specify the Bravais matrix directly, you implicitly specify a 60 degree angle between the first two lattice vectors. In the other case you specify a 120 degree angle.

I don't know, which of these two different options you actually want to have, but that is the difference. If you specify in your first example a gamma=60.0 you obtain about the same FLEUR input file as in the 2nd case.

...you probably want to have the structure with the larger MT radii. ...just a guess.

The value generated by the FLEUR input generator is already pretty good. These are not repeated slab calculations. You get semi-infinite vacua on both sides of the 2D film. dVac is not the size of the vacuum, it is the thickness of the film, beyond which the vacuum starts.

If I want to perform highly precise FLEUR calculations, I sometimes add 0.5 to 1.5 Bohr to dVac and dTilde. You definitly do not need much more.

What is done by default is

dTilda = dVac + 2.5

I hope, this helps.

I'm now really curious, why you want to have such a giant dVac. This is computationally very inefficient and also problematic with respect to the representation of the basis functions. It implies that you have to describe a long decaying tail of the wave functions by plane waves. Is there also a benefit from this?

This is really strange.

You can fix this by using the following inpgen input file.

Mn3Ge (1-unit-cell thin film)
 
&input film=t cartesian=f /
 
1.0 0.0 0.0
0.5 sqrt(3.0)/2.0 0.0
0.0 0.0 1.0
9.6402026110092500
1.0 1.0 0.8076
 

8
32 0.6666666667 0.3333333333 1.9463569071627670
32 0.3333333333 0.6666666667 -1.9463569071627670
25 0.1632000000 0.3264000000 1.9463569071627670
25 0.6736000000 0.8368000000 1.9463569071627670
25 0.1632000000 0.8368000000 1.9463569071627670
25 0.8368000000 0.6736000000 -1.9463569071627670
25 0.3264000000 0.1632000000 -1.9463569071627670
25 0.8368000000 0.1632000000 -1.9463569071627670
 
 

It is mostly the same, but the 41.6872335863255300 was removed. I don't know yet, why this has such an effect, but I hope, this new inpgen input solves the issue for you. Maybe the general advice is to not explicitly set the film thickness dVac in the inpgen input. ...if you want to readjust it, you can do that in the inp.xml file.

Please give a short feedback once you see how the results for consistent MT radii, ... look like. If the problem is still there, we have to think again. :)

I have not yet a clear understanding on what you are actually doing, but if you compare total energies between different calculations, make sure that only this one change that you actually want to investigate, distinguishes the calculations. MT radii and other parameters should be consistent between the calculations. Otherwise effects of these numerical parameters on the total energy will distort your results.

This is probably related to the enormous number of decimal places you provide in your input. At some precision we have the problem that different tolerance scales in different subroutines compete with each other and that may lead to such an error. I suggest to cut values in your input after the sixth place after the decimal point. Please try that out and report on whether that already helped.

A segmentation fault can have different causes. The most probable in your case are

1. Not enough working memory.
2. A problem in the ScaLAPACK library.

Depending on the cause the possible solutions differ.

Could you give some numbers regarding the parallelization and the system size, i.e., the number of k-points, the chosen OpenMP and MPI parallelizations, the number of compute nodes, the working memory per compute node? Could you provide the complete terminal output?

Dear mgeo06,

Could you attach the FLEUR input files? Otherwise it won't be possible to reproduce the problem. You might have to rename the input files such that they have a ".txt" suffix instead of a ".xml" suffix.

This bug has been fixed in the develop version of FLEUR a few minutes ago with commit https://iffgit.fz-juelich.de/fleur/fleur...d6ef29b4b7ce4b8 together with commit https://iffgit.fz-juelich.de/fleur/fleur...b04775571af8c05 from yesterday.

Dear Tim,

Thank you for reporting this issue. Since a few days I am looking into this. I have verified the problem, but it is not yet fully understood. I will inform here once the bug is fixed.

Just try out starting your noncollinear calculation without having a cdn.hdf file in the directory. I think, you don't need the collinear preparation step that you performed.

1. The band structure data should not be seen as bands that are written out to some file. We actually only provide energy eigenvalues found for k-points along the inspected k-point path. The ordering is naive and does not consider band crossings.

2. In the newer FLEUR versions there is also a more structured output of the band structure data. It is found in the banddos.hdf file. Please have a look at https://www.flapw.de/MaX-8.0/documentation/banddosPlotting/ for some inspirations on how to use this file.

I would assume that the states that you show there are not well represented by the LAPW basis. The LAPW basis is k-point dependent and if some band is not well represented by it, you see such a behavior.

Please check whether a) your MT description is good for these states and b) whether the behavior depends strongly on Kmax.

You can place a tag "special" in the section of an atom species in the FLEUR input file, directly after the energy parameters. In that you can define the attribute "vca_charge".

See, e.g., there: https://www.flapw.de/MaX-7.0/documentati...species-section

I hope this helps.

You can just copy the species entry, rename it, adjust the assignments to the atom groups, and add the respective U entries.

We write out the size of the band gap to the out.xml file (and also to the out file) for the k-point set that was used in the respective calculation as the difference between the lowest unoccupied and the highest occupied state. Between the self-consistency calculation and the band structure calculation the k-point set differs. At this point you have to ask yourself, whether the real lowest unoccupied state and the real highest occupied state are found at k-points covered by the respective k-point sets. If you identify such a calculation, you can just search in the output like

grep gap out.xml
 
 

to see what the value of the band gap is.

Often the band extrema are found at high-symmetry points or on high-symmetry lines. In such a case a k-point path that covers these extrema in a band structure calculation is a good basis to extract the band gap. If this is not the case the self-consistency calculation is probably the better starting point for extracting the gap. If you increase the k-point density, you also have a systematic approach to obtain the gap for sure. But this is typically not needed. I suggest to use the grep-command above on both calculations and then use the smaller of the reported values.

I hope this helps.

I probably don't understand you. Your plot already shows projections on certain orbital characters at certain atom sites.

If you want to make this independent of the orbital character, just add up s, p, d, f at each atom site. That should cover about everything at that site.