Hi guys,
Just wondering if pyfr can use a data file containing fluid field variables as the initial condition. I want to do a benchmark between pyfr and nektar and I want to use fluid field from nektar output to restart on pyfr. The data format is just .dat.
And maybe more partially, how can I extract rans simulation result as bc in pyfr? Does pyfr have corresponding tools for this propose?
Cheers,
Zhenyang
For this you would need to create an initial solution file yourself which is specific to the .ini file you plan to run the case with. The difficult bit here is ensuring that the data you have is suitably interpolated onto the solution points which will be used by the PyFR simulation. This requires some care.
Regards, Freddie.
Hi Freddie,
Thanks for your reply. I guess you mean I have to write my own .pyfrs from my data and use that as a restart file, right? But the difficult point here is the .pyfrs file is compressed and data structure can’t be found. Can you please inform me what structure it looks like
Cheers
Zhenyang
The .pyfrs format, although stable, is not formally documented outside of the source code. Nevertheless, it is not particularly difficult to work with (and indeed several other high-order CFD codes including incorporated support for it).
Regards, Freddie.
Hi Freddie,
Sorry for my ignorance, I still don’t have clue about it. Let me make it clear: I have a file containing the flow variables, and I want to use it as the initial condition on pyfr, the simulation will be on the same set of mesh so there’s no need to worry about interpolation. My question is how to tell pyfr to recognise the data file (more clearly, how to indicate it in the .ini file). It will be wonderful if you have some example files.
Btw, maybe you are interested, pyfr gpu version is much much faster than nektar++, but I can’t give you the exact figure how much it is faster at present. And maybe in next few weeks, me and my colleague will add Nek5000 into comparison as well.
Zhenyang
Interpolation is still very likely required here, even if the mesh is the same. This is on account of the fact that the solution is stored inside of each element as a nodal polynomial. Hence, if your data file is at a different polynomial order or employs a different set of nodal points then interpolation will be required to generate the solution file.
Regards, Freddie.
Yes that’s a very good point. I have used same polynomial order and GLL points inside the element for both simulations so I guess it’s the same but still, I will compare the position of each node. As for interpolation, does pyfr has any inbuilt function to do this?
Zhenyang
There are internal interpolation routines in PyFR, but you will need to write some code to use them. See shapes.py and polys.py in the code.
As an aside GLL points are not recommended and almost always result in worse numerical performance compared with GL points. This difference more than offsets any computational benefits associated with GLL points.
Regards, Freddie.
3 posts were split to a new topic: Nektar++ comparison