Hello Ruochun, Thank you for your answer.
That makes a lot of sense, especially since, in my case, I know how many I need from the beginning. Your proposed method is quite smart; I will try to implement it. I will run some tests and come back here to report the difference. Something else I was also wondering is there any way to kind of "relax" the problem in some parts of the geometry? The bottom of the geometry will not see large velocities and strong changes once few spheres have covered it, and that applies to the layers above later in the simulation. If that is a possibility somehow, I am expecting this to be a large time saver as well. Thank you, Yves On Thursday, February 1, 2024 at 3:35:11 AM UTC-5 Ruochun Zhang wrote: > 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/ecd803af-0e42-4cb5-8508-be22c449f127n%40googlegroups.com.
