^@^@^@\>^C33\>^Fff\> \231\232\>^L\314\315\>^P^@
^@\>^S33\>^Vff\>^Y\231\232\>^\314\315\> ^@^@\>#33\>&ff\>)\231\232\>,\314\315\>0^@^@\>333\>6ff\>9\231\232\>\<\314\315\>@
^@^@\>C33\>Fff\>I\231\232\>L\314\315\>P^@^@\>S33\>Vff\>Y\231\232\>\314\315\>`^@^@\>c33\>fff\>i\231\232\>l\314\315\>p^@
^@\>s33\>vff\>y\231\232\>|\314\315\>\200^@^@\>\201\231\232\>\20333\>\204\314\315\>\206ff\>\210^@^@\>\211\231\232\>\2
1333\>\214\314\315\>\216ff\>\220^@^@\>\221\231\232\>\22333\>\224\314\315\>\226ff\>\230^@^@\>\231\231\232\>\23333\>\
234\314\315\>\236ff\>\240^@^@\>\241\231\232\>\24333\>\244\314\315\>\246ff\>\250^@^@\>\251\231\232\>\25333\>\254\31
4\315\>\256ff\>\260^@^@\>\261\231\232\>\26333\>\264\314\315\>\266ff\>\270^@^@\>\271\231\232\>\27333\>\274\314\315\>
\276ff\>\300^@^@\>\301\231\232\>\30333\>\304\314\315\>\306ff\>\310^@^@\>\311\231\232\>\31333\>\314\314\315\>\316ff\
> \320^@^@\>\321\231\232\>\32333\>\324\314\315\>\326ff\>\330^@^@\>\331\231\232\>\33333\>\334\314\315\>\336ff\>\340^
> @^@\>\341\231\232\>\34333\>\344\314\315\>\346ff\>\350^@^@\>\351\231\232\>\35333\>\354\314\315\>\356ff\>\360^@^@\>\3
> 61\231\232\>\36333\>\364\314\315\>\366ff\>\370^@^@\>\371\231\232\>\37333\>\374\314\315\>\376ff?^@^@^@?^@\314\315
> ?^A\231\232?^Bff?^C33?^D^@^@?^D\314\315?^E\231\232?^Fff?^G33?^H^@^@?^H\314\315? \231\232?
> ff?^K33?^L^@^@?^L\314\315?^M\231\232?^Nff?^O33?^P^@^@?^P\314\315?^Q\231\232?^Rff?^S33?^T^@^@?^T\314\315?
> ^U\231\232?^Vff?^W33?^X^@^@?^X\314\315?^Y\231\232?^Zff?\[1\]\231\232?^^ff?^\_33? ^@^@
> ? \314\315?!\231\232?"ff?#33?^@^@?\314\315?%\231\232?&ff?‘33?(^@^@?(\314\315?)\231\232?\*ff?+33?,^@^@?,
> \314\315?-\231\232?.ff?/33?0^@^@?0\314\315?1\231\232?2ff?333?4^@^@?4\314\315?5\231\232?6ff?733?8^@^@?8\3
> 14\315?9\231\232?:ff?;33?\<^@^@?\<\314\315?=\231\232?\>ff??33?@^@^@?@\314\315?A\231\232?Bff?C33?D^@^@?D\314
> 1\232?vff?w33?x^@^@?x\314\315?y\231\232?zff?{33?|^@^@?|\314\315?}\231\232?~ff?^?33?\200^@^@
> POINT\_DATA 308481
> Scalars u’ float
> LOOKUP\_TABLE default
* * *
1. 33?^^@^@?^\314\315?^
---
### Author:  [@Kenneth\_Moreland](https://discourse.paraview.org/u/Kenneth_Moreland)
#### Post date: [July 27, 2021, 12:37pm UTC](https://discourse.paraview.org/t/image-size-changes-with-the-number-of-grid-points/7564/9 "2021-07-27T12:37:45Z")
I don’t think pasting binary files into a discourse comment is going to work. Can you attached the files by using the upload button at the top of the comment box or using drag and drop?
---
### Author:  [@hopitigala](https://discourse.paraview.org/u/hopitigala)
#### Post date: [July 27, 2021, 1:52pm UTC](https://discourse.paraview.org/t/image-size-changes-with-the-number-of-grid-points/7564/10 "2021-07-27T13:52:19Z")
Here are the files.
[xz1\_0064.vtk](https://discourse.paraview.org/uploads/short-url/6xZkAKluFSIljmgk5q1ZUCUJneh.vtk) (1.2 MB)
[xz1\_0063.vtk](https://discourse.paraview.org/uploads/short-url/uo2BKXAKne3jAfzP9ZYeA2YfQbt.vtk) (305.3 KB)
Thanks,
---
### Author:  [@Kenneth\_Moreland](https://discourse.paraview.org/u/Kenneth_Moreland)
#### Post date: [July 27, 2021, 2:27pm UTC](https://discourse.paraview.org/t/image-size-changes-with-the-number-of-grid-points/7564/11 "2021-07-27T14:27:15Z")
This is really weird. When you go to the later time step with the larger extent, the Information tab is correctly reporting the changed extent and the data are correctly rescaled in the view, but for some reason it is only loading the smaller extent of the data. That is, at the later time step it should be loading a 961x1x321 array, but it instead is just loading a 481x1x161 array.
This looks like it might be a bug with the VTK pipeline. I think either the pipeline at the reader is not updating the whole extent during the request information phase or the update extent is not being updated at the bottom of the pipeline during the request update extent phase.
@utkarsh.ayachit, do you want to take a look at this?
---
### Author:  [@hopitigala](https://discourse.paraview.org/u/hopitigala)
#### Post date: [July 27, 2021, 3:02pm UTC](https://discourse.paraview.org/t/image-size-changes-with-the-number-of-grid-points/7564/12 "2021-07-27T15:02:12Z")
One of my colleagues suggested me to use a new Paraview session for each change in grid resolution. I did that and was able to see the entire domain. However, this is painful in creating animations. I had to figure out the time steps where the resolution is altered and load them into separate Paraview sessions and create separate videos for each change in resolution. And then join each avi file to compose the entire animation. If we could find a better solution for this that would be great.
One other question is whether I can get the time variable in the header of these file to annotate with the animation. Does anyone has idea about it?
---
### Author:  [@mwestphal](https://discourse.paraview.org/u/mwestphal)
#### Post date: [August 2, 2021, 8:09am UTC](https://discourse.paraview.org/t/image-size-changes-with-the-number-of-grid-points/7564/13 "2021-08-02T08:09:20Z")
Usually caused by incoherence between extent and actual data.
---
### Author:  [@Kenneth\_Moreland](https://discourse.paraview.org/u/Kenneth_Moreland)
#### Post date: [August 2, 2021, 12:58pm UTC](https://discourse.paraview.org/t/image-size-changes-with-the-number-of-grid-points/7564/14 "2021-08-02T12:58:30Z")
I think the problem is that the `WHOLE_EXTENT` of this data is changing over time and ParaView is not changing the `UPDATE_EXTENT` accordingly. ParaView keeps trying to pull the extent from time step 0 even though that extent is no longer valid.
So, for any given file in the time series, there is no incoherence between the extent and the data. You can load any file in this series on its own just fine. But when you try to animate it, ParaView applies the extent from the first file to all files, and the incoherence appears. I raised a bug report here: [https://gitlab.kitware.com/paraview/paraview/-/issues/20863](https://gitlab.kitware.com/paraview/paraview/-/issues/20863).
---
### Author:  [@Kenneth\_Moreland](https://discourse.paraview.org/u/Kenneth_Moreland)
#### Post date: [August 3, 2021, 1:08pm UTC](https://discourse.paraview.org/t/image-size-changes-with-the-number-of-grid-points/7564/15 "2021-08-03T13:08:41Z")
While discussing this problem on the [bug report](https://gitlab.kitware.com/paraview/paraview/-/issues/20863), we found a possible workaround for this problem. Try adding the `Group Datasets` filter. (It is one of the common filters on the third toolbar.) That seems to fix the updating problems.
---
### Author:  [@mwestphal](https://discourse.paraview.org/u/mwestphal)
#### Post date: [August 3, 2021, 1:28pm UTC](https://discourse.paraview.org/t/image-size-changes-with-the-number-of-grid-points/7564/16 "2021-08-03T13:28:45Z")
Yes, I do not think this is supported to have a growing WHOLE\_EXTENT in ParaView
---
### Author:  [@hopitigala](https://discourse.paraview.org/u/hopitigala)
#### Post date: [August 6, 2021, 4:01am UTC](https://discourse.paraview.org/t/image-size-changes-with-the-number-of-grid-points/7564/17 "2021-08-06T04:01:55Z")
Group Datasets filter worked for my case.
---
### Author:  [@KillianBabilotte](https://discourse.paraview.org/u/KillianBabilotte)
#### Post date: [June 21, 2022, 11:58am UTC](https://discourse.paraview.org/t/image-size-changes-with-the-number-of-grid-points/7564/18 "2022-06-21T11:58:10Z")
Hello, I’m currently facing the same problem. My WHOLE\_EXTENT is growing over time but paraview doesn’t update and keep showing the data located in the first WHOLE\_EXTENT. I’m using .pvti files with 5 pieces (.vti) that are about 3GB each. And in this case the “Group Datasets” filter doesn’t seem to fix the problem. Have you any idea on what I could try to solve it ?