GPU Co-sim Collision Bug?

[Darwin Mick]

Hi,

I'm running a co-simulation script to simulate dropping a solid body onto a particle bed using a material based model. When using one set of material properties, the solid body will collide with the particle bed as expected. However, when I change the material properties, the body falls through the particles and experiences no collision. The simulation reports no errors, and the only difference between the working and broken simulations is the material properties. 

Does anyone know why this is the case? My current theory has to do with instability within the particle bed due to the changed Young's Modulus of the particles. Does chrono have a way to report instability such as this?

Thank you!

Darwin Mick

[Dan Negrut]

Darwin – is there a code that you can share with us?

Dan

 

-------------------------------------------------

Bernard A. and Frances M. Weideman Professor

NVIDIA CUDA Fellow

Director, Wisconsin Applied Computing Center

Department of Mechanical Engineering

Department of Computer Science

University of Wisconsin - Madison

4150ME, 1513 University Avenue

Madison, WI 53706-1572

608 772 0914

http://sbel.wisc.edu/

http://projectchrono.org/

-------------------------------------------------

--
You received this message because you are subscribed to the Google Groups "ProjectChrono" group.
To unsubscribe from this group and stop receiving emails from it, send an email to projectchron...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/projectchrono/06e26e9e-565e-47d6-83b7-da9f5d1f5df2n%40googlegroups.com.

[Darwin Mick]

Yes, I've attached the working code and a table that shows how we change the parameters. The major differences are in time step, Young Modulus, particle size, and sphere density.

Best,

Darwin Mick

[Dan Negrut]

Darwin – we’ll do our best to help… We don’t have a whole lot of bandwidth but we’ll try to help if we can.

Meanwhile, I don’t know what sort of applications you have, but we are more and more using SPH for modeling granular terrains. It’s fast and robust.

Maybe this is something that would help you too.

The relevant papers: here and here. Folder with some sim.

To view this discussion on the web visit https://groups.google.com/d/msgid/projectchrono/881d1b8f-d7e5-4cbb-ba96-6e1aa40e51bcn%40googlegroups.com.

[Ruochun Zhang]

Hi Darwin,

That is indeed a bug in Chrono::GPU. It is not about materials but meshes. There was a misuse of data type, which caused Chrono::GPU to not pick up triangles in a mesh, when subdomains (SDs) used to discretize the space are small enough. SDs are small when the particle size is small, and that is the actual cause. I don't know why it did not happen in our tests which have much larger problem scales and maybe this only happens when the radius is numerically small; but either way, I was able to fix that. I will push a fix to github in a few days, but if you don't want to wait, you can fix it easily in your own clone of Chrono:

1) Find the following function in ChGpu_SMC_trimesh.cuh:

__inline__ __device__ void triangle_figureOutSDBox(const float3& vA,
                                                   const float3& vB,
                                                   const float3& vC,
                                                   int* L,
                                                   int* U,
                                                   ChSystemGpu_impl::GranParamsPtr gran_params) {
    int3 min_pt;
    min_pt.x = MIN(vA.x, MIN(vB.x, vC.x));
    min_pt.y = MIN(vA.y, MIN(vB.y, vC.y));
    min_pt.z = MIN(vA.z, MIN(vB.z, vC.z));

    // Enlarge bounding box
    min_pt.x -= gran_params->SD_size_X_SU / SAFETY_PARAM;
    min_pt.y -= gran_params->SD_size_Y_SU / SAFETY_PARAM;
    min_pt.z -= gran_params->SD_size_Z_SU / SAFETY_PARAM;

    int3 max_pt;
    max_pt.x = MAX(vA.x, MAX(vB.x, vC.x));
    max_pt.y = MAX(vA.y, MAX(vB.y, vC.y));
    max_pt.z = MAX(vA.z, MAX(vB.z, vC.z));

    max_pt.x += gran_params->SD_size_X_SU / SAFETY_PARAM;
    max_pt.y += gran_params->SD_size_Y_SU / SAFETY_PARAM;
    max_pt.z += gran_params->SD_size_Z_SU / SAFETY_PARAM;

    int3 tmp = pointSDTriplet(min_pt.x, min_pt.y, min_pt.z, gran_params);
    L[0] = tmp.x;
    L[1] = tmp.y;
    L[2] = tmp.z;

    tmp = pointSDTriplet(max_pt.x, max_pt.y, max_pt.z, gran_params);
    U[0] = tmp.x;
    U[1] = tmp.y;
    U[2] = tmp.z;
}

2) Replace it entirely with the following snippet:

