CohFrictMat fragile mode does not break interaction

Asked by loiseaurare

Hi everybody !

I am trying to test what exactly do the fragile and plastic mode of CohFrictMat, and for this I have implemented a very simple simulation, appending a fixed sphere, and a second one who is moving the opposite way from initial contact, in order to break the cohesion bond by exceeding the tensile strength limit.

I am plotting Fn versus un displacement, and when I run the simulation using Fragile = False in the simulation I get first elastic increase of fn, and then flat plastic behavior, then the two particles are set apart, and interaction disappears. Which is fine.

However, when I use fragile = True, the same elastic behavior initially occurs, up until the fragile limit, then, at that precise timestep, no interaction is detected by Yade, and then this interaction is reset, with a very high value, and that does not drop to zero until the particles are really apart ( they are still overlapping when the strenght limit is reached, and that is because they are initially overlapping).

So I don't really know what is going on here. Could it be that it is the setting of the equilibrium distance again ? since unp relates to plastic displacement ?

any help would be appreciated !

Here is the script, running already until the strenght limit is reached, pressing run you can see what happens next !

# coding=utf-8
# TEST 8 : Appliance of horizontal disp one ball (rebound)-- > no grav/no coh
# EXPECTED : we want to see breakage of cohesion bond

from __future__ import division
import numpy as np
from yade import plot,pack,timing
from pprint import pprint

# DATA COMPONENTS

nb_iter = 1

# INPUTS
# Geometry
RSph = 0.1
CoeffSph = 0.9
Pos1 = (RSph*CoeffSph,RSph,0.)
Pos2 = (-RSph*CoeffSph,RSph,0.)

# Material
EyCohFrictMat = 1e7
poissonCohFrictMat = 0.25
densityCohFrictMat = 2600.
FrictAngSphere = 30.*pi/180.
NCohesionCohFrictMat = 30000
SCohesionCohFrictMat = 30000

# Calculation
damp=0.5
gz=0.
SphereVel= (-1.5,0.,0.)

#EXPORTATION

#création des différentes listes de forces

lisForce = []
lisForN = []
lisForSh = []
lisTime = []

################################################################################"
# SIMULATION BEGINNING - SIMULATION BEGINNING - SIMULATION BEGINNING

## CREATE MATERIAL - CREATE MATERIAL - CREATE MATERIAL

O.materials.append(
  CohFrictMat(
  young = EyCohFrictMat,
  poisson= poissonCohFrictMat,
  density= densityCohFrictMat ,
  frictionAngle = FrictAngSphere,
  normalCohesion = NCohesionCohFrictMat ,
  shearCohesion = SCohesionCohFrictMat ,
  fragile = True,
  momentRotationLaw=True,
  etaRoll=0.1,
  etaTwist=-1,
  alphaKr=0.,
  alphaKtw=0.,
  isCohesive = True,
  label='MatSpheres'))

## CREATE SPHERES - CREATE SPHERES - CREATE SPHERES -

# they could use the default material (utils.defaultMat)
O.bodies.append([
   # fixed: particle's position in space will not change
   sphere(center=Pos1,radius= RSph,fixed=True, material ='MatSpheres'),
   # this particles is free, subject to dynamics
   sphere(Pos2,RSph, material ='MatSpheres')
])

setBodyVelocity(1,SphereVel, 'xyz')

## FUNCTIONAL COMPONENTS - FUNCTIONAL COMPONENTS - FUNCTIONAL COMPONENTS -

O.engines=[

   ForceResetter(),
   InsertionSortCollider([Bo1_Sphere_Aabb()]),
   InteractionLoop(
      [Ig2_Sphere_Sphere_ScGeom6D(interactionDetectionFactor=1.5,label='ss2sc')], # collision geometry
      [Ip2_CohFrictMat_CohFrictMat_CohFrictPhys(setCohesionNow = True)], # collision "physics"
      [Law2_ScGeom6D_CohFrictPhys_CohesionMoment(useIncrementalForm = True)] # contact law -- apply forces
   ),
    #Apply gravity force to particles. damping: numerical dissipation of energy.
   NewtonIntegrator(gravity=(0.,0.,gz)),
   PyRunner(command='addPlotData()',iterPeriod=1, dead= True, label = 'dataPlot')

]

