Hertz Contact Patch and Curvature Information in Chrono

[OUSSAMA EL MOUIAH]

Hello Chrono developers,

I am currently  investigating the use of Hertzian contact within Chrono (SMC).

I have a few questions regarding the contact information available through Chrono:

1. As far as I understand, the Hertz-based contact models implemented in ChSystemSMC provide the normal contact force using the penetration depth and equivalent radius, but they do not provide the actual contact patch dimensions (e.g., semi-axes (a) and (b) of the Hertz ellipse) or the contact area directly. Is this correct, or is there already a way to access this information?

2. In my tests, the collision systems based on Bullet and Multicore seem to provide contact points and normals, but not the principal curvatures (or curvature radii) of the contacting surfaces for arbitrary geometries. From the source code, it appears that Multicore computes equivalent radii only for some primitive shapes (sphere, cylinder, box, etc.), while for general triangle meshes or custom geometries this information is not available.

   Is there any existing module, utility, or ongoing development effort within Chrono aimed at computing local surface curvatures (principal curvature radii) at contact points for arbitrary collision geometries?

Any guidance or suggestions would be greatly appreciated.

Thank you.

[Mariusz Warzecha]

Hi,

Although I am not a Chrono developer, I extensively use various contact models in my work, so here is my take on your questions.

Ad 1.
You are correct. The default contact force models implemented in Chrono are penetration-based. They do not provide the semi-axes of the contact patch or the contact area directly. Nevertheless, you should be able to calculate these quantities from the available contact information, provided that the required geometric parameters are known.

Ad 2.
To the best of my knowledge, no such extension is currently planned. Computing local curvatures for arbitrary geometry would not be an easy task, and the potential benefits would probably not justify the implementation effort in most use cases.

Best regards,

Mariusz Warzecha

[Radu Serban]

Mariusz is correct.

 

However, there is no “default” contact force model in Chrono. You can use either a penetration-based contact force model (aka soft-body approach, or penalty approach) which we call SCM (for Smooth Contact Model) or a complementarity-based approach (aka rigid-body approach) which we call NSC (for NonSmooth Contact model). The choice is made by constructing a Chrono system of type ChSystemSMC or ChSystemNSC, respectively.

 

Both contact force formulations require a collision detection system. Again, while there are two choices (the one from Bullet, modified for use in Chrono, or our “multicore” system), there is no default set on a Chrono system; instead, you have to attach one or the other (via ChSystem:: SetCollisionSystemType or ChSystem:: SetCollisionSystem). 

 

A collision system must provide all geometric information that a particular contact force model might require. Local curvature information could only be used for SCM (NSC does not need it).

• Since Bullet Physics always used a non-smooth contact model, their collision system never had to worry about such information. As such, local curvature is not made available by the collision detection system when using the Bullet version. 
• For the Multicore collision system where we use analytical geometric processing for simple primitive shapes (with fallback to MPR, Minkowski Portal Refinement) during the narrow phase, we provide curvature information where possible.  As Mariusz said, calculating such geometric information for general shapes is either too computationally costly or else questionable (e.g., for triangular meshes). So, where not available, we use some approximations: for example, when one of the colliding objects is a triangular mesh, we use the radius of a “sweeping” sphere which combined with the radius at the contact point of the other object gives the “effective radius” that can be used in an SCM contact formulation.

 

--Radu

--
You received this message because you are subscribed to the Google Groups "ProjectChrono" group.
To unsubscribe from this group and stop receiving emails from it, send an email to projectchron...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/projectchrono/2b7ff7df-8768-4e6a-a47f-9727a05770b5n%40googlegroups.com.

[Ruochun Zhang]

Mariusz,

Just came across this and thanks for your explanation! Very helpful for me and I surmise for the OP as well. I do want to mention that, speaking of "plans" for supporting more detailed contact info like the Hertz ellipse, I do plan to include that, even for mesh--mesh contact, in the next version of Chrono DEM-Engine. Might be useful for some of your use cases too.

Thanks for Radu's detailed explanation as well.

Ruochun

[OUSSAMA EL MOUIAH]

Hi Mariusz, Radu, and Ruochun,

Thank you all very much for your detailed replies.

Mariusz, thank you for confirming my understanding and for your insightful explanation.

Radu, I really appreciate the detailed clarification, Your explanation was very helpful.

Ruochun, Coincidentally, I have recently started developing a Hertzian contact module to compute additional contact quantities that are not currently available in Chrono, such as the contact patch shape (Hertz ellipse) and the pressure distribution. Since our interests seem to overlap, I would be very interested in discussing this further and possibly collaborating if you think it could be useful for the DEM-Engine or related developments.

Thanks again to all of you for your time and valuable explanations.

Best regards,

Oussama ELMOUIAH

[Ruochun Zhang]

Oussama,

Interesting and sure, I'd like to know how you are implementing it and how it could affect the GPU implementation. If you would like to have a meeting to discuss it sometime, feel free to PM me. In any case, I could notify you when DEME's said capability is online and we could also go from there.

Ruochun