Ambiguous dispatch : too much laws ?

Hello Nicolas,
The order does not matter.

I am not sure there is a solution to this particular problem yet I am nearly sure that the problem (if it can be solved) comes from parts of the script that you did not show (assignement of materials to the different objects).
Also, the problem is not to have too many functors, instead it is due to _missing_ functors.

> ambiguous 2d dispatch (arg1=GridCoGridCoGeom, arg2=LubricationPhys, distance=2)

It tells that contacts between different grid elements are supposed to be lubricated contacts (according to your materials definition). Since you did not include any Law2_GridCoGridCoGeom_ImplicitLubricationPhys yade tries to guess if another one could possibly be used through inheritance, and it finds many (8!), too many, hence the ambiguity.
Choosing one among them is not a solution since it is unlikely to give the desired behavior.
The real solution is to insert Law2_GridCoGridCoGeom_ImplicitLubricationPhys but it doesn't exist at the moment.

The true question is: do you really want to have lubricated contacts between elements of the grid? If not, just don't assign a viscous material to the grid and it should be fine.

Further questioning: why mixing WirePhys and PFacets? I would expect WirePhys OR PFacets since they are two different ways to modelize grids, so in principle no reason to use both in one single simulation.

Bruno

Hello Bruno,

I remember having encountered the problem of the order, I will check some previous test scripts and share it if I find it.
In fact, I could share the script but it's a 1500 line scripts and it is almost not legible at the moment...

The mesh is made of FrictMat for the GridConnections and CohFrictMat for the GridNodes.

> The true question is: do you really want to have lubricated contacts between elements of the grid?

No of course, LubricationPhys is only for the viscous flow (made of sphere with FrictMat also).

Indeed, PFacet need to be deleted (was used to make a test channel, I replace by aabbWall).

Nicolas

Hello,

I just try to invert the two Ip2 FrictMat FrictMat. I put FrictPhys after LubricationPhys and I manage to run the script without error (so it seems that the order matter ?).
When I run on a single thread I don't have error but on multithread (-jN) :

ambiguous 2d dispatch (arg1=ScGeom6D, arg2=WirePhys, distance=1), dispatch matrix:
AMBIGUOUS: 0+8 -> Law2_ScGeom_ImplicitLubricationPhys
AMBIGUOUS: 1+3 -> Law2_ScGeom_FrictPhys_CundallStrack
AMBIGUOUS: 2+3 -> Law2_ScGeom_FrictPhys_CundallStrack
AMBIGUOUS: 2+5 -> Law2_ScGeom6D_CohFrictPhys_CohesionMoment
AMBIGUOUS: 6+3 -> Law2_GridCoGridCoGeom_FrictPhys_CundallStrack
AMBIGUOUS: 7+5 -> Law2_ScGeom6D_CohFrictPhys_CohesionMoment
AMBIGUOUS: 11+3 -> Law2_ScGridCoGeom_FrictPhys_CundallStrack

I have this law Law2_ScGeom_WirePhys_WirePM() but their is not ScGeom6D_WirePhys law yet.

Nicolas

The results you describe make non sense to me. I can't say anything more without seeing a script. :)
Hopefully it will not take 1500 to just show combinations of functors and materials on couple bodies.
Bruno

I clean a bit the code by removing functions et variable definitions (especially the value that could be confidential).
I let some all material definitions, engine routine and some creation's routine that help to understand the material assignation.

https://pastebin.com/2DaA7SBJ

I hope it will help.

Nicolas

A working script would be more helpful.
B

Hello Nicolas,

There are some variables missing from the script. I would suggest reducing it as much as possible and checking it before posting.

Cheers,

Marcus.

Hello,

Here we are, I had issue with the lubrificationlaw that can't compute if some bodies inter-penetrate at time=0.0 so we fix it by isolating this bodies using mask and collider.avoidSelfInteractionMask.

I notice some strange bugs so I asked permission so share the whole script and it's OK.
So, I will explain and here is the main script : https://pastebin.com/hkmimXSb (sorry for the size). I comment what concerns the modified DragEngine so it should run without problem on an updated Yadedaily.

