Hi David, It's a bit weird, I checked and I almost did not change anything. I did comment out line 120~122 (because in your json file you don't have rolling friction defined), but I tested adding them back and it affected nothing, I can still run it. Are you running it with your original mesh? If so can you have a try with the mesh I attached in a earlier post let me know if it helps? If it does not help, we can go from there; however I'd be very confused at that point.
Thank you, Ruochun On Monday, May 16, 2022 at 2:43:17 PM UTC-5 [email protected] wrote: > Hi Ruochun, > > Sorry, I had made some changes to my script. I redownloaded the original > scripts I provided here earlier, and rebuilt chrono with the feature/gpu > branch from a fresh repo clone with the touched by sphere change. After > doing all of this and running the exact same script that I had uploaded > originally, I now got a “negative local pod in SD” error around frame 90. > This is a bit strange since you had managed to run that script > successfully, and everything was a clean install with the same script that > I uploaded, so it should’ve had the same outcome as your run. Did you make > any changes to the script/json? > > On Monday, May 16, 2022 at 12:29:58 PM UTC-6 Ruochun Zhang wrote: > >> 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/5c164202-c2f9-43ac-aebb-049d20db6b22n%40googlegroups.com.
