Hi Yves, I only had a brief look at the script. So what you needed is to add more spherical particles into the simulation, one by one, and I assume you need to do this thousands of times.
The problem is that adding clumps, or say *UpdateClumps()*, is not designed to be called too frequently, and it's really for adding a big batch of clumps. When you call it, you need to sync the threads (perhaps the cost of one round of contact detection), then the system goes through a process that is similar to initialization (no just-in-time compilation, but still a lot of memory accesses). Although I would expect it to be better than what you measured (6.2s), maybe you also included the time needed to advance a frame in between---I didn't look into that much detail. In any case, it's much better to get rid of adding clumps. If you know how many you will have to add eventually, then initialize the system with them in, but frozen (in a family that is fixed and has contacts disabled with all other families). Track these clumps using a tracker (or more trackers, if you want). Then each time you need to add a clump, use this tracker to change a clump in this family (using offset, starting from offset 0, then moving on to 1, 2... each time) to be in a different family so it becomes an "active" simulation object. Potentially, you can SetPos this clump before activating it. This should be much more efficient, as a known-sized simulation should be. As for material properties, I don't think they have significant effects here. Let me know if there is any difficulty implementing it, Ruochun On Wednesday, January 31, 2024 at 1:27:17 AM UTC+8 [email protected] wrote: > Hello, > > I am working on a problem which involves dropping one sphere at a time in > a geometry from its top in DEME-Engine. The geometry can have multiple > hundreds of thousands of spheres poured in it, so I would need something > efficient. The constraint is that I have to always drop the sphere with a > null velocity from the same spot. > > The problem I have is that it is very slow. > > I made an example attached, where I fast-forward to 50,000 spheres in the > geometry, then drop them one by one. When measuring the performance (see > log attached), I obtain something like 6.2 seconds per drop. The overhead I > measured, when starting from 0, was ~0.2s, so it gives 6/50000=120e-6 > s/sphere. If I adjust perfectly the step size to have a drop, that means > that to fill the geometry with, says 500,000 spheres, it would take me > around 6 months of computation to complete. > > Therefore, I write to see if: > > 1. Something is wrong my script. > 2. Some values can be safely relaxed. The Young's modulus and other > sphere parameters were taken from a paper, so I would prefer not to touch > it. The time step seems already fairly high in my example. > 3. If there are techniques that could be applied to lower the > computation for this kind of common problem. > > Thank you! > -- 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/df3ddd66-9e4a-4ab0-a383-0ce540fe1063n%40googlegroups.com.