The script as it is on pastebin runs on single and multiple threads without problem but the spherepack go through the walls.
I analyze the forces between bodies using a test script : https://pastebin.com/GaMW8Bhn
A lubrication force exists between the spheres so that's enough for my problem, a basic FrictPhys between spheres and flexible barrier is OK.

Now, if you invert the lines 202 and 203 (first the FrictMat_FrictMat_LubricationPhys and second the FrictPhys), I noticed several issues.
1- The spherepack still go through the walls.
2- If you try to run on multiple threads, it returns an ambiguous dispatch.
/home/godetnicolas/myYade/trunk/lib/multimethods/DynLibDispatcher.hpp:344: ambiguous 2d dispatch (arg1=ScGeom6D, arg2=WirePhys, distance=1), dispatch matrix:
AMBIGUOUS: 0+8 -> Law2_ScGeom_ImplicitLubricationPhys
AMBIGUOUS: 1+3 -> Law2_ScGeom_FrictPhys_CundallStrack
AMBIGUOUS: 2+3 -> Law2_ScGeom_FrictPhys_CundallStrack
AMBIGUOUS: 2+5 -> Law2_ScGeom6D_CohFrictPhys_CohesionMoment
AMBIGUOUS: 6+3 -> Law2_GridCoGridCoGeom_FrictPhys_CundallStrack
AMBIGUOUS: 7+5 -> Law2_ScGeom6D_CohFrictPhys_CohesionMoment
AMBIGUOUS: 11+3 -> Law2_ScGridCoGeom_FrictPhys_CundallStrack

So I summarize:
- I have a collider issue, the spherepack go through the walls. This issue does not appear in my script without the flexible barrier (https://pastebin.com/JTSv5Ucr)
- The order of Ip2 functors affects something that causes ambiguous dispatch with multi-thread computing but it does not appear on single-thread computing.

I tried to be as clear as possible but it's not simple.
The main script is very long, it's still a work in progress and there is a lot of improvements that need to be done to clarified the script.

Nicolas

Too complex for me sorry. There seem to be multiple problems and I'm stuck at the very first step:
> some bodies inter-penetrate at time=0.0 so we fix it by isolating this bodies using mask and collider.avoidSelfInteractionMask.

If you discard interactions between spheres I don't think it will work very well from a physical point of view. What is the logic? I would think the solution is simply to not generate overlapping spheres.

Possibly make simpler scripts to isolate independent problems.

Bruno

p.s. Previously you did not want to share precise numbers for some parameters. In order to send a working script it would have been enough to set them to different values instead of leaving them undefined.

I just realize this:
[...
Ip2_FrictMat_FrictMat_FrictPhys(),
Ip2_FrictMat_FrictMat_LubricationPhys(eta=m_viscosity,eps=m_roughness,label="Phys_Lub"),
...]

Which means:
If b1 is frictMat and b2 is FrictMat then generate a FrictPhys AND If b1 is frictMat and b2 is FrictMat then generate a LubPhys.
You will have to decide, obviously. :)
You actually decide, by putting one first. Still there is logical error in this set of functors and it should not happen. Dispatching is order-independant only for consistent set of functors.

Bruno

You script still doesn't work...

Traceback (most recent call last):
  File "/usr/bin/yadedaily", line 182, in runScript
    execfile(script,globals())
  File "gridNicolasGodet.py", line 16, in <module>
    os.mkdir(folder)
OSError: [Errno 2] No such file or directory: 'Results/FILETAIEAIE/'

Should be better now : https://pastebin.com/hkmimXSb
Disable what concerning folder creations and files.

> If you discard interactions between spheres I don't think it will work very well from a physical point of view. What is the logic? I would think the solution is simply to not generate overlapping spheres.

I avoid interactions between gridConnections inside the mesh. I didn't mention that sorry.
On 1 node, there are up to 4 gridConnections on the same node and these gridCon are inter-penetrating. The designer of the mesh told me that it should be a problem if the gridCon don't see each others.
The problem with this inter-penetration at time = 0 is that the lubricationlaw is designed so that it can not handle pre-existing contact at the initialization of the law. William explained me that.

First, I let "Ip2_FrictMat_FrictMat_FrictPhys()" because it returns error without but of course, I want LubricationPhys between my spheres and between spheres-wall but for the contact between a sphere and another element (like gridCon or nodes) a simple FrictPhys is enough,

