Hi Giuseppe,
I hope you’re doing well.
I’ve been running some tests to see how the CFL number (dtadaptfactor) affects MIPPS. My results show that as I increase the CFL number, MIPPS decreases—but I would have expected the opposite. Am I overlooking something in the setup or interpretation?
Thank you!
Best ,
Alireza
I’m actually surprised that the CFL has a measurable impact on the MIPPS metric at all. Since the MIPPS measures the number of iterations * particles per (wallclock, runtime —not simulated) second, the primary factors affecting the performance are the computational costs of each iteration, which is independent of the timestep width in general. To wit, if a simulation of 1M particles is doing 100 iterations per second (100MIPPS), that would be 100 iterations regardless of whether your timestep was 10^-4 or 10^-5.
Off the top of my head, the only way I see the CFL affecting the MIPPS metric would be because it triggers more or less frequent checkpointing: smaller timesteps would mean less frequent checkpointing so I would expect the MIPPS metric to go up rather than down —which I assume is why your expectation was similar?
How significant are the effects you’re seeing? What are the values before/after the CFL change? Are they still observable if you run with the --nosave --debug benchmark-only --maxiter 10000 (to run a fixed number of iterations with all saving disabled)
Thank you very much, Giuseppe!
Your explanation makes sense. I ran two sets of analyses:
1- For CFL values around 0.2, 0.3, and 0.35, MIPPS remain comparable.
2- However, at CFL = 0.2, 0.4 and 0.6, I observed that opposite trend—and in those runs, the wave gauge data returned NaN values after a few seconds. So, my conclusion is that with 100 m/s for the sound speed, I can’t use CFL more that 0.35.
I assume the neighbors list column refers to the period (in iterations) of the neighbors list rebuilding. For this, it makes sense that the more frequent the rebuild is, the lower the MIPPS are. If the measures are taken with writing enabled, it also makes sense that at lower sound speeds (resulting in larger timestep) the MIPPS decrease, because fewer iterations are needed to get to the next checkpointing. This is why the --nosave --debug benchmark-only flags are important when doing benchmarking: it avoids the influence of I/O (which is not only slow, but also unpredictable, so it can make the MIPPS estimation fluctuate over time).
