yade-users team mailing list archive

[Chareyre <question175394@xxxxxxxxxxxxxxxxxxxxx>]

Question #175394 on Yade changed:
https://answers.launchpad.net/yade/+question/175394

Chareyre proposed the following answer:
If you use Ip2_FrictMat_FrictMat_CapillaryPhys +
Law2_ScGeom_FrictPhys_CundallStrack, then you are not simulating Hertz-
Mindlin, but a linear law instead.

These lines have no effect:
ContactModel.betan=viscous_normal # normal direction
ContactModel.betas=viscous_shear # shear direction
ContactModel.useDamping=True

The "contact model" (physics functor) has no such attributes (see https
://yade-
dem.org/doc/yade.wrapper.html#yade.wrapper.Ip2_FrictMat_FrictMat_CapillaryPhys).
It has in fact no attributes at all, so you are just adding data to it
(python allows that) but they are never used in computations.

I think it explains the differences in time-steps since contact
stiffness are most likely very different (the straight way to check that
is to compare directly contacts kn/ks in Yade and PFC - for Yade use
simulation inspector to see the values).

In order to simulate Hertz contact + capillary forces, I think it will
need an additional Ip2 functor implemented, that will generate the
capillary data in addition to what is already defined by
Ip2_FrictMat_FrictMat_MindlinPhys. There is nothing to implement in
terms of physics, it's only a matter of declaring things correctly and
creating the good Ip type.

For different contact laws with walls, it is theoreticaly possible, but
I think that, again, it will need a little bit of work on the c++ side.

Currently, it would work if combining functors and laws like this for instance:
InteractionLoop(
  [Ig2_Sphere_Sphere_ScGeom(),Ig2_Facet_Sphere_Dem3Dof()],
  [Ip2_FrictMat_FrictMat_CapillaryPhys(label='ContactModel')],
  [Law2_ScGeom_FrictPhys_CundallStrack(), Law2_Dem3Dof_FrictPhys_CundallStrack()],

As you see here, sphere-sphere and sphere-facet will have different geometry types (ScGeom vs. Dem3Dof), hence they will be dispatched to different contact laws (even if the two contact laws I mention here are doing the same thing actually).
In your case, it would not work unfortunately, because you need ScGeom for both contact groups. A solution would be to make one contact group artificially different by deriving another geometry type from ScGeom, that would be exactly the same except the name. It is easy to do with inheritance but sounds like a hack.
This is actually an interesting problem since it shows a design problem in Yade.

-- 
You received this question notification because you are a member of
yade-users, which is an answer contact for Yade.