# Best practice pyFR export solution **URL:** \ **Category:** Cases\ **Tags:** visualisation\ **Created:** [28 April 2023 12:51 UTC](https://pyfr.discourse.group/t/best-practice-pyfr-export-solution/808 "2023-04-28T12:51:50Z")\ **Posts on this page:** 13\ **Page:** 1
**Author:** ![Frankx9](https://avatars.discourse-cdn.com/v4/letter/f/3e96dc/32.png) [@Frankx9](https://pyfr.discourse.group/u/Frankx9)\ **Post date:** [28 April 2023 12:51 UTC](https://pyfr.discourse.group/t/best-practice-pyfr-export-solution/808/1 "2023-04-28T12:51:50Z")
Hi, do you have any advice regarding the export from `.pyfrs` to `.vtu` setting an appropriate division flag? At the moment I use the same number of divisions as my polynomial order but retaining a constant `-d 1` would save a lot of space but this can by any means affect the quality of the results. (e.g. various plots over lines or integral quantities calculations?) Do you have any suggestions? Moreover, I noticed that when converting the windowed time-averaged quantities with the same division of instantaneous solutions, the converted windowed file gets a bump in size of 13x whilst the instantaneous solution is roughly 1.5x (for the same `-d` flag). Is this normal, and why? Regards ---
**Author:** ![WillT](https://avatars.discourse-cdn.com/v4/letter/w/bc79bd/32.png) [@WillT](https://pyfr.discourse.group/u/WillT)\ **Post date:** [28 April 2023 13:30 UTC](https://pyfr.discourse.group/t/best-practice-pyfr-export-solution/808/2 "2023-04-28T13:30:19Z")
I wouldn’t use devision and instead use the high order vtu option. This will also reduce the export time, reduce memory usage in paraview and reduce fvtu file size. As to your point about the time averager, I have no idea why that mght be. I’ll look into it. ---
**Author:** ![Frankx9](https://avatars.discourse-cdn.com/v4/letter/f/3e96dc/32.png) [@Frankx9](https://pyfr.discourse.group/u/Frankx9)\ **Post date:** [28 April 2023 20:49 UTC](https://pyfr.discourse.group/t/best-practice-pyfr-export-solution/808/3 "2023-04-28T20:49:45Z")
Let me know about the time averager ---
**Author:** ![fdw](https://avatars.discourse-cdn.com/v4/letter/f/a587f6/32.png) [@fdw](https://pyfr.discourse.group/u/fdw)\ **Post date:** [29 April 2023 15:30 UTC](https://pyfr.discourse.group/t/best-practice-pyfr-export-solution/808/4 "2023-04-29T15:30:01Z")
> [@Frankx9](#): > > Moreover, I noticed that when converting the windowed time-averaged quantities with the same division of instantaneous solutions, the converted windowed file gets a bump in size of 13x whilst the instantaneous solution is roughly 1.5x (for the same `-d` flag) Do you have the exact sizes of the relevant `.pyfrs` files, the commands used, and the sizes of the resulting `.vtu` files? Are you also 100% sure that both files were computed at the same polynomial order? Regards, Freddie. ---
**Author:** ![Frankx9](https://avatars.discourse-cdn.com/v4/letter/f/3e96dc/32.png) [@Frankx9](https://pyfr.discourse.group/u/Frankx9)\ **Post date:** [30 April 2023 07:01 UTC](https://pyfr.discourse.group/t/best-practice-pyfr-export-solution/808/5 "2023-04-30T07:01:27Z")
Hi @fdw, I’ve noticed this behaviour with small files, in my case the windowed .pyfrs file was 2MB while the converted .vtu reached the ~120MB. I’ll let you know in a couple of days if this is consistent with bigger files Lastly a question regarding windowed and continuous time averaging: say that I have a simulation spanning t=[0,4]s. If I use window averaging with a dt-out=2s to compute Reynolds stresses in pyFR it will use for the first window the mean value (say of U) in t=[0,2]s and for the second window the mean value of U in t=[2,4]. If I use continuous averaging it will use the mean value (say U again) in t=[0,4]s Am I correct? If my guess is right, and I want to get unbiased turbulent statistics I need to use continuous averaging but there is no possibility to know a priori when I should start collecting them, hence a propri I cannot set tstart = value in continuous averaging. Do you have any suggestion to overcome this rather than restarting with continuous averaging? Maybe allowing user to specify a batch of useful tstart and in the end he can choose which one he wants to retain. What do you think? ---
**Author:** ![fdw](https://avatars.discourse-cdn.com/v4/letter/f/a587f6/32.png) [@fdw](https://pyfr.discourse.group/u/fdw)\ **Post date:** [30 April 2023 11:30 UTC](https://pyfr.discourse.group/t/best-practice-pyfr-export-solution/808/6 "2023-04-30T11:30:12Z")
> [@Frankx9](#): > > I’ve noticed this behaviour with small files, in my case the windowed .pyfrs file was 2MB while the converted .vtu reached the ~120MB. This itself does not mean much. Pass a high enough value for the level of sub-division and an arbitrarily large file size is possible. Regards, Freddie. ---
**Author:** ![Frankx9](https://avatars.discourse-cdn.com/v4/letter/f/3e96dc/32.png) [@Frankx9](https://pyfr.discourse.group/u/Frankx9)\ **Post date:** [2 May 2023 11:08 UTC](https://pyfr.discourse.group/t/best-practice-pyfr-export-solution/808/7 "2023-05-02T11:08:26Z")
What about averages? Regards ---
**Author:** ![WillT](https://avatars.discourse-cdn.com/v4/letter/w/bc79bd/32.png) [@WillT](https://pyfr.discourse.group/u/WillT)\ **Post date:** [2 May 2023 14:45 UTC](https://pyfr.discourse.group/t/best-practice-pyfr-export-solution/808/8 "2023-05-02T14:45:42Z")
The average files are handled in the same way as the solution files. So the same rules apply. ---
**Author:** ![Frankx9](https://avatars.discourse-cdn.com/v4/letter/f/3e96dc/32.png) [@Frankx9](https://pyfr.discourse.group/u/Frankx9)\ **Post date:** [2 May 2023 14:56 UTC](https://pyfr.discourse.group/t/best-practice-pyfr-export-solution/808/9 "2023-05-02T14:56:57Z")
> [@Frankx9](#): > > Lastly a question regarding windowed and continuous time averaging: say that I have a simulation spanning t=[0,4]s. > > If I use window averaging with a dt-out=2s to compute Reynolds stresses in pyFR it will use for the first window the mean value (say of U) in t=[0,2]s and for the second window the mean value of U in t=[2,4]. > > If I use continuous averaging it will use the mean value (say U again) in t=[0,4]s > > Am I correct? > > If my guess is right, and I want to get unbiased turbulent statistics I need to use continuous averaging but there is no possibility to know a priori when I should start collecting them, hence a propri I cannot set tstart = value in continuous averaging. Do you have any suggestion to overcome this rather than restarting with continuous averaging? Maybe allowing user to specify a batch of useful tstart and in the end he can choose which one he wants to retain. > > What do you think? I was referring to this, not to exporting. Sorry if I’ve not specified Regards ---
**Author:** ![WillT](https://avatars.discourse-cdn.com/v4/letter/w/bc79bd/32.png) [@WillT](https://pyfr.discourse.group/u/WillT)\ **Post date:** [3 May 2023 08:00 UTC](https://pyfr.discourse.group/t/best-practice-pyfr-export-solution/808/10 "2023-05-03T08:00:18Z")
Maybe the best course of action is to use windowed averaging, and then merge the averages after the run. That way you decide which windows to include. We have been working on a merge feature that isn’t quite ready yet, but it is straight forward enough to do yourself. ---
**Author:** ![Frankx9](https://avatars.discourse-cdn.com/v4/letter/f/3e96dc/32.png) [@Frankx9](https://pyfr.discourse.group/u/Frankx9)\ **Post date:** [3 May 2023 08:39 UTC](https://pyfr.discourse.group/t/best-practice-pyfr-export-solution/808/11 "2023-05-03T08:39:05Z")
Hi @WillT, I already come up with the same idea of averaging multiple windows but this will produce biased statistics. To actually compute them you need the averaged value over the entire average period and then average the fluctuations. This is not the same thing of averaging multiple windows. The thing of allowing a batch of tstart is something viable? Or easily to attain by digging into code? Regards ---
**Author:** ![WillT](https://avatars.discourse-cdn.com/v4/letter/w/bc79bd/32.png) [@WillT](https://pyfr.discourse.group/u/WillT)\ **Post date:** [3 May 2023 08:45 UTC](https://pyfr.discourse.group/t/best-practice-pyfr-export-solution/808/12 "2023-05-03T08:45:31Z")
I don’t follow how this approach doesn’t work for you? Say you are using the following config for you tavg plugin: ```ini avg-u = u avg-v = v avg-uu = u*u avg-vv = v*v avg-uv = u*v fun-avg-upup = uu - u*u fun-avg-vpvp = vv - v*v fun-avg-upvp = uv - u*v ``` If you were to merge windowed average files you would simply merge the `avg-` terms and then recompute the functional terms `fun-avg-`. This is exactly what I did here: [PyFR/tavg.py at 7ae172f2e1b85a0739d17cc04adf90ca8f775cb3 · WillTrojak/PyFR · GitHub](https://github.com/WillTrojak/PyFR/blob/7ae172f2e1b85a0739d17cc04adf90ca8f775cb3/pyfr/plugins/tavg.py#L368) That plugin class uses the new addition of CLI plugins to the develop branch. The standard deviation isn’t quite right at the moment but the averages are correct. ---
**Author:** ![WillT](https://avatars.discourse-cdn.com/v4/letter/w/bc79bd/32.png) [@WillT](https://pyfr.discourse.group/u/WillT)\ **Post date:** [15 September 2023 08:22 UTC](https://pyfr.discourse.group/t/best-practice-pyfr-export-solution/808/13 "2023-09-15T08:22:24Z")
A post was split to a new topic: [Understanding the tavg function terms](https://pyfr.discourse.group/t/understanding-the-tavg-function-terms/920)