Gas Particle Forces
dynamics node
A microsolver that computes pairwise collision forces between particles that represent instanced spheres.
The Gas Particle Forces DOP is a microsolver used to build larger fluid simulations. It is currently used to compute pressure forces in the Particle Fluid Solver DOP. It computes and optionally applies pairwise collision forces between particles.
Collision forces are found by looking at the instance path of each particle. That instance path is resolved into a path to attached SIM_Geometry to the particle. Spheres in that geometry are then used for collision detection. Where collisions occur, a very stiff repulsive force is generated to separate the particles.
Spheres do not need to lie at the particle origin. Instead, they can be offset from the particle. Collision forces will then generate torque in addition to forces.
Parameters
|
Geometry |
The geometry containing the particle set for which collision forces are to be computed. |
||||||||
|
Enable Pressure Force |
Enables or disables pressure forces applied by this DOP. |
||||||||
|
Poisson Ratio |
A material property typically between 0-0.5. Affects the repulsion strength. Lower values increases the repulsion strength. |
||||||||
|
Elastic Repulsion |
Controls the linearity of the particle’s response to collisions. The default value of 1.5 is a commonly accepted value and typically does not need to be changed. |
||||||||
|
Repulsion Strength (Young’s modulus (Pa) ) |
Controls the magnitude of the restorative force to cancel collisions. Lower values allow the particles to overlap longer before they separate. Higher values increases the stiffness of the system and require more substeps to remain stable. |
||||||||
|
Viscous Dampening |
Controls the linearity of the particle’s response to dampening. The default value of 0.5 is a commonly accepted value and typically does not need to be changed. |
||||||||
|
Dampening Strength |
Controls the magnitude of the dampening of collisions. Lower values allows the elastic repulsion to dominate the collision response. Higher values dampens the collision response. |
||||||||
|
Contact Resistance |
Controls the linearity of the particle’s response to contact friction. The default value of 1.5 is a commonly accepted value and typically does not need to be changed. |
||||||||
|
Contact Dampening |
Controls the linearity of the particle’s response to contact dampening. The default value of 0.5 is a commonly accepted value and typically does not need to be changed. |
||||||||
|
Rolling Friction |
Coefficient of rolling friction. Typically much smaller than coeffient of sliding friction. |
||||||||
|
Obj. Rolling Friction |
Coefficient of rolling friction for objects in contact with particles. |
||||||||
|
Obj. Impulse Duration |
Controls the magnitude of the frictional impulse upon object-particle collision. Smaller values mean the impulse is large and this increases the stiffness of the system and simulation time. Larger values indicate object friction have less affect on the particles. |
||||||||
|
Obj. Trans. Impulse Factor |
Object’s Translation Impulse Factor controls the magnitude of the object’s impulse to slow the particle’s translational motion. |
||||||||
|
Obj. Roll. Impulse Factor |
Object’s Rolling Impulse Factor controls the magnitude of the object’s impulse to slow the particle’s rotational motion. |
||||||||
|
Compute New Velocity |
When this option is enabled, the DOP computes forces acting between particles and directly modifies the velocity attribute of the affected particles. If it is not, the DOP simply places the computed forces in the force attribute of the particles. |
||||||||
|
Do Collisions |
Any volume data marked as a collision relationship will also be included in the collision computation. |
||||||||
|
Use SDF Velocity |
Use object’s SDF velocity for particle-object collisions |
||||||||
|
Use GEO Velocity |
Use object’s GEO velocity for particle-object collisions |
||||||||
|
Parameter Operations |
Each data option parameter has an associated menu which specifies how that parameter operates.
|
||||||||
|
Default Operation |
For any parameters with their Operation menu set to Use Default, this parameter controls what operation is used. This parameter has the same menu options and meanings as the Parameter Operations menus, but without the Use Default choice. |
||||||||
|
Make Objects Mutual Affectors |
All objects connected to the first input of this node become mutual affectors. This is equivalent to using an Affector DOP to create an affector relationship between “*” and “*” before connecting it to this node. This option makes it convenient to have all objects feeding into a solver node affect each other. |
||||||||
|
Group |
When an object connector is attached to the first input of this node, this parameter can be used to choose a subset of those objects to be affected by this node. |
||||||||
|
Data Name |
Indicates the name that should be used to attach the data to an object or other piece of data. If the Data Name contains a “/” (or several), that indicates traversing inside subdata. For example, if the Fan Force DOP has the default Data Name “Forces/Fan”. This attaches the data with the name “Fan” to an existing piece of data named “Forces”. If no data named “Forces” exists, a simple piece of container data is created to hold the “Fan” subdata. Different pieces of data have different requirements on what names should be used for them. Except in very rare situations, the default value should be used. Some exceptions are described with particular pieces of data or with solvers that make use of some particular type of data. |
||||||||
|
Unique Data Name |
Turning on this parameter modifies the Data Name parameter value to ensure that the data created by this node is attached with a unique name so it will not overwrite any existing data. With this parameter turned off, attaching two pieces of data with the same name will cause the second one to replace the first. There are situations where each type of behavior is desirable. If an object needs to have several Fan Forces blowing on it, it is much easier to use the Unique Data Name feature to ensure that each fan does not overwrite a previous fan rather than trying to change the Data Name of each fan individually to avoid conflicts. On the other hand, if an object is known to have RBD State data already attached to it, leaving this option turned off will allow some new RBD State data to overwrite the existing data. |
Usages in other examples
| Example name | Example for |
|---|