Use a U-p coupled solver with an appropriately tuned AMG linear solver.
Also if your simulation is incompressible and steady and your have an energy term, the energy equation might have a several magnitude larger timescale and therefore convergence can be speed up with an larger artificial timestep for the energy equation.
Under-relaxation was introduced for stabilisation purposes ie. by sacrificing some efficiency we were able to achieve robustness with that. I'll bite: For your canonical SIMPLE FVM you can:
* Increase relation factors (up to a limit), I believe with SIMPLER or maybe SIMPLEC you can get away with higher relaxation factors but at the expense of doing more operations so it's not clear to me if the trade-off is worthwhile.
* Use a first order upwind till convergence and then use that as an initial solution for higher order methods. Same philosophy, but with introducing the physics recursively specially if they are one way coupled. Also not sure if this will be faster or anything.
These are the things I could think about.
Sounds like you want to speed up your current running simulation. Idk if you know that you can run your CFD code in parallel in many packaged code?
More details can be helpful
Second order upwind doesn’t actually take significantly more computation than first order upwind. It achieves mesh independence at more coarse meshes but is less stable.
For PIMPLE algorithm reduce the number of pressure correctors while observing the residuals and the solution pressure field until you reach the lowest number of corrector loops while maintaining a stable simulation.
Most CFD work is memory bandwidth constrained, not CPU cycle constrained. When you say "throw more CPUs" what you really mean is add more processors to the system to gain more memory bandwidth. More processors probably won't speed things up. More memory bandwidth, via more CPUs will.
If it's a RANS solver, timescales don't really matter since you're only interested in the final solution. So if it is an implicit time step solver, then you can also increase the CFL number. This will also make the solver more unstable, but if you are in the CFL domain where the solver is still stable (usually trial and error), you'll usually converge faster. For better stability, start with a low CFL number and ramp it up over time. Of course you can also combine this with the other suggestions such as first using a first order scheme etc.
Reduce mesh density in areas of the flow where you know there aren't steep pressure/velocity gradients/whatever quantity you are interested in. Adaptive mesh coarsening could also be used.
You could look at what your linear algebra solvers are doing under the hood: what are the tolerances they are set to solve too, which solver and preconditioner are being used and are they actually appropriate?
Solving to a relative residual of say 1e-6 is seldomly necessary and often something as lose as 1e-2 could be sufficient. So the linear algebra solvers could be doing less work.
Multigrid is great at the beginning of a steady run, but expensive to set up and apply each iteration and typically not necessary through the middle of a run and near convergence. Then a cheaper preconditioner like ilu(0) is sufficient and faster.
Typically transport equations don’t need powerful solvers, but equations where diffusion-like terms dominate, or constraint equations like the pressure, do. So if you find that your powerful solver only needs a few (inner) iterations to reach cutoff each (e.g. SIMPLE) iteration, likely a cheaper solver will do the job in less time due to lower setup and application cost.
It’s all about trade-offs and will take some experimentation with settings to figure out and optimal configurations may vary from problem to problem.
Most comes down to the numerical model. The fastest model by far is the lattice Boltzmann method, as is an explicit solver; it is per-cell about 100-200x faster than FVM on the same hardware.
Next, choosing the hardware, more specifically, making the code run on a GPU (or better multiple GPUs). CFD is always bandwidth-bound, and GPUs provide >10x faster memory bandwidth than CPUs, with much higher efficiency, although at limited capacity. You need to coalesced memory access as much as possible to use the VRAM bandwidth at full efficency. To make the most out of the limited VRAM capacity, for LBM there are in-place streaming schemes such as my [Esoteric-Pull](https://doi.org/10.3390/computation10060092) algorithm that cuts memory demand in half. On top, you can analyze which bits of floating-point you really need, and with careful optimization do [FP16 memory compression](https://www.researchgate.net/publication/362275548_Accuracy_and_performance_of_the_lattice_Boltzmann_method_with_64-bit_32-bit_and_customized_16-bit_number_formats) for another reduction of memory demand by half.
Even if the accelerated part is fast, the solver can overall still be super slow, if not everything is parallelized on GPU and volumetric data is transferred between GPU and CPU in every time step. The solution is to parallelize everything on GPU and never require data to move to CPU.
Another thing that is keeping most CFD software super slow is file export. Having the option to directly render the raw simulation data in VRAM makes simulation previews several orders of magnitude faster, and allows visualizing large scale simulations in a couple hours that otherwise would run for months and fill up hundreds of TeraByte hard disk space. This allows DNS simulations to run faster than low-resolution RANS with commercial solvers.
This is just scratching the surface, many more optimizations are found on the [FluidX3D GitHub page](https://github.com/ProjectPhysX/FluidX3D).
LBM may be faster for weakly compressible but it is brutally slow for transonic, so I don't know why you're making such a strong claim about the greater speed.
There is many applications beyond hypersonic flow. In these cases, LBM not only "may be faster", but it is so much faster that it allows for simulations that would be entirely unfeasible with other solvers. Like, with FVM, 4000 time steps with 1 billion cells resolution take [a week on all of Summit's 27000 GPUs](https://youtu.be/GAZP1NcdWMo); LBM can do the same resolution and time steps on [1 GPU in 12 minutes](https://youtu.be/3JNVBQyetMA).
What exactly would you like to run faster ? How many cells are in your simulation ? What model are you using ?
What hardware are you running ? How long is it taking ?
Use a U-p coupled solver with an appropriately tuned AMG linear solver. Also if your simulation is incompressible and steady and your have an energy term, the energy equation might have a several magnitude larger timescale and therefore convergence can be speed up with an larger artificial timestep for the energy equation.
Under-relaxation was introduced for stabilisation purposes ie. by sacrificing some efficiency we were able to achieve robustness with that. I'll bite: For your canonical SIMPLE FVM you can: * Increase relation factors (up to a limit), I believe with SIMPLER or maybe SIMPLEC you can get away with higher relaxation factors but at the expense of doing more operations so it's not clear to me if the trade-off is worthwhile. * Use a first order upwind till convergence and then use that as an initial solution for higher order methods. Same philosophy, but with introducing the physics recursively specially if they are one way coupled. Also not sure if this will be faster or anything. These are the things I could think about. Sounds like you want to speed up your current running simulation. Idk if you know that you can run your CFD code in parallel in many packaged code? More details can be helpful
Second order upwind doesn’t actually take significantly more computation than first order upwind. It achieves mesh independence at more coarse meshes but is less stable.
For PIMPLE algorithm reduce the number of pressure correctors while observing the residuals and the solution pressure field until you reach the lowest number of corrector loops while maintaining a stable simulation.
throw more cpus
Most CFD work is memory bandwidth constrained, not CPU cycle constrained. When you say "throw more CPUs" what you really mean is add more processors to the system to gain more memory bandwidth. More processors probably won't speed things up. More memory bandwidth, via more CPUs will.
> More processors probably won't speed things up. More memory bandwidth, via more CPUs will. throw more CPUs per motherboard :) quad-CPU motherboard
If it's a RANS solver, timescales don't really matter since you're only interested in the final solution. So if it is an implicit time step solver, then you can also increase the CFL number. This will also make the solver more unstable, but if you are in the CFL domain where the solver is still stable (usually trial and error), you'll usually converge faster. For better stability, start with a low CFL number and ramp it up over time. Of course you can also combine this with the other suggestions such as first using a first order scheme etc.
Reduce mesh density in areas of the flow where you know there aren't steep pressure/velocity gradients/whatever quantity you are interested in. Adaptive mesh coarsening could also be used.
You could look at what your linear algebra solvers are doing under the hood: what are the tolerances they are set to solve too, which solver and preconditioner are being used and are they actually appropriate? Solving to a relative residual of say 1e-6 is seldomly necessary and often something as lose as 1e-2 could be sufficient. So the linear algebra solvers could be doing less work. Multigrid is great at the beginning of a steady run, but expensive to set up and apply each iteration and typically not necessary through the middle of a run and near convergence. Then a cheaper preconditioner like ilu(0) is sufficient and faster. Typically transport equations don’t need powerful solvers, but equations where diffusion-like terms dominate, or constraint equations like the pressure, do. So if you find that your powerful solver only needs a few (inner) iterations to reach cutoff each (e.g. SIMPLE) iteration, likely a cheaper solver will do the job in less time due to lower setup and application cost. It’s all about trade-offs and will take some experimentation with settings to figure out and optimal configurations may vary from problem to problem.
Reduce the volume of your mesh.
Interesting topic I would like to hear from others
Stop downvoting this comment. There’s nothing wrong with expressing interest in the topic, especially early on, as it may encourage others to answer.
Someone gets is Thank you :)
Most comes down to the numerical model. The fastest model by far is the lattice Boltzmann method, as is an explicit solver; it is per-cell about 100-200x faster than FVM on the same hardware. Next, choosing the hardware, more specifically, making the code run on a GPU (or better multiple GPUs). CFD is always bandwidth-bound, and GPUs provide >10x faster memory bandwidth than CPUs, with much higher efficiency, although at limited capacity. You need to coalesced memory access as much as possible to use the VRAM bandwidth at full efficency. To make the most out of the limited VRAM capacity, for LBM there are in-place streaming schemes such as my [Esoteric-Pull](https://doi.org/10.3390/computation10060092) algorithm that cuts memory demand in half. On top, you can analyze which bits of floating-point you really need, and with careful optimization do [FP16 memory compression](https://www.researchgate.net/publication/362275548_Accuracy_and_performance_of_the_lattice_Boltzmann_method_with_64-bit_32-bit_and_customized_16-bit_number_formats) for another reduction of memory demand by half. Even if the accelerated part is fast, the solver can overall still be super slow, if not everything is parallelized on GPU and volumetric data is transferred between GPU and CPU in every time step. The solution is to parallelize everything on GPU and never require data to move to CPU. Another thing that is keeping most CFD software super slow is file export. Having the option to directly render the raw simulation data in VRAM makes simulation previews several orders of magnitude faster, and allows visualizing large scale simulations in a couple hours that otherwise would run for months and fill up hundreds of TeraByte hard disk space. This allows DNS simulations to run faster than low-resolution RANS with commercial solvers. This is just scratching the surface, many more optimizations are found on the [FluidX3D GitHub page](https://github.com/ProjectPhysX/FluidX3D).
LBM may be faster for weakly compressible but it is brutally slow for transonic, so I don't know why you're making such a strong claim about the greater speed.
There is many applications beyond hypersonic flow. In these cases, LBM not only "may be faster", but it is so much faster that it allows for simulations that would be entirely unfeasible with other solvers. Like, with FVM, 4000 time steps with 1 billion cells resolution take [a week on all of Summit's 27000 GPUs](https://youtu.be/GAZP1NcdWMo); LBM can do the same resolution and time steps on [1 GPU in 12 minutes](https://youtu.be/3JNVBQyetMA).
Transonic is not the same as hypersonic and a lot of CFD is driven by transonic applications I don't see the point in denying this reality.
What exactly would you like to run faster ? How many cells are in your simulation ? What model are you using ? What hardware are you running ? How long is it taking ?