Changes between Version 90 and Version 91 of doc/app/errmsg

Timestamp:

Nov 23, 2011 10:05:34 AM (13 years ago)

Author:

heinze

Comment:

--

doc/app/errmsg

@@ -168 +168 @@
 ||[=#PA0145 PA0145]   ||collision_efficiency out of range: ...   || Theres ||
 ||[=#PA0146 PA0146]  ||maximum_number_of_particles needs to be increased but this is not allowed with netcdf_data_format < 3  ||netCDF output is switched on ([../d3par#data_output_format data_output_format] = '' 'netcdf' '') and a netCDF3 format is used ([../d3par#netcdf_data_format  netcdf_data_format ] < 3). \\\\ If output of particle data is switched on (see [../d3par#dt_write_particle_data dt_write_particle_data]), the size of the particle array, given on each processor by [../d3par#maximum_number_of_particles maximum_number_of_particles], is not allowed to increase during the run, when the netCDF3 data format is used, because netCDF3 allows only one unlimited dimension, which is the time dimension. Anyhow, PALM tries to increase the size of the particle array, if the number of particles in a subdomain becomes larger than the size of this array. This may happen because of a flow convergence or because new sets of particles are released (see [../d3par#dt_prel dt_prel]).\\\\This problem can be avoided by using the netCDF4 data format ([../d3par#netcdf_data_format netcdf_data_format] > 2), which allows more than one unlimited dimension.\\\\Alternatively, [../d3par#maximum_number_of_particles maximum_number_of_particles] can be given a sufficiently large value.  ||
-||[=#PA0147 PA0145]PA0147   ||maximum_number_of_tails needs to be increased but this is not allowed with netcdf_data_format < 3   ||netCDF output is switched on ([../d3par#data_output_format data_output_format] = '' 'netcdf' '') and a netCDF3 format is used ([../d3par#netcdf_data_format  netcdf_data_format ] < 3). \\\\ If output of particle data is switched on (see [../d3par#dt_write_particle_data dt_write_particle_data]), the size of the particle array, given on each processor by [../d3par#maximum_number_of_tails maximum_number_of_tails], is not allowed to increase during the run, when the netCDF3 data format is used, because netCDF3 allows only one unlimited dimension, which is the time dimension. Anyhow, PALM tries to increase the size of the particle array, if the number of particles in a subdomain becomes larger than the size of this array. This may happen because of a flow convergence or because new sets of particles are released (see [../d3par#dt_prel dt_prel]).\\\\This problem can be avoided by using the netCDF4 data format ([../d3par#netcdf_data_format netcdf_data_format] > 2), which allows more than one unlimited dimension.\\\\Alternatively, [../d3par#maximum_number_of_particles maximum_number_of_particles] can be given a sufficiently large value.  ||
+||[=#PA0147 PA0147]   ||maximum_number_of_tails needs to be increased but this is not allowed with netcdf_data_format < 3   ||netCDF output is switched on ([../d3par#data_output_format data_output_format] = '' 'netcdf' '') and a netCDF3 format is used ([../d3par#netcdf_data_format  netcdf_data_format ] < 3). \\\\ If output of particle data is switched on (see [../d3par#dt_write_particle_data dt_write_particle_data]), the size of the particle array, given on each processor by [../d3par#maximum_number_of_tails maximum_number_of_tails], is not allowed to increase during the run, when the netCDF3 data format is used, because netCDF3 allows only one unlimited dimension, which is the time dimension. Anyhow, PALM tries to increase the size of the particle array, if the number of particles in a subdomain becomes larger than the size of this array. This may happen because of a flow convergence or because new sets of particles are released (see [../d3par#dt_prel dt_prel]).\\\\This problem can be avoided by using the netCDF4 data format ([../d3par#netcdf_data_format netcdf_data_format] > 2), which allows more than one unlimited dimension.\\\\Alternatively, [../d3par#maximum_number_of_particles maximum_number_of_particles] can be given a sufficiently large value.  ||
 ||[=#PA0148 PA0148]   ||particle too fast. n = ...   ||  ||
 ||[=#PA0149 PA0149]   ||particle out of range: i=... j=... k=... nxl=... nxr=... nys=... nyn=... nzb=... nzt=...     ||  ||
@@ -242 +242 @@
 ||[=#PA0219 PA0219]   ||unknown boundary condition bc_par_lr = "..."   ||  ||
 ||[=#PA0220 PA0219]   ||unknown boundary condition bc_par_ns = "..."   ||  ||
-||[=#PA0221 PA0221]   ||number of PEs of the prescribed topology (...) does not match the number of PEs available to the job ()   ||  ||
-||[=#PA0222 PA0222]   ||if the processor topology is prescribed by the user, both values of "npex" and "npey" must be given in the NAMELIST-parameter file   ||  ||
+||[=#PA0221 PA0221]   ||number of PEs of the prescribed topology (...) does not match the number of PEs available to the job (...)   ||In case that the number of PEs along the x- and y-direction of the virtual processor grid is set via [../d3par#npex npex] and [../d3par#npey npey], the product npey*npex has to match exactly the total number of processors which is assigned by the '''mrun'''-option -X. ||
+||[=#PA0222 PA0222]   ||if the processor topology is prescribed by the user, both values of "npex" and "npey" must be given in the NAMELIST-parameter file   || In case that only one number of processors along x- or y- direction [../d3par#npex npex] or [../d3par#npey npey] is set in the [../d3par#pgrid &d3par-Namelist], the remaining, so far not assigned, number of processors has to be set, too.   ||
 ||[=#PA0223 PA0223]   ||psolver = "poisfft_hybrid" can only be used in case of a 1d-decomposition along x     || Siggi ||
 ||[=#PA0224 PA0224]   ||no matching grid for transpositions found   ||  ||