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/ddf554bc-3a29-4186-831d-9f78349adcf0n%40googlegroups.com.
