Error messages

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 the 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 out file.

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 kill command.

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 inp.xml file, 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.

differ

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/magnetism/@l_noco and calculationSetup/coreElectrons/@ctail are both set to T Fleur complains that the coretail option cannot be used. In such a case one has to set calculationSetup/coreElectrons/@ctail to F.

e>vz0 and e >= vz0

Whenever film calculations are performed energy parameters also have to be defined or determined for the vacuum regions. The errors e>vz0 and 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 very small 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.

Both inp & inp.xml given

Very old Fleur versions used a different input file and format: The inp file. Such files can still be read, though not all functionalities are available for these old inputs. If both, an inp file and an inp.xml file are present in the same working directory Fleur has no indicator which one to use. The program therefore just complains.

No input file found

If there exists no input file in the working directory, i.e., neither an inp.xml file nor an inp file, Fleur has no way of finding out what it is supposed to do. It therefore complains.