Skip to content

Changes

Page history
Convert from dokuwiki to markdown syntax using pandoc authored by Philipp Rüssmann's avatar Philipp Rüssmann 
find . -name \*.txt -type f -exec /Users/ruess/Downloads/pandoc-2.7.2/bin/pandoc -f mediawiki -t markdown -o {}.md {} \;
then replace all .txt.md files by .txt
and finally run git mv on all .txt files to convert to .md files
Show whitespace changes
Inline Side-by-side
kkrnano/prepare.md 0 → 100644
View page @ a593e338
###### Source files {#source_files}
A KKRnano code repository can be found on the Trac system of FZJ:
<https://trac.version.fz-juelich.de/KKRnano>
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}
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.`
: !: It is possible to use potentials calculated for a certain
geometry as a starting point for a calculation with modified
geometry.
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")~~
Binary input files:
` * `[`kkrnano:Binary`` ``files`](kkrnano:Binary_files "wikilink")
###### Build information {#build_information}
` * `[`kkrnano:List`` ``of`` ``preprocessor`` ``macros`](kkrnano:List_of_preprocessor_macros "wikilink")
###### 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")
###### 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`
- ) Relevant makefile: kkr2/Makefile
<!-- -->
- ) Create build directories (these paths are hardcoded in the
makefiles)
` $HOME/build/kkr0`\
` $HOME/build/kkr2`\
` `
- ) building:
` make PLATFORM=`<insert platform>` TYPE=`<debug or nodebug>\
` `\
` where PLATFORM can be JUQUEEN, if PLATFORM is left out it builds with mpiifort`\
` `
======================== 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
======================= Stack vs. heap arrays: =======================
\"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.
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
` (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
` '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: ========================
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
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
======================== 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
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\'
======================== 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
<!-- -->
- ) k-mesh depends on Fermi-Energy from \'potential\' or \'EFERMI\'
file, which is not the
` actual one`
- ) 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)
ALREADY FIXED bugs:
- ) Near field correction do not work with more than 1 MPI rank.
</HTML>