This is the user forum of the DFT FLAPW code FLEUR.
It is meant to be used as a place to asks questions to other users and the developers, to provide feedback and suggestions.
The documentation of the code can be found at the FLEUR homepage.
[b][/b]
[i][/i]
[u][/u]
[code][/code]
[quote][/quote]
[spoiler][/spoiler]
[url][/url]
[img][/img]
[video][/video]
Smileys
smile
smile2
spook
alien
zunge
rose
shy
clown
devil
death
sick
heart
idee
frage
blush
mad
sad
wink
frown
crazy
grin
hmm
laugh
mund
oh
rolling_eyes
oh2
shocked
cool
[pre][/pre]
Farben
[rot][/rot]
[blau][/blau]
[gruen][/gruen]
[orange][/orange]
[lila][/lila]
[weiss][/weiss]
[schwarz][/schwarz]
Gregor
Posts: 85 | Last online: 01.22.2022
Date registered
04.07.2021
Sex
not specified
    • You know, a simple "Thank you!" is enough. There is no need to be overly enthusiastic about any person, especially not in a user support forum.

      I'm glad that my suggestions helped to solve the problem.

      With respect to further knowledge about the Fleur code I suggest you have a look at the different sections in our user guide available at: https://www.flapw.de/

      If that doesn't go far enough there are also references to original publications provided. A general introduction to the FLAPW method is also available in the book by D. J. Singh and L. Nordström: "Planewaves, Pseudopotentials, and the LAPW Method".

    • Ok, just for your information, my output for this looks like:

      1
      2
      3
      4
      5
      6
      7
      8
      9
      10
      11
      12
      13
      14
       

      gregor@analyticalEngine:~$ find /usr/ -name libxml2*
      /usr/lib/x86_64-linux-gnu/libxml2.so
      /usr/lib/x86_64-linux-gnu/girepository-1.0/libxml2-2.0.typelib
      /usr/lib/x86_64-linux-gnu/libxml2.a
      /usr/lib/x86_64-linux-gnu/libxml2.so.2.9.10
      /usr/lib/x86_64-linux-gnu/libxml2.so.2
      /usr/share/aclocal/libxml2.m4
      /usr/share/doc/libxml2
      /usr/share/doc/libxml2-dev
      /usr/share/doc/libxml2-utils
      /usr/share/lintian/overrides/libxml2
      /usr/include/libxml2
       
       


      Some of the things that are found on my machine are not needed, but some are or may be needed.

      1. What is definitely needed is the include directory. Maybe this is named slightly differently for you, but If have this '/usr/include/libxml2' directory with another 'libxml' subdirectory containing numerous files with a '.h' ending. This is the part of the library that is needed for compiling programs. I found instructions on how to install this part of the library on a Debian linux there: https://installonlinux.com/debian/jessie/libxml2-dev You need administrator rights for this. It is probably the same procedure also for other versions of Debian. Please try installing this part of the library and then calling the Fleur configure script again.

      2. If this still doesn't work I sometimes saw that the system expects to find a '.so' file for the library and a '.so.2' file is not detected. Essentially the files with the number endings are just copies or links to copies of the library with different version numbers. So this can be fixed by creating another link 'libxml2.so' in the respective directory that links to the related 'libxml2.so.2' file. Such a (symbolic) link is created by changing into the respective directory '/usr/lib/x86_64-linux-gnu/' and then executing

      1
      2
      3
       

      ln -s libxml2.so.2 libxml2.so
       
       


      Maybe it is also required to perform this operation with administrator rights. In that case it would be:

      1
      2
      3
       

      sudo ln -s libxml2.so.2 libxml2.so
       
       


      Please try this and report afterwards whether it solved the issue.

    • Maybe we should in a simple way first check whether it should be available. I don't know the typical folder hierarchy on Debian machines, but could you test what the output of

      1
       
      find /usr/ -name libxml2*
       



      is? Maybe we have to tell Fleur by force where to look for this library.

    • 1. Does this only happen if you have the "-libxc TRUE" flag in the call to the configure script or also with a pure call to it without any command line arguments?

      2. Are you compiling on a special machine like a compute cluster or do you do this on your workstation?

      I ask because this error can have numerous causes. In general the libxml2 library should be available on every typical linux system. But for compute clusters this is sometimes hidden at places where the configure script does not search. In such a case one would have to load certain modules. It may also be that the compiler arguments for linking libraries are somehow broken and cannot be correctly interpreted. The third possible cause that comes to mind is that often the libxml2 library is split into two parts. One part that only contains the library as it would be used by compiled programs and another part that is also important for compiling programs. We need both, but some linux distributions by default only provide the first part. In package managers the compilation-related part is sometimes called libxml2-dev.

    • Gregor has written a new post "Low CPU utilisation" 01.13.2022

      Another point: At the moment I am doing convergence studies on numerous Oxide materials, also to prepare a more efficient default parameter setup... With respect to convergence it may be a good idea to increase the Oxygen MT radius. In my studies I find that this radius should be at least 1.3 Bohr radii. Zinc probably can be slightly smaller (you have to make compromises on the other atoms). I don't know what demands Hydrogen has.

    • Gregor has written a new post "Low CPU utilisation" 01.13.2022

      Here is what I can say:

      1. nvd is about the number of LAPW basis functions (without LOs) that you have in your system. 23.000 LAPW basis functions really is a lot for 82 atoms (typical sizes are about 100/atom). This seems to be due to a very high choice for Kmax. Was this automatically generated or the result of a convergence study? It may be reasonable because you have rather small bond lengths in your system and thus also rather small MT spheres.

      2. It is good that you mix MPI parallelization with OpenMP parallelization. Maybe a little bit less OpenMP would improve the CPU utilization. In that plot you can see that at the moment we would expect about a factor 5 speedup when 12 OpenMP threads are used, but with 6 OpenMP threads you also nearly get this speedup. I typically use something like 4 to 8 OpenMP threads. If you can rebalance the different parallelization schemes in that direction you might benefit. You can also use more than 32 MPI processes. 64 or 128 may be reasonable. You can also see in the plot that the diagonalization actually is the limiting code part when it comes to the OpenMP parallelization. In your system you have many LAPW basis functions for not so many atoms. This leads to a large runtime demand for the diagonalization and thus this becomes the determining bottleneck.

      3. Since the CPU utilization is strongly determined by the diagonalization, which is processed in a separate library there are only a few measures you can take to improve this situation. Rebalancing the different parallelization schemes is one approach, another would be the use of a more efficient diagonalization library. It may be a good idea to try out the ELPA library. This may give you some boost.

    • Gregor has written a new post "Low CPU utilisation" 01.12.2022

      The diagonalization seems to consume a larger fraction of the runtime than what I would expect. This may or may not be acceptable. But it should be understood. So two more questions:

      1. Which library do you use for the diagonalization?
      2. What is the output of "grep nvd out.xml"

    • Gregor has written a new post "Low CPU utilisation" 01.11.2022

      I have a few questions to better understand the problem.

      1. On how many nodes do you run the calculation, how many CPU cores are available on each node?
      2. How many OpenMP thredas do you use?
      3. There is a file juDFT_times.json created. Could you attach that?

      Best, Gregor.

    • Gregor has written a new post "exchange parameters calculations" 01.04.2022

      Just copy everything. You definitly need rhomat_inp. There should not be a need to delete anything.

    • Gregor has written a new post "exchange parameters calculations" 01.03.2022

      In every iteration Fleur writes out the charge density. In this old Fleur version this is stored in the cdn1 file, in newer Fleur versions this is stored in the cdn.hdf file. Whenever such a file is present in the working directory Fleur will use it as the starting point for its calculation. So if you have such a file available in your directory just start Fleur again and it will continue with the calculation. Maybe it is a good idea to also store every file you have in the directory in an additional backup directory, just to make sure that nothing gets lost. When Fleur runs it will overwrite a few files, especially the out file.

      For some calculation modes, e.g., calculations including noncollinear magnetism, there are further or other files needed to continue with a calculation, but they should all be available in your working directory.

    • Gregor has written a new post "output" 12.16.2021

      You can use the charge density slicing feature to plot the density originating from the states within a user-defined energy range or even more specific criteria like the density originating from a single user-defined state. Such a feature is useful if you want to visualize states related to doping atoms or maybe edge states related to some surface. The usage of this feature together with an example is described on the density plotting page of the user guide.

    • Gregor has written a new post "FLEUR compilation on AMD EPYC Processor" 12.07.2021

      Dear Soumyajyotih,

      Actually our group-internal cluster has that kind of CPUs. One has to be careful to compile Fleur in such a way that it shows good performance on such systems. Especially when you use Intel compilers and libraries this is not the use case for which they were developed. You can get inspiration for the compilation on such a system by having a look at the cmak/IFFAMD.sh machine file in your fleur directory:

      1
      2
      3
      4
      5
      6
      7
      8
      9
      10
      11
      12
      13
      14
      15
      16
      17
      18
      19
      20
      21
      22
      23
      24
      25
       

      echo "Using special config for IFF-cluster"
       
      #Set the compilers to mpiifort, mpiicc, mpiicpc
      export FC=mpiifort
      export CC=mpiicc
      export CXX=mpiicpc
       
      FLEUR_LIBRARIES="-lxml2;-lmkl_scalapack_lp64;-lmkl_blacs_intelmpi_lp64;-mt_mpi"
      #echo "Wannier is switched off-manually"
      #CLI_USE_WANNIER=FALSE
      echo "ChASE is switched off-manually"
      CLI_USE_CHASE=FALSE
      echo "Broken linker can be used"
      CLI_WARN_ONLY=1
      echo "Patch MKL"
      CLI_PATCH_INTEL=1
       
      #Set environment variables usefull for external dependencies, e.g. ELPA
      export CFLAGS=-mkl
      export CMAKE_Fortran_FLAGS="$CMAKE_Fortran_FLAGS -mkl"
      export FCFLAGS=-mkl
      export LIBS="-mkl -lmkl_scalapack_lp64 -lmkl_blacs_intelmpi_lp64"
      export SCALAPACK_LDFLAGS="-lmkl_scalapack_lp64 -lmkl_blacs_intelmpi_lp64"
       
       


      Especially the variables defined in this machine file are important (e.g. CLI_PATCH_INTEL). They are used to execute certain code paths in the configuration script. I additionally use the compiler option "-amd" when calling the configure script, though I am unsure whether that is actually needed. It looks like this is just another way of setting CLI_PATCH_INTEL to 1.

      You have to be aware that even though these AMD CPUs are compatible to Intel CPUs, their performance characteristics and memory layout differ. You can get more performance out of the AMD CPUs, but they are not really more performant per CPU core, but due to the availability of more cores. This means that you also have to make sure that you invoke Fleur with adequate parallelization schemes with a reasonable number of MPI processes and a reasonable number of OpenMP threads.

    • Gregor has written a new post "Spin-polarized calculation" 12.05.2021

      Whenever you start a calculation with a nonmagnetic starting density the result will also stay nonmagnetic. In such a situation it does not matter whether you perform the calculation with jspins=1 or jspins=2. This means that you have to indicate the magnetic configuration you are interested in to the starting density generator. This is done by specifying magnetic moments at each atom (or at least at one atom) in your unit cell. Specifying magnetic moments is done by modifying the electronConfiguration of the related atomSpecies in the inp.xml file. If you inspect your inp.xml file you will see that the occupations of the atomic states is symmetrical with respect to spin up and spin down electrons. Just shift some spin-down electrons to spin-up electrons and you will get an initial magnetic moment.

      In your case you are probably interested in putting a magnetic moment on the Vanadium atoms. The relevant states here are the 3d3/2 and 3d5/2 valence states. The 3d3/2 states offer place for up to 2 spin-up electrons (and 2 spin-down electrons. The 3d5/2 states offer place for 3 spin-up (and 3 spin-down) electrons. Overall there should be 3 electrons in the d states of Vanadium. I don't know what final magnetic moment to expect in the systems you investigate. In general I would put a slightly larger initial magnetic moment on the atoms than what I would expect for the final magnetic moment. If the initial magnetic moment is too small there is a chance lose it and end up in a nonmagnetic solution. I would thus put all 3 Vanadium d electrons in the spin-up channel: 1.2 in the 3d3/2 states and 1.8 in the 3d5/2 states.

    • Gregor has written a new post "FLEUR-Max installation on Jureca cpu " 11.12.2021

      How do you set the number of OMP threads for ELPA in an automatized way? Is this something in your jobscript?

    • Gregor has written a new post "MPI_Abort" 10.28.2021

      Could you also provide the sym.xml and kpts.xml files?

    • Gregor has written a new post "error in spex" 10.20.2021

      I did not yet forget you, I was / am just busy. It looks like the investigation of this issue might take some time, but the answer will come. Until then: The solution Stefan mentioned should also work for you. Doesn't it?

    • Gregor has written a new post "k-point path" 10.19.2021

      Dear Kirill,

      The first part of my answer is about the reciprocal Bravais matrix. This is actually written out to the out file by the input generator. But it is overwritten once you perform a Fleur calculation. For example for Si inpgen out has a section that looks like

      1
      2
      3
      4
      5
      6
      7
      8
      9
      10
       

      Bravais lattice vectors
      0.000000 5.130609 5.130609
      5.130609 0.000000 5.130609
      5.130609 5.130609 0.000000
      reciprocal lattice vectors
      -0.612324 0.612324 0.612324
      0.612324 -0.612324 0.612324
      0.612324 0.612324 -0.612324
       
       


      Be careful to interpret these matrices in the correct way. There may be a transposition present.

      The second part is about the calculation of the cartesian coordinates of the k points:

      We calculate the band band structure path in cartesian coordinates in the file dos/types_eigdos.F90 within the fleur source code folder. It is this loop:

      1
      2
      3
      4
      5
      6
      7
      8
      9
       

      kx(1) = 0.0
      vkr_prev=matmul(kpts%bk(:,1),cell%bmat)
      DO k = 2, kpts%nkpt
      vkr=matmul(kpts%bk(:,k),cell%bmat)
      kx(k)=kx(k-1)+ sqrt(dot_product(vkr-vkr_prev,vkr-vkr_prev))
      vkr_prev=vkr
      ENDDO
       
       


      kx is the x coordinate along the bandstructure plot. vkr is the cartesian coordinate of the respective k point stored in kpts%bk. cell%bmat is the reciprocal Bravais matrix though I am not sure whether the factor 2*pi is in it.

      About compiling and linking to HDF5 I would like to add that (a) it is important to compile HDF5 with the same compiler you use for Fleur, (b) on my machine I use the following configure line for HDF5:

      1
      2
      3
       

      FC=/usr/local/intel/impi/2019.3.199/intel64/bin/mpiifort CC=/usr/local/intel/impi/2019.3.199/intel64/bin/mpiicc CXX=/usr/local/intel/impi/2019.3.199/intel64/bin/mpiicpc ./configure --enable-fortran --enable-parallel
       
       


      Of course your compilers differ, but one important point here is the --enable-fortran switch. (c) You need to specify the HDF5 library path in your LD_LIBRARY_PATH environment variable. For me this looks like

      1
      2
      3
       

      export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:~/hdf5/current/hdf5/lib
       
       


      Of course, for you this is a different path.

    • Gregor has written a new post "error in spex" 10.15.2021

      This is strange. Besides trying out Stefan's solution could you please provide the initial input together with a description of what you did to end up in this situation? I would like to understand what is happening there.

Recipient
Gregor
Subject:


text:

Sign up, to leave a comment


Xobor Einfach ein eigenes Xobor Forum erstellen
Datenschutz