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/5bd520e2-364e-4eb9-a03a-b758f4736ef7n%40googlegroups.com.
