Hi Yves, Make sure that after making the change in ChrGpuDefines.h that you are rerunning make in both your chrono_build directory, and in the application directory so that everything is properly linked with the changes. The script previously posted should work once the changes are made, I only increased MAX_SPHERES_TOUCHED_BY_SPHERE to 12 and it worked for me.
Thanks, David On Tuesday, June 14, 2022 at 8:16:05 AM UTC-7 [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/d8081fae-a7c9-4912-87de-aed019f467a3n%40googlegroups.com.
