ICODE-ADC/lammps
4
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

a few formal changes and spelling updates

Browse Source
This commit is contained in:
Axel Kohlmeyer
2022-11-02 20:39:10 -04:00
parent b5d57531d9
commit 871efda589
4 changed files with 32 additions and 34 deletions
Download Patch File Download Diff File Expand all files Collapse all files

26
doc/src/Modify_gsm.rst
View File

@ -1,5 +1,5 @@
Granular Submodel (GSM) styles
===========
Granular Sub-model (GSM) styles
===============================
In granular models, particles are spheres with a finite radius and rotational
degrees of freedom as further described in the
@ -9,22 +9,22 @@ of motion as described in :doc:`pair granular <pair_granular>` and
:doc:`fix wall/gran <fix_wall_gran>`. In both cases, the exchange of forces,
torques, and heat flow between two types of bodies is defined using a
GranularModel class. The GranularModel class organizes the details of an
interaction using a series of granular submodels each of which describe a
interaction using a series of granular sub-models each of which describe a
particular interaction mode (e.g. normal forces or rolling friction). From a
parent GSM class, several types of submodel classes are derived:
parent GSM class, several types of sub-model classes are derived:
* GSMNormal: normal force submodel
* GSMDamping: normal damping submodel
* GSMTangential: tangential forces and sliding friction submodel
* GSMRolling: rolling friction submodel
* GSMTwisting: twisting friction submodel
* GSMHeat: heat conduction submodel
* GSMNormal: normal force sub-model
* GSMDamping: normal damping sub-model
* GSMTangential: tangential forces and sliding friction sub-model
* GSMRolling: rolling friction sub-model
* GSMTwisting: twisting friction sub-model
* GSMHeat: heat conduction sub-model
For each type of submodel, more classes are further derived, each describing
For each type of sub-model, more classes are further derived, each describing
a specific implementation. For instance, from the GSMNormal class the
GSMNormalHooke, GSMNormalHertz, and GSMNormalJKR classes are derived which
calculate Hookean, Hertzian, or JKR normal forces, respectively. This modular
structure simplifies the addition of new granualar contact models as as one only
structure simplifies the addition of new granular contact models as as one only
needs to create a new GSM class without having to modify the more complex
PairGranular, FixGranWall, and GranularModel classes. Most GSM methods are also
already defined by the parent classes so new contact models typically only require
@ -82,7 +82,7 @@ There are also several type-specific methods
* - ``GSMNormal->calculate_area()``
- Optional method to return the surface area of the contact. By default, this returns the geometric cross section.
* - ``GSMNormal->set_fncrit()``
- Optional method that defines the critical force to break the contact used by some tangential, rolling, and twisting submodels. By default, this is the current total normal force including damping.
- Optional method that defines the critical force to break the contact used by some tangential, rolling, and twisting sub-models. By default, this is the current total normal force including damping.
* - ``GSMNormal->calculate_forces()``
- Required method that returns the normal contact force
* - ``GSMDamping->calculate_forces()``

6
doc/src/fix_temp_integrate.rst
View File

@ -41,12 +41,6 @@ the *constant* or *type* keywords. For style *constant*, the specific heat
is a constant value *cp* for all atoms. For style *type*, *N* different values
of the specific heat are defined, one for each of the *N* types of atoms.
----------
.. include:: accel_styles.rst
----------
Restart, fix_modify, output, run start/stop, minimize info

33
doc/src/pair_granular.rst
View File

@ -766,26 +766,29 @@ These extra quantities can be accessed by the :doc:`compute pair/local <compute_
Restrictions
""""""""""""
All the granular pair styles are part of the GRANULAR package. It is
only enabled if LAMMPS was built with that package. See the :doc:`Build package <Build_package>` page for more info.
This pair style is part of the GRANULAR package. It is
only enabled if LAMMPS was built with that package.
See the :doc:`Build package <Build_package>` page for more info.
These pair styles require that atoms store torque and angular velocity
(omega) as defined by the :doc:`atom_style <atom_style>`. They also
require a per-particle radius is stored. The *sphere* atom style does
all of this.
This pair style requires that atoms store per-particle radius,
torque, and angular velocity (omega) as defined by the
:doc:`atom_style sphere <atom_style>`.
This pair style requires you to use the :doc:`comm_modify vel yes <comm_modify>` command so that velocities are stored by ghost
atoms.
This pair style requires you to use the :doc:`comm_modify vel yes <comm_modify>`
command so that velocities are stored by ghost atoms.
These pair styles will not restart exactly when using the
:doc:`read_restart <read_restart>` command, though they should provide
statistically similar results. This is because the forces they
compute depend on atom velocities. See the
:doc:`read_restart <read_restart>` command for more details.
This pair style will not restart exactly when using the
:doc:`read_restart <read_restart>` command, though it should provide
statistically similar results. This is because the forces it
computes depend on atom velocities and the atom velocities have
been propagated half a timestep between the force computation and
when the restart is written, due to using Velocity Verlet time
integration. See the :doc:`read_restart <read_restart>` command
for more details.
Accumulated values for individual contacts are saved to to restart
Accumulated values for individual contacts are saved to restart
files but are not saved to data files. Therefore, forces may
differ significantly when a system is reloaded using A
differ significantly when a system is reloaded using the
:doc:`read_data <read_data>` command.
Related commands