# Clarifications regarding ice and IcePhys models

+1 vote
172 views
asked Jun 8, 2015
Hi all,

I am an ex-Yade user who has just begun developing new projects using Woo, most of which involve the ice model and IcePhys functor. I have a few general queries regarding the mechanics of bonding under the ice model.

1. I noticed, during a reversed-gravity test, that if IcePhys bonding is enabled ("bonds1"=15), bonds will form between Spheres and Walls, not just between pairs of Spheres. Is there any means of turning off automatic bond creation between spheres and walls on contact? Would changing the material of the walls to something other than ice accomplish this?

2(a). Is it possible to set up the Woo 3D View (or the Display pane) such that bonds are explicitly shown on the screen (e.g., by lines) while other contacts are NOT shown? In other words, is it possible to get a visual representation only of bonded contacts?

2(b). Would such bonds-only visualization be possible in ParaView if we exported our data to that program?

3(a). What is the precise effect of the damping coefficient "damping", which is defined in (I believe) the "Leapfrog" integrator? There are some circumstances in which it appears to not produce any damping at all. The most notable of these occurs when a particle is in free-fall and lands on a surface: it will rebound (bounce) to the full height from which it was originally dropped, with no inelasticity whatsoever. This occurs despite my "damping" coefficient being set to 0.5.

3(b). Is there a means of introducing hysteretic damping?

Cheers,
Christopher Stanbridge
commented Jun 10, 2015 by (49,030 points)

one more thing: for hysteretic damping, there must be some hysteretic loop, i.e. changing tangent stiffness, where cyclic loading delimits a non-zero area (dissipated energy) in the strain-stress diagram. Viscous damping might be more suitable since stiffness is constant (brittle breakage).

answered Jun 8, 2015 by (49,030 points)
selected Jun 10, 2015

Hi Christopher, thanks for baptizing the new forum with your question :)

1. I noticed, during a reversed-gravity test, that if IcePhys bonding is enabled ("bonds1"=15), bonds will form between Spheres and Walls, not just between pairs of Spheres. Is there any means of turning off automatic bond creation between spheres and walls on contact? Would changing the material of the walls to something other than ice accomplish this?

This is not directly possible. If you need to have different bonds between different groups of particles handled differently, we can introduce some switching based on either particle's mask, or perhaps based on Material instances of which couples would be handled using MatchMaker (this is a sort-of forgotten framework for handling such things, e.g. when different material combinations required different friction coefficients). If this is what you need, then let me think about the most elegant way to do it. We always want to extend the functionality in ways which are useful for other cases, and don't complicate other things overly.

2(a). Is it possible to set up the Woo 3D View (or the Display pane) such that bonds are explicitly shown on the screen (e.g., by lines) while other contacts are NOT shown? In other words, is it possible to get a visual representation only of bonded contacts?

2(b). Would such bonds-only visualization be possible in ParaView if we exported our data to that program?

Again, not directly possible now. What would be possible and relatively straightforward is combining the following two points:

1. enhance Gl1_DemField to have color scale for contacts based on various things (like there is for particles which can be colored according to radius, velocity, mask, displacement etc).
2. Make contacts outside of the range of the color scale not appear at all (the underlying code has been there for some time already, I just never really finished that). Since bonds are characterized by different stiffness values, this could work. A model-dependent criterion (like bonded/unbonded) would be less nice, but perhaps doable.

For Paraview, same thing. Since VtkExport exports also stiffnesses, by applying some filters, this result could be achieved.

3(a). What is the precise effect of the damping coefficient "damping", which is defined in (I believe) the "Leapfrog" integrator? There are some circumstances in which it appears to not produce any damping at all. The most notable of these occurs when a particle is in free-fall and lands on a surface: it will rebound (bounce) to the full height from which it was originally dropped, with no inelasticity whatsoever. This occurs despite my "damping" coefficient being set to 0.5.

I enhanced the documentation at https://woodem.org/theory/leapfrog.html#numerical-damping (just took over what I wrote for Yade a few yars back). And I checked and found a bug that you describe, in that that ContactModelSelector did not set Leapfrog.damping for any other contact models than the linear one (so not for ice, either). When you update from git (which includes this commit) it should behave as you had expected.

3(b). Is there a means of introducing hysteretic damping?

Yes, it is called c++. If you give me the equations, I will add them to the ice model.