So I just removed it from the Ip2 functors but the spherepack still go through the walls.

I will make a simplest script today.

Nicolas

P.S. : Concerning the value of variables, it does not really matter, this mesh is not well calibrated so it's not the correct values.

I've done an easier script that contains almost every elements that's are in the big one.

https://pastebin.com/ipF53JhW

The spheres are able to interact with the mesh but go through the walls...
I have exactly the same Bo1 and Ig2 functors that deal with walls or box in the viscous flow script (https://pastebin.com/JTSv5Ucr).

Hello,

> The spheres are able to interact with the mesh but go through the walls...

in this last version, you have no Ig2_Wall_Sphere, so according to [1]: "missing combination will cause given shape combinations to freely interpenetrate one another"

cheers
Jan

[1] https://yade-dem.org/doc/user.html#ig2-functors

Hello Jan,

Well Ok, that's strange because I have 0 issue when I use Ig2_Box_Sphere_ScGeom6D() in https://pastebin.com/JTSv5Ucr
Furthermore, I add Ig2_Wall_Sphere_ScGeom() and still, the spheres don't see the wall.

A aabbWalls is the simplest element to make plan or Facet could be better ?

Nicolas

> The spheres are able to interact with the mesh but go through the walls...
> W1 = O.bodies.append(aabbWalls(...

aabbWalls actually creates Boxes..

But yes, the interaction between spheres and boxes is missed, strange..

I ran the script #15 for many minutes, nothing happening.
If it needs more than a few seconds to see the problem please reduce the number of particles (I tried, but then big particles were overlapping a box at time zero, I then resigned).

Also, I see that the problem mentioned in #10 is still there.

B

The script that need to be debug is this one : https://pastebin.com/ipF53JhW
It’s a very simplified model of the 1500 line script.

The script #15 is working perfectly (take several days to compute), this is the one that I developed for my internship.
I mention it because there is aabbWalls in this one and spheres are able to interact with. Thing that is not possible in the script given in the beginning of this message.

I see, thanks.
I tried the good one this time, not in details but: you have 6 boxes in
it but none of them seem to cover the surface you want to modelize (it
looks transparent).
If you want to have just a floor better insert a single Box.
Bruno

Hello,

I tried to :
 - put only 1 box that create my floor : no interaction
 - 3D box with spheres inside : no interaction
 - facet instead of box : interaction
I test on 2 computers (1 ubuntu, 1 debian) with 2 different versions of yadedaily and I observed the same behavior.
By commenting/decommenting some lines, it is easy to switch the configuration : https://pastebin.com/3rM8bW0K

So it seems that the problem comes from aabbwalls but I don't understand why because it is the same configuration that in my script that works perfectly (https://pastebin.com/JTSv5Ucr the time step can be increased up to 1e-5 just to see the interaction between wall (boxes) and spheres).
There is no difference in the O.engines that justify the error (same collider, same interactionLoop).

Nicolas

Hi Nicolas, if possible please post the examples here on launchpad.
"pastebin" hides details away from the question so it makes reading less easy, plus those links have unknown lifetime which is not good for the long run.
Also please don't send scripts with a lot of commented lines, it is not helpful.
Bruno

The first one in #20 is nearly perfect. :)
It could fit in less lines if you remove some blanks... then it can appear here.
Bruno

>"put only 1 box that create my floor : no interaction"

Could you show this one? You say it is easy to switch but I can' t figure out what to comment/uncomment to see this elementary case.
B

I setup the expiration date to "Never" for the pastebin so it should not be a problem for the future but I will put the script directly here now.

> Could you show this one? You say it is easy to switch but I can' t figure out what to comment/uncomment to see this elementary case.

from yade import plot,qt
from yade.gridpfacet import *
import math

O.dt = 0.000001

Rad = 0.1
Factor=1.5
m_viscosity=3
m_roughness=0.02

O.materials.append(
  FrictMat(
   density=2500,
   frictionAngle=math.radians(35.),
   poisson=0.2,
   young=1e7,
   label='Frict'))
S2 = O.bodies.append(sphere(center=[1.5*Rad,0,Factor*2.1*Rad],radius=Rad,material='Frict',fixed=False))
Stest = O.bodies.append(sphere(center=[1.5*Rad,0,3*Factor*2.1*Rad],radius=Rad,material='Frict',fixed=False))
W1 = O.bodies.append(aabbWalls([(4*Rad,-2*Rad,15*Rad),(0,3*Rad,0)],thickness=0.,material='Frict',oversizeFactor=1.0))
for i in [0,1,3,4,5]:
 O.bodies.erase(W1[i])
O.engines=[
 ForceResetter(),
 InsertionSortCollider(
  [Bo1_Sphere_Aabb(aabbEnlargeFactor=Factor, label="aabb"),
   Bo1_Box_Aabb(),
   Bo1_Wall_Aabb(),],#Bo1_Facet_Aabb(),
   verletDist=-0.1,
   allowBiggerThanPeriod=False),
 InteractionLoop(
        [Ig2_Sphere_Sphere_ScGeom6D(interactionDetectionFactor=Factor,label="Ig2"),
         Ig2_Wall_Sphere_ScGeom(),
         Ig2_Box_Sphere_ScGeom6D(),],
        [Ip2_FrictMat_FrictMat_LubricationPhys(eta=m_viscosity,eps=m_roughness),],
      [Law2_ScGeom_ImplicitLubricationPhys(activateNormalLubrication=True,activateTangencialLubrication=True,activateTwistLubrication=False,activateRollLubrication=False,
theta=0.55,resolution=1,NewtonRafsonTol=1e-6,warnedOnce=True,maxSubSteps=20,debug=False,),]),
 NewtonIntegrator(damping=0.,gravity=[0,-5,-5],label='newton'),]
qt.View()

And here is with facet instead of box :

from yade import plot,qt
from yade.gridpfacet import *
import math

O.dt = 0.000001

Rad = 0.1
Factor=1.5
m_viscosity=3
m_roughness=0.02

O.materials.append(
  FrictMat(
   density=2500,
   frictionAngle=math.radians(35.),
   poisson=0.2,
   young=1e7,
   label='Frict'))
S2 = O.bodies.append(sphere(center=[1.5*Rad,0,Factor*2.1*Rad],radius=Rad,material='Frict',fixed=False))
Stest = O.bodies.append(sphere(center=[1.5*Rad,0,3*Factor*2.1*Rad],radius=Rad,material='Frict',fixed=False))
F1=O.bodies.append(facet([[-10,-2*Rad,0],[10,-2*Rad,0],[0,-2*Rad,10]],fixed=True,material='Frict'))
O.engines=[
 ForceResetter(),
 InsertionSortCollider(
  [Bo1_Sphere_Aabb(aabbEnlargeFactor=Factor, label="aabb"),
   Bo1_Facet_Aabb(),],
   verletDist=-0.1,
   allowBiggerThanPeriod=False),
 InteractionLoop(
        [Ig2_Sphere_Sphere_ScGeom6D(interactionDetectionFactor=Factor,label="Ig2"),
   Ig2_Facet_Sphere_ScGeom()],
        [Ip2_FrictMat_FrictMat_LubricationPhys(eta=m_viscosity,eps=m_roughness),],
        [Law2_ScGeom_ImplicitLubricationPhys(activateNormalLubrication=True,activateTangencialLubrication=True,activateTwistLubrication=False,activateRollLubrication=False,
theta=0.55,resolution=1,NewtonRafsonTol=1e-6,warnedOnce=True,maxSubSteps=20,debug=False,),]),
 NewtonIntegrator(damping=0.,gravity=[0,-5,-5],label='newton'),]
qt.View()

Nicolas

There was a misunderstanding since the beginning it seems.
There is no "aabbWalls" shape in yade.
aabbWalls() is a python shorthand to create a domain bounded by 6 Box's.
If you want a floor you don't want aabbWalls, you want just one "Box" (it is the name of the shape) instead of 6.
Did you try this yet?

Also note that the first two arguments of aabbWalls are called min and max for a reason... it seems to be defined inconsistently in your case.

Bruno

The problem was the min and max...

Well I'm sorry for this basic error, a lot of noise for nothing...
Many thanks.

Nicolas

You are welcome.
This is typically something one would figure out by himself when elaborating a real MWE. :)
And that's why we insist on people not sending us their scripts as they are.
Imagine the time it takes for us to find that min>max in 1500+ lines...
Bruno