# Shear cell

Hi everyone!

I'm trying to simulate a shear cell. What I would like to achieve is that the particles are "caged" by walls (on the top, bottom, front and back) and are then sheared off by the moving walls left and right. A picture of the setup I have drawn can be seen here: http://www.scajugend.w4y.at/drawing.png . But I got no sensible result with that way.

The most promising setup for me was to combine the rot_compress.py from the tutorial with the suggestions in question 84821 (https://answers.launchpad.net/esys-particle/+question/84821) and question 98583 (https://answers.launchpad.net/esys-particle/+question/98583).

My script can be downloaded here http://www.scajugend.w4y.at/shearcell.py together with http://www.scajugend.w4y.at/ServoWall.py . I tried different forces, but I got either no reaction or a compression of the whole block, which left it flat like a pizza. I also tried to change the elastic stiffness of the wall, but then the particles where flying around.

So my question is, if I have understood something wrong in the answers of the question above or if another step is missing, where the walls are defined as permeable for particles for example.

Best regards, Christian

## Question information

Language:
English Edit question
Status:
Solved
For:
ESyS-Particle Edit question
Assignee:
No assignee Edit question
Solved by:
Dion Weatherley
Solved:
Last query:
 Revision history for this message Dion Weatherley (d-weatherley) said on 2010-02-09: #1

Hi Christian,

That's an interesting (but challenging!) setup you are trying to simulate. Unfortunately you face the same problem as Chen in Question #98583. Whilst you can easily use stationary, simple planar walls to cage your particles (top,bottom, front and back), you will not be able to use planar walls left and right. Simple walls are infinite in extents and any particle that touches one of the walls will be repelled from it. As you compress the left and right walls, all of the particles along those edges will be compressed, not half the particles as indicated in your drawing.

My suggestion would be to do two things:

1) Add 4 plates of particles on the left and right of the model. Two of these plates should be made non-dynamic so they will not move at all during the simulation. The other two plates should be bonded to planar walls on the left and right

2) Implement a new tagged particle-wall interaction (or modify the existing one) so that only particles with a specified tag will interact with the wall. Use this interaction for your left and right walls and set the particle tag to be that of your movable plate particles. Then you can use servo walls to apply the desired force to the plates.

Step 1) is easily done with LSMGenGeo. Step 2) requires you to modify the source code of ESyS-Particle. Since both Chen and yourself have expressed a need for this special tagged particle-wall interaction, I'll ask around for any volunteers to implement it (no promises as yet though!).

I think the reason your particles were getting squashed flat like a pizza (or flying everywhere) is because you were essentially compressing particles within a cage that prevented them from moving laterally to accommodate the compressive forces. The particles had nowhere to go except to overlap each other or the surrounding walls. As you continue to compress the particles, the internal forces may eventually be large enough to push particles through the walls and fly away. Changing the stiffness of the walls inhibits that but then the particles have no choice but to overlap each other even more so they end up flat like a pan-cake.

Also, I'm not sure your setup will work as desired for very large loading forces or wall displacements. As the loading plates move inwards, eventually a gap will develop above and behind them. Particles will probably try to escape through those gaps. As long as you are shearing a block of bonded particles until fracture/failure there should not be a problem. The plates will only move a fraction of a particle radius before failure. This setup will not work for shearing unbonded, granular material though.

Cheers,

Dion.

 Revision history for this message Christian Witz (christian-witz) said on 2010-02-10: #2

Hi Dion!

Sorry that I'm replying so late. Thanks for your suggestions! But there are three things I don't really understand (I'm pretty new to particle simulation...):

Why do I need the 2 non-dynamic walls? Isn't then the force pressing against them from the other side (with the "caging" problem)?

What's the difference between the particle tag, which is specified in the NRotBondedWallPrms and the tag you suggest to implement?

If I'm trying to do the modifications by myself, are they nescessary in the InteractionGroup in the createWall or in the applyForceToWall file?

Again, thanks a lot for your answer! Now I understand the behaviour of the program much better. The limitations you mentioned are no problem for my setup. I need only the initial force, when the particles start to move.

Greetings from Austria!

Ciao, Christian

 Revision history for this message Dion Weatherley (d-weatherley) said on 2010-02-10: #3

Hi Christian,

It's quite challenging to answer these questions without a pen and paper to draw diagrams but I'll do my best! ;)

> Why do I need the 2 non-dynamic walls? Isn't then the force pressing against them
> from the other side (with the "caging" problem)?

You need the non-dynamic walls to prevent the particles simply being pushed out of the simulation domain by the wall at the other side of the model. If the particles are not confined, they will simply disappear from the simulation once they move outside the simulation domain. If the total displacement of particles will be very small then this can be avoided and the non-dynamic walls are unnecessary.

