Skip to content

Changes

Page history
Fix style of some KKRnano files authored by Philipp Rüssmann's avatar Philipp Rüssmann
Show whitespace changes
Inline Side-by-side
kkrnano/prepare.md
View page @ 04943cc8
###### Source files {#source_files}
###### Source files
A KKRnano code repository can be found on the Trac system of FZJ:
......@@ -8,13 +8,13 @@ You will need an account for this to access the code which can be set up
for you by a KKRnano developer. There is a step-by-step guide on how to
download the code onto your local machine.
###### Input files {#input_files}
###### Input files
Initial preparation of a calculation - when no binary potential is
available:
` * `[`potential`](kkrnano/Formatted_potential "wikilink")\
` * `[`kkrnano/shapefun`](kkrnano:shapefun "wikilink")`: Only the interstitial mesh information is needed from this file. It must match to the potential. :!: The shape function values are ignored, but must have the right format.`
* [potential](kkrnano/Formatted_potential)
* [kkrnano/shapefun](kkrnano/shapefun): Only the interstitial mesh information is needed from this file. It must match to the potential. :!: The shape function values are ignored, but must have the right format.
: !: It is possible to use potentials calculated for a certain
geometry as a starting point for a calculation with modified
......@@ -22,253 +22,222 @@ available:
Config files:
` * `~~[`kkrnano/atominfo`](kkrnano:atominfo "wikilink")~~` (no longer necessary)`\
` * `[`kkrnano/input.conf`](kkrnano:input.conf "wikilink")\
` * `[`kkrnano/global.conf`](kkrnano:global.conf "wikilink")` (optional)`\
` * `~~[`kkrnano/rbasis`](kkrnano:rbasis "wikilink")~~` / `[`kkrnano:rbasis.xyz`](kkrnano:rbasis.xyz "wikilink")\
` * `~~[`kkrnano/lcutoff`](kkrnano:lcutoff "wikilink")~~
* [kkrnano/atominfo](kkrnano/atominfo) (no longer necessary)
* [kkrnano/input.conf](kkrnano/input.conf)
* [kkrnano/global.conf](kkrnano/global.conf) (optional)
* [kkrnano/rbasis](kkrnano/rbasis) / [kkrnano:rbasis.xyz](kkrnano/rbasis.xyz)
* [kkrnano/lcutoff](kkrnano/lcutoff)
Binary input files:
` * `[`kkrnano/Binary`` ``files`](kkrnano:Binary_files "wikilink")
* [kkrnano/Binary files](kkrnano/Binary_files)
###### Build information {#build_information}
###### Build information
` * `[`kkrnano/List`` ``of`` ``preprocessor`` ``macros`](kkrnano:List_of_preprocessor_macros "wikilink")
* [kkrnano/List of preprocessor macros](kkrnano/List_of_preprocessor_macros)
###### Developer notes {#developer_notes}
###### Developer notes
` * `[`KKRnano`` ``coding`` ``guidelines`](:kkrnano_coding_guidelines "wikilink")\
` * `[`kkrnano/Editing`` ``input`` ``parameters`](kkrnano:Editing_input_parameters "wikilink")\
` * `[`coding:Fortran`` ``notes`](coding:Fortran_notes "wikilink")\
` * `[`kkrnano/Dictionary`` ``of`` ``parameter`` ``names`](kkrnano:Dictionary_of_parameter_names "wikilink")
* [KKRnano coding guidelines](kkrnano_coding_guidelines)
* [kkrnano/Editing input parameters](kkrnano/Editing_input_parameters)
* [coding:Fortran notes](coding/Fortran_notes)
* [kkrnano/Dictionary of parameter names](kkrnano/Dictionary_of_parameter_names)
###### Instructions
<HTML>
======================== Building KKRnano ========================
- ) 1 program to build: kkr.exe
<!-- -->
- ) Command line arguments:
` --prepare Former kkr0.exe functionality`\
` --help This command line help function`\
` --check Check input files for errors`\
` --convert Converter to and from ASCII files`\
` --voronano Produces Voronoi output necessary to start a calculation with KKRnano`
```
========================
Building KKRnano
========================
- ) Relevant makefile: kkr2/Makefile
*) 1 program to build: kkr.exe
<!-- -->
*) Command line arguments:
--prepare Former kkr0.exe functionality
--help This command line help function
--check Check input files for errors
--convert Converter to and from ASCII files
--voronano Produces Voronoi output necessary to start a calculation with KKRnano
- ) Create build directories (these paths are hardcoded in the
makefiles)
*) Relevant makefile: kkr2/Makefile
` $HOME/build/kkr0`\
` $HOME/build/kkr2`\
` `
*) Create build directories (these paths are hardcoded in the makefiles)
$HOME/build/kkr0
$HOME/build/kkr2
- ) building:
*) building:
make PLATFORM=<insert platform> TYPE=<debug or nodebug>
` make PLATFORM=`<insert platform>` TYPE=`<debug or nodebug>\
` `\
` where PLATFORM can be JUQUEEN, if PLATFORM is left out it builds with mpiifort`\
` `
where PLATFORM can be JUQUEEN, if PLATFORM is left out it builds with mpiifort
======================== Stack size: ========================
========================
Stack size:
========================
The program needs a large amount of stack space, otherwise segfaults:
(space needed depends mainly on lmax and number of mesh points\...)
Use this environment variable, when using OpenMP-threads: export
OMP\_STACKSIZE=20M
Without OpenMP threads, one might have to set: ulimit -s 20000
(space needed depends mainly on lmax and number of mesh points...)
======================= Stack vs. heap arrays: =======================
Use this environment variable, when using OpenMP-threads:
export OMP_STACKSIZE=20M
\"vbmrv\_mat\_mod.f90\" is explicitely coded to need stack allocated
arrays (default for Fortran automatic arrays
Without OpenMP threads, one might have to set:
ulimit -s 20000
`for C programmers: variable length arrays (C99), allocated with "alloca")`
=======================
Stack vs. heap arrays:
=======================
Also in this case this is only important when using OpenMP. use:
\"export OMP\_STACKSIZE=20M\"
"vbmrv_mat_mod.f90" is explicitely coded to need stack allocated arrays
(default for Fortran automatic arrays
for C programmers: variable length arrays (C99), allocated with "alloca")
Also in this case this is only important when using OpenMP.
use: "export OMP_STACKSIZE=20M"
The other files should work with heap allocated Fortran automatic arrays
(-heap-arrays option in ifort), but this has not been tested.
ScatteringCalculation\_mod.F90 also requires stack allocated arrays when
using OpenMP. The reason for this is unknown.
ScatteringCalculation_mod.F90 also requires stack allocated arrays when using
OpenMP. The reason for this is unknown.
TODO: a safe strategy would be to not use the \'heap-arrays\' option for
TODO: a safe strategy would be to not use the 'heap-arrays' option for
code that uses OpenMP.
======================= Interpolation of potential to new mesh and
on-the-fly shape-function generation =======================
- ) A shapefun file with as many entries as there are atoms has to be
provided to specify the initial interstitial mesh
- ) the shape-functions in \'shapefun\' are not used! (but have to be
specified
` to avoid I/O errors in preparation step 'kkr.exe --prepare')`
- ) The interstitial mesh in shapefun changes if the muffin-tin radius
changes
` (due to 'muffin-tinization', where points of the MT-region are added to the`\
` interstitial mesh)`
======================= Possible problems: =======================
- ) Core electron configuration is specified in file \'potential\'
(not atominfo!)
` 'kkr.exe --prepare' reads it and writes it into (binary) file 'atoms'`\
` When using binary potential files from a previous calculation, make sure`\
` the core configuration matches.`
- ) Number of mesh points depends on an algorithm using floating point
numbers:
` However, processes working on the same atom must arrive at the same results.`\
` Otherwise there will be problems with spin/energy-parallelisation`\
` Workaround: If problems occur: calculate without spin/energy-parallelisation`
- ) Interpolation to a larger muffin-tin radius problematic,
` since spline polynomial at boundary is unbounded, it blows up when r > rmax`\
` Workaround: do several calculations, moving atoms in small steps only`\
` SHOULD BE SOLVED NOW`
- ) Small deviations observed when restarting a calculation (6. digit
after .):
` Deviations were much larger when a converged potential was used`\
` Reason: mesh interpolation`\
` Fixed: check if mesh has changed - do not interpolate if mesh stays the same`\
` STILL OCCURS`
- ) Convergence problems with lmax=5
` TODO: check if only for irregular lattice positions`\
` `
- ) I/O with several processes writing to the same file can lead to
problems
=======================
Interpolation of potential to new mesh and on-the-fly shape-function generation
=======================
*) A shapefun file with as many entries as there are atoms has to be provided to specify the initial interstitial mesh
*) the shape-functions in 'shapefun' are not used! (but have to be specified
to avoid I/O errors in preparation step 'kkr.exe --prepare')
*) The interstitial mesh in shapefun changes if the muffin-tin radius changes
(due to 'muffin-tinization', where points of the MT-region are added to the
interstitial mesh)
=======================
Possible problems:
=======================
*) Core electron configuration is specified in file 'potential' (not atominfo!)
'kkr.exe --prepare' reads it and writes it into (binary) file 'atoms'
When using binary potential files from a previous calculation, make sure
the core configuration matches.
*) Number of mesh points depends on an algorithm using floating point numbers:
However, processes working on the same atom must arrive at the same results.
Otherwise there will be problems with spin/energy-parallelisation
Workaround: If problems occur: calculate without spin/energy-parallelisation
*) Interpolation to a larger muffin-tin radius problematic,
since spline polynomial at boundary is unbounded, it blows up when r > rmax
Workaround: do several calculations, moving atoms in small steps only
SHOULD BE SOLVED NOW
*) Small deviations observed when restarting a calculation (6. digit after .):
Deviations were much larger when a converged potential was used
Reason: mesh interpolation
Fixed: check if mesh has changed - do not interpolate if mesh stays the same
STILL OCCURS
*) Convergence problems with lmax=5
TODO: check if only for irregular lattice positions
*) I/O with several processes writing to the same file can lead to problems
(e.g. on RWTH cluster with Lustre filesystem)
Solution: use task-local files
This should not be a problem with the GPFS file system (as on JUQUEEN), since
it is advertised as having "byte-range"-locking. This matches also with our
experience.
` (e.g. on RWTH cluster with Lustre filesystem)`\
` Solution: use task-local files`\
` `\
` This should not be a problem with the GPFS file system (as on JUQUEEN), since`\
` it is advertised as having "byte-range"-locking. This matches also with our`\
` experience.`
======================== Task-local files: ========================
- ) Compile with preprocessor-macro TASKLOCAL\_FILES defined to get
` a version that uses task-local files for meshes and potentials instead of`\
` Fortran direct access files `
======================== Checkpointing: ========================
- ) Files needed to restart a calculation:
` energy_mesh, vpotnew, vpotnew.idx, meshes, meshes.idx`\
` LDA+U: wldau.unf`\
` `
- ) To restart calculation:
` -) run 'kkr.exe --prepare' *first*`\
` -) then rename them to:`\
` energy_mesh.0, vpotnew.0, vpotnew.0.idx, meshes.0, meshes.0.idx`\
` -) alternatively use the scripts 'save.sh', 'restore.sh and 'prepare.sh' `
\'kkr.exe \--prepare\':
- ) \'kkr.exe \--prepare\' can generate a start potential from a
formatted potential file named
========================
Task-local files:
========================
` 'potential' and a shape-function file 'shapefun'`
*) Compile with preprocessor-macro TASKLOCAL_FILES defined to get
a version that uses task-local files for meshes and potentials instead of
Fortran direct access files
- ) Start potential generation can be skipped by removing/renaming
file \'potential\'
========================
Checkpointing:
========================
` and providing an approximate Fermi-energy in file 'EFERMI' (used for k-mesh`\
` generation heuristics)`\
` One also has to provide the file 'atoms', since it is not generated`\
` by 'kkr.exe --prepare' if 'potential' is missing!!!`
*) Files needed to restart a calculation:
energy_mesh, vpotnew, vpotnew.idx, meshes, meshes.idx
LDA+U: wldau.unf
*) To restart calculation:
-) run 'kkr.exe --prepare' *first*
-) then rename them to:
energy_mesh.0, vpotnew.0, vpotnew.0.idx, meshes.0, meshes.0.idx
-) alternatively use the scripts 'save.sh', 'restore.sh and 'prepare.sh'
'kkr.exe --prepare':
*) 'kkr.exe --prepare' can generate a start potential from a formatted potential file named
'potential' and a shape-function file 'shapefun'
*) Start potential generation can be skipped by removing/renaming file 'potential'
and providing an approximate Fermi-energy in file 'EFERMI' (used for k-mesh
generation heuristics)
One also has to provide the file 'atoms', since it is not generated
by 'kkr.exe --prepare' if 'potential' is missing!!!
======================== K-points: ========================
========================
K-points:
========================
Procedure for using a different k-mesh than automatically generated:
Let\'s assume that we want to use the same number of k-points at each
Let's assume that we want to use the same number of k-points at each
E-point
- ) run \'kkr.exe \--prepare\'
- ) look in the output how many k-meshes are needed
- ) create a file \'new.kpoints\' containing EXACTLY the same number
of k-meshes
` (format as file 'kpoints')`\
` => replicate the k-mesh N times`
- ) run \'kkr.exe \--prepare\'
- ) proceed as usual
*) run 'kkr.exe --prepare'
*) look in the output how many k-meshes are needed
*) create a file 'new.kpoints' containing EXACTLY the same number of k-meshes
(format as file 'kpoints')
=> replicate the k-mesh N times
*) run 'kkr.exe --prepare'
*) proceed as usual
======================== Specifying the initial Fermi-Energy:
========================
Specifying the initial Fermi-Energy:
========================
The initial Fermi energy is used by kkr0 to decide how much k-points are
calculated for each energy points. The full k-mesh is used for points
The initial Fermi energy is used by kkr0 to decide how much k-points
are calculated for each energy points. The full k-mesh is used for points
close to the Fermi level
The initial Fermi level can be specified:
*) in first entry in file 'potential'
*) if file potential is not present it is taken from file 'EFERMI'
- ) in first entry in file \'potential\'
- ) if file potential is not present it is taken from file \'EFERMI\'
======================== Weighted Voronoi diagrams
========================
Weighted Voronoi diagrams
========================
Specify weights in file \'voro\_weights\'. Each line contains a real
number specifying the weight of the corresponding atom. When regular
Voronoi diagrams (Wigner-Seitz cells) are required, set every weight to
1.0
Compilation with preprocessor macro USE\_VOROWEIGHTS defined. This is
required because the reading of the Voronoi weights is done in an
inefficient way (every process reads complete file \'voro\_weights\')
======================== Some Bugs: ========================
- ) Fermi energy in formatted DOS output is not the correct Fermi
energy
- ) Title in DOS files is not correct
Specify weights in file 'voro_weights'.
Each line contains a real number specifying the weight of the corresponding
atom.
When regular Voronoi diagrams (Wigner-Seitz cells) are required, set every
weight to 1.0
<!-- -->
Compilation with preprocessor macro USE_VOROWEIGHTS defined. This is required
because the reading of the Voronoi weights is done in an inefficient way
(every process reads complete file 'voro_weights')
- ) k-mesh depends on Fermi-Energy from \'potential\' or \'EFERMI\'
file, which is not the
========================
Some Bugs:
========================
` actual one`
*) Fermi energy in formatted DOS output is not the correct Fermi energy
*) Title in DOS files is not correct
- ) if one uses a saved energy-mesh and makes changes
*) k-mesh depends on Fermi-Energy from 'potential' or 'EFERMI' file, which is not the
actual one
` affecting the energy-mesh in input.conf then this asks for trouble`\
` `
*) if one uses a saved energy-mesh and makes changes
affecting the energy-mesh in input.conf then this asks for trouble
- ) iguess cannot be combined with l-cutoff (RS-cutoff is OK)
*) iguess cannot be combined with l-cutoff (RS-cutoff is OK)
ALREADY FIXED bugs:
- ) Near field correction do not work with more than 1 MPI rank.
</HTML>
*) Near field correction do not work with more than 1 MPI rank.
```