[aerosayan]

I'm working on a 2D FVM compressible Euler solver, and was able to make a single threaded explicit solver.


I compared the explicit solver's performance with Hiroaki Nishikawa's EDU2D implicit solver.


The EDU2D implicit solver was significantly faster than my explicit code, even though Nishikawa acknowledges that the EDU2D solver wasn't built with performance in mind.


As per my understanding and some interaction I had with the author, EDU2D ramps up the CFL value and accelerates the solution process.


That was really fascinating to me and I wanted to implement other techniques that we can use to improve the performance of my FVM based compressible Euler solver.


Could you please share some papers or CFD codes that I can study to understand how to accelerate my solver?


In far future, I plan to use this solver to study flows inside rocket nozzles.
Currently it's only a hobby project.




ADDITIONAL MATERIALS


I. Some reasons why my explicit solver was slow:

- Used explicit formulation.
- Didn't use acceleration techniques such as SOR.
- My core loop had sever branch mis-prediction issues since my internal and boundary cells are mixed together.
- The cells weren't renumbered using a Space Filling Curve. So cache misses were high.

[aerosayan]

One solution I found, is using multigrid approach :

"Multigrid solution of the Euler equations using implicit schemes." by Antony Jameson and Seookwan Yoon, PAGE-1737-1743, AIAA JOURNAL, VOL. 24, NO. 11, November 1986, https://arc.aiaa.org/doi/10.2514/3.9518

Will be glad to receive information on other methods.

[t.teschner]

There are several oddities in your post. What do you mean by the implicit EDU2D code is faster than your explicit code? You mean in total wall clock time? That is not surprising if both solvers are running at different time steps. Even if all input parameters are the same (including the CFL number and timestep), you would still see a difference in performance because one uses explicit and the other implicit time stepping. Are you writing your solver in the same programming language as the EDU2D solver? And are you using the same compiler flags in terms of optimisation for both programs? There are so many things that are influencing the solver performance that it is really difficult to read any meaning into the performance comparison if not done carefully.

As per the rest of your list, SOR is not an accelerator but a way to solve the linear system of equations for an implicit method, so you wouldn't be able to use it for your explicit scheme.

Are you using a structured or unstructured mesh? For structured meshes you would typically not need to renumber your mesh elements as you should already be in a storage optimal data structure which promotes a minimum of cache misses, especially for a single-threaded program. Certainly, space-filling curves can be used to renumber your mesh, but if you have a structured mesh then chances are that you would have a lot more cache misses using space-filling curves. Also, the indexing is important, i.e. if you have two nested loops over the x and y direction, respectively, using an index i and j, is i or j your inner index? This is important to reduce cache misses, though compilers can optimise these for you if it is clear what you are doing and it is safe to optimise this by the compiler.

In your case, I would loop over internal cells (faces) first and then over the boundary cells (faces). Keep those loops separate and you will automatically reduce cache misses.

In general, I think there is always a point to make that we should always try to optimise our code first before we start to think about making it faster using parallelisation or other fancy CFD algorithms. The book of Hager and Wellein "Introduction to High Performance Computing for Scientists and Engineers" makes this point particularly well, I think, see Chapter 3 and 4.

In terms of schemes, if you decide to go implicit, you may want to check the paper by Buecker et al. On CFL Evolution Strategies for Implicit Upwind Methods in Linearized Euler Equations, which talks about different CFL ramping strategies as you have mentioned.

Multigrid can be an accelerator, but keep in mind that those were originally introduced for elliptic equations, the Euler equations are hyperbolic and it requires a lot more fine tuning and experience to get it to work properly. I am not saying that they can't be used, but from personal experience I have not always seen a clear cut advantage as is often attested to multigrids.

To sum up, and getting back to your question, I think the best way to improve performance is through your code and the way you design your data structure. Choose a high performant language. I was programming for a while in Fortran which is still very popular in CFD. However, programming languages have matured and these days I see no point in not using a different language that gives you additional tools at your disposal. C++'s standard template library (STL), for example, is both performant and offers you great algorithms pre-implemented into the language so you don't have to repeat and re-write the code. Similarly, it comes with optimised data containers and you don't have to write your own ones. In Recent years, there seems to be a move towards Julia in the scientific community, which is sort of the best of C++ and Python combined (Python's user-friendliness and ease of use combined with C++'s performance), so this may as well be a promising candidate to consider. I would steer away from Python and Matlab for anything where performance is of importance but would still recommend C and/or Fortran for someone who doesn't want to get stuck for hours on programming related problems.

Anyways, those are my thoughts, hopefully they are of use to you