However, when I add a AnnotateTimeFilter, it only reads “Time: 0.000000”, as a single row into its Data Array, so when I change the time with the toolbar, the Annotation will always show “Time: 0.000000”.
I first figured that maybe my small timesteps were being cut off by precision, so I used TemporalShiftScale to change them all to values larger than 1, and then used AnnotateTimeFilter, but the result is unchanged.
I have not been able to find a topic with this issue. My bandaid solution is manually applying a Shift from 0 to my current timestep, but this bandaid won’t help if I want to create an animation with a filter that automatically updates as the time is advanced.
I resolved this issue by applying a Annotate Time source before applying the Annotate Time Filter. If that is the intended use, I suppose the user guide had not made that clear to me.
Applying the Annotate Time source shouldn’t be required, hence it is not in the documentation. The Annotate Time Filter should use the time step information set on the data set (DATA_TIME_STEP information key for developers) and if that isn’t available, it should display ParaView’s current time. That seems to be working fine with the Wavelet source with timesteps I defined manually in the Time Manager - the Wavelet source doesn’t set a time step (pipeline: Wavelet → Annotate Time Filter), but the Annotate Time Filter displays ParaView’s current time.
Also, I tested loading the pflotran_kupp_flow.h5 test file with ParaView 5.13.3, which uses the VisItBridge PFLOTRAN reader, and Annotate Time Filter worked as expected with it, so I don’t suspect a systemic issue with readers in VisItBridge.
Maybe try setting the Format property of the Annotate Time Filter to “Time: {time:e}”? That should render the time in scientific notation.
And if that doesn’t help, like @mwestphal said, there is likely a bug somewhere along the way most easily found using the dataset that raises the issue.
Unfortunately I am unable to share my data publicly. I did however generate for you a 1D minimum working example, with the same data structure and leads to the same behaviour with AnnotateTimeFilter. I have 3 timesteps attached as separate hdf5 files (same format I would typically use). hdf5_plt_cnt_0000 (366.3 KB) hdf5_plt_cnt_0001 (366.3 KB) hdf5_plt_cnt_0002 (366.3 KB)
I open these files (in a client with VisItBridge enabled) using the VisitFLASHreader with the pattern hdf5_plt_cnt_00..
I apply TimeShiftScale with a scale of 1e9,
Then I apply AnnotateTimeFilter (I get the bug regardless of the format I use here, I tried @cory.quammen suggestion to use scientific notation as well).
I change the timestep using the toolbar, which updates the data correctly, but does not update AnnotateTimeFilter.
Thanks. Can you show what your pipeline looks like? It might be a bug specific to my build because I am not able to reproduce. Note the time in the toolbar is not reflected in 16 digits of precision in the annotation.
I installed the 5.13.3 Linux binary as well as the 6.0.0-RC3 Linux binary, and neither fixed the issue, with AnnotateTimeFilter still showing 0.000 at all timesteps.
So I finally figured out what is happening (kinda) and why we do not see the same thing.
The Visit flash reader has two modes, one were it outputs a AMR and one where it outputs a Multiblock datasets.
To switch between then two modes, just select the non-amr block in the properties and it will output a multiblock, this is what I was doing.
By the way, this is not recommended for a reader to change its outputs like that but it should not have impact on the time in ParaView.
So, why would that impact the AnnotateTimeFilter ?
Well, as it turns out, there is a bug in VTK/ParaView where if there is an AMR source in the pipeline branch, time steps are not passed down correctly.
More investigation needed of course, but a simple reproducer is as follows:
