spelling
This commit is contained in:
@ -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 <balance>` or :doc:`fix balance
|
||||
<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.
|
||||
|
||||
|
||||
@ -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::
|
||||
|
||||
|
||||
@ -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
|
||||
|
||||
Reference in New Issue
Block a user