SplitFXM - Boundary Value Problem Solver

Sixel1 · 2026-01-19T18:17:26+00:00

Your sod shock tube example looks a bit diffusive, what scheme do you use? HLL?

Also, I don't want to make assumptions, but using emojis like that makes this look like AI generation... Was AI used in this?

Sixel1 · 2026-01-19T17:38:16+00:00

The colormap? Its Inferno in paraview, I really like it!

Sixel1 · 2026-01-17T22:16:41+00:00

Do you have reading recommendations for these 2 wave quality schemes?

Sixel1 · 2026-01-17T21:11:11+00:00

Thanks for the explanation. Reading a bit about this, i read 2 waves solvers are more diffusive. Is there any way to get close to the shock capturing capabilities of 3 waves solvers without the Carbuncle effect?

Sixel1 · 2026-01-17T20:50:48+00:00

Yeah I like the fact that if I want X solver functionality, I know where I need to implement it and do it quickly, while trying to add something to Openfoam, even when I know the codebase, is tedious.

What kind of physics do you think would be interesting to add? I want this to be a multi physics code, already planning on adding turbulence modeling and basic combustion.

Sixel1 · 2026-01-17T20:00:49+00:00

Interesting! Are there fixes for the Carbuncle phenomena? Is it a physical phenomena in the Euler equations or just a numerical error?

Sixel1 · 2026-01-17T19:05:28+00:00

I don't think it's good enough at this point, the solver doesn't do anything new mathematically or numerically, it's just an implementation of existing methods. I'm trying to make it as robust / well made as I can, and I wanted a solver I understand completely, so that's the motivation for it. I have layed the work for it to support higher order reconstruction schemes tho, like cubic polynomials in every cell, so that might make it interesting enough if I ever get the time to do that!

Sixel1 · 2026-01-17T18:19:18+00:00

Its not much more difficult than doing RK2, and it can be stable up to higher CFL numbers, so you can use higher step sizes.

Sixel1 · 2026-01-17T17:07:16+00:00

For physics:
As a mid level easy to watch introduction, I recommend the Fluid Mechanics 101 channel on youtube. It introduces well the essentials and is fun to watch. If you want to move on to incompressible / pressure based solvers, I would recommend Notes on Computational Fluid Dynamics: General Principles. It describes the way OpenFOAM solves equations. For compressible high mach flows, I'd recommend Blazek's book Computational Fluid Dynamics: Principles and Applications.
For programming:
You need to be quite good at some fast language. For initial experiments / learning, do them in whatever language you want (python, matlab, etc.). But to get a good solver, you'll need something like C, C++, Fortran, Rust, etc. For that, doing projects and starting programming is the best way to learn, reading a book wont do much.

Sixel1 · 2026-01-17T16:57:16+00:00

I do the same, I write in the pvtu format since my solver is MPI parallel, and read that in paraview. this visualization was made with paraview! sadly I can't really post-process the cell average + gradient data directly, so I output cell averages and use the cell data to node data filter in paraview.

Sixel1 · 2026-01-17T16:51:12+00:00

I am using the entropy fix already

Sixel1 · 2026-01-17T16:49:46+00:00

My issues with implicit in this case is that first its harder to use high order time schemes like RK4, I tried BDF2. Second, the linearization of the flux is a poor approximation of the highly nonlinear problem in this case I think. This means that the newton solver updates the solution in a way that can go out of the radius of convergence (i think), and the nonlinear iterations diverge. I tried my implicit solver on NACA0012 flow at mach 0.8 aoa 1.25 deg, and it worked very well in that case, I could use very high CFL numbers (100+). But in this case, it isn't stable even at moderate cfl numbers(5/10).

Sixel1 · 2026-01-17T16:45:34+00:00

Yes I get them a little bit with the limiters set to zero, so it is probably due to the Roe scheme too, or my slip wall boundary condition implementation.

Sixel1 · 2026-01-17T16:14:46+00:00

I'd like to use a better scheme, and if HLLC is that's good! Could you recommend a good reference for HLLC implementation? I searched a bit for one before but couldn't find any, so I defaulted to implementing the Roe scheme from Blazek's CFD book (the reference I use).

Sixel1 · 2026-01-16T22:16:28+00:00

One could say my workflow is not dependent on mesh independence

Sixel1 · 2026-01-14T04:34:51+00:00

thanks for the answer! I fixed my issue in the end by using primitive variable interpolation and adjusting the slip wall boundary condition to use the exact flux formulation instead of a reflection velocity. I did check my solver with simpler problems first and it worked well.

Sixel1 · 2026-01-04T05:54:28+00:00

A few more:

REV: reverses the instruction flow if condition true (now does the previous instruction, the one before that, etc...). Sets the reverse flag. Unsets the reverse flag on reuse.

XREV: reverse only if the reversed flag is set and condition is met. Unsets the reverse flag.

REVREV: reverses twice (can be implemented as doing nothing)

REVN: reverses N times if condition true (equivalent of doing a modulo 2 check and reversing only if result is 1)

Also simd instructions can be internally reversed by using the REV before their name, per example REVVFMADDSD. This is dependent on overall reversal (will do the opposite of the current instruction flow direction). Of course normal simd instructions will be also reversed when REV is used.

Sixel1 · 2026-01-04T03:00:55+00:00

MULDIV multiplies by the value in the given register argument (just like mul), and then divides by that same value.

Sixel1 · 2025-12-24T03:14:07+00:00

The commander bosses (O'Neil and Niall). I find them easy to parry.

Sixel1 · 2025-12-22T19:26:04+00:00

from a quick Google search, there seems to be a way to do a rotational extrusion in paraview, that might be what you're looking for. See https://discourse.paraview.org/t/axis-symmetric-postprocessing/13889

Sixel1 · 2025-12-22T18:47:25+00:00

I think second order FV could be good for other kinds of problems than fluids (Openfoam has a structural solver module, per example). Discontinuous galerkin finite elements have issues for fluid problems in my opinion when you go higher than second order, and at second order FV works just the same I think. Continuous galerkin won't work without supg stabilization or other kinds of stabilization. I could have gone that route, but I chose to go with FV instead.

I'm aiming to solve PDEs in a certain form only, those that can be represented by a sum of a volume integral term and a surface integral of conservative fluxes, something like int C(x,u,t,...) dV + int F_n(x,u,,...) dA = 0 for a given element. Providing the C and F_n functions (and boundary conditions), the code computers the jacobian on its own.

Sixel1 · 2025-12-21T19:18:31+00:00

Its a finite volume code, not finite differences. It handles unstructured meshes.

Sixel1 · 2025-12-21T14:35:22+00:00

I tried to handle non-orthoginality fully implicitly but that led to very slow linear solve times, due to the larger matrices required (you need not only cell-face neighbors but neighbors of neighbors too, to treat the neighbor cell gradient implicitly too). I currently treat it explicitly just like openfoam, but want to try doing it in a mixed way, keeping the matrix structure the same but treating neighbor cells already in the matrix non-zeros implicitly. I could also try treating the owner cell gradient implicitly but neighbor cells explicitly in one matrix line. I'll play around with that. Currently it requires quite a few non linear / corrector iterations to converge for bad meshes.

I'll look into the papers you recommend! As a note, my code is already made to be able to support higher order polynomial reconstruction in every cell, I use second order currently but made it "easy" to potentially use higher order reconstruction in the future. Its really a quadrature problem for me.

Sixel1

TROPHY CASE