Dear developers,
It seemly that the timestep value is not read correctly in version 3.10.4.
It always show 0 for all frames, as figure below
Hi,
Can we have a look at your trajectory file? Feel free to send it via DM, or email.
Also note that in certain situations it may well be that the “Timestep” attribute does not get updated.
For example, this can happen if you first import a trajectory file format containing timestep information and then, in a second step, replace it by importing a different kind of file that does not contain timestep information. If you choose not to reset the pipeline during this step, the old timestep attributes will remain in the list and won’t get updated.
Please describe in more detail what type of file you have imported, whether you have done this in one or more steps, and whether the Load Trajectory Modifier was used or not. Then we can say more precisely whether the observed behavior is intentional or not.
hi @kalcher,
Here is a part of my Lammps dump file
ITEM: TIMESTEP
33000
ITEM: NUMBER OF ATOMS
33152
ITEM: BOX BOUNDS xy xz yz pp pp pp
-3.6621357260638518e+00 7.7838848998036468e+01 0.0000000000000000e+00
-4.2287585529112874e+00 7.6400953960451176e+01 0.0000000000000000e+00
-8.0661571172000038e+01 1.6448753486494235e+02 0.0000000000000000e+00
ITEM: ATOMS id mol type xu yu zu c_peA
1 1 1 0.821083 -3.06783 -1.40126 -2.88781
2 0 1 -0.700598 -0.694002 49.5238 -3.15684
3 0 1 -1.22168 -0.341448 41.832 -2.93037
4 1 1 -0.427919 0.0850596 85.4338 -2.76038
5 0 1 -1.47978 0.282733 34.9307 -3.21459
6 0 1 -0.437876 -0.476318 71.0291 -3.31525
7 0 1 -0.657556 -0.220857 63.5242 -3.23592
8 0 1 -0.554372 -0.511504 13.3348 -3.24172
9 4 1 -0.613959 -0.786119 5.84773 -2.96526
10 0 1 -0.693075 -0.514894 27.7411 -3.19297
11 0 1 -0.505201 -0.347414 56.2923 -3.31904
12 4 1 -1.0078 -0.360999 78.2913 -3.20069
13 0 1 -0.884462 -0.47769 20.6667 -3.13617
14 0 1 -0.817824 51.6494 29.8597 -3.21887
15 0 1 -1.08495 51.54 22.5764 -3.0777
You can save it and check on you site.
I have checked my trajectory with some older Ovito versions, and it works as normal.
So, I think there is no problem with my dump files
@stukowski, I just simple open a dump file using Ovito gui, and the Timestep information did not show as described. I do not load more/ replace existed pipeline, just simple open a new file in a fresh ovito.
For more information, I am installing Ovito 3.10.4 basic on Win 11. And this error is found both in Ovito gui and python interface.
Thank you for providing further information. We would need the actual trajectory file though, to be able to investigate further. Could you please share it with us?
The file size is large. And I think it is not necessary.
You just need to copy the above text, and save it into few files, say, dump_1.cfg,…dump_10.cfg,… with different Timestep values. Then you will get the actual trajectory.
Thanks.
We do have our own test data thank you.
At this time, we still cannot rule out the possibility that the issue may be on your end. If you are unable to share your files with us, may I recommend verifying the headers on your end? Could you please run the following command and check if the timestep numbers are contiguous?
grep -A1 "TIMESTEP" dump_*.cfg > log.txt
Let me know what you find, you can share your log file (privately) via DM.
1 Like
And as a cross-check: What do you see when you load the following files into OVITO?
Thanks for your help.
test_dump_0.cfg (960 Bytes)
test_dump_1000.cfg (963 Bytes)
test_dump_2000.cfg (963 Bytes)
Thank you for your guide.
I have uninstalled my ovito, and reinstalled it again. And now I can see Timestep in GUI. However, I still can not get it in python interface
I will try to find what wrong and will provide more information
Thanks