> What's the difference between the particle tag, which is specified in the
> NRotBondedWallPrms and the tag you suggest to implement?

The particleTag for NRotBondedWallPrms specifies which particles will be bonded to the wall but other particles (with a different tag) will still be repelled from the wall if they touch it (much like NRotElasticWallPrms). The tag I propose to implement will allow particles without that tag to pass through the wall as though it doesn't exist (i.e. they will not be repelled by the wall when they touch it).

> If I'm trying to do the modifications by myself, are they nescessary in
> the InteractionGroup in the createWall or in the applyForceToWall file?

Unfortunately, to do the modifications you need to change the C++ source code and recompile ESyS-Particle. This change cannot be done in a Python script. The changes would need to be done in (at least) the following files (all in the Model/ subdirectory):

EWallInteraction.hpp
BWallInteraction.hpp

I looked into how to do this a couple days ago and it might be possible to "hard-wire" the changes temporarily to achieve your goal. Just add checks in the calcForces() subroutines that each particle has a particular tag before applying the force. Then just make sure you tag particles correctly in the simulation. It is quick-and-dirty but will solve your problem temporarily. This is definitely not a great solution but if it works... ;)

Cheers,

Dion.

 Revision history for this message Christian Witz (christian-witz) said on 2010-02-10: #4

Hi Dion!

Thanks a lot! I will try the quick and dirty solution and report the changes, if the simulation works.

Ciao, Christian

 Revision history for this message Christian Witz (christian-witz) said on 2010-02-10: #5

Thanks Dion Weatherley, that solved my question.

 Revision history for this message Anton Gladky (gladky-anton) said on 2010-02-11: #6

Hi all!

I think, you can set up 4 non-dynamic walls around your specimen, as Dion suggested to prevent the specimen to "jump" everywhere. But for the "moving walls" you can also use meshes. In the simplest case, you need just 4 triangular meshes to simulate 2 square plates and give them the motion.

For the moment It is difficult to get forces, acting to meshes. But also can be solved.

Hope it will give you some more ideas.

 Revision history for this message Christian Witz (christian-witz) said on 2010-02-11: #7

Hi Anton!

Thanks for the suggestion! I tried that setup too, until I realized that I cannot measure the force on a mesh. If that would be possible, the solution with the mesh would be the easier one. But I think implementing the force measurement is beyond my programming capabilities.

Ciao, Christian

 Revision history for this message Dion Weatherley (d-weatherley) said on 2010-02-11: #8

Hi Christian,

Steffen and I had a discussion about your setup and we agree that the best solution would be to implement a function to apply a specified force to a mesh wall, applyForceToMeshWall(..). I've added this to the ESyS-Particle Blueprints. Given that it will require a pretty in-depth knowledge of the tri-mesh interaction logic to implement, I guess Steffen and I will have to toss a coin to see who does it... ;) Can't promise this will be available for a few months so you might want to consider the tagged-wall-interaction hack I described previously as an interim solution.

Thanks for identifying applyForceToMeshWall(..) as an important missing feature of ESyS-Particle.

Cheers,

Dion.

 Revision history for this message Anton Gladky (gladky-anton) said on 2010-02-11: #9

Hi all,

I would like to shear my humble opinion on applyForceToMeshWall() function.

I think this function will be useful only for planar surfaces like in
Christian's task. But meshes are mostly for complicated forms.

For instance, if we want to simulate a shear test not with the plates, but
with an incisor, it will be impossible to use applyForceToMeshWall, because
all meshes will be under different angles. And, of course, they will have
different acting forces, depending on velocity, angles etc.. If we give to
all these meshes an equal force, we will loose the shape of our incisor. In
this case we just need to use something like MoveTaggedMeshBy and something
for "gathering" force information from tagged meshes to calculate the
resulting force, if we need it.

Thank you.
______________________________

2010/2/11 Dion Weatherley <email address hidden>

> Question #100432 on ESyS-Particle changed:
>
> Dion Weatherley posted a new comment:
> Hi Christian,
>
> best solution would be to implement a function to apply a specified
> force to a mesh wall, applyForceToMeshWall(..). I've added this to the
> ESyS-Particle Blueprints. Given that it will require a pretty in-depth
> knowledge of the tri-mesh interaction logic to implement, I guess
> Steffen and I will have to toss a coin to see who does it... ;) Can't
> promise this will be available for a few months so you might want to
> consider the tagged-wall-interaction hack I described previously as an
> interim solution.
>
> Thanks for identifying applyForceToMeshWall(..) as an important missing
> feature of ESyS-Particle.
>
> Cheers,
>
> Dion.
>
> --
> contact for ESyS-Particle.
>

 Revision history for this message Dion Weatherley (d-weatherley) said on 2010-02-11: #10

Hi Anton,

