Not sure, the scripts in this post runs well for me in the end. Make sure you are using the newest CUDA, not 11.2. Then, common causes were already mentioned in this thread. If you are gradually refining the particle size in a problem and at some point (or just directly running with small particles size and large time step size), it stops working and gives "No available contact pair" error, it's more likely that the time step size is not sufficiently small for this particle size and the simulation crashes with large particle penetration. To debug, you can: 1. Visualize to see if the simulation already becomes not physical before the crash; 2. Try larger particles size to see if it works or, if you don't mind longer testing time, try smaller time steps.
I don't think MAX_SPHERES_TOUCHED_BY_SPHERE being 12 causes that many problems in itself, unless with some specific meshes, maybe you should debug with that set back to 12. Thank you, Ruochun On Tuesday, June 14, 2022 at 10:16:05 AM UTC-5 [email protected] wrote: > Hello, > > I am actually running into the exact same problem. > > For instance, with the scripts attached in the first post, and modifying > the MAX_SPHERES_TOUCHED_BY_SPHERE to 32 (then rebuilding the solver), I get > the "No available contact pair" error after around 40 steps. > I am on the updated version of the feature/gpu branch, so I am a bit > confused. > > Do you have any clue of what it could be? > > Best regards, > Yves > On Wednesday, June 8, 2022 at 7:07:16 PM UTC+3 Ruochun Zhang wrote: > >> Hi David, >> >> Thanks for sharing! >> >> Ruochun >> >> On Monday, June 6, 2022 at 10:34:24 AM UTC-5 [email protected] wrote: >> >>> Realized I forgot to share my changes to add the group functionality. >>> I’m not super familiar with GitHub so I’ll just upload my chrono_gpu source >>> files here. I believe that I only made changes to >>> ChGPUDefines.h,,ChSystemGPU.h and .cpp, and ChSystemGpu_impl.h and .cpp to >>> add the SetParticleGroup function. >>> >>> Thanks! >>> David >>> >>> On Sunday, June 5, 2022 at 10:29:33 PM UTC-6 Ruochun Zhang wrote: >>> >>>> Hi Yves, >>>> >>>> If by "relocation" you mean something similar to the "particle source" >>>> method mentioned in this thread, then you can already see how it's done >>>> from the scripts shared therein: basically, adding more spheres to the >>>> system then "re-initialize". If you meant establishing a periodic >>>> boundary, >>>> then I don't believe it is discussed in this thread, and as I said this is >>>> a more dedicated issue and worth a separated discussion. >>>> >>>> Thanks, >>>> Ruochun >>>> >>>> On Saturday, June 4, 2022 at 2:02:14 PM UTC-5 [email protected] >>>> wrote: >>>> >>>>> Hello, >>>>> >>>>> I would be very interested in this feature for my project, would it be >>>>> possible to share the changes you made, especially for the particles >>>>> relocation? >>>>> Please let me know, we can exchange by email as well. >>>>> >>>>> Yves >>>>> >>>>> On Monday, May 16, 2022 at 5:55:47 PM UTC+3 [email protected] wrote: >>>>> >>>>>> Hi Ruochun, >>>>>> >>>>>> Thanks for the help, it seems to be working now! I was able to get >>>>>> the particle relocation working as well. >>>>>> >>>>>> I am interested in the new solver. Let me know when a release/test >>>>>> build is available for it, I’d like to try it out to see if it’s faster >>>>>> for >>>>>> these applications. >>>>>> >>>>>> Thanks! >>>>>> David >>>>>> >>>>>> On Friday, May 13, 2022 at 3:43:36 PM UTC-6 Ruochun Zhang wrote: >>>>>> >>>>>>> Hi David, >>>>>>> >>>>>>> This issue is a weakness in the default assumption we made that a >>>>>>> sphere can have at most 12 contacts. This assumption is made to save >>>>>>> GPU >>>>>>> memory and to help identify some large-penetration problems in >>>>>>> simulation >>>>>>> which is typical with insufficient time step size. This assumption is >>>>>>> fine >>>>>>> with near-rigid spherical contacts, but problematic when meshes are >>>>>>> involved (each mesh facet in contact with a sphere eats up one slot as >>>>>>> well). Imagine a sphere sitting on the tip of a needle made of mesh, it >>>>>>> could have contacts with tens of mesh facets, and we haven't counted >>>>>>> the >>>>>>> sphere neighbors it can potentially have. >>>>>>> >>>>>>> The fix is easy, please 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 if you need it. Rebuild it and your >>>>>>> script should run fine. Note the error messages are hard-coded to say >>>>>>> 12 is >>>>>>> not enough if *MAX_SPHERES_TOUCHED_BY_SPHERE* is exceeded, so if >>>>>>> 20 is not enough and you need even more, just change it and do not let >>>>>>> the >>>>>>> error messages confuse you. >>>>>>> >>>>>>> Another thing is that it is better to use meshes with relatively >>>>>>> uniform triangle sizes. I attached a rebuilt mesh based on your >>>>>>> original >>>>>>> one. It's optional and does not seem to affect this simulation, but >>>>>>> it's a >>>>>>> good practice. >>>>>>> >>>>>>> To answer your other questions: Unfortunately C::GPU does not >>>>>>> currently have an *efficient* way of streaming particles into the >>>>>>> system. The method you are using (re-initialization) is probably what I >>>>>>> would do too if I have to. With a problem size similar to yours, it >>>>>>> should >>>>>>> be fine. And C::GPU does not have an official API that enforces manual >>>>>>> particle position changes. However this should be fairly >>>>>>> straightforward to >>>>>>> implement. The naive approach is of course, do it on the host side with >>>>>>> a >>>>>>> for loop. If you care about efficiency, then we should instead add one >>>>>>> custom GPU kernel call at the end of each iteration, that scans the z >>>>>>> coordinates of all particles, and add an offset to them if they are >>>>>>> below a >>>>>>> certain value. It would be nice if you can tailor it to your needs, but >>>>>>> if >>>>>>> you need help implementing this custom kernel you can let us know (it >>>>>>> may >>>>>>> be good to add it as a permanent feature). >>>>>>> >>>>>>> Lastly, I don't know if you are interested or not but in the new >>>>>>> generation of DEM simulator that we are currently developing, apart >>>>>>> from >>>>>>> supporting non-trivial particle geometries, there will be >>>>>>> *efficient* ways to do both things (sleeper and active entities; >>>>>>> periodic boundary with no extra cost). It is not out yet, however. >>>>>>> >>>>>>> Thank you, >>>>>>> Ruochun >>>>>>> >>>>>>> On Thursday, May 12, 2022 at 10:47:27 PM UTC-5 [email protected] >>>>>>> wrote: >>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> I have been working on trying to use the GPU module in project >>>>>>>> chrono to fill a vessel with spherical particles. I have been able to >>>>>>>> successfully do so by using the method in the demos of generating >>>>>>>> particle >>>>>>>> sheets and allowing them to settle in the vessel. I have recently, >>>>>>>> however, >>>>>>>> been attempting to fill the vessel with a "particle source" method >>>>>>>> that >>>>>>>> continuously streams particles into the domain until a certain number >>>>>>>> of >>>>>>>> particles is reached. I am unsure if this method is officially >>>>>>>> supported >>>>>>>> with the GPU module, and I am encountering crash that continuously >>>>>>>> seems to >>>>>>>> happen. I receive the error *No available contact pair slots for >>>>>>>> body # and body # *after the simulation has progressed. It seems >>>>>>>> to occur sometime after the particles hit the bottom of the vessel. I >>>>>>>> have >>>>>>>> tried reducing my timestep, reducing the "flow rate" of incoming >>>>>>>> particles, >>>>>>>> changing the height of the particle inflow, and altering some >>>>>>>> stiffness/damping constants, but this error seems to always happen >>>>>>>> soon >>>>>>>> after the particles make contact with the vessel. I have attached my >>>>>>>> input >>>>>>>> files, any help would be appreciated. >>>>>>>> >>>>>>>> An unrelated question, but does the GPU module support the changing >>>>>>>> of particle positions during the simulation (i.e. taking all particles >>>>>>>> below a certain z and moving them to the top to "recycle" them >>>>>>>> continuously >>>>>>>> during the simulation)? >>>>>>>> >>>>>>>> Thanks! >>>>>>>> David >>>>>>>> >>>>>>>> >>>>>>>> -- 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/1f7b9b9f-2c6a-407f-a5e5-d56ea5815554n%40googlegroups.com.
