Hello,

I am actually running into the exact same problem.

For instance, with the scripts attached in the first post, and modifying 
the MAX_SPHERES_TOUCHED_BY_SPHERE to 32 (then rebuilding the solver), I get 
the "No available contact pair" error after around 40 steps.
I am on the updated version of the feature/gpu branch, so I am a bit 
confused.

Do you have any clue of what it could be?

Best regards,
Yves
On Wednesday, June 8, 2022 at 7:07:16 PM UTC+3 Ruochun Zhang wrote:

> 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/42fec08e-dd31-4ec0-8ab4-936b45e0be97n%40googlegroups.com.

Reply via email to