Skip to content

GitLab

Convergence control · Changes

Page history
Update Convergence control authored by Gabriel Wlazłowski's avatar Gabriel Wlazłowski
Hide whitespace changes
Inline Side-by-side
Convergence-control.md
View page @ 911e3df3
......@@ -2,8 +2,8 @@
There are two parameters controlling the computation accuracy of the solution (listed in *input* file):
```bash
energyconveps 1.0e-6 # energy convergence epsilon
# energy changes between two subsequent iteration
# expressed in units E_ffg needs to be smaller than npartconveps
# energy changes between two subsequent iterations
# expressed in units, E_ffg needs to be smaller than npartconveps
# for converged solution
# default=1.0e-6
npartconveps 1.0e-6 # number of particles convergence epsilon
......@@ -24,7 +24,7 @@ and particle number satisfies criteria `npartconveps`:
\dfrac{|N_{\sigma}^{(i)}-N_{\sigma}^{(input)}|}{N_{\uparrow}^{(input)}+N_{\downarrow}^{(input)}}<\varepsilon_{\textrm{npart}}^{(\sigma)}
```
Info about the status of convergence is printed on standard output.
Info about the convergence status is printed to standard output.
Example of a report for converged solution for input parameters:
```bash
Na 17 # requested particle number, spin-a
......@@ -51,14 +51,14 @@ E_pairext: NEW= 0 OLD= 0 DIFF= 0 CONVS
# Number of iterations
The algorithm iterates until one of the following criteria is met:
1. convergence is achieved (see the section above);
2. number of iteration exceeded maximal allowed number of iteration specified in *input* file
1. Convergence is achieved (see the section above).
2. Number of iterations exceeded the maximum allowed number of iterations specified in the *input* file
```bash
maxiters 200 # maximum number of iterations, default=10000
```
# Imposing constraints to speed up convergence
Providing additional information about properties of the expected solution (based on physical arguments) may speed-up converging significantly.
Providing additional information about the expected solution's properties (based on physical arguments) can significantly speed up convergence.
```bash
spinsymmetry 1 # set to 1 if you want to impose Na=Nb, default: 0
nocurrents 1 # set to 1 if you want to impose ja=jb=0
......@@ -66,25 +66,25 @@ nocurrents 1 # set to 1 if you want to impose ja=jb=0
```
# Mixing types
The self-consistent algorithm tracks the behavior of solutions as a function if the iteration number and utilizes this information to create a new prediction for the solution. In the samples scheme (called *linear mixing*) this process is realized via the formula:
The self-consistent algorithm tracks the behavior of solutions as a function of iteration number and uses this information to generate a new prediction for the solution. In the samples scheme (called *linear mixing*), this process is realized via the formula:
```c
for(ixyz = 0; ixyz < SOLDIM; ixyz++)
h_solution[ixyz] = md.linearmixing * h_solution[ixyz] + (1.0-md.linearmixing) * h_solution_old[ixyz];
```
Here there is subtle issue: what should be treated as the solution vector: [densities of potentials](Physical quantities)? In principle, this should not matter, but in practice, it turns out that converges properties depend on this choice. For this reason W-SLDA toolkit provided a tag in the *input* file that can be used to select meaning of the *solution* vector:
Here, there is a subtle issue: what should be treated as the solution vector: [densities of potentials](Physical quantities)? In principle, this should not matter, but in practice, it turns out that convergent properties depend on this choice. For this reason W-SLDA toolkit provided a tag in the *input* file that can be used to selectthe meaning of the *solution* vector:
```bash
mixingtype p # 'd' - mix densities, 'p' - mix potentials (default)
```
Our tests show that typically the algorithm converges faster when *potentials* are used for the mixing procedure. However, we found (rare) cases where mixing of *densities* provides better efficiency.
Our tests show that the algorithm typically converges faster when *potentials* are used in the mixing procedure. However, we found (rare) cases where mixing *densities* improves efficiency.
## Disabling mixing in the first iteration
In some cases, it is required to disable mixing in the first iteration. Typically, it is required when:
* the solver has been [initialized manually](https://gitlab.fizyka.pw.edu.pl/wtools/wslda/-/wikis/Initialization%20of%20the%20st-wslda%20solvers#custom-initialization-of-the-solver), and thus integral integrity of data is not maintained.
* [automatic interpolations](https://gitlab.fizyka.pw.edu.pl/wtools/wslda/-/wikis/Automatic%20interpolations) have been applied.
* The solver has been [initialized manually](Initialization-of-the-st-wslda-solvers#custom-initialization-of-the-solver), and thus the integrity of data is not maintained.
* [automatic interpolations](Automatic-interpolations) have been applied.
In such cases, not all buffers related to the previous iteration are filled correctly. In the case of the [custom initialization](https://gitlab.fizyka.pw.edu.pl/wtools/wslda/-/wikis/Initialization%20of%20the%20st-wslda%20solvers#custom-initialization-of-the-solver) most likely they are set to zero, while in the case of the [automatic interpolations](https://gitlab.fizyka.pw.edu.pl/wtools/wslda/-/wikis/Automatic%20interpolations) some quantities like $`\nu`$ or $`\tau`$ are interpolated incorrectly (strong cut-off dependence is not taken into account). To do not propagate the incomplete/incorrect data into the self-consistent process in the first iteration we can disable fragments of the code that depend on the historical iterations.
To do this use the following flag:
In such cases, not all buffers related to the previous iteration are filled correctly. In the case of the [custom initialization](Initialization-of-the-st-wslda-solvers#custom-initialization-of-the-solver), most likely they are set to zero, while in the case of the [automatic interpolations](Automatic-interpolations), some quantities like $`\nu`$ or $`\tau`$ are interpolated incorrectly (strong cut-off dependence is not taken into account). To prevent incomplete or incorrect data from propagating into the self-consistent process in the first iteration, we can disable code fragments that depend on historical iterations.
To do this, use the following flag:
```bash
nomixstart 1 # do not do mixing for starting iteration
```