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/a05abbee-56e3-478f-be77-13fad96bfce2n%40googlegroups.com.
