From dbfc5c74cec0093b26ef22d44b8bae50dcecf738 Mon Sep 17 00:00:00 2001 From: Axel Kohlmeyer Date: Thu, 1 Dec 2022 10:36:12 -0500 Subject: [PATCH] spelling --- doc/src/Developer_grid.rst | 24 ++++++++++----------- doc/src/dump.rst | 2 +- doc/utils/sphinx-config/false_positives.txt | 19 ++++++++++++++++ 3 files changed, 32 insertions(+), 13 deletions(-) diff --git a/doc/src/Developer_grid.rst b/doc/src/Developer_grid.rst index e18fc399f9..4012b2b1f2 100644 --- a/doc/src/Developer_grid.rst +++ b/doc/src/Developer_grid.rst @@ -26,9 +26,9 @@ grid. More specifically, a grid point is defined for each cell (by default the center point), and a processor owns a grid cell if its point is -within the processor's spatial subdomain. The union of processor -subdomains is the global simulation box. If a grid point is on the -boundary of two subdomains, the lower processor owns the grid cell. A +within the processor's spatial sub-domain. The union of processor +sub-domains is the global simulation box. If a grid point is on the +boundary of two sub-domains, the lower processor owns the grid cell. A processor may also store copies of ghost cells which surround its owned cells. @@ -60,7 +60,7 @@ y-dimension. It is even possible to define a 1x1x1 3d grid, though it may be inefficient to use it in a computational sense. Note that the choice of grid size is independent of the number of -processors or their layout in a grid of processor subdomains which +processors or their layout in a grid of processor sub-domains which overlays the simulations domain. Depending on the distributed grid size, a single processor may own many 1000s or no grid cells. @@ -233,7 +233,7 @@ invoked, because they influence its operation. void set_zfactor(double factor); Processors own a grid cell if a point within the grid cell is inside -the processor's subdomain. By default this is the center point of the +the processor's sub-domain. By default this is the center point of the grid cell. The *set_shift_grid()* method can change this. The *shift* argument is a value from 0.0 to 1.0 (inclusive) which is the offset of the point within the grid cell in each dimension. The default is 0.5 @@ -243,9 +243,9 @@ typically no need to change the default as it is optimal for minimizing the number of ghost cells needed. If a processor maps its particles to grid cells, it needs to allow for -its particles being outside its subdomain between reneighboring. The +its particles being outside its sub-domain between reneighboring. The *distance* argument of the *set_distance()* method sets the furthest -distance outside a processor's subdomain which a particle can move. +distance outside a processor's sub-domain which a particle can move. Typically this is half the neighbor skin distance, assuming reneighboring is done appropriately. This distance is used in determining how many ghost cells a processor needs to store to enable @@ -293,7 +293,7 @@ to the Grid class via the *set_zfactor()* method (*set_yfactor()* for 2d grids). The Grid class will then assign ownership of the 1/3 of grid cells that overlay the simulation box to the processors which also overlay the simulation box. The remaining 2/3 of the grid cells -are assigned to processors whose subdomains are adjacent to the upper +are assigned to processors whose sub-domains are adjacent to the upper z boundary of the simulation box. ---------- @@ -547,13 +547,13 @@ Grid class remap methods for load balancing The following methods are used when a load-balancing operation, triggered by the :doc:`balance ` or :doc:`fix balance ` commands, changes the partitioning of the simulation -domain into processor subdomains. +domain into processor sub-domains. In order to work with load-balancing, any style command (compute, fix, pair, or kspace style) which allocates a grid and stores per-grid data should define a *reset_grid()* method; it takes no arguments. It will be called by the two balance commands after they have reset processor -subdomains and migrated atoms (particles) to new owning processors. +sub-domains and migrated atoms (particles) to new owning processors. The *reset_grid()* method will typically perform some or all of the following operations. See the src/fix_ave_grid.cpp and src/EXTRA_FIX/fix_ttm_grid.cpp files for examples of *reset_grid()* @@ -562,7 +562,7 @@ functions. First, the *reset_grid()* method can instantiate new grid(s) of the same global size, then call *setup_grid()* to partition them via the -new processor subdomains. At this point, it can invoke the +new processor sub-domains. At this point, it can invoke the *identical()* method which compares the owned and ghost grid cell index bounds between two grids, the old grid passed as a pointer argument, and the new grid whose *identical()* method is being called. @@ -577,7 +577,7 @@ the command can simply delete the old data array(s) and grid instance(s). It can then return. If the grid data does need to persist, then the data for each grid -needs to be "remapped" from the old grld partitioning to the new grid +needs to be "remapped" from the old grid partitioning to the new grid partitioning. The *setup_remap()* and *remap()* methods are used for that purpose. diff --git a/doc/src/dump.rst b/doc/src/dump.rst index 60efddbd62..4547c76289 100644 --- a/doc/src/dump.rst +++ b/doc/src/dump.rst @@ -66,7 +66,7 @@ Syntax * style = *atom* or *atom/adios* or *atom/gz* or *atom/zstd* or *atom/mpiio* or *cfg* or *cfg/gz* or *cfg/zstd* or *cfg/mpiio* or *cfg/uef* or *custom* or *custom/gz* or *custom/zstd* or *custom/mpiio* or *custom/adios* or *dcd* or *grid* or *grid/vtk* or *h5md* or *image* or *local* or *local/gz* or *local/zstd* or *molfile* or *movie* or *netcdf* or *netcdf/mpiio* or *vtk* or *xtc* or *xyz* or *xyz/gz* or *xyz/zstd* or *xyz/mpiio* or *yaml* * N = dump on timesteps which are multiples of N * file = name of file to write dump info to -* attribute1,filel2,... = list of attributes for a particular style +* attribute1,attribute2,... = list of attributes for a particular style .. parsed-literal:: diff --git a/doc/utils/sphinx-config/false_positives.txt b/doc/utils/sphinx-config/false_positives.txt index e9f3a4089b..e515d3bd0b 100644 --- a/doc/utils/sphinx-config/false_positives.txt +++ b/doc/utils/sphinx-config/false_positives.txt @@ -412,6 +412,7 @@ cdennist cdof ceil Ceil +cekk centerline centro centroid @@ -470,6 +471,7 @@ Cij cis civ CKD +ckk Clang clearstore Cleary @@ -559,6 +561,8 @@ Coulombic Coulombics counterion counterions +CountI +CountN Courant covalent covalently @@ -1240,6 +1244,7 @@ Glosli Glotzer gmail gmake +gmap gmask Gmask GMock @@ -1439,6 +1444,7 @@ ieni ifdefs iff ifort +ihi Ihle ij ijk @@ -1449,6 +1455,7 @@ ilabel Ilie ilmenau Ilmenau +ilo ilp Ilya im @@ -1550,6 +1557,8 @@ Iw Iwers iwyu ixcm +ixhi +ixlo ixx Ixx ixy @@ -2388,6 +2397,7 @@ nlayers nlen nlines Nlines +nlist nlo nlocal Nlocal @@ -2517,11 +2527,15 @@ Nwait nwchem nx Nx +nxlo nxnodes +Nxyz ny Ny +nylo nz Nz +nzlo ocl octahedral octants @@ -2590,6 +2604,8 @@ overlayed Ovito oxdna oxDNA +oxhi +oxlo oxrna oxRNA packings @@ -2657,6 +2673,7 @@ Peng peptide peratom Pergamon +pergrid peri peridynamic Peridynamic @@ -3370,6 +3387,8 @@ Sugaku Suhai Sukumaran Sulc +SumI +SumN sumsq Sunderland supercell