About Standard Scheme for incompressible solver

[Will]

Dear all,

I just wonder why std time integrator cannot be implemented in ac-euler or ac-navier-stokes solvers. Is dual-time stepping compulsory for incompressible solvers?

Additionally, does PyFR have any "do nothing" boundary conditions?

Best regards,
Will

[Freddie Witherden]

Hi Will,

On 29/10/17 19:35, Will wrote:
> I just wonder why std time integrator cannot be implemented in ac-euler
> or ac-navier-stokes solvers. Is dual-time stepping compulsory for
> incompressible solvers?

It is a requirement for artificial compressibility which is the
technique used by PyFR to implement incompressible Navier-Stokes.

> Additionally, does PyFR have any "do nothing" boundary conditions?

If by "do nothing" you mean a symmetry condition, then yes, most solvers
have those.

Regards, Freddie.

[Will]

Thanks Freddie,

Does it mean that for fully incompressible fluid, artificial compressibility should be "ac-zeta = 0.0" ?

Some other questions.
 
1. How can I continue my simulation from the latest time step?

2. Is it able to map the flow field from one case to another case, even regardless the difference of mesh? (Something like "mapFileds" in OpenFOAM)

3. Is there any command in PyFR that we can export all .pyfrs files to .vtu files at once rather than export one time step by one time step?

4. The output file is ".vtu", which is unreadable by text readers. Is there any command to export readable text file such as vtk, csv or text for the entire fluid field for post-processing? (Pretty similar to the output "U" and "p" file in OpenFOAM)

5. I am quite not sure what "[solver-dual-time-integrator-multip]" is in dual-time-stepping solvers, since it is deletable and simulation becomes much faster when it is deleted.

Best regards,
Will

[Vincent, Peter E]

Hi Will,

Thanks for your interest in PyFR.

Does it mean that for fully incompressible fluid, artificial compressibility should be "ac-zeta = 0.0” ?

No. You need some artificial compressibility for the approach to work.

1. How can I continue my simulation from the latest time step?

You can restart from a .pyfrm/.pyfrs file (pyfr restart mesh.pyfrm solution.pyfrs) - see the User Guide online.

2. Is it able to map the flow field from one case to another case, even regardless the difference of mesh? (Something like "mapFileds" in OpenFOAM)

No.

3. Is there any command in PyFR that we can export all .pyfrs files to .vtu files at once rather than export one time step by one time step?

There have been other threads on this. For various reasons, it is best just to write a quick BASH script.

4. The output file is ".vtu", which is unreadable by text readers. Is there any command to export readable text file such as vtk, csv or text for the entire fluid field for post-processing? (Pretty similar to the output "U" and "p" file in OpenFOAM)

5. I am quite not sure what "[solver-dual-time-integrator-multip]" is in dual-time-stepping solvers, since it is deletable and simulation becomes much faster when it is deleted.

Which simulation?

Thanks

Peter

Dr Peter Vincent MSci ARCS DIC PhD FRAeS
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

On 31 Oct 2017, at 03:45, Will <hol...@gmail.com> wrote:

Warning from Imperial College ICT:  This message contains a link to a website sometimes used by "phishers" to steal credentials.  

 

Caution is advised when clicking on these links. To avoid credential theft, you should not enter your Imperial College username and password into any form linked from this message.

 

The original messages continues below.

---

-- 
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.

[Loppi, Niki]

Hi Will,

5. I am quite not sure what "[solver-dual-time-integrator-multip]" is in dual-time-stepping solvers, since it is deletable and simulation becomes much faster when it is deleted.

In the artificial compressibility formulation, you need dual time stepping to recover time-accuracy. To put it shortly, the physical time is discretised with a BDF scheme whose solution is iterated with explicit pseudo-time stepping in fictitious time. The analogy to OpenFOAM is that the pseudo-time stepping is like solving the Poisson equation for pressure in more local way.

[solver-dual-time-integrator-multip] enables polynomial multigrid acceleration in the pseudo-time. If it is enabled you perform pseudo-niters-max number of multigrid cycles within each time step. If you remove the multip field you perform pseudo-niters-max number of iterations, not cycles. So if you keep pseudo-niters-max constant, removing the field makes the simulation quicker, but it also means that your convergence is much worse.

Cheers,

Niki

[Kurt Sansom]

Hi,
I am investigating using pyfr for use in cardiovascular simulations where the use of gpus is desired.
What is the reasoning behind implementing the artificial compressibility method versus other incompressible approaches?

Does it lend itself well to the flux reconstruction method over others? or does it parallelize more easily? I have been reading about the method but would like to be pointed where to look for more information?
Regards,

Kurt sansom

[Niki Loppi]

Hi Kurt,

Thanks for you interest in the project.

The main reason for the artificial compressibility method is that is
well-suited for modern parallel platforms which have an abundance of
compute capability to memory bandwidth. When you discretise it with flux
reconstruction in space and explicit dual time stepping in time, the
majority of operations can be cast as matrix-matrix multiplications.
Pressure based algorithms (Poisson equation) / fully implicit time
stepping tend to require more coupling between elements which introduces
memory indirection. Moreover, many of the linear solvers are not scale
invariant and increasing parallelism can decrease the efficiency of the
preconditioner. Finally, the flux Jacobian matrices in 3D at higher
orders are very large which can limit the problem size especially on GPUs.

In summary, we are developing the solver to maximise local computation.
There are several acceleration techniques that can be added without
compromising the parallel efficiency. For instance, the polynomial
multigrid that has already been implemented gives 3.5x speed-up compared
to pseudo-time stepping only at the highest level. Other explicit
acceleration techniques will be added in the future releases.

Cheers,
Niki

[Will]

Dear all,

Is there any benchmark on choosing max number of iterations for pseudo time step considering accuracy? It seems there is a strong connection between the max number of iterations and real calculation time for each physical time step.

Best regards,
Will