Chrono error

[Mohammad Wasfi]

  Hi,

I am trying to use the Chrono gpu to achieve a similar effect as the run a cone penetration test but have been running into some difficulties. I hope that somebody here would be able to help me out.

When setting the young's modulus for the particles and boundaries to 1e9, I get the following error:

• No available contact pair slots for body xxxxx and body xxxxx

However, when I run the simulation with values larger than 1e9, the simulation runs smoothly. 

It seems strange to me that there seems to exist a critical value of cohesion that causes models to behave in unexpected ways. I am wondering if anybody here has had success with using low values for young's modulus in Chrono GPU. I am attaching my file for your reference. 

[Ruochun Zhang]

Hi,

Did you visualize your simulation? I doubt if this script can produce the correct physics. Last time, I stated that I believed one Chrono body was enough, and you had to collect force from both pieces of your meshes. This script uses at least 4 ChBodies (it may work, but I do not understand how they are used here) and seems the force is collected from the tip mesh only. Again, that's my speculation, because I don't know the mesh you used; but I doubt it would work, with low or high Young's modulus. It may happen to not throw an error at certain settings.

Perhaps more importantly, I know the tip force is what you are after but did you manage to get a one-mesh-one-cone test scenario running, visualize it and validate the physics it produces? I think you have to start there, and if you have that the rest should follow naturally.

Thank you,

Ruochun

[Mohammad Wasfi]

Hello,

I have implemented one body and included the two meshes there. However, the results I got did not match what I expected where the forces were not producing the stress values that I was expecting on the tip of the cone. As a result, I decided to switch back to my old method and see what differences I get. I am only using three of the four bodies that are created (I should probably comment on the one that I am not using out). One of the three bodies is used as a guide for the motor. Also, I assumed that both implementations would generate the same results since I am basically trying to do the same thing in two different ways. However, I get completely different results as well. I have animated the results for a specific young modulus value and everything looks good when animated. However, the physics is still different for both implementations. I am including the animation of the file that I attached earlier as well as the meshes I used and my other implementation for one body.  

Thank you, 

Mohammad

[Ruochun Zhang]

Hi,

This animation does not look good at all to me. The cone seems to have gone through the granular bed with no resistance at all, and the granular bed did not seem to respond to this impacting object. Also, if you monitored the cone force, I suspect you just got an extremely small reading. Do you agree? I would like to ask you to do one thing: could you pull from the develop branch of Chrono (newest commit), then build and run your script again with it? This is because there was a bug in granular module that could potentially disable mesh--particle contact unexpectedly, if you used an older version. I do not think it is very likely that your simulation suffered from this bug, but let's rule out this possibility first.

After that, the task is to make this simulation physical. I believe the "no contact pair when Young's modulus is below particular value" is just the by-product of some unphysical phenomenon, such as huge penetration, super large angular velocity, failure to detect contacts etc. And you have to debug based off a "minimal" run that is physical. To be physical, it has to look right at least... In your case, you have to find a test scenario where it runs without errors, and the mesh and particles seem to interact with each other normally (cone punches a crater on the granular bed).

By the way, we still cannot run your script because there is no JSON file attached. On top of that, I am sorry that I currently do not have time to run or debug it even with the JSON file. But maybe I can read it to get a brief idea. I also think this post discussing the general question-asking practice can be useful to consider.

Thank you!

Ruochun

[Mohammad Wasfi]

Hello,

Thank you so much for your reply. The forces I obtain from this simulation are considerably large (on the order of 10^4-10^6). If the particles do not interact with the mesh, I am not sure how these forces were generated. I assumed that the bed particles are not showing resistance because the speed of the cone was small (that is probably incorrect). Also, when running the simulation with Young's modulus value of 1e10, I get no errors at all (the animated results are still the same). As for the file that I attached in my first post, you do not need a JSON file to run the simulation. My latest Chrono build was from the newest commit (I rebuilt it a week ago). However, I will try one more time. 

Thank you, 

Mohammad

