Driving the boundaries
In Rockable there is no special “wall” object: a boundary is an ordinary body
that happens to be driven. The bodies that can be driven are the first
nDriven entries of the Particles list, and what is done to them is
described in a file named drivingSystem.txt.
nDriven 6
Particles 2006
...
The file drivingSystem.txt
The file sits in the folder where the computation runs. A token starting with
/, # or ! discards the rest of the line.
Note
If the file does not exist, the first nDriven bodies simply do not move.
This is the usual way of building a container of fixed walls: no file is
needed at all.
Important
Unlike the rest of the setup, drivingSystem.txt is re-read every time
a conf-file is dumped, that is every interConf. A loading can therefore
be changed while the computation runs, without restarting it: edit the file,
and the change is taken into account at the next dump. This is also why the
driving is never written into the conf-files.
Imposing a component: Control
The elementary entry drives one component of one body:
Control <type> <bodyNumber> <value>
|
|
Meaning |
|---|---|---|
|
1 real |
Imposed velocity component. |
|
1 real |
Imposed angular velocity component. |
|
1 real |
Imposed force component. |
|
1 real |
Imposed moment component. |
|
3 reals |
Imposed angular velocity vector. |
|
3 reals |
Imposed moment vector. |
# a floor moving up slowly
Control _y_Vel_ 0 0.01
# a piston pushed with a constant force
Control _y_For_ 1 -250.0
# a drum rotating about the z axis
Control _xyzrot_Vel_ 2 0 0 1.5
A component of a driven body that is not controlled is not integrated at
all: the body keeps its position along that degree of freedom. A wall listed in
drivingSystem.txt with a single _y_Vel_ control therefore moves
vertically at the imposed velocity, and stays where it is along \(x\) and
\(z\), whatever the forces it receives.
Note
Velocity-driven and force-driven components are not integrated in the same way. A velocity-driven component is simply translated at the imposed velocity, which makes it exactly kinematic. A force-driven component is integrated like a free body, with the imposed force added to the resultant of the contact forces. Gravity is not applied to it: the imposed force is the only external force along that component, so the weight of a heavy piston has to be included in the imposed force if it matters. See Integration schemes.
Warning
A Control can also be given to a free body (one that is not among the
nDriven first ones), for instance to hold the ends of a beam. The
controlled velocity component is then reset at every step, but the body is
still integrated as a free one, so it moves by \(a\,\Delta t^2/2\)
per step along that component, \(a\) being its acceleration. Such a
control holds the body only as long as the forces on it are nearly balanced;
to impose a motion exactly, make the body a driven one.
Tip
TrackBody and TrackRockfall subtract the imposed force from the
recorded resultant, so that the column holds the force actually transmitted
by the contacts. This is how a wall is used as a force sensor.
Automatic controls: Servo
A Servo recomputes the values of its controls at every time step, from the
current state of the sample. It is the way to impose a stress rather than a
force, since the force to apply depends on the current area of the wall.
Servo <name> <parameters>
Warning
Only one servo can be active: the servo function is a single callback,
so the last Servo entry read replaces any previous one. Several
Control entries, on the other hand, coexist without any problem.
The available servos are described in Available servo-controllers.
Driving a periodic cell
When Rockable is compiled with ROCKABLE_ENABLE_PERIODIC, the same file also
drives the periodic cell, through the PeriodicLoading keyword. There are no
walls in that case, and the loading is applied to the cell matrix itself. See
Periodic boundary conditions.
A worked example: a box of six walls
The most common setup is a cuboidal box whose six walls are the first six
bodies. With generator, the walls are produced by
generatePacking:wallBox, which emits them in the order
0: Xmin 1: Xmax 2: Ymin 3: Ymax 4: Zmin 5: Zmax
Fixed box, particles simply poured in:
# no file needed: the 6 walls do not move
Oedometric compression, the top wall coming down at a constant velocity:
Control _y_Vel_ 3 -0.01
Same, but pushing with a constant force instead:
Control _y_For_ 3 -1000.0
Isotropic compression at a controlled pressure, which requires a servo because the force must follow the changing wall areas:
Servo tritriIsostaticCompression 0 1 2 3 4 5
1000