Convergence-control.md

@@ -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
 ```