NormalShearInteraction::{normalForce,shearForce} has undefined orientation

Bug #493102 reported by Václav Šmilauer
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Yade
Won't Fix
High
Unassigned

Bug Description

NormalShearInteraction::{normalForce,shearForce} should contain forces on the interaction, which can be used for various purposes by other functions. However, different functors use them with different sign

ef2_Spheres_Elastic_ElasticLaw (a.k.a. ElasticContactLaw):

   applyForceAtContactPoint(-currentContactPhysics->normalForce-shearForce, ... )

Law2_Dem3DofGeom_CpmPhys_Cpm:

   applyForceAtContactPoint(BC->normalForce+BC->shearForce, ...)

This is a convention issue, but must be fixed. Should normalForce and shearForce be oriented as it applies on id1 (first case) or id2 (second case)? 2nd case is nicer WRT applyForceAtContactPoint syntax, but that one is arbitrary as well.

Changed in yade:
importance: Undecided → High
status: New → Confirmed
Revision history for this message
Bruno Chareyre (bruno-chareyre) wrote :

If the normal is b1->b2, it makes more sense to define the force as "applied by b1on b2". My two cents...

Revision history for this message
Bruno Chareyre (bruno-chareyre) wrote : Re: [Yade-dev] [Bug 493102] [NEW] NormalShearInteraction::{normalForce, shearForce} has undefined orientation

Huh? We don't receive mails when the comment is typed from inside
launchpad website?

If the normal is b1->b2, it makes more sense to define the force as
"applied by b1 on b2".

Bruno

Václav Šmilauer a écrit :
> <pre wrap>Public bug reported:
>
> NormalShearInteraction::{normalForce,shearForce} should contain forces
> on the interaction, which can be used for various purposes by other
> functions. However, different functors use them with different sign
>
> ef2_Spheres_Elastic_ElasticLaw (a.k.a. ElasticContactLaw):
>
> applyForceAtContactPoint(-currentContactPhysics-&gt;normalForce-
> shearForce, ... )
>
> Law2_Dem3DofGeom_CpmPhys_Cpm:
>
> applyForceAtContactPoint(BC-&gt;normalForce+BC-&gt;shearForce, ...)
>
> This is a convention issue, but must be fixed. Should normalForce and
> shearForce be oriented as it applies on id1 (first case) or id2 (second
> case)? 2nd case is nicer WRT applyForceAtContactPoint syntax, but that
> one is arbitrary as well.
>
> ** Affects: yade
> Importance: High
> Status: Confirmed
>
> ** Changed in: yade
> Importance: Undecided =&gt; High
>
> ** Changed in: yade
> Status: New =&gt; Confirmed
>
> </pre></body>
> </html>
> </html>

--

_______________
Chareyre Bruno
Maître de Conférences

Grenoble INP
Laboratoire 3SR - bureau E145
BP 53 - 38041, Grenoble cedex 9 - France
Tél : 33 4 56 52 86 21
Fax : 33 4 76 82 70 43
________________

Revision history for this message
Václav Šmilauer (eudoxos) wrote :

OTOH, if force is as applied on b2, then force ⋅ normal is positive when it is pressure (which is conventionally negative, at least in mechanics I know; IIRC geotechnicians use + for pressure, but the is not consistent with elasticity theory I think).

Revision history for this message
Bruno Chareyre (bruno-chareyre) wrote : Re: [Yade-dev] [Bug 493102] Re: NormalShearInteraction::{normalForce, shearForce} has undefined orientation

You are right on the "geotechnical" sign convention. But don't worry, it
is consistent with elasticity (you just replace outward normals by
inward normals everywhere in the theory). I prefer to keep the most
common convention though, with positive tensile stress/strain. I just
didn't realize this sign convention could be applied to forces.
It is still really non-intuitive for me, but I'm just one.
At least Janek or Olivier got the same intuition than me apparently...

Revision history for this message
Václav Šmilauer (eudoxos) wrote :

