Simplicits - Solver leads to slow simulated motion sometimes

[rdecharette]

Hello,

I've been using Simplicits for some time and with the help of @itsvismay it works well, but the newton solver sometimes generates "slow motion".
Put in words (sorry for the non-technical description): the first simulation steps are correct (collision, etc.) then -- randomly -- for a few simulation step it seems like the generate motion of the QPs slow down (visually, it looks like a slow motion). After some simulation steps, it may some time return to normal.

This 'slowmo' always happens upon contact of objects and is hardly predictable. The more objects there is, the more often this happen.
I'm currently using these solver options:

"direct_solve":False, 
"use_cuda_graphs":False,
"timestep":0.01, 
"max_newton_steps":20, 
"max_ls_steps":10, 
"newton_hessian_regularizer":1e-5,
"cg_iters":100, 
"conv_tol": 1e-7

with collision:

"collision_particle_radius": 0.05, 
"detection_ratio": 1.5, 
"impenetrable_barrier_ratio": 0.25,
"collision_penalty": 1000.0,
"max_contact_pairs": 50000, 
"friction": 0.5, 

Any idea on how to solve this ? With more than 10 objects, it happens in 3/4 of the simulation. I already tweaked parameters and it didn't help.

Unrelated: I also observed, that in some simulations, the memory allocated grows at each simulation step (usually only after collision steps) and I observe 10x growth after 400 simulation steps. Other similar simulations (same number of objects/qps, same params) with other initialization have memory remains more or less stable across the simulation after the scene reset call. Any idea ? I did not observe any correlation between "slowmo" and "memory growth".

Best.

[rdecharette]

Additional insight: when fixing all seeds the simulation behaves almost perfectly deterministic, yet I noticed that for the same seed the "slowmo" is sometimes triggered sometimes not.

I'm wondering if this relates then to cpu/gpu synchronization, since the renderer uses CPU to write the image file ?

Best.

[itsvismay]

Ah sorry, I missed this earlier.

Regarding the slow motion, one thing to try would be to disable collision bounds. Collision bounds will guarantee no intersections, but it does this by clamping the Newton update. This could be the cause of the damping/slow motion.

[itsvismay]

Regarding the memory growth, its very strange. The collision code is very memory hungry, especially for larger scenes because we build very large, dense collision jacobians.

However, I have not noticed that calling reset() improves memory performance. This seems suspicious, but I will debug it more carefully after the CVPR deadline.

[rdecharette]

Thanks @itsvismay for the suggestion. I disabled the collisions bounds which seems to help but not fully solve the problem. Now, instead of "slow motion" it sometimes almost "freezes" the update (though less often).

Any way, thanks and good luck for the CVPR deadline.

[itsvismay]

Following up on this @rdecharette.

I'm happy to help debug if you have a minimal example you could share?

Is there a big difference in the stiffnesses of the colliding objects? That could cause poor convergence during collisions.

[rdecharette]

Thanks @itsvismay. I'll try to come with a minimal example next week. It requires some work as this is part of a much bigger project.

Is there a big difference in the stiffnesses of the colliding objects? That could cause poor convergence during collisions.

No, it also happens sometime with only soft objects or only stiff objects colliding with the scene. Scenes object uses: {yms: 1e7, prs: 0.45, rhos: 1000, appx_vol: 1.} (although unsure if properties are useful given that the scene is kinematic).

I'd say slowmo happens 5% of the time with ~4 objects and around 90-100% with > 20 objects.