Apply a force on a wall

JF's picture
Submitted by JF on Fri, 04/12/2013 - 15:46


I am discovering a very interesting function "mesh/surface/stress/servo" which enables to apply a force on a wall.

fix servo all mesh/surface/stress/servo file plate.stl type 1 com 0. 0. 0. ctrlPV force dim z set_point -10 vel_max 1.

First, I would like to know, what is the parameter 'set_point' in your example ?

Then, I would like to apply a force (10N) on two walls (top and bottom) to perform a compression test in the Z-direction.

#========= Script =============
fix topwall all mesh/surface/stress/servo file topwall.stl type 3 com 0.004 0.004 0.01 ctrlPV force target_val -10 dim z vel_max 1.
fix bottomwall all mesh/surface/stress/servo file bottomwall.stl type 3 com 0.004 0.004 0.00 ctrlPV force target_val 10 dim z vel_max 1.
fix wall all wall/gran/hertz/history mesh n_meshes 2 meshes topwall bottomwall

My problem is the top wall doesn't move and the bottom wall moves away.

Please can you give me some advice to fix this problem.

Thanks in advance.

PS: I have chosen the centre of mass as the center of the wall which is constituted by two triangles

cstoltz | Fri, 04/12/2013 - 17:07

I think the 'set point' is a typo and should have been 'target_val'. Your syntax looks correct to me. Two suggestions to help w/ potential debugging:

1) Try to reverse the order of the two fixes. If you do this and only the topwall moves, then I assume it will only accept one servo statement and is just accepting the last one entered. There used to be a similar limitation when applying moves to meshed geometries. No idea if that is going on here or not.

2) Try to reverse the direction of the normal vectors for your geometry. Again, no idea if this will do anything. Am wondering if it is somehow using the normal vectors to control the motion and if yours are pointing in the wrong direction, the bottom plate will go the wrong direction.


JF's picture

JF | Fri, 04/12/2013 - 20:00

Hi Chris,

Thank you for your prompt reply. I will try your suggestions.


ckloss's picture

ckloss | Fri, 04/19/2013 - 15:50

Hi JF and Chris,

I just found out that 'set_point' was used in the examples section of the fix mesh/surface/stress doc, I'll correct this.
If it still doesn't move, I can have a look


AGl | Tue, 04/30/2013 - 12:54

I confirm, it does not work as awaited.

jtvanlew | Tue, 04/30/2013 - 21:31

could it simply be that 10N is lower than the weight of the pebble bed on the bottom wall? The bottom wall might be moving down to try and relieve that force but it's constantly being chased by the pebbles who keep pushing it lower. If you upped it to like 1kN, does it still happen?

I've successfully done some z-compression tests but only with a servo wall on the top. You can change the target_val during the simulation and have it compress-decompress-compress... in cycles. It's a pretty nice new feature -- we were limited only to strain-driven simulations before this.


ckloss's picture

ckloss | Thu, 05/02/2013 - 13:32

On my end it works fine with the latest version. If anyone thinks it does not behave as suspected, just post a simple case so that I can reproduce the isssue


aaigner's picture

aaigner | Wed, 05/22/2013 - 16:38

I hope all problems are solved and there is no bug in the code, since I implemented the code. :-)

Some remarks to the example with two plates:

  • It is quite strange that the upper wall doesn't move at all. Do you use the latest version of liggghts?
  • Both walls work with 10N against each other. Then the bottom wall with move back since 10N(top)+particle weight > 10N (bottom)
  • aaigner's picture

    aaigner | Wed, 05/22/2013 - 22:16

    Sry.. I have to correct myself.
    The walls won't move if large surfaces (walls) are present, on which the particles can be supported. This also requires a sufficiently high particle-wall coefficient of friction.

    In any case, this does not explain why the upper wall does not move.
    To debug your case you can dump the wall position and the force and torque acting on it.

    aaigner's picture

    aaigner | Wed, 07/24/2013 - 14:07

    Today I have found a logic bug in the servo wall that may explain the strange behaviour of your test case.

    Servo wall should work fine for negative target_val (shear cells for example), but may fail with positive values. The bug fix should be included in the next release.

    If you need the correction now, don't hesitate to write me an email.