Discussed in this thread: http://<email address hidden>/msg01285.html

Revision history for this message
Chiara Modenese (chiara-modenese) wrote :

In Classical Mechanics the convention is compression negative and tension positive. However, in Contact Mechanics (see Hertzian theory as well as Johnsons et al.) the convention holds a positive sign for compression and a negative one for tension (e.g. adhesion normal force is negative whether presents). I would warmly suggest to follow the latter convention, hence as positive the force applied by b1 on b2 if normal is b1->b2.

Revision history for this message
Václav Šmilauer (eudoxos) wrote :

OK, my list of weird people has 2 items now:

* gomechanicians
* contact law freaks

Seriously, though (and with all due respect), for me the reference is continuum mechanics; in structural engineering (presumably in mechanical engineering as well), in FEM etc etc, outer normal is used, leading to tension having positive sign. I am happy I already persuaded Bruno.

For ht work to be done on this: since the ScGeom-based laws use shearForce in the incremental formulation, all the increments must have signs changed. I think it doesn't need more than a few hours of attentive code walkthrough (by someone who is familiar with the code) and some testing.

Revision history for this message
Bruno Chareyre (bruno-chareyre) wrote :

> OK, my list of weird people has 2 items now:
>
> * gomechanicians
> * contact law freaks
>
>
Haha!
I fell like a contact law freak more than a geomechanician. The contact
law freak asks Vaclav : what the hell continuum mechanics as to do with
interactions in multibody systems? ;)

There are two different logics and I think both of them are right.
Vaclav convinced me that there was a consistent reason for his sign
convention. However, he didn't persuaded me that his logic was more
intuitive (read post #4).
The alternative is :
1. We want the same signs as in continuum mechanics for
tension/compression. As a consequence, we need to define the shear force
as applied by b2 on b1 (right?).
2. We use the convention that an interaction is "from 1 to 2", which
apply for the definition of the normal as well as for contact forces,
which represent forces applied by b1 on b2, defined in the global
coordinate system.

In logic 2, there is no inward or outward normal. The sign of fn in
traction is the (unfortunate) consequence, not the objective. I agree
with Chiara on the fact that logic 2 is at the same time more common,
and more intutive (for the majority, not for Vaclav).

Perhaps make a vote in yade users to evaluate what is the most popular
convention?

Revision history for this message
Václav Šmilauer (eudoxos) wrote :

> what the hell continuum mechanics as to do with interactions in multibody systems?
They happen to be computed by the same program of which I happen to be the main dev currently. Voting about such things is really a bad idea.

Branch contact+geomechanics yade version where you make everything the inverse, if you like; if not, we need to keep one background for everything, and there continuum mechanics is what seems more established to me.

You can add ass well an alternative #3, that interaction is "from 2 to 1"...

Revision history for this message
Bruno Chareyre (bruno-chareyre) wrote :

Vaclav, I was just sarcasticaly playing the role of the contact law freak. Horrible idea apparently.

Speaking seriously then :

You didn't get the implicit in the sarcasm. In my vision, your model belongs to the family of "multibody systems" even if interactions reflect the microscale behaviour of a continuum (which perhaps makes it somehow hybrid). Did I criticize that once? I remember writing it was consistent.

#3 Is not an option. It would make the current normal inward, which both of us dislike.

For sign convention, I observe the former devs choosed the one that was usual in DEM litterature (Trubal, PFC, SDEC, Cundall, Thornton, etc.). When you started working with yade, you decided to change this convention in your code, and now you think it should apply for everybody else's code.
If you make it a casus belli, I'll not oppose. Changing signs everywhere in my code is a very cheap due for what the main dev's achieved. And if one ask me why this unusual sign convention in Yade, I'll say it's been inspired by you, while you were deeply rationalizing continuum-discrete modelling.

Cheers.

Revision history for this message
Václav Šmilauer (eudoxos) wrote :

Marking wontfix as no-one cares enough to put some work in it.

Changed in yade:
status: Confirmed → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.