__inline__ __device__ void triangle_figureOutSDBox(const float3& vA,
                                                   const float3& vB,
                                                   const float3& vC,
                                                   int* L,
                                                   int* U,
                                                   ChSystemGpu_impl::GranParamsPtr gran_params) {
    int64_t min_pt_x = MIN(vA.x, MIN(vB.x, vC.x));
    int64_t min_pt_y = MIN(vA.y, MIN(vB.y, vC.y));
    int64_t min_pt_z = MIN(vA.z, MIN(vB.z, vC.z));

    // Enlarge bounding box
    min_pt_x -= gran_params->SD_size_X_SU / SAFETY_PARAM;
    min_pt_y -= gran_params->SD_size_Y_SU / SAFETY_PARAM;
    min_pt_z -= gran_params->SD_size_Z_SU / SAFETY_PARAM;

    int64_t max_pt_x = MAX(vA.x, MAX(vB.x, vC.x));
    int64_t max_pt_y = MAX(vA.y, MAX(vB.y, vC.y));
    int64_t max_pt_z = MAX(vA.z, MAX(vB.z, vC.z));

    max_pt_x += gran_params->SD_size_X_SU / SAFETY_PARAM;
    max_pt_y += gran_params->SD_size_Y_SU / SAFETY_PARAM;
    max_pt_z += gran_params->SD_size_Z_SU / SAFETY_PARAM;

    int3 tmp = pointSDTriplet(min_pt_x, min_pt_y, min_pt_z, gran_params);
    L[0] = tmp.x;
    L[1] = tmp.y;
    L[2] = tmp.z;

    tmp = pointSDTriplet(max_pt_x, max_pt_y, max_pt_z, gran_params);
    U[0] = tmp.x;
    U[1] = tmp.y;
    U[2] = tmp.z;
}

Doing these 2 steps and rebuild, this problem should be gone (it's just replacing int type with int64). Let me know if this helps.

Thank you!

Ruochun

[Darwin Mick]

This worked! Thank you for the help!

Best,

Darwin

[Darwin Mick]

Hello,

I made the fix, but as I continued to experiment with material values the same issue persisted. In the working script I attached above, the material properties of the particles and the falling body are the same, but in the new script they are different. I also started using a more complicated mesh (Screw_CM.obj) but the issue still occurred when I reverted to the mesh of the cone (Part1.obj). Is there a potential bug fix here as well?

Best,

Darwin

[Ruochun Zhang]

Hi Darwin,

If by "the same issue" you mean the mesh was not felt by the granular material at all and goes through it, then I was not able to reproduce it using your script: the mesh and granular material interact normally. However, your simulation does crash when the cone touches the granular material, and that is because the moments of inertia of this cone is set to be extremely small, compared to the mass of this cone (screw_inertia is something like 7e-4 while its mass is ~100). This is not physical and causes the cone to rotate at a huge angular velocity, leading to large mesh--particle penetration and destabilize the simulation.

I was able to make this simulation run normally by supplying large MOI numbers, for example, just using those cone_inertia_xyz in your code: 

cone_body->SetInertiaXX(ChVector<>(cone_inertia_x,cone_inertia_y,cone_inertia_z));

I hope this answers the question.

Thank you,

Ruochun

[Darwin Mick]

Hello,

We have worked on making the mesh properties more physically realistic, but are still not finding a solution. The mesh is falling through the bed with no contact. I've attached the script we are using along with the mesh. We've used CAD software to ensure that the mass and inertias of the mesh are feasible. 

Thank you,

Darwin Mick

[Ruochun Zhang]

Hi Darwin,

This is sort of interesting, it still seems to be the fallout of the previous problem we had. I'll jump into the fix. Again I'll push the fix in a few days but you can fix it yourself. In file  ChGpu_SMC_trimesh.cuh, line 176~178 should be changed to

SDcenter[0] = gran_params->BD_frame_X + (int64_t)(i * 2 + 1) * (int64_t)gran_params->SD_size_X_SU / 2;
SDcenter[1] = gran_params->BD_frame_Y + (int64_t)(j * 2 + 1) * (int64_t)gran_params->SD_size_Y_SU / 2;
SDcenter[2] = gran_params->BD_frame_Z + (int64_t)(k * 2 + 1) * (int64_t)gran_params->SD_size_Z_SU / 2;

And line 268~270 line should be changed to this as well:

SDcenter[0] = gran_params->BD_frame_X + (int64_t)(i * 2 + 1) * (int64_t)gran_params->SD_size_X_SU / 2;
SDcenter[1] = gran_params->BD_frame_Y + (int64_t)(j * 2 + 1) * (int64_t)gran_params->SD_size_Y_SU / 2;
SDcenter[2] = gran_params->BD_frame_Z + (int64_t)(k * 2 + 1) * (int64_t)gran_params->SD_size_Z_SU / 2;

(continued to the next post...)

[Ruochun Zhang]

As you can see, this is also a problem involving int32_t integer overflow. I am not worried about this overflow problem hindering simulation accuracy as long as it does not happen, meaning the past simulations you did should still be fine. The interesting thing is it can happen when you change seeming unrelated parameters such as Young's modulus, and that is because those parameters affect the user unit--simulation unit conversion rate, so when the mass is small enough, domain is big enough and stiffness is large enough, it's just right for it to overflow. For what it's worth, I want to point out we don't do this unit conversion in our perspective new generation DEM solver anymore.

(again continued to the next...)

[Ruochun Zhang]

With this fix, I can simulate the screw drop scene, see the attached picture (can't upload video, it's too big). It seems the granular bed is not quite thick enough for this heavy part, so it hits the bottom and the particles there gave a large resistance that bounces the screw back. One last minor thing I'd like to mention is that the mesh is generally fine, with some slender elements here and there. I won't be a big problem but it's always better to use a smoothed mesh, and I attached a smoothed version of your part. Again, your call, either one works fine as it seems.

Thank you,

Ruochun