Velocity cap

Zilong Qiu

Hi all,

There is a 'particle limits' option in the EDEM 'creator pannel'. It seems that the limits will apply to all particles.

Is there any way to apply this limitation to a certain part particles according to their IDs through API? 

 

Thank you for your kind help!

Regards,

Zilong

 

RWood

Hi,

Within the API you can do this, yes. In the particle body force API, you get access to a particle's ID through particle.ID. From there, you can perform whatever checks you require to only apply a body force to a subset of the particle IDs.

It gets a little bit more complicated because in the API you can't set particle velocities directly, you will need to calculate the force that results in the velocity you require and apply that through the results.force.set() methods.

Richard

Zilong Qiu

Hey Richard,

 

Thank you for your quick reply and suggestions!

I have tried to apply an external force to the particle from the particle body force API. However, it is hard to find a proper force to use.

For example, I would like to keep a particle's velocity to zero, no matter how much the external force on it. Because the external force keeps changing, what I have done is try to decelerate the particle's velocity to zero within a timestep. However, this approach doesn't work well.

Do you have any ideas to find a proper force on the particles to control their velocity?

 

Regards,

Zilong

RWood

Zilong Qiu said:

Hey Richard,

 

Thank you for your quick reply and suggestions!

I have tried to apply an external force to the particle from the particle body force API. However, it is hard to find a proper force to use.

For example, I would like to keep a particle's velocity to zero, no matter how much the external force on it. Because the external force keeps changing, what I have done is try to decelerate the particle's velocity to zero within a timestep. However, this approach doesn't work well.

Do you have any ideas to find a proper force on the particles to control their velocity?

 

Regards,

Zilong

Have a look at this post, I think it's what you are after:

https://community.altair.com/community?id=community_question&sys_id=3729fb461b548d94507ca6442a4bcbf9&view_source=searchResult

Richard

Zilong Qiu

Richard Wood_20774 said:

Have a look at this post, I think it's what you are after:

https://community.altair.com/community?id=community_question&sys_id=3729fb461b548d94507ca6442a4bcbf9&view_source=searchResult

Richard

Hello Richard,

 

I have tried the method mentioned in that post.

Indeed, the particle velocity can be constrained in a small range if the external force or the time step is small.

In that method, the applied force for deacceleration depends on the particle velocity at the previous timestep. Therefore, the particle will always move a distance (0.5*external force* timestep*timestep) in the next timestep after the velocity decreases to zero. For large external forces or timesteps, this method will not work anymore.

I am wondering if there is another way to try.

 

Regards,

 Zilong

 

 

 

RWood

Zilong Qiu said:

Hello Richard,

 

I have tried the method mentioned in that post.

Indeed, the particle velocity can be constrained in a small range if the external force or the time step is small.

In that method, the applied force for deacceleration depends on the particle velocity at the previous timestep. Therefore, the particle will always move a distance (0.5*external force* timestep*timestep) in the next timestep after the velocity decreases to zero. For large external forces or timesteps, this method will not work anymore.

I am wondering if there is another way to try.

 

Regards,

 Zilong

 

 

 

The force currently acting on a particle for the current timestep is accessible by results.force(). I'm fairly certain that this contains the force coming from in-built contact models from the current timestep too. PBF models are called last, therefore, as long as you subtract the current force component at that timestep as well, there shouldn't be any resultant force acting on the particle.

So something along the lines of:

results.force.setx(-results.force.getx() - particle.mass* particle.velocity.getX() / timeStepData.timeStep)

for the three components should handle that... I think. 

Richard

Zilong Qiu

Richard Wood_20774 said:

The force currently acting on a particle for the current timestep is accessible by results.force(). I'm fairly certain that this contains the force coming from in-built contact models from the current timestep too. PBF models are called last, therefore, as long as you subtract the current force component at that timestep as well, there shouldn't be any resultant force acting on the particle.

So something along the lines of:

results.force.setx(-results.force.getx() - particle.mass* particle.velocity.getX() / timeStepData.timeStep)

for the three components should handle that... I think. 

Richard

I used ParticleBodyForce API, version 2_3_0.

