What is the best option to install SIESTA's dependencies?

I am wondering what the best option is when installing SIESTA’s dependencies, I plan to install SIESTA on my workstation, and I found there are detailed steps in the SIESTA-DOC, when installing the dependencies, it requires to install BLAS and LAPACK with apt or yum.

But the SIESTA manual says that If you use your *nix distribution package manager to install BLAS you are bound to have a poor performance. Please try and use performance libraries, whenever possible!. Does this mean it is better to download every dependency package and compile them manually?

“Achieving good performance” is a rather complex question to which there is no one-size-fits-all answer.

If you’re using a personal computer, you might not get the “best” performance by using libraries installed by your system package manager but it will be fairly sufficient in most cases. It is also not always clear whether what you will gain by installing “optimised” libraries will compensate the burden of installing them. I’ve already spent half a day to install such libraries for a speedup of 3%, which is definitely not worth it. I personally recommend to use an OpenBLAS package from your preferred Linux distribution, being careful with how you set the OMP_NUM_THREADS variable (OpenMP).

If you have the Intel compiler, it can be worth trying with MKL. They even provide packages for popular Linux distributions. You can typically expect between 5% and 20% faster calculations than with the standard Netlib libraries. You can also use frameworks that will compile the libraries on your machine, such as EasyBuild. This usually requires a significant effort to bootstrap, though.

More generally, good performance is usually achieved with appropriate compiler flags, as long as you don’t use flags that affect negatively the accuracy of floating-point operations (see the documentation of your compiler for details).

If the machine is a cluster and you want to make calculations for resource-demanding systems, you should definitely contact your system administrator and ask for libraries optimised for this particular architecture.

Is there any comparison between the OpenBLAS version and INTEL MKL version of siesta?
I found some templates of the arch.make when compiling siesta, it says that The atom.f code is very vulnerable. Particularly the Intel compiler will make an erroneous compilation of atom.f with high optimization levels. does this mean I should avoid using Intel MKL?

here is the link:

does this mean I should avoid using Intel MKL?

No: First, the statement is about the Intel compiler, not the MKL library. Second, the purpose of the statement is to explain the rules below: generic Fortran files (.F, .F90) are compiled using the FFLAGS flags, which include user-defined optimisation levels, but atom.F is compiled with FFLAGS_DEBUG, that has a low optimisation level (-O1). This traditionally ensures this file is compiled correctly.

Here my thesis in Turkish. It may be useful while compiling.

Since DFT (Density Functional Theory) came to existence, the computational nano
science has became significant. The numerical calculations based on computers have
focused on two main subject, computational accuracy and computational speed. In
this work, we have compared PW (Plane wave) based QE (Quantum Espresso) Code
and AO (Atomic Orbitals) based Siesta Code, which are both Open-Source, by
performing the calculations of BP (Black Phosphorene)-Alanine molecule for the
first time. Also we have calculated the binding energies of Adenine and Guanine
molecules on the phosphorene to compare with previous results in the literature.
Next, we have explored the difference between the codes and/or methodologies by
analyzing computational speed, making efforts to decrease the consumed
computational time without compromising calculation accuracy. Our current this
study shows that the newer version of the suitable compiler yields to very promising
results and also effective use of the cores and flags of the compiler have also a great
impact on the computational time.