Hi Yves, This is expected. The step sizes 1e-4, 5e-5, and 3e-5 you used gave unphysical responses since they were not fine enough to capture the collision. Past those, it becomes better. I'd like to note that the test scenario is challenging to begin with, since the ball impacts with a high velocity and the wall stiffness is very high (2.5e11 Pa), making the contact difficult to resolve. I am not surprised at all that it requires a step size as small as 1e-5s. You should try smaller step sizes too, and they should converge to a specific bouncing pattern, and this is perhaps the way to find an appropriate step size to use (the largest one that gives this "converged" bouncing).
In reality, the vast majority of DEM simulations use artificially reduced stiffness to relax the physics, with empirically decided step sizes. The rule is trying to ensure that the contact events are resolved with no less than 4 time steps (but more is even better), but it's not always necessary to do separate tests to find that out. Reasonable bulk metrics like total energy or max velocity are sometimes enough of an indicator of good simulations, plus many simulations have main physics driven by prolonged contacts like grinding rather than "hard" collisions, making resolving "worst" contacts like the collisions that happen only in parts of the simulation not a big concern. You probably know that DEM-Engine has the method *UpdateStepSize *to allow for on-fly step size change, should the physics change significantly at different parts of your simulation which mandates an update on the step size. However, that is manual and requires that you have an idea of the appropriate step size. As for automatic step size adaption, it is a bigger engineering problem, and the way I plan to implement that involves a complex prerequisite subsystem too (I won't spoil it). It will not be there too soon, because the testing needed to show it is a meaningful mechanism sounds like a full paper to me. Thank you, Ruochun On Saturday, March 16, 2024 at 1:00:42 AM UTC+8 [email protected] wrote: > Hello, > > I wanted to verify that my time step was right in my "ball drop" > simulations. in DEM-Engine. > One minimal example I created is attached. I just drop one ball in a 5 > meter-high box from z=2m with a null velocity. Then, I record and plot the > velocity and elevation of the ball over time. > > Here are some examples attached, with dt=1e-4, 1e-5, 2e-5, 3e-5, and 5e-5 > seconds. > > What I found is that the behavior of the ball is completely different > between different time steps: the bounces can make the ball go higher than > its initial position, which breaks the energy conservation. Even stranger, > setting a very small time step also leads to that issue. > > Here, I do not know which one should be taken as true, dt=1e-5s seems > good, but if I double the time step there are still bounces, just lower. > Here this is for a very simple example, but that tells me that there is too > much variability in the results based on the time step. > > Therefore, I was wondering: is there an issue with my test? If not, how do > we know the time step we are setting is hitting the sweet spot: not too > low, not too large? Is there a criterion we can use? And finally, can > DEM-Engine adapt its time step automatically to prevent the user to play > with that value when it might produce unrealistic behaviors? > > Thanks! > > -- 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/09513a98-984a-4f09-a6c9-38cc88f62d05n%40googlegroups.com.