The idea behind applyForceToMeshWall(..) is to move all nodes by the same amount to achieve a specified net force. The mesh will not deform in this case. I think the incisor example should still work fine because, like applyForceToWall(..) we will resolve the forces acting on the mesh from the particles into the direction parallel to the desired force to ensure that when the whole mesh is moved, that net force is achieved.

I don't think it is necessary to have tagged meshes. You can always import multiple meshes from different files and give each mesh a different name in LsmMpi.readMesh(..).

In addition to applyForceToMeshWall(..), one can imagine a slightly more complicated function in which each triangle of a mesh must support a specified stress. In this case, the nodes of the mesh will be moved individually and the mesh allowed to deform. This is sometimes called a 'membrane' in the literature. This second function would not be useful for Christian's case but highly beneficial if for example, one wanted to do a triaxial test on a cylinder.

I've added blueprints for both applyForceToMeshWall(..) and applyStressToMesh(..).

Cheers,

Dion.

 Revision history for this message Anton Gladky (gladky-anton) said on 2010-02-12: #11

Hi Dion,

I think in this case applyForceToMeshWall() function will be really useful.
Sorry, I did not get an idea about applying the "resulting force" to the
group of meshes.

Thank you!
______________________________

2010/2/11 Dion Weatherley <email address hidden>

> Question #100432 on ESyS-Particle changed:
>
> Dion Weatherley posted a new comment:
> Hi Anton,
>
> The idea behind applyForceToMeshWall(..) is to move all nodes by the
> same amount to achieve a specified net force. The mesh will not deform
> in this case. I think the incisor example should still work fine
> because, like applyForceToWall(..) we will resolve the forces acting on
> the mesh from the particles into the direction parallel to the desired
> force to ensure that when the whole mesh is moved, that net force is
> achieved.
>
> I don't think it is necessary to have tagged meshes. You can always
> import multiple meshes from different files and give each mesh a
>
> In addition to applyForceToMeshWall(..), one can imagine a slightly more
> complicated function in which each triangle of a mesh must support a
> specified stress. In this case, the nodes of the mesh will be moved
> individually and the mesh allowed to deform. This is sometimes called a
> 'membrane' in the literature. This second function would not be useful
> for Christian's case but highly beneficial if for example, one wanted to
> do a triaxial test on a cylinder.
>
> I've added blueprints for both applyForceToMeshWall(..) and
> applyStressToMesh(..).
>
> Cheers,
>
> Dion.
>
> --
> contact for ESyS-Particle.
>

 Revision history for this message Christian Witz (christian-witz) said on 2010-02-15: #12

Hi Dion, hi Anton!

The quick and dirty solution was really quick but not so dirty as it could be. I had to change just one "!" into a "=".
In the file BWallInteractionGroup.hpp in the "Model" subdirectory in line 181:

The "not" in the comment can also be deleted to reflect the changes in the code. The elastic property of the bonded-wall interaction is now limited to particles with the tag specified in the NRotBondedWallPrms.
So (after recompiling) the particles in the slope_friction_floor.py example in the tutorial, which trickle down from the block, fall down into nowhere.

I modified my python-script a bit, you can find it here: http://www.scajugend.w4y.at/shearcell.py Now I have four walls, two of them (one at the top, one at the bottom, both on the right half of the block) move in the same direction at the same velocity. So I prevent particles from falling out the block. Videos of the simulation can be found here: http://www.scajugend.w4y.at/shearcell5.mpg and here: http://www.scajugend.w4y.at/shearcell4.mpg.

(The videos where created with the command ffmpeg -f image2 -i snap_%04d.png shearcell.mpg out of the snap0001.png, ... pictures, just in case someone needs that :) )

Ciao, Christian

 Revision history for this message Anton Gladky (gladky-anton) said on 2010-02-15: #13

Hi Christian!

As for me it is a very clever solution, as it allows you to solve your task.
Sure, it will be useful for somebody. Thanks for a good advice!

Chees, Anton.

 Revision history for this message Anton Gladky (gladky-anton) said on 2010-02-15: #14

Hi Christian!

As for me it is a very clever solution, as it allows you to solve your task.
Sure, it will be useful for somebody. Thanks for a good advice!

Cheers, Anton.

 Revision history for this message Dion Weatherley (d-weatherley) said on 2010-02-15: #15

Hi Christian,

That's a nice hack. As you say, not as dirty as it could be. This nice thing is that the change is so easy. If you want to upgrade to a newer development version it won't be too hard to incorporate your change.

I had a look at your movies. Looks like you are getting close to a workable setup. One thing though, a few particles appear to be flying around or getting shot out of the assembly. This is sometimes evidence that your timestep increment is a bit too large. You might try reducing it by a factor of 5 or 10 and re-run the simulation just to check. The simulation may be slightly numerically unstable at the moment.

Have fun!

Dion.