Tips on Time Playback of Solution Files

[Jonny Hyman]

Hello everyone!

I'm doing some simple tests to get acquainted with PyFR. 

I would like to have a time playback in Paraview? I can get the single solutions from the .pyfrs files and the export functionality to .vtu, but I'm not super clear on how to make a 4-dimensional simulation - effectively mashing all of the pyfrs solutions into one file or set of arrays which can be played back over time.

Does anyone have tips? I may just write a Python script to merge all of the data in the .pyfrs files into a time dependent vtu but I don't want to go through the trouble if there's some simpler solution.

Thanks so much!
Jonny

[Freddie Witherden]

On 13/12/2016 21:02, Jonny Hyman wrote:
> I'm doing some simple tests to get acquainted with PyFR.
>

> I would like to have a *time playback *in Paraview? I can get the single

> solutions from the .pyfrs files and the export functionality to .vtu,
> but I'm not super clear on how to make a 4-dimensional simulation -
> effectively mashing all of the pyfrs solutions into one file or set of
> arrays which can be played back over time.
>
> Does anyone have tips? I may just write a Python script to merge all of
> the data in the .pyfrs files into a time dependent vtu but I don't want
> to go through the trouble if there's some simpler solution.

You should be able to open up all of the .vtu files at once in ParaView
and then step through them using the built in UI.

In general, the kinds of simulations that PyFR is used for are of
sufficient scale that it is simply not practical to work with more than
a single solution file at a time. As such there has been no work around
merging multiple files together.

Regards, Freddie.

[Jonny Hyman]

Interesting! When you say PyFR isn't really used for simulations of sufficient scale, do you mean computationally, spatially, or based on complexity? It seems to me that the flux reconstruction approach should be scalable to many different flows, so I'm a bit confused as to what you mean. :)

Thanks so much for your helpful information! 

You guys are the best!

[Freddie Witherden]

On 14/12/2016 08:00, Jonny Hyman wrote:
> Interesting! When you say PyFR isn't really used for simulations of
> sufficient scale, do you mean computationally, spatially, or based on
> complexity? It seems to me that the flux reconstruction approach should
> be scalable to many different flows, so I'm a bit confused as to what
> you mean. :)

For a simulation of reasonable scale the .vtu files are often in excess
of 10 gigabytes per file. Thus, loading 50 or so of these files into a
single instance of ParaView is not really practical. Indeed, it is
likely to take several minutes to step between each point.

Merging 50 of these files together into a single .vtu file would result
in a ~500 gigabyte behemoth and thus would be very difficult to work with.

Regards, Freddie.

[Vincent, Peter E]

Hi Jonny,

Regarding:

Interesting! When you say PyFR isn't really used for simulations of sufficient scale,

I think you mis-read Freddie’s message, which said:

In general, the kinds of simulations that PyFR is used for are of 
sufficient scale that it is simply not practical to work with more than 
a single solution file at a time.

Typical simulations are of such scale that lumping a time series into a single file is not practical/sensible. Typically what we do is script paraview to process a series of individual files and produce an animation. And more recently we have been working to add in-situ vis capabilities such that PyFR can generate images, to make an animation, on-the-fly as the simulation proceeds. They latter approach significantly reduces the amount of data written to disk.

Peter

Dr Peter Vincent MSci ARCS DIC PhD
Reader in Aeronautics and EPSRC Fellow
Department of Aeronautics
Imperial College London
South Kensington
London
SW7 2AZ
UK

web: www.imperial.ac.uk/aeronautics/research/vincentlab
twitter: @Vincent_Lab

--
You received this message because you are subscribed to the Google Groups "PyFR Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pyfrmailingli...@googlegroups.com.
To post to this group, send email to pyfrmai...@googlegroups.com.
Visit this group at https://groups.google.com/group/pyfrmailinglist.
For more options, visit https://groups.google.com/d/optout.

[Nolan Dyck]

So it seems like the default output behaviour of PyFR should remain as-is for the reasons mentioned above, but I'm wondering if an extra option could be added to the ini file to adjust the naming conventions of the output files so that Paraview can load it as a time series? I'd be happy to handle this change.

Nolan

[Vincent, Peter E]

Hi Nolan,

Thanks for your interest in PyFR.

I’m not sure I follow. Paraview can’t, at the moment, read in native .pyfrm/s files - you have to convert them to .vtu files using pyfr export (which involves linear sub-sampling of the fundamentally polynomial solutions) - so it’s not just a case of changing output naming conventions (which I think we can control anyway?)

Sorry if I missed your point!

Cheers

Peter

[Nolan Dyck]

Peter,

Sorry I forgot for a moment that PyFR has an extra export step :S.

Right now a .pyfrs solution file can be exported to .vtu using, for example:

pyfr export couette_flow_2d.pyfrm couette_flow_2d-040.pyfrs couette_flow_2d-040.vtu -d 4

If I wanted to export all the timesteps (i.e. 0-40), then I would need to manually export each one, or write a script to do so.

Instead of this, can we just add a command line option for the export argument to process all output files matching the given base file name? So something similar to the following command would export all the timesteps:

pyfr export couette_flow_2d.pyfrm couette_flow_2d- couette_flow_2d_ -d 4 --all

Nolan

[Nolan Dyck]

I've attached a script which does what I've suggested: sequentially converts a series of .pyfrs files to .vtu files. It can be called like so:

python export_pyfr_timeseries.py couette_flow_2d rel\or\abs\path\to\soln\files\couette_flow_2d

The resulting .vtu files are automatically recognized as a time-series when loading into Paraview.

Nolan

[Freddie Witherden]

Hi Nolan,

On 17/07/2017 14:23, Nolan Dyck wrote:
> If I wanted to export all the timesteps (i.e. 0-40), then I would
> need to manually export each one, or write a script to do so.
>
> Instead of this, can we just add a command line option for the
> export argument to process all output files matching the given base
> file name? So something similar to the following command would export
> all the timesteps

Currently, the recommended way of exporting a bunch of .pyfrs files is
to use GNU parallel as:

parallel pyfr export -d5 mesh.pyfrm {} {.}.vtu ::: *.pyfrs

which is a one-liner that will export everything in parallel. Thus,
there is no means in PyFR for directly exporting a batch of files. Now,
it is true that we could improve the performance if it were all done in
PyFR for we could reuse some of the interpolation matrices. However,
even for moderately sized simulations it is simply not possible to open
up a large number of .vtu files; thus we have never investigated further.

Regards, Freddie.

[M S]

Dear Peter,

I hope you're doing well.

I am a PhD student at MIT and interested in parallel MPI based in-situ simulations.

You mentioned in this post from 2016 that you're working on in-situ animation while simulation is taking place with PyFR.

Do you have any models to demo this and some tutorials on how to get it to work please?

I am new to PyFR and just got it installed and have the simple couette_flow_2d example working properly with MPI on Linux. I am also able to post-process the solution files manually by converting the *.pyfrs files into *.vtu and then animating them in Paraview.

Any guidance on doing this in-situ is appreciated.

Many thanks.

Sincerely,

Mohamad Sindi

MIT

On Thursday, December 15, 2016 at 2:55:00 AM UTC-5, Vincent, Peter E wrote: