wall_contact_model command

Purpose

Command for setting particle/wall interactions.

Note

This command is supported by Aspherix GPU.

Syntax

wall_contact_model keyword value

Keywords:

Keyword	Description
style	type of pair potential default: `gran`
normal	contact model in normal direction; `off` or normal style (see normal models) default: `hertz`
tangential	contact model in tangential direction; `off` or tangential style (see tangential models) default: `history`
cohesion	cohesion model; `off` or cohesion model style (see cohesion models) default: `off`
rolling_friction	rolling friction model; `off` or rolling friction model style (see rolling friction models) default: `off`
surface	surface model; `off` or surface model style (see surface models) default: `default` for sphere, multisphere, fiber, bonded and fragments. Other shapes trigger specific surface model styles.
settings	multiple setting_name / setting_value pairs can be added; available settings depend on models default: `off`

At least one contact model between normal, tangential, cohesion, rolling_friction must be selected.

Besides from the contact model settings, the wall_contact_model command has a list of settings on its own:

Keyword	Description
store_force	`yes` or `no`; determines if the wall force exerted on the particles is stored in a fix property/atom with id force_(ID), where (ID) is the id of the fix wall/gran command default: `no`
contact_area	available options: `overlap`, `projection`, `constant` constant_value, `superquadric` or `convex` constant_value = value of the constant contact area (units: [length^2]) default: for convex and concave particles `convex`, for superquadric particles `superquadric`, and `overlap` otherwise
area_shape	available options: `square` or `circle` default: `circle`
area_correction	`yes` or `no`, available for `contact_area` `overlap`, `superquadric` or `convex` calculates the contact area using a different value of the Young’s Modulus (`youngModulusOriginal`) default: `no`
modified_area_correction	`yes` or `no`, available for `contact_area` `overlap`, `superquadric` or `convex` applies correction factor for the heat transfer coefficient default: `no`
shear	legacy; please define shear directly for every primitive_wall or set `surface_velocity` for mesh; parameters: dimension (`x`, `y` or `z`) and value
temperature	legacy; please define the wall temperatures in the primitive_wall or mesh commands

Examples

wall_contact_model normal hertz tangential history rolling_friction epsd2
wall_contact_model normal hertz tangential history surface multicontact
wall_contact_model normal hertz tangential history settings shear x 1.0 store_force yes

Description

Bound the simulation domain of a granular system with a frictional wall. All particles in the group interact with the wall when they are close enough to touch it. The equation for the force between the wall and particles touching it is the same as the corresponding equation on the pair_style granular doc page, in the limit of one of the two particles going to infinite radius and mass (flat wall).

You must choose the models matching the particle contact model used, otherwise an error is created. As with the particle_contact_model command, you have to define the mechanical properties for each material you are using in the simulation with fix property commands.

For wall meshes, defined by the mesh command, the triangle-particle neighbor lists are built to efficiently track particle-triangle contacts. Particle-tri neighbor list build is triggered if any particle moves more than half the skin distance or (in case of moving mesh) if the mesh itself moves more than half the skin distance since the last build. A warning is generated if a dangerous particle-tri neigh list build is detected (e.g. if particles are inserted too close to a wall, see section ‘Restrictions’). For wall meshes, the material type is inherited from the mesh command.

Primitive walls are defined by the command primitive_wall and the material is inherited from the same.

For the shear keyword is a legacy keyword, it has been replaced by a shear keyword for the primitive_wall command and a surface_velocity or surface_angular_velocity keyword in mesh command. Please set the properties directly for the respective geometry.

By setting it the wall moves continuously in the specified dimension with velocity vshear. The dimension must be tangential to walls with a planar wallstyle, e.g. in the y or z directions for a primitive plane wall normal to x. For a primitive cylinder wall with axis along z, a dimension of z means the cylinder is moving in the z-direction along it’s axis. A dimension of x or y means the cylinder is spinning around the z-axis, either in the clockwise direction for vshear > 0 or counter-clockwise for vshear < 0. In this case, vshear is the tangential velocity of the wall at whatever radius has been defined. The same applies to primitive cylinder walls with axes along x and y accordingly. The keyword shear can NOT be used for wall meshes. For a moving a granular wall mesh, use the keyword motion provided by the more flexible command mesh_module_wrapper, or use the keywords surface_velocity or surface_angular_velocity in mesh.

