Hello, Thank you for your answers.
It seems that after a clean install, it works. I must have done something wrong in the steps. I appreciate your support. Best regards, Yves On Wednesday, June 15, 2022 at 11:39:46 PM UTC+3 [email protected] wrote: > 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/5ee5cc41-db87-4d8b-9ca0-373326b40dadn%40googlegroups.com.
