Difference between revisions of "TriaxialTest"
From Yade
Line 1: | Line 1: | ||
=Triaxial Test= |
=Triaxial Test= |
||
− | Yade includes tools to simulate triaxial |
+ | Yade includes tools to simulate triaxial tests on particles assemblies. The pre-processor TriaxialTest (and variants like e.g. CapillaryTriaxialTests) illustrate how to use them. It generates a scene which will - by default - go through the following steps : |
+ | *generate random loose packings in a parallelepiped. |
||
− | * |
+ | *compress the packing isotropicaly, either squeezing the packing between moving rigid boxes or expanding the particles while boxes are fixed (depending on flag "InternalCompaction"). The confining pressure in this stage is defined via "sigmaIsoCompaction". |
⚫ | |||
+ | *when the packing is dense and stable, simulate a loading path and get the mechanical response as a result. |
||
− | |||
+ | |||
⚫ | The default loading path corresponds to a constant lateral stress (sigmaLateralConfinement) in 2 directions and constant strain rate on the third direction. This default loading path is performed when the flag AutoCompressionActivation = true, otherwise the simulation stops after isotropic compression. |
||
+ | |||
+ | Different loading paths might be performed. In order to define them, the user can modify the flags found in engine TriaxialStressController at any point in the simulation. If TriaxialStressController::wall_X_activated is "true" boundary X is moved automatically to maintain the defined stress level sigmaN (see axis conventions below). If "false" the boundary is not controlled by the engine at all. In that case the user is free to prescribe fixed position, constant velocity, or more complex conditions. |
||
+ | |||
+ | Axis conventions : |
||
+ | The boundaries perpendicular to axis ex=(1,0,0) are called "left" and "right", ey=(0,1,0) corresponds to "top" and "bottom", and axis ez=(0,0,1) to "front" and "back". In the default loading path, strain rate is assigned along ey, and constant stresses are assigned on ex and ez. |
||
==Essential engines :== |
==Essential engines :== |
||
− | # The''' TrixialCompressionEngine''' is used for controlling the state of the sample and simulating loading paths. TrixialCompressionEngine inherits from TriaxialStressController, which |
+ | # The''' TrixialCompressionEngine''' is used for controlling the state of the sample and simulating loading paths. TrixialCompressionEngine inherits from TriaxialStressController, which computes stress- strain-like quantities in the packing and maintain a constant level of stress at each boundary. TriaxialCompressionEngine has few more members in order to impose constant strain rate and control the transition between isotropic compression and triaxial test. Transitions are defined by changing some flags of the TriaxialStressController, switching from/to imposed strain rate to/from imposed stress. |
# The class '''TriaxialStateRecorder''' is used to write to a file the history of stresses and strains. |
# The class '''TriaxialStateRecorder''' is used to write to a file the history of stresses and strains. |
||
# TriaxialTest is using '''GlobalStiffnessTimeStepper''' to compute an appropriate dt for the numerical scheme. |
# TriaxialTest is using '''GlobalStiffnessTimeStepper''' to compute an appropriate dt for the numerical scheme. |
||
Line 21: | Line 28: | ||
The initial positioning of spheres is done by generating random (x,y,z) in a box and checking if a sphere of radius R (R also randomly generated with respect to a uniform distribution between mean*(1-std_dev) and mean*(1+std_dev) can be inserted at this location without overlaping with others. |
The initial positioning of spheres is done by generating random (x,y,z) in a box and checking if a sphere of radius R (R also randomly generated with respect to a uniform distribution between mean*(1-std_dev) and mean*(1+std_dev) can be inserted at this location without overlaping with others. |
||
− | If the sphere overlaps, new (x,y,z)'s are generated until |
+ | If the sphere overlaps, new (x,y,z)'s are generated until a free position for the new sphere is found. This explains the message you have : after 3000 trial-and-error, the sphere couldn't be placed, and the algorithm stops. |
− | You get the message above if you try to generate an initialy dense packing, which is not possible with this |
+ | You get the message above if you try to generate an initialy dense packing, which is not possible with this algorithm. It can only generate clouds. You should keep the default value of porosity (n~0.7), or even increase if it is still to low in some cases. The dense state will be obtained in the second step (compaction, see below). |
− | The dense state will be obtained in the second step (compaction, see below). |
||
==="How is the compaction done, what are the parameters maxWallVelocity and finalMaxMultiplier?"=== |
==="How is the compaction done, what are the parameters maxWallVelocity and finalMaxMultiplier?"=== |
Revision as of 14:03, 22 April 2010
Triaxial Test
Yade includes tools to simulate triaxial tests on particles assemblies. The pre-processor TriaxialTest (and variants like e.g. CapillaryTriaxialTests) illustrate how to use them. It generates a scene which will - by default - go through the following steps :
- generate random loose packings in a parallelepiped.
- compress the packing isotropicaly, either squeezing the packing between moving rigid boxes or expanding the particles while boxes are fixed (depending on flag "InternalCompaction"). The confining pressure in this stage is defined via "sigmaIsoCompaction".
- when the packing is dense and stable, simulate a loading path and get the mechanical response as a result.
The default loading path corresponds to a constant lateral stress (sigmaLateralConfinement) in 2 directions and constant strain rate on the third direction. This default loading path is performed when the flag AutoCompressionActivation = true, otherwise the simulation stops after isotropic compression.
Different loading paths might be performed. In order to define them, the user can modify the flags found in engine TriaxialStressController at any point in the simulation. If TriaxialStressController::wall_X_activated is "true" boundary X is moved automatically to maintain the defined stress level sigmaN (see axis conventions below). If "false" the boundary is not controlled by the engine at all. In that case the user is free to prescribe fixed position, constant velocity, or more complex conditions.
Axis conventions : The boundaries perpendicular to axis ex=(1,0,0) are called "left" and "right", ey=(0,1,0) corresponds to "top" and "bottom", and axis ez=(0,0,1) to "front" and "back". In the default loading path, strain rate is assigned along ey, and constant stresses are assigned on ex and ez.
Essential engines :
- The TrixialCompressionEngine is used for controlling the state of the sample and simulating loading paths. TrixialCompressionEngine inherits from TriaxialStressController, which computes stress- strain-like quantities in the packing and maintain a constant level of stress at each boundary. TriaxialCompressionEngine has few more members in order to impose constant strain rate and control the transition between isotropic compression and triaxial test. Transitions are defined by changing some flags of the TriaxialStressController, switching from/to imposed strain rate to/from imposed stress.
- The class TriaxialStateRecorder is used to write to a file the history of stresses and strains.
- TriaxialTest is using GlobalStiffnessTimeStepper to compute an appropriate dt for the numerical scheme.
NOTE : TriaxialStressController::ComputeUnbalancedForce(...) returns a value that can be usefull for evaluating the stability of the packing. It is defined as (mean force on particles)/(mean contact force), so that it tends to 0 in a stable packing. This parameter is checked by TriaxialCompressionEngine to switch from one stage of the simulation to the next one (e.g. stop isotropic confinment and start axial loading)
Frequently asked questions :
"How is generated the packing? How to change particles sizes distribution? Why do I have a message "Exceeded 3000 tries to insert non-overlapping sphere"?"
The initial positioning of spheres is done by generating random (x,y,z) in a box and checking if a sphere of radius R (R also randomly generated with respect to a uniform distribution between mean*(1-std_dev) and mean*(1+std_dev) can be inserted at this location without overlaping with others.
If the sphere overlaps, new (x,y,z)'s are generated until a free position for the new sphere is found. This explains the message you have : after 3000 trial-and-error, the sphere couldn't be placed, and the algorithm stops.
You get the message above if you try to generate an initialy dense packing, which is not possible with this algorithm. It can only generate clouds. You should keep the default value of porosity (n~0.7), or even increase if it is still to low in some cases. The dense state will be obtained in the second step (compaction, see below).
"How is the compaction done, what are the parameters maxWallVelocity and finalMaxMultiplier?"
Compaction is done (1) by moving rigid boxes or (2) by increasing the sizes of the particles (decided using the option "internalCompaction" : true => size increase). Both algorithm needs numerical parameters to prevent instabilities. For instance, with method (1) maxWallVelocity is the maximum wall velocity, with method (2) finalMaxMultiplier is the max value of the multiplier applied on sizes at each iteration (always something like 1.00001).
"During the simulation of triaxial compression test, the wall in one direction moves with an increment of strain while the stresses in other two directions are adjusted to sigmaiso. How the stresses in other directions are maintained constant to sigmaiso? What is the mechanism? Where is it implemented in Yade?"
The control of stress on a boundary is based on the total stiffness K of all contacts between the packing and this boundary. In short, at each step, displacement=stress_error/K. This algorithm is implemented in TriaxialStressController, and the control itself is in TriaxialStressController::ControlExternalStress(...). The control can be turned off independantly for each boundary, using the flags wall_XXX_activated, with XXX = top, bottom, left, right, back, front. The imposed sress is a unique value (sigma_iso) for all directions if TriaxialStressController::isAxisymmetric, or 3 independant values sigma1,2,3.
"Which value of friction angle do you use during the compaction phase of the Triaxial Test?"
The friction during the compaction (whether you are using the expansion method or the compression one for the specimen generation) can be anything between 0 and the final value used during the Triaxial phase. Note that higher friction than the final one would result in volumetric collapse at the beginning of the test. The purpose of using a different value of friction during this phase is related to the fact that the final porosity you get at the end of the sample generation essentially depends on it as well as on the assumed Particle Size Distribution. Changing the initial value of friction will get to a different value of the final porosity.
"Which is the aim of the bool isRadiuControlIteration?"
This parameter allows to perform some cycle without expanding between two radius expansions. Cycling without expanding is just a way to speed up the simulation.
"How comes the unbalanced force reaches a low value only after many timesteps in the compaction phase?"
The value of unbalanced force (dimensionless) is expected to reach low value (i.e. identifying a static-equilibrium condition for the specimen) only at the end of the compaction phase. The code is not aiming at simulating a quasistatic isotropic compaction process, it is only giving a stable packing at the end of it.