The keyword temperature is used to assign a constant temperature to the wall. This keyword is a legacy command as well, please use the temperature keyword for primitive_wall and the mesh command. This setting gets effective in conjunction with heat conduction via the enable_heat_transfer command. For wall meshes, the value for the temperature given in this command is ignored and the temperature value is specified per mesh via mesh.

Contact area calculation

Using keyword contact_area, you can choose from 5 modes of calculating the contact area for particle-particle interactions, which is used e.g. by the mesh_module heattransfer command. If overlap is used, the contact area is calculated from the area of the sphere-sphere intersection. If constant is used, a constant user-defined overlap area is assumed. If projection is used, the overlap area is assumed to be equal to $r_{min}^2 \pi$ , where $r_{min}$ is the radius of the smaller of the two particles in contact. For pure superquadric simulation you may also use the superquadric scheme that uses the local curvature radii to calculate the contact area. Finally the convex scheme can be used for simulations with convex particles only. This approach uses information provided by the corresponding surface model.

In rare cases involving concave particles, if the simulation time step is not sufficiently small, the particle-wall overlaps might be excessively high, higher than the diameter of the smallest atom of the concave body. This can lead to negative contact areas when contact_area overlap is used. Thus, for concave and convex particles the default contact_area mode is convex, where this situation is by definition not possible. The command check_timestep with check_overlap yes is useful to obtain the appropriate value of the simulation time step (see here).

Area correction

For contact_area = overlap, superquadric or convex, a correction to the contact area (used e.g. in heat transfer calculations) can be performed using area_correction yes to account for the fact that the Young’s modulus might have been decreased in order to speed-up the simulation, thus artificially increasing the overlap. In this case, you have to specify the original Young’s modulus of each material by means of the material_properties command:

material_properties glass youngsModulusOriginal 50e9 ...

This correction is performed by scaling the contact area with $\left(Y^*/Y^*_{orig} \right )^a$ , where $Y^*$ and $Y^*_{orig}$ are calculated as defined in pair_style gran. The scaling factor is given as e.g. $a = 1$ for a Hooke and $a = 2/3$ for a Hertz interaction.

Modified area correction

With the optional keyword/arg pair modified_area_correction yes an additional contact area correction can be applied. For the enable_heat_transfer and mesh_module heattransfer commands this requires defining the ht_modification interaction property in the heat transfer commands.

Instead of using a constant factor a .csv file can be used, e.g.

material_interaction_properties steel plastic ht_modification steel_plastic.csv ...

Each such file needs to contain a table (relative overlap | scaling factor) for linear interpolation. Thus, depending on the relative overlap (for particle-particle this is defined as overlap/(sum of radii)) the contact area can be scaled. This models the even better contact/heattransfer for increased overlaps/stresses.

Area shape

This keyword sets how the particle-particle and particle-wall heat transfer coefficients are calculated. See the details at the enable_heat_transfer command.

By specifying store_force = ‘yes’, you can instruct the command to store the wall force exerted on the particles in a fix property/atom with id force_(ID), where (ID) is the id of the fix wall/gran command. A property/atom is defined using command.

The effect of keyword rolling_friction, cohesion, tangential_damping, viscous and absolute_damping is explained in pair gran

Restart, fix_modify, output, run start/stop

If applicable, contact history is written to binary restart files so simulations can continue properly. None of the fix_modify options are relevant to this command. No global scalar or vector or are stored by this command. If store_force = ‘yes’ is specified, the per-particle wall force can be accessed by the various output commands via f_force(ID)**1**, f_force(ID)**2**, f_force(ID)**3**. (ID) is the id of the fix wall/gran command.

Restrictions

When using mesh walls in combination with a particle insertion command, you always have to keep a minimum distance between the wall and the insertion region that is equal to maximum particle radius + half the skin defined in the neighbor_list command. Otherwise, newly inserted particles interpenetrate the walls before a triangle neighbor list is built the first time.

The keyword shear can NOT be used for mesh walls.

Any dimension (xyz) that has a planar granular wall must be non-periodic.