← Back to team overview

yade-users team mailing list archive

Re: [Question #269831]: HydroForceEngine not defined?

 

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

    Status: Open => Answered

Raphaël Maurin proposed the following answer:
Hi, 
Funny script, I like it =)
The problem is in the order of the engine. HydroForceEngine should be before NewtonIntegrator, otherwise the buoyancy force is not taken into account in the DEM resolution at the time step considered, and ForceResetter() will erase the force before beginning the resolution of the next time step so that the force added is never taken into account. It should work if you try a loop like that:
O.engines=[
    ForceResetter(),
    InsertionSortCollider([Bo1_Sphere_Aabb(),Bo1_Facet_Aabb(),Bo1_Wall_Aabb()],label='collider'),
    InteractionLoop(
        [Ig2_Sphere_Sphere_ScGeom(),Ig2_Facet_Sphere_ScGeom(),Ig2_Wall_Sphere_ScGeom()],
        [Ip2_FrictMat_FrictMat_FrictPhys()],
        [Law2_ScGeom_FrictPhys_CundallStrack()],
    ),
    #HydroForceEngine(densFluid=rau_wat,ids=spids,lift=True),
    HydroForceEngine(densFluid = 1024,viscoDyn = 1e-3,zRef = -D_wat,deltaZ = 0.1,nCell = 20,vxFluid=numpy.zeros(20),phiPart = numpy.zeros(20),vFluctX = np.zeros(len(spids)),vFluctZ = np.zeros(len(spids)),ids = spids ),
    NewtonIntegrator(damping=.1,exactAsphericalRot=True,gravity=(0,0,-9.81)),
    TranslationEngine(translationAxis=[1,0,0],velocity=5.0,ids=[id.id for id in strut])
]

I don't know what is exactly doing TranslationEngine but it is also
maybe better to put it before NewtonIntegrator. It seems that there is
also a problem in the way you collect the particles's ID as not all the
particles are submitted to buoyancy.

Some comments on your script: 
- The young modulus you impose leads to very high contact stiffness for DEM simulation. This impact directly the computational time. It is usually possible to soften artificially the stiffness (so the young modulus) without modifying the results if you stay in the rigid grain limit. The rigid grain limit corresponds to the limit for which the deformation/overlap of the spheres stay negligible with respect to the particle diameters. For dense granular media, it has been related to the maximum pressure undergone by the particles [1][2], and can be evaluated before computation. For any other situation, the game is to see if a reduction of the stiffness modify the results or not. This will allow you to gain a lot of computational time. 
- You are using PWaveTimeStep() for the time step determination, consider using GlobalStiffnessTimeStepper(), itcan make you gain computational time.
- You are considering a dynamical situation with a contact law more adapted to quasi static ones. If you want a more realistic dynamical behavior with dissipation at contact characterized by a restitution coefficient, have a look at the Law2_ScGeom_ViscElPhys_Basic.
- Walls made of facets might have some unwanted behavior if the particles are hitting the joint between two facets, I prefere using "box" to build walls and avoid these problems. 
- When you define a material, it is safer to label it with a name, e.g.  O.materials.append(FrictMat(young=10e9,poisson=.25,frictionAngle=0.5,density=980., label='Mat1')), and specify the material when you are creating the bodies, with e.g.  sp.toSimulation(material = 'Mat1'). (I don't know how to do with facet box but this should be similar. )
This allows you to define different materials and make you sure you are using the material you want for this specific body. 

Regards

Raphaël

[1]  section 4, p.4 of: N Roux and G. Combe. Quasistatic rheology and the origins of strain. Comptes Rendus Physique, 3(2):131 – 140, 2002
[2]  section IV, p.4-5 of: F. da Cruz, S. Emam, M. Prochnow, J-N. Roux, and F. Chevoir. Rheophysics of dense granular materials: Discrete simulation of plane shear flows. Phys.Rev. E, 72:021309, 2005.

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