In this version, there is no 'results.force.setx' method. Instead, I used 'calculatedForceX' and 'velX' in the calculation.

Could this be the reason for the failed try?

 

If it is, could you send me a link to the example of the new version ParticleBodyForce API?

 

Thank you very much for your help in advance!

 

Regards,

Zilong

 

 

 

Zilong Qiu

Richard Wood_20774 said:

The force currently acting on a particle for the current timestep is accessible by results.force(). I'm fairly certain that this contains the force coming from in-built contact models from the current timestep too. PBF models are called last, therefore, as long as you subtract the current force component at that timestep as well, there shouldn't be any resultant force acting on the particle.

So something along the lines of:

results.force.setx(-results.force.getx() - particle.mass* particle.velocity.getX() / timeStepData.timeStep)

for the three components should handle that... I think. 

Richard

Hello Richard,

 

I have managed to add a particle body force to a free-falling particle under gravity through

  results.force.setX(-results.force.getX() - particle.mass * particle.velocity.getX() / timeStepData.timeStep);
results.force.setY(-results.force.getY() - particle.mass * particle.velocity.getY() / timeStepData.timeStep);
results.force.setZ(-results.force.getZ() - particle.mass * particle.velocity.getZ() / timeStepData.timeStep);

The particle seems to stop moving when the timestep is 5e-7s. but moving 'fast' when increasing the timestep to 1e-4.

I also tried to immobilize particles when doing the one-way fluid coupling throng Particle body force plugin. The mentioned method doesn't work as well.

 

As you mentioned, the results.force() may contain the force from the contact model. However, the force from noncontact, e.g., gravity or force from fluid when doing the two-way coupling, doesn't take into account.

 

Best regards,

Zilong

 

 

RWood

Zilong Qiu said:

Hello Richard,

 

I have managed to add a particle body force to a free-falling particle under gravity through

  results.force.setX(-results.force.getX() - particle.mass * particle.velocity.getX() / timeStepData.timeStep);
results.force.setY(-results.force.getY() - particle.mass * particle.velocity.getY() / timeStepData.timeStep);
results.force.setZ(-results.force.getZ() - particle.mass * particle.velocity.getZ() / timeStepData.timeStep);

The particle seems to stop moving when the timestep is 5e-7s. but moving 'fast' when increasing the timestep to 1e-4.

I also tried to immobilize particles when doing the one-way fluid coupling throng Particle body force plugin. The mentioned method doesn't work as well.

 

As you mentioned, the results.force() may contain the force from the contact model. However, the force from noncontact, e.g., gravity or force from fluid when doing the two-way coupling, doesn't take into account.

 

Best regards,

Zilong

 

 

API plugin PBF models are the last thing to be called when it comes to forces, so if you know the gravitational force then you can take that into account as well.  In most scenarios that'll be as simple as reading the value from the GUI and hardcoding it. If you have a moving gravity vector, say with the coupling interface, then it might get a bit trickier.

I'm not sure why the timestep would make a difference though.

Richard

Zilong Qiu

Richard Wood_20774 said:

API plugin PBF models are the last thing to be called when it comes to forces, so if you know the gravitational force then you can take that into account as well.  In most scenarios that'll be as simple as reading the value from the GUI and hardcoding it. If you have a moving gravity vector, say with the coupling interface, then it might get a bit trickier.

I'm not sure why the timestep would make a difference though.

Richard

Hello Richard,

 

Thank you very much for your answer!

yes, gravity is easy to be handled. However, when doing the FLUENT-EDEM two-way coupling. The 'particle body force' of the drag force will play an important role. And the mentioned method may be failed to freeze particles.

 

As far as I know, the purpose of the 'results.force.set' method is to deaccelerate particles to zero. For an isolated particle with a zero velocity, principally, the 'results.force.set' method will do nothing. At this moment, if a fluid passes by the particle fast. The drag force will accelerate the particle, and the distance it moves in the next timestep depends on the square of the timestep. 

So, for the situation of an unknown particle body force, it will be hard to immobilize particles by using the 'results.force.set' method. And it becomes more complex if we have to play with the coupling interface before it is compiled (not many documents can be referred to).

 

Regards,

Zilong