Forming an unbreakable multiphere entity from individual particles, using EDEM API contact model.

MQ

Hi everyone,

I would please need your advise/pointers in implementing a cohesive contact model, using EDEM API. Or perhaps any alternative suggestion(s) to acheive this:

Context:

The idea is when the two (or more) particles come into contact with eachother, a normal user-defined force (under a condition) is applied between them. After a certain amount of overlap (i.e. half way through), they should become one unbreakable entity like a multisphere, even if that condition is removed afterwards. Any general contact model (such as HM or linear-spring) should act on the multisphere as a whole.

User-defined force and problem:

Under the user-defined force, after the overlap is halfway through, I apply a stopping force to bring their relative velocities to zero, and then the linear cohesion V2 (LCV2) model. However, the particles keep sinking into each other. And if HM is applied in combination with LCV2 the particles get repelled. Secondly, when particles are stacked, the further effect of gravity cause the top particle to sink.

Thank you.

Best regards,

MQ

RWood

Hi,

Sounds tricky, though it should be doable, with the right physics implemented.

My initial thought would be could you not remove the two individual particles using the particle manager (markForRemoval) and then inject a new particle that has the two spheres already defined as a multisphere?

If you've got a lot of contacts then this might not be feasible though as ensuring an exact repositioning would be almost impossible.

Richard

MQ

Hi Richards,

Thanks for you response. Actually there could be complete chain of particles, that become kind of bonded with their neighbouring particle, but the only difference being that the overlap is to be halfway through.

Secondly, the overall powder bed would mostly remain static, except for the selected particles that move slightly to overlap and form a bond.

Could there be anyway to use a bonded particles model, rather than LCV2 in this scenario?

MQ

jpmorr

Most likely what you want to do is do bond the particles together when your trigger criterion is met instead of using a bonding time, but to use an infinitely high bond strength that will not break or deform. You could also implement this as a bond that will not break but that allows large deformation, much like a piece of dough being pulled. 

However, there is a strong caveat to doing something like this - Large overlaps should be avoided in DEM. DEM was developed for dealing with small deformations, around the 1-2% of overlap. Physics models like Hertz-Mindlin will not be giving the correct answer for large deformation behaviour as they were developed for elastic, hard spheres. Coupling HM at 40-50% overlap as proposed will lead to massive forces calculated and huge repellent forces. The linear cohesion model is using contact patch area to calculate a cohesive force and at such large overlaps there will likely be a huge cohesive force counteracting the huge HM force, creating a rather difficult numerical stability to maintain. I don't know the specifics of your problem, but if you must have such large overlaps, then you would need to develop an appropriate physics model for such a use case rather than trying to fit models developed for a different regime.

JP

MQ

Hi JP,

Thanks for your response. Just a wild idea in this case, even though I'll have to test this: Do you think introducing a 'virtual offset to overlap' would work, to trick the solver into thinking that offset is only 1 or 2%, regardless of original position of particles?

Something like this:

- A user-defined force brings the particles to 50% overlap, while HM or cohesion is not there.

- Then an offset of 48% or 49% is introduced to a 'variable', and that 'variable' is passed on as an overlap for HM and bond/cohesion calculation.

MQ

jpmorr

MQ said:

Hi JP,

Thanks for your response. Just a wild idea in this case, even though I'll have to test this: Do you think introducing a 'virtual offset to overlap' would work, to trick the solver into thinking that offset is only 1 or 2%, regardless of original position of particles?

Something like this:

- A user-defined force brings the particles to 50% overlap, while HM or cohesion is not there.

- Then an offset of 48% or 49% is introduced to a 'variable', and that 'variable' is passed on as an overlap for HM and bond/cohesion calculation.

MQ

You can very easily do that in the API and it works quite well - it's basically how the Timoshenko Beam Bond Model is implemented - it was developed before the concept of contact and physical radii existed in EDEM!

I would probably suggest that linear spring might be more appropriate than HM, but what you say should work. 

MQ

Thank you again JP and Richard for your quick replies! I'll try this method soon.

MQ

Hi Richard & JP,

Do we have any standard EDEM API code for linear spring available, which I can modify for our discussed model, rather than rewriting from scratch?

I can't seem to find in the Altair forum. It was available in the previous edemsimulation form, as I remember, but didn't download it at that time!

MQ

jpmorr

MQ said:

Hi Richard & JP,

Do we have any standard EDEM API code for linear spring available, which I can modify for our discussed model, rather than rewriting from scratch?

I can't seem to find in the Altair forum. It was available in the previous edemsimulation form, as I remember, but didn't download it at that time!

MQ

There are many example contact models here and linear spring is probably one of them. I think they are all in the script & model library section but I can never find them anymore!

Someone from Altair EDEM will know the exact locations!

JP

RWood

MQ said:

Hi Richard & JP,

Do we have any standard EDEM API code for linear spring available, which I can modify for our discussed model, rather than rewriting from scratch?

I can't seem to find in the Altair forum. It was available in the previous edemsimulation form, as I remember, but didn't download it at that time!

MQ

I had a quick look on the Community site and I can't see it either.

I've attached the only version I can find, but it's not exactly in great shape. I had to change it to a .txt file to upload it. This is using version 1.1 (that's not a typo) of the API. Bear in mind we're currently on version 3.3. The core of the calculateForce() function should still be of use, but any namespaces, classes, macros, etc. specific to EDEM will likely be completely different. 

I'll make a note internally to update it but in the mean time you'll have to do it yourself, unfortunately.

Richard

MQ

Richard Wood_20774 said:

I had a quick look on the Community site and I can't see it either.

I've attached the only version I can find, but it's not exactly in great shape. I had to change it to a .txt file to upload it. This is using version 1.1 (that's not a typo) of the API. Bear in mind we're currently on version 3.3. The core of the calculateForce() function should still be of use, but any namespaces, classes, macros, etc. specific to EDEM will likely be completely different. 

I'll make a note internally to update it but in the mean time you'll have to do it yourself, unfortunately.

Richard

Thank you Richard! Still much better than starting from scratch.