def setEquilibrium():
 O.dt = 0.
 O.step()

 for i in O.interactions :
   i.phys.unp = i.geom.penetrationDepth

 O.step()

 dataPlot.dead = False
 ss2sc.interactionDetectionFactor=1. # now reset the interaction radius and go ahead

 O.dt=5e-4*PWaveTimeStep()

def addPlotData():
 yade.plot.addData({'t':O.time,'i':O.iter,'Fn':O.interactions[0,1].phys.normalForce[0] ,'Fs':O.interactions[0,1].phys.shearForce[0], 'un':SphereVel[0]*O.time
   })
 #pprint (plot.data)

setEquilibrium()

plot.plots={'un':('Fn')}
plot.plot()

O.run(250,True)

yade.qt.Controller(), yade.qt.View()

cheers,
Manon

Question information

Language:
English Edit question
Status:
Answered
For:
Yade Edit question
Assignee:
No assignee Edit question
Last query:
Last reply:
Revision history for this message
Bruno Chareyre (bruno-chareyre) said :
#1

Hello,
I think what you find is mainly a flaw of this whole "initially overlapping particles" concept, yet it also suggests a small change in the code.

What you get is logical from an algorithmic point of view (interaction broken, then reset with unp=0), yet not logical from a physical point of view.
You could say: "ok, let's just keep the zero force until there is no overlap". It can be implemented easily and it would certainly improve the situation, I can do it if you like.
However, if the contact is created again after the reset, it will be fresh and the equilibrium overlap will be zero. Which means that some volume is created overall.
Conversely, the interaction will not be reset if the bond breakage is followed by a large rolling motion (while continuously overlapping).
I don't see the rational behind the fact that moving apart is resetting the equilibrium distance while rotating is not. It should be the opposite in my view: if the surface of the grain is locally flat translating it back and forth keeps the flatness unchanged in the contact region; rotating is changing it.

Anyway, again, if there is an agreement on what the physical assumptions should be implementing them is easy.
My suggestion is to maintain fn=0 until the overlap disappears.

Bruno

Revision history for this message
Janek Kozicki (cosurgi) said :
#2

I keep a close eye on this. And this weekend I'll definitely start working on https://answers.launchpad.net/yade/+question/619109

I was also wondering what to do then particles move away using the initial overlap. I suppose that the safe option is a "user choice" and implement several possible scenarios.

Revision history for this message
loiseaurare (loiseaurare) said :
#3

Hi Bruno and Janek,

Thanks for your answers, somehow I had come to the same conclusion. Now, what happens is exactly as you describe it, there is bond breakage when the strength limit is reached, and at the next step, contact is reset, but in a frictional way, with effectively unp set back to zero. That causes instability in a lot of my simulations using the feature fragile = True, because when Fragile = false the interaction Force stays on the strenght limit until the particles are set apart. Now, since this is microscale behavior, maybe I could achieve in doing what I want using microscale platic behavior, and calibrating it that way. However, I still feel it is physically more correct to describe rock behavior as fragile at the micro level ...

To give you more information, I have been testing the sensitivity of this overlapping problem, I was thinking that maybe a very small initial overlap would prevent the "jump" in forces to be too strong, or maybe setting a high value of cohesion would allow the particles to break away before strenght limit could be reached. But I have found that even a very small value of overlap with a high value of cohesion definitively messes the data, and actually usually make the sample explode.

Now, this feature, of keeping fn = 0 until the particles are set apart is what is implemented in jcfPM I think, so that was probably the choice made by Luc Scholtes.
I don't understand it when you say that some volume will be created overall, can you maybe be a little more specific ?

Revision history for this message
Bruno Chareyre (bruno-chareyre) said :
#4

>I don't understand it when you say that some volume will be created overall,

Setting equilibrium distance back to zero means that at equilibrium the particles occupy more space than initially.
B

Revision history for this message
Bruno Chareyre (bruno-chareyre) said :
#5

>the safe option is a "user choice" and implement several possible scenarios.

Yes, best and only choice I guess. That is why I often reply to questions by asking people which model they would like instead of selling/justifying the current ones. It can suggest interesting extensions.
B

Can you help with this problem?

Provide an answer of your own, or ask loiseaurare for more information if necessary.

To post a message you must log in.