Hi David, Oh sorry before you do that, could you try this: I assume you cloned Chrono and built from source. Then can you checkout the *feature/gpu* branch first, then apply the MAX_SPHERES_TOUCHED_BY_SPHERE change, and then build and try again with the script you failed to run initially? I did apply a bug fix in *feature/gpu* branch and it is probably not in *develop* branch yet, and I hope to rule out the possibility that this bug was hurting you.
Thank you, Ruochun On Monday, May 16, 2022 at 1:23:06 PM UTC-5 Ruochun Zhang wrote: > Hi David, > > I am pretty sure that script worked for me until reaching a steady state, > like in the picture attached. One thing is that I'd be quite surprised if > MAX_SPHERES_TOUCHED_BY_SPHERE = 200 and the kernels did not fail to > compile... I'd say something like 32 is the maximum that you should assign > it. Maybe you should try something like 30 to see if it works. But if it > still gives the same error, we have to have a look at the script. Is it > still the same script you attached? > > Changing particle sizes has large impact on the physics and, "contacts > over limit" problem can happen naturally (like in your first question), or > happen as a result of non-physical behavior in the simulation, which is > often related to improper sim parameters wrt the sphere radius. So it's > hard to say without context. One thing you should do is of course, > visualize simulation results before the crash and see if there is something > non-physical. > > Thank you, > Ruochun > > On Monday, May 16, 2022 at 10:41:03 AM UTC-5 [email protected] wrote: > >> Actually, it looks like the particle source still isn’t working, even >> when increasing the MAX_SPHERES_TOUCHED_BY_SPHERE up to 200. The simulation >> will run for longer, but still fail with the same contact pairs error. >> Interestingly, it seems like it will fail sooner if I made the particle >> source radius smaller (fails after 627 pebbles added (step 34) when the >> source radius is 0.26 and fails after 31499 pebbles added (step 85) when >> the source radius is 1.1.). Do I still just need to increase the number >> further or is this a different issue? >> >> Thanks! >> David >> On Monday, May 16, 2022 at 8:55:47 AM UTC-6 David Reger 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/bea2b4da-633c-4c5a-b440-dcf133661b3dn%40googlegroups.com.
