177 | | By default, particles are sorted in memory in a way that their order follows the order in which the gridpoint values are stored. This may improve cache coherence in case of larger numbers of particles and gridpoints. However, since the sorting itself is time consuming and since the requirement of sorting depends on the strength of mixing in the flow, performance can be improved if the sorting is applied only after certain time intervals. The proper length of this interval '''dt_sort_particles''' must be determined empirically by carrying out test runs with different intervals. Check file [../iofile#CPU_MEASURES CPU_MEASURES] to find the value of '''dt_sort_particles''' which gives the best performance.\\\ |
178 | | Note: |
179 | | In case of [../inipar#cloud_droplets cloud_droplets] = '' '.T.' '', any given non-zero value of '''dt_sort_particles''' will be reset to zero and a corresponding warning message will appear in the job protocol. |
| 177 | By default, particles are sorted in memory in a way that their order follows the order in which the gridpoint values are stored. This may improve cache coherence in case of larger numbers of particles and gridpoints. However, since the sorting itself is time consuming and since the requirement of sorting depends on the strength of mixing in the flow, performance can be improved if the sorting is applied only after certain time intervals. The proper length of this interval '''dt_sort_particles''' must be determined empirically by carrying out test runs with different intervals. Check file [../iofile#CPU_MEASURES CPU_MEASURES] to find the value of '''dt_sort_particles''' which gives the best performance.\\\\ |
| 178 | '''Note:''' In case of [../inipar#cloud_droplets cloud_droplets] = '' '.T.' '', any given non-zero value of '''dt_sort_particles''' will be reset to zero and a corresponding warning message will appear in the job protocol. |