FLAPW calculations and DFT calculations in general are very complex. They require complex input, rely on complex files on the disc and are performed on complex computers. Therefore it is not surprising that at some point one will encounter error messages when working with such codes. To simplify the diagnosis of error messages related to using the Fleur code in this section the most important Fleur error messages will be discussed.
There are different types of error messages:
juDFT-Error: This kind of error is thrown if a Fleur run enters a problematic state from which no recovery is possible. It is most likely due to unfortunate or erroneous calculation setups. But program bugs are also possible causes.
juDFT-Warning: A warning is thrown if a Fleur rund enters a problematic state from which automatic recovery is unlikely. It is also thrown when a calculation is about to be performed that uses experimental features or features requiring detailed user insights to avoid unintended results. Fleur can be started such that the program flow does not stop when a warning is thrown.
- Status messages: Fleur writes out some messages which might look like errors to new users but are actually only notes that certain situations occured during a Fleur run. The program flow is unaffected by such messages.
- Errors in linked software libraries: A crash in a linked library can also trigger an error message. These messages look different than other Fleur errors and can have many different causes.
In general the most important advice is to actually read occuring error messages and also the last lines in
out file. This may already provide enough hints to overcome the respective problem. For more complex
errors it may be a good idea to investigate the
out in more detail and check whether certain output values
are unexpected. Note: Depending on the used compiler the Fleur console output may be redirected to the
Succesful Fleur run with multiple MPI processes
Even if you are performing a succesful Fleur calculation with multiple MPI processes you may encounter error messages. An example for such a case is provided below.
***************************************** Run finished successfully Stop message: all done ***************************************** Rank:0 used 2.695GB/ 2826072 kB % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 784 100 40 100 744 123 2293 --:--:-- --:--:-- --:--:-- 2289 Usage data send using curl: usage.json OK =================================================================================== = BAD TERMINATION OF ONE OF YOUR APPLICATION PROCESSES = RANK 0 PID 30853 RUNNING AT iff691 = KILLED BY SIGNAL: 9 (Killed) ===================================================================================
At first the output says that the
Run finished successfully then you receive a message about the reporting of the
usage metrics and finally the output compains about a
BAD TERMINATION OF ONE OF YOUR APPLICATION PROCESSES. Note that the
final error message may actually differ depending on the machine you use for the calculation.
If you see such an output everything is ok. The error message is thrown because whenever Fleur ends in a controlled way the MPI process that reaches the end point aborts all other MPI processes. This is done because in certain calculations only a single MPI process actually processes the code part leading to the ending subroutine. If it would not be done in such a way other MPI processes may not end at all but remain running as zombie processes. Do not worry about whether all MPI processes actually did what they have to do. This is taken care of in the code.
Note that there are still situations in which zombie processes may remain after Fleur ends. This is the case if Fleur comes
to an uncontrolled end, i.e., it crashes without providing a Fleur error message. You may still obtain an error message related to
some software library. If you are unsure whether the Fleur ending was actually controlled check with
top whether there are
still Fleur processes running and terminate them manually with the
XML document file not parsable: inp.xml
This error indicates that the Fleur input file is ill-formed. This is probably due to an incomplete manual modification of the input file. You may obtain additional hints above this error message.
XML document cannot be validated against Schema.
This error indicates that at least one of the parameters in the Fleur input file has an illegal value. You may obtain additional hints above this error message. For example an error output like
inp.xml:16: element kPointCount: Schemas validity error : Element 'kPointCount', attribute 'count': '-5' is not a valid value of the atomic type 'xs:nonNegativeInteger'. **************juDFT-Error***************** Error message:XML document cannot be validated against Schema. Error occurred in subroutine:xmlValidateDoc Hint:See hints in lines directly above this error message. Error from PE:0/1 ***************************************** Last kown location: Last timer:r_inpXML Timerstack: Timer:Initialization Timer:Total Run *****************************************
indicates that in line 16 of the input file the parameter
count of the XML element
kPointCount was set
to a negative value, which is not allowed. Note that the additional hints above the error message are written out by the
used libxml2 library. They may vary on different machines and may even be missing for certain machine configurations. There
also exist illegal parameter values that are not detected on this stage of the input parsing. In such a case one will obtain
a different error message.
I/O warning : failed to load external entity "relax.xml"
This is not an error at all. When performing force relaxations Fleur writes out the relaxation history and the atom displacements
for the next calculation to the file
relax.xml. When starting Fleur this file is automatically included into the
even if no force relaxations are performed. Whenever this file is not present one obtains the warning that it could not be loaded.
The consequence is that there will not be any displacements of the atom positions defined in the input file. The Fleur run will
continue as intended.
Multiple differing error messages with MPI parallelization
If you start an MPI parallelized Fleur calculation you may obtain multiple differing error messages. These may or may not include XML validation and parsing errors, HDF5 errors, and different Fleur errors. In such a situation it is most likely that the different Fleur processes were actually not started such that they are connected by MPI. In consequence the different Fleur processes running in the same working directory may harm each other. For example one process may write a file while another process already reads it.
There are two possible reaons why such a situation occurs. The first case is that MPI is configured correctly but it is used on a Fleur executable that has not been compiled with MPI support. The other case is that a Fleur executable with MPI support is used but the MPI setup is wrong. In the most simple case this may be due to a missing command line option in the call of the MPI executable.
The differ error comes in the two flavors
differ 1 and
differ 2. As the error message says it is related to problems
in solving the Dirac equation. The Dirac equation is solved for two purposes:
- The determination of the core electron states and energies.
- The determination of the energy parameters for the LAPW basis and the LOs.
The solver for the Dirac equation assumes that the eigenenergies are found within a certain energy window. If a differ error is thrown this means that the respective eigenenergy could not be found in that region. The reason for such a situation is typically a messed-up potential, for example due to ghost bands, a linear dependence of the LAPW basis, an inconsistent Fleur input or other causes. Resolving this problem therefore is often dependent on the experience of the user. The general advice is to investigate the out file for possible hints on the cause, e.g., the identification of the affected atom and state, and also to check whether possible issues can identified in the Fleur input. In the end the input may have to be changed to overcome the problem.
E-field too big or No. of e- not correct
The efield error typically arises whenever the user sets up a charged unit cell. Charge neutrality is crucial when bulk systems are investigated. The most likely cause of this problem is an erroneous shifting of core electrons to the valence window. Typical mistakes here are due to a wrong setting of the new number of core states or a wrong calculation of the new number of valence electrons.
Error checking M.T. radii
MT radii checks fail whenever the MT spheres of two different atoms overlap. This can be due to a manual change in the MT radii or due to changes of in the unit related to structural relaxations or lattice constant calculations. A solution may be to slightly reduce the MT radii. If this error is due to a massive change in the unit cell the initial setup should also be adapted. Within force relaxations there may be an overshooting of the correction to the atom positions. In such a case it might be a good idea to erase the relaxation history and start with other initial displacements.
Too low eigenvalue detected
Fleur complains about too low eigenvalues in the calculation of the Fermi energy whenever there exists a valence electron energy eigenvalue that is far below the lowest energy parameter. Similar to the differ error the cause for this problem typically is a messed-up potential and the advice to the user is again to investigate the output and double-check the input. Note that this complaint only is a warning. Fleur can be started such that warnings are only written out but the program is not stopped. However, in most cases ignoring this warning in such a way will yield a differ error.
U+SS+EV-PAR and U+LO+EV-PAR
Certain features are not compatible to each other. The error message
U+SS+EV-PAR indicates that LDA+U is used together with
spin-spiral calculations and eigenvector parallelization. One has to get rid of one of these aspects, for example by using a different
parallelization scheme. The error message
U+LO+EV-PAR indicates the simultaneous usage of LDA+U, local orbitals, and eigenvector
parallelization. This is also not possible.
Coretail option cannot be used!!!
The rigorous treatment of the core elctron tails outside the originating MT sphere is not implemented for calculations employing
non-collinear magnetism. If
calculationSetup/coreElectrons/@ctail are both set
T Fleur complains that the coretail option cannot be used. In such a case one has to
e>vz0 and e >= vz0
Whenever film calculations are performed energy parameters also have to be defined or determined for the vacuum regions. The
e >= vz0 indicate that the energy parameters are above the vacuum potential at an infinite distance from
the film. Such a situation does not yield a state bound to the film. A vacuum function for the LAPW basis therefore cannot be calculated.
The solution is to modify the vacuum energy parameters in the Fleur input file such that they are below the vacuum potential at infinity.
Determination of fermi-level did not converge
Whenever a complex electronic structure in the vicinity of the Fermi energy is sampled by a very coarse -point mesh and a
FermiSmearingEnergy is used, the determination of the Fermi energy may not be possible. Such situations can be resolved
by increasing the -point density and/or increasing the smearing for the Fermi distribution used to determine the occupation
numbers for the Kohn-Sham orbitals.
No input file found
If there exists no input file in the working directory, i.e., no
inp.xml file , Fleur has no way of
finding out what it is supposed to do. It therefore complains.