3.1 Usability (convenience)

This functionality allows FHI-aims to stop in a controlled fashion, but not instantly. If you are interested in an instant stop, the Unix ’kill’ command (or its equivalent in the queueing system of a production machine) is the best way to proceed. See Sec. 2.5 for some further remarks.

This functionality allows FHI-aims to stop in a controlled fashion, but not instantly. If you are interested in an instant stop, the Unix ’kill’ command (or its equivalent in the queueing system of a production machine) is the best way to proceed. See Sec. 2.5 for some further remarks.

This file allows to modify some of the parameters of a calculation during runtime of FHI-aims. At present, this is limited to the settings of the convergence of the SCF cycle, namely: sc_accuracy_rho, sc_accuracy_eev, sc_accuracy_etot, sc_accuracy_potjump, sc_accuracy_forces, sc_accuracy_stress.

This flag is introduced as default purely to monitor and possibly undo errors that should not happen. Theoretically, all MPI tasks of a given FHI-aims run should have the same atomic coordinates and lattice vectors. In practice, it appears that certain hardware and/or compilers/libraries introduce bit flips between different instances of what is formally the same variable on different CPUs.

If check_cpu_consistency is .true., the code checks for deviations.

If the discrepancy is numerically negligible (below the value set by the tolerance parameter cpu_consistency_threshold, the code will work based on the assumption that the observed discrepancy is a platform-dependent artifact, will set all instances of the geometry to that stored on MPI task myid=0, and continue the run. Nonetheless, a warning will be printed in the output file and near the end of the output.

If the discrepancy is larger than the tolerance parameter cpu_consistency_threshold, the code will stop and inform the user.

See keyword check_cpu_consistency. If check_cpu_consistency is .true., then keyword cpu_consistency_threshold determines the maximum value to which discrepancies of geometry-related quantities between different MPI tasks will be tolerated (they will, however, be set to identical values even if the run continues).

By default, FHI-aims checks that unlimited allocation on stack are allowed by the operating system. This option allows to disable this check.

Currently, two CODATA sets are implemented:

• •

  CODATA 2002: https://physics.nist.gov/cuu/pdf/all_2002.pdf

• •

  CODATA 2018: https://physics.nist.gov/cuu/pdf/all_2018.pdf

The selection of a specific CODATA set will slightly change numerical values written in the main output file, e.g., all output values that are given in eV and Bohr radii. This keyword is especially helpful when combining FHI-aims with other frameworks that use different CODATA sets.

This keyword is useful to check the consistency of input files with the same exact binary that may later be used in a series of (perhaps queued) production runs. If there are trivial errors in the input files, no need to wait for the queue. The same effect can be achieved by building a ’parser’ binary, but this version saves the recompilation. The price is that one must not forget to comment out the dry_run option in the actual, queued input files.

This flag allows users to bypass CPU compatibility checks that are performed automatically at runtime to ensure consistent and reliable calculations across different hardware configurations.

By default (override_cpu_checks .false.), FHI-aims performs the following CPU compatibility verifications:

• •

  Comparison between build-time CPU and runtime execution CPU

• •

  Detection of heterogeneous CPU configurations within compute nodes

• •

  Verification of identical CPU architectures across multiple nodes

When CPU mismatches between build-time and runtime are detected, FHI-aims issues warnings but continues execution.

However, when heterogeneous hardware configurations are detected (different CPU types within a node or across nodes), FHI-aims will terminate execution by default. Such configurations can lead to unpredictable numerical behavior and incorrect results due to differences in floating-point implementations, instruction set capabilities, and architecture-specific compiler optimizations.

Setting override_cpu_checks to .true. disables these protective measures and allows execution to continue regardless of detected hardware incompatibilities.

Caution: Use this override only if you fully understand the implications and are confident that your specific hardware configuration will not affect calculation accuracy. Running on heterogeneous hardware may produce numerical errors that are difficult to detect. For production calculations, we strongly recommend using homogeneous hardware configurations rather than relying on this override.