Shear cell

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

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.

Hi Dion!

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

Ciao, Christian

Thanks Dion Weatherley, that solved my question.

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://answers.launchpad.net/esys-particle/+question/88887
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.

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

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.

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.
______________________________

Anton Gladkyy

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

> Question #100432 on ESyS-Particle changed:
> https://answers.launchpad.net/esys-particle/+question/100432
>
> 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, 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.
>
> --
> You received this question notification because you are an answer
> contact for ESyS-Particle.
>

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.

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!
______________________________

Anton Gladkyy

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

> Question #100432 on ESyS-Particle changed:
> https://answers.launchpad.net/esys-particle/+question/100432
>
> 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
> 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.
>
> --
> You received this question notification because you are an answer
> contact for ESyS-Particle.
>

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:

From: if(((*iter)->getTag() & m_mask )!=(m_tag & m_mask )){ // only add to elastic if not bonded/tagged

To: if(((*iter)->getTag() & m_mask )==(m_tag & m_mask )){ // only add to elastic if not bonded/tagged

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 :) )

Thanks a lot for your help and for your suggestions!

Ciao, Christian

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.

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.

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.