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://
The most promising setup for me was to combine the rot_compress.py from the tutorial with the suggestions in question 84821 (https:/
My script can be downloaded here http://
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.
Thanks in advance!
Best regards, Christian
Question information
- Language:
- English Edit question
- Status:
- Solved
- Assignee:
- No assignee Edit question
- Solved by:
- Dion Weatherley
- Solved:
- Last query:
- Last reply:
Revision history for this message
|
#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.
I hope these comments help.
Cheers,
Dion.
Revision history for this message
|
#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
|
#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 NRotElasticWall
> 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):
EWallInteractio
BWallInteractio
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
|
#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
|
#5 |
Thanks Dion Weatherley, that solved my question.
Revision history for this message
|
#6 |
Hi all!
One more idea about this test.
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.
One problem can occur described here https:/
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
|
#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
|
#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, applyForceToMes
Thanks for identifying applyForceToMes
Cheers,
Dion.
Revision history for this message
|
#9 |
Hi all,
I would like to shear my humble opinion on applyForceToMes
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 applyForceToMes
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.
_______
Anton Gladkyy
2010/2/11 Dion Weatherley <email address hidden>
> Question #100432 on ESyS-Particle changed:
> https:/
>
> Dion Weatherley posted a new comment:
> 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, applyForceToMes
> 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-
> interim solution.
>
> Thanks for identifying applyForceToMes
> feature of ESyS-Particle.
>
> Cheers,
>
> Dion.
>
> --
> You received this question notification because you are an answer
> contact for ESyS-Particle.
>
Revision history for this message
|
#10 |
Hi Anton,
The idea behind applyForceToMes
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.
In addition to applyForceToMes
I've added blueprints for both applyForceToMes
Cheers,
Dion.
Revision history for this message
|
#11 |
Hi Dion,
I think in this case applyForceToMes
Sorry, I did not get an idea about applying the "resulting force" to the
group of meshes.
Thank you!
_______
Anton Gladkyy
2010/2/11 Dion Weatherley <email address hidden>
> Question #100432 on ESyS-Particle changed:
> https:/
>
> Dion Weatherley posted a new comment:
> Hi Anton,
>
> The idea behind applyForceToMes
> 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 applyForceToWal
> 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.
>
> In addition to applyForceToMes
> 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 applyForceToMes
> applyStressToMe
>
> Cheers,
>
> Dion.
>
> --
> You received this question notification because you are an answer
> contact for ESyS-Particle.
>
Revision history for this message
|
#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 BWallInteractio
From: if(((*iter)
To: if(((*iter)
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_
I modified my python-script a bit, you can find it here: http://
(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 :) )
Thanks a lot for your help and for your suggestions!
Ciao, Christian
Revision history for this message
|
#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
|
#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
|
#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.