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 <https://www.researchgate.net/publication/346879528_Simplified_Johnson-Kendall-Roberts_SJKR_Contact_Model_-_Implementation_in_PFC#pf10>, 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 On Tuesday, July 26, 2022 at 10:59:30 AM UTC-5 [email protected] wrote: > 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, > > On Friday, July 22, 2022 at 5:27:29 PM UTC-7 Ruochun Zhang wrote: > >> 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 >> >> >> On Friday, July 22, 2022 at 6:16:11 PM UTC-5 [email protected] wrote: >> >>> 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, >>> >>> On Thursday, July 14, 2022 at 12:54:28 AM UTC-7 Ruochun Zhang wrote: >>> >>>> 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 >>>> >>>> On Wednesday, July 13, 2022 at 9:56:04 PM UTC-5 [email protected] wrote: >>>> >>>>> 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 >>>>> >>>>> On Sunday, July 10, 2022 at 1:36:15 AM UTC-7 Ruochun Zhang wrote: >>>>> >>>>>> 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 >>>>>> >>>>>> On Saturday, July 9, 2022 at 9:09:38 PM UTC-5 [email protected] >>>>>> wrote: >>>>>> >>>>>>> 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, >>>>>>> >>>>>>> On Friday, July 8, 2022 at 12:53:40 AM UTC-7 Ruochun Zhang wrote: >>>>>>> >>>>>>>> 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 >>>>>>>> >>>>>>>> On Thursday, July 7, 2022 at 11:32:39 PM UTC-5 [email protected] >>>>>>>> wrote: >>>>>>>> >>>>>>>>> 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, >>>>>>>>> On Wednesday, July 6, 2022 at 11:21:00 AM UTC-7 Mohammad Wasfi >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> 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 >>>>>>>>>> <https://docs.paraview.org/en/latest/UsersGuide/animation.html#:~:text=In%20ParaView%2C%20you%20can%20create%20animations%20by%20recording,the%20parameters%2C%20you%20can%20play%20through%20the%20animation.> >>>>>>>>>> >>>>>>>>>> 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 >>>>>>>>>> On Tuesday, July 5, 2022 at 2:42:52 AM UTC-7 [email protected] >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> 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. >>>>>>>>>>> >>>>>>>>>>> Le mar. 5 juil. 2022 à 01:28, Mohammad Wasfi < >>>>>>>>>>> [email protected]> a écrit : >>>>>>>>>>> >>>>>>>>>>>> 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, >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> 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 [email protected]. >>>>>>>>>>>> To view this discussion on the web visit >>>>>>>>>>>> https://groups.google.com/d/msgid/projectchrono/6d42e6d0-d9f3-4612-b5ea-ad853ac2b082n%40googlegroups.com >>>>>>>>>>>> >>>>>>>>>>>> <https://groups.google.com/d/msgid/projectchrono/6d42e6d0-d9f3-4612-b5ea-ad853ac2b082n%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>>>>>>>> . >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> С наилучшими пожеланиями, Богиня Фрейя >>>>>>>>>>> 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 >>>>>>>>>>> مع أطيب التمنيات ، فريا الإلهة >>>>>>>>>>> >>>>>>>>>> -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/projectchrono/af7edae1-b224-4d0a-b4c1-76c1786ded41n%40googlegroups.com.