If you are going to do only quasi-static simulations for ice (which I'd say also includes simulations with massively scaled time, and only the resulting forces matter), use the numerical damping. Otherwise contact-level damping is the way to go.

Hope this helps,

Václav

answered Jun 8, 2015 by (49,030 points)

Would changing the material of the walls to something other than ice accomplish this?

PS Actually this is a great idea. Since IceMat derives from FrictMat, making the wall from from FrcitMat will dispatch IceMat+FrictMat to Cp2_FrictMat_FrictPhys. Then however one needs to fiddle a bit with functors (add Cp2_FrictMat_FrictPhys and also Law2_L6Geom_FrictPhys_IdealElPl or whatever else you may need) for handling FrictPhys, but it will get the job done. If you need I can assist with that.

commented Jun 10, 2015 by (1,030 points)

What is the correct combination of functors for handling an IcePhys+FrictPhys contact? All of the permutations of the ones you mentioned result in the following error for me as soon as the two types of materials touch:

"con Contact.phys created from FrictMat and IceMat (a CPhysFunctor must be available for every contacting material combination)."

This is followed by a core dump (force quit) situation. The program does not know what to do when these two materials are collided. It seems as though it is not recognizing that IcePhys is derived from FrictPhys at all. Is this a bug, or is there a correct combination of functors?

commented Jun 10, 2015 by (1,030 points)

Update: Not sure why this happened, but I just tried manually setting my Leapfrog engine's damping coefficient to a non-zero value after opening the script, and TWO of my problems were resolved:

(a) Damping in free-fall now proceeded correctly (resolves Question 3a from above); and

(b) When I reversed the direction of gravity in my simulation, I found that particles which were on the "floor" (a wall) no longer remained bonded to the floor (also what I want; resolves Question 1).

I'll contact you if I make any more developments.

commented Jun 11, 2015 by (49,030 points)

(b) When I reversed the direction of gravity in my simulation, I found
that particles which were on the "floor" (a wall) no longer remained
bonded to the floor (also what I want; resolves Question 1).

I'd think this is simply because the gravity broke the bonds immediately, is that possible?

commented Jun 16, 2015 by (49,030 points)

"con Contact.phys created from FrictMat and IceMat (a CPhysFunctor
must be available for every contacting material combination)."

This is followed by a core dump (force quit) situation. The program
does not know what to do when these two materials are collided. It
seems as though it is not recognizing that IcePhys is derived from
FrictPhys at all. Is this a bug, or is there a correct combination of
functors?
Gimme a few day, I will look at that.

commented Jun 16, 2015 by (1,030 points)

Actually, I cracked the answer to that problem yesterday. It was because I was using the wrong string value -- "ice" -- in the ContactModelSelector to determine which contact model to use. If I set it to "linear" instead, it begins recognizing, without bugs, the relationship between FrictMat and IceMat. Thus, the problem appears solved. Thanks for offering though.

I've also simply started breaking the sphere-wall bonds manually using an "if" statement.

commented Jun 17, 2015 by (49,030 points)

Alright, this explains it. When you use model='linear', you don't get the ice behavior anywhere, it is just the linear model.

If you look at ContactModelSelector's source, you see it is nothing more than an object which composes a piece of the engines (with proper functors) for you, via DemField.minimalEngines (source here); you know that from Yade, right?

With model='ice', it only gives Cp2IceMatIcePhys for ContPhys functors, since that's what you're "supposed" to use. So if you use FrictMat, ContactLoop will complain that there is no functor to handle FrictMat+IceMat, because there is really not. It exists in Woo, but it was not given among the functors to use.

So there is a few options what could be done; the first one is my personal favorite.

1. Extent ContactModelSelector to somehow make it possible to use several contact models simultaneously. The question is how to do that elegantly. I'd be inclined to not allow it from the UI (it would get messy, and is an expert thing anyway), but support it from scripts, e.g. by setting and additional extraModels=['linear',...] parameter or such.

2. Call minimalEngines like you do normally, then get contactLoop (it is labeled, so just use S.lab.contactLoop to access it) and add Cp2_FrictMat_FrictPhys() to phyDisp and Law2_L6Geom_IdealElPl() to lawDisp (you need to copy and assign the list, things like .append() will not work: S.lab.contactLoop.phyDisp=S.lab.contactLoop.phyDisp+[Cp2_FrictMat_FrictPhys()] for instance).

3. Set the engines fully manually. I would not recommend this, since it makes your script more likely to break due to internal changes in the future, and there are more things to break (the order must be right and such).

Hope this helps,

Václav