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

On Friday, July 3, 2026 at 9:06:01 PM UTC+8 [email protected] wrote:

> 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
>
> Le vendredi 3 juillet 2026 à 14:29:21 UTC+2, Ruochun Zhang a écrit :
>
>> 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
>>
>> On Friday, July 3, 2026 at 8:21:19 PM UTC+8 Radu Serban wrote:
>>
>>> 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
>>>
>>>  
>>>
>>> *From:* 'Mariusz Warzecha' via ProjectChrono <[email protected]> 
>>>
>>> *Sent:* Friday, July 3, 2026 12:08 PM
>>> *To:* ProjectChrono <[email protected]>
>>> *Subject:* [chrono] Re: Hertz Contact Patch and Curvature Information 
>>> in Chrono
>>>
>>>  
>>>
>>> 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
>>>
>>>  
>>>
>>> poniedziałek, 1 czerwca 2026 o 19:26:28 UTC+2 [email protected] 
>>> napisał(a):
>>>
>>> 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.
>>>
>>>  
>>>
>>> -- 
>>> 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 [email protected].
>>> To view this discussion visit 
>>> https://groups.google.com/d/msgid/projectchrono/2b7ff7df-8768-4e6a-a47f-9727a05770b5n%40googlegroups.com
>>>  
>>> <https://urldefense.com/v3/__https:/groups.google.com/d/msgid/projectchrono/2b7ff7df-8768-4e6a-a47f-9727a05770b5n*40googlegroups.com?utm_medium=email&utm_source=footer__;JQ!!Mak6IKo!P5VoHofvMWYqTCynQW4ZBLM3ZrA0QOlN_UdAHrrgQh7rly8FWmT_gpJ54h3-BFuNXs84yxQDJM-KT00nSS9VSwxZ2uI$>
>>> .
>>>
>>

-- 
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 [email protected].
To view this discussion visit 
https://groups.google.com/d/msgid/projectchrono/73ec1962-d196-4087-bdbb-4c53f72acf6fn%40googlegroups.com.

Reply via email to