[Ruochun Zhang]

Hi,

If you got some force readings then perhaps that bug is not the cause, but kindly try that anyway, if you would. But if the cone's velocity is not high and it is not super heavy, then it should be stopped by the granular bed, should it not? I saw in the animation the cone almost "phased through" the material. I can only see it from the side so I am not 100% sure, but did you see the same in Paraview? You can apply glyph (sphere) filters to the particles (with their diameter being the scaling factor) and/or reduce the opacity of the cone to help you observe. The cone should push the particles out of the way while descending, and finally rest in the crater it creates. Pay attention to the particles that are originally on the trajectory of the cone, do they get inside the cone?

In a co-simulation, the GPU module does not manage the Chrono objects such as the cone, it just reports the force that cone should feel to Chrono core, and let the Chrono core handle their dynamics, then receive updates of the locations of objects from Chrono core. Looks to me that in this test the reported force and torque are not honored by the core module somehow. Can you give a better rendering of one of the cases that worked for you so we can go from there?

Thank you,

Ruochun

[Mohammad Wasfi]

Hi,

Thank you so much for your help. I really appreciate it. I will definitely rebuild Chrono again using the latest version and will let you know if any changes occur. For the cone, I have implemented a motor that ensures a constant velocity of the cone. My understanding is that the motor applies as much force as needed to maintain a constant velocity of the cone which is the reason why the cone does not stop in the bed. I have generated another video using ParaView (https://drive.google.com/file/d/1q-hgTcJY62kLblqr37sFoHX-4goOwbzR/view?usp=sharing) and it shows that the cone pushes the particles away as it moves. Also, non of the particles get inside the cone. I have included the .cpp file needed to run this simulation to avoid any confusion.

Forgive me I had to upload the video as a link due to size limitations for the post. 

Thank you so much for your help and please let me know if there is anything else you want me to provide to you, 

Mohammad, 

[Ruochun Zhang]

Hi,

I see, great. It looks alright to me now. To resolve that, can you please try what's in this post and let us know how it works. The short version is

Go to the file ChGpuDefines.h (in chrono\src\chrono_gpu), and replace

#define MAX_SPHERES_TOUCHED_BY_SPHERE 12

by

#define MAX_SPHERES_TOUCHED_BY_SPHERE 20

or some even larger number (for you, you may need something like 24? 30?). Rebuild it and run your script. 

I took a look at your tip mesh, and that falls exactly into the "a sphere sitting on the tip of a needle" category, and I suspect a sphere contacting with too many mesh facets is the cause. It makes sense because if you reduce the stiffness, the penetration gets higher and it potentially worsens the problem.

Another suggestion is that if possible, you should create a cone mesh that has less slender elements near the tip. It affects the shape little but can be a big help to the simulation. It should be easily doable with the CAD tool you used to create the meshes.

Thank you!

Ruochun

[Freya the Goddess]

Hi Mohammad,

can I ask how you create the Chrono video with Paraview? I want to create video of my Chrono example with Paraview too. Which CUDA version are you using ? I want to install chrono::gpu and I am trying CUDA 11.7 but it does not work correctly, maybe because my GPU is not CUDA compatible. Perhaps later on if I have better GPU.

Thanks for sharing the video.

--
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/6d42e6d0-d9f3-4612-b5ea-ad853ac2b082n%40googlegroups.com.

--

С наилучшими пожеланиями, Богиня Фрейя

Atenciosamente, Freya the Goddess

Meilleurs voeux, Freya the Goddess

Liebe Grüße, Freya the Goddess

Best wishes, Freya the Goddess

よろしくお願いします、Freya the Goddess

最好的祝福，Freya the Goddess

Matakwa mema, Freya the Goddess

مع أطيب التمنيات ، فريا الإلهة

[Mohammad Wasfi]

Hi Freya, 

My coda version is 11.4. I have an intel GPU and it still works for me so I am not sure how the compatibility of the GPU affects the animation. 

This page should have everything you need about ParaView: 7. Animation — ParaView Documentation 5.10.0 documentation

In short, I do the following steps;

1- open my .csv files obtained from my Chrono simulation in ParaView ( ParaView groups all files under the one.). 

2- right click on the files the .csv --> add filter --> alphabetical-->Table to points.

3- assign the x,y, and z columns. 

the window should have a visualization of your results ( you could change the representation to what you think is best under the representations menu).

4- file --> save animation. 

Hope this helps,

Mohammad

[Mohammad Wasfi]

Hi Ruochun,

I have tried the solution you told me about in your post. I have changed the MAX_SPHERES_TOUCHED_BY_SPHERE to be 30. However, now, I am getting the following error (error file: unspecified launch failure in ChGpu_SMC_trimesh.cu 754,     Output file: Sphere 16054 is touching 12 spheres already and we just found another!!!). Also, I have tried to change the mesh to have less slender elements near the tip however I still got the same error. 

Thank you so much, 

[Ruochun Zhang]

Hi Mohammad,

Then it is quite surprising. This error means a sphere is touching 30 objects, mesh facets and other spheres included. What comes close to being the cause is still in my opinion, the tip of the mesh. I'd suggest you modify your script a bit so it represents a scenario where a cylinder is dropped (i.e. the same part, but without the tip) onto the granular bed. Run it and if it works you know the problem is the tip mesh, and I have a few ideas on how to resolve that. If that still does not work, then in the simulation at some point the physics must've gone wild somehow, and that'd take a bit more effort to find.

Also, make sure you rebuild Chrono each time you make change to the source code, such as changing MAX_SPHERES_TOUCHED_BY_SPHERE. You can change it back to 12 or something smaller like 20 when you are doing the testing.

Thank you,

Ruochun

[Mohammad Wasfi]

Hello Ruochun, 

Thank you for constantly following up and answering my posts. I have suppressed the tip of the cone and tried to run the simulation but I am still getting exactly the same error. 

Thank you so much, 

[Ruochun Zhang]

Hi Mohammad,

I took a look at the script you shared and it seems that you have a couple of custom functions such as SetInterfacialSurfaceEnergy (which is why I can't build it). It is a possibility that those parameters interplay with existing DEM parameters so some of them become not physical on given settings.

Other than that, I'd suggest you repeat the previous test with the cone_shaft_modified mesh I attached in this post to see if this works. The construction of that mesh should rule out the influence of mesh quality. You can try even smaller time step size (maybe 1e-7) in the test, although I feel 5e-7 that you are using is fine enough...

If they still do not help, then again it's even stranger. I can try to debug to see if it is because of Chrono under-the-hood unit conversion, if I have access to a script that helps me reproduce the problem.

Thank you,

Ruochun

[Darwin Mick]

Hello,

Mohammad and I are working together on this project. The custom functions are used to pass new parameters into an updated collision model we are using and have taken into account the unit conversion. Primarily, we are changing the way the normal force is calculated. I'm assuming this is why we are seeing instability from our chrono build. We've done this by simply changing the way normal force is being calculated in the function computeSphereNormalForces_matbased() in ChGpu_SMC.cuh. We've set UseMaterialBasedModel as true.

Does this methodology sound correct? We're trying to debug if our implementation is correct, to figure out if our collision model is the main problem. I've attached the folder.

Thank you,

Darwin Mick

[Ruochun Zhang]

Hi Darwin,

Sure, you can modify the force model this way. I didn't see any obvious problem with the added code in function computeSphereNormalForces_matbased, apart from that in the calculation of a_SJKR, the dist_SJKR² term seems to just cancel out in the numerator and denominator, and that I'd ask you to make sure the CED_SU term is properly converted to the simulation unit before usage.

If there are scenarios where it fails and you want to debug, then a better approach is always, to start from the minimum and gradually isolate the problem. You can test if it works without the newly added cohesion force first, then go from there.

Thank you,

Ruochun

[Mohammad Wasfi]

Hello Ruochun, 

We have double-checked our implementation and ensured that the CED_SU term is correctly converted to the simulation unit. However, we still get the same error when running the simulation. We have run the same code without the cohesion force and it seems that it runs smoothly without errors for any young's modulus value we choose. However, the values of our results (forces on tip of the cone) are not what we are expecting. This ensures that the problem is within our implementation of the cohesion force. Is there a different way that you would recommend using for implementing cohesion force in Chrono? and what would be your best advice to ensure the accuracy of this implementation? 

Thank you so much,

[Ruochun Zhang]

Hi Mohammad,

If it is just "any" cohesion model that you are after, then Chrono::GPU provides a method to add cohesion forces: SetCohesionRatio(cohesion_ratio) and SetAdhesionRatio_SPH2MESH( cohesion_ratio). It implements a constant cohesion force model where, say for example, you set cohesion_ratio to be 2, then there will be a constant force 2 times the weight of a sphere, that pulls 2 spheres that are in contact together. I know it sounds extremely "naive", yet in many scenarios it turns out to be quite an effective model and about as good as some other sophisticated ones. You could use that, if your research is not about the performance of a particular cohesion model (that you just have to use that particular one).

If your research is about a particular cohesion/force model and you are asking about the best practice in terms of implementing it in the code, then it is a different story. I'd say you go the hard way. Create a new Git branch to add your experiment code, then when you are testing it, start from the minimal. You can instantiate 2 spheres in your simulation system, control their penetration length, measure the exact force between them and inspect if their motion is what you would expect. Once the small scale tests turn out to be good, you can move on to larger scales. It is indeed a lot to do but I suppose when you report the work to other people, you have to do it anyway.

Let me just say one more thing about the cohesion model you and Darwin are working on. I am not familiar with this exact model, but it looks generally reasonable with a potential danger: this force seems to get larger as the sphere penetration increases. So, depending on the rate it increases, it could incentivize larger and larger penetration on softer materials, and by the time the repulsive force takes over, the penetration is already too large, then the sphere gets lunched out with extreme velocity and destabilize the simulation. Again those are my speculations, I do not know what actually happened. Of course it may be worth it to try other types of models you encounter in literature as well, and I know there are a lot out there, even in other Chrono modules.

Thank you,

Ruochun

[Mohammad Wasfi]

Hello Rouchun, 

Thank you so much for your recommendation. The Chrono cohesion module seems to help us to obtain the trend we want. I just want to ask for some more description about that module. I looked into the forum and you had a post describing that module. Although, I wanted to ask about how the cohesion ratio is defined? the module that I am trying to use is called SJKR (Simplified Johnson-Kendall-Roberts). We are trying to use that module because we are looking into the effect of what is called "Cohesion energy density" on the simulation. The SJKR uses the cohesion energy density in its definition so I was wondering if you would know how to relate the cohesion ratio that Chrono uses to the cohesion energy density value (Formula??)?

Thank you so much,  

[Ruochun Zhang]

Hi Mohammad,

I talked about how the cohesion model (and its constant cohesion ratio) in current Chrono::GPU is defined/implemented in the previous thread. Here if I read correctly you are asking about how to decide/select a cohesion ratio for a specific problem? I think this is purely model-dependent.

For Chrono::GPU, cohesion ratio is just a number (a multiplier for particle weight) and Chrono::GPU does not assume how you get this number. If you are asking how to relate this number to Eq. 34 of the SJKR paper, then obviously cohesion_ratio = C * A / (particle_weight). Note here the cohesion ratio does not have a one-to-one correspondence to cohesion energy density C, because area A is a variable related to particle penetration length. If it is some other models you are referring to, then you just need to derive accordingly.

Because there is perhaps no one-to-one correspondence, you may have to do some development in the force calculation kernels, to make the exact SJKR model happen, like where you were doing. Of course, maybe you can also try to find their correspondence empirically using some averaging method, without worrying about the contact area or do your own development: after all, they have to be positively correlated. Those are all the suggestions I can think of.

Thank you,

Ruochun