I have an issue reading data results when I use a specific time stepping schema.
In my simulation, I use variable time steps as follow:
242 times steps of 4.54545e-5 s
30 time steps of 1 s
242 times steps of 4.54545e-5 s
30 time steps of 1 s
242 times steps of 4.54545e-5 s
30 time steps of 1 s
and so on (the same pattern is repeated many times…)
At some point, I end up having solutions at following times:
… 536.387, 537.387, 538.387, 539.387, 540.387, 540.387045455, 540.387090909 …
and the problem occurs here. Paraview skips the results at time 540.387045455.
It seems like Praview does not make a difference between time 540.387 and 540.387045455 (based on a given tolerance or threshold) and skips one of them. This problem repeats many other times and at the end Paraview only shows me 6490 out of the 6900 time steps that are written in my simulation result file (.case; my simulation writes results in Ensight format).
I just tried to increase the Animation Time Precision to maximum value of 17 and reload the results, but didn’t solve the issue. Thank you for the suggestion.
I did a simulation with minimal result field (only the Temperature). With those results, I’ve created a tar.gz file that makes 1.2G (total of 6902 result files). What would be the better way to share this file?
Thanks for the data. I was not able to reproduce in ParaView 5.11.2 nor in in ParaView 5.12 RC2.
So you may want to try one of those more recent version.
I just downloaded Paraview 5.12 RC2 to try and I still have the problem (I’m using a pre compiled version and I launched Paraview on my Red Hat Enterprise Linux machine).
One thing I’ve noticed, time steps shown in Paraview don’t match the time steps written in the .case file. For instance, time step 20 in case file corresponds to time t=0.000909090909091s, but Paraview shows 0.000909090915229, as illustrated here :
It seems like errors accumulate in some way, since the last time step in the case file (#6900) corresponds to t=6810.5375s, but Paraview shows t=6810.53759766s (time step #6490), as illustrateed here:
Thanks for reporting, (https://gitlab.kitware.com/paraview/paraview/-/issues/22461). It should now be fixed in VTK, so it will be part of a future release of ParaView (after 5.12.0 that is already on its way), and soon will be part of the ParaView nightly builds.