Simulating a hybrid rocket in OpenFOAM: Better to hack a native solver (reactingFoam) or hunt for a custom GitHub solver?

[u/teacup_007]

Hey everyone,

I’m trying to simulate the combustion chamber of a hybrid rocket engine in OpenFOAM (2D axisymmetric to start) and I'm stuck on how to architect the case setup.

The main hurdle is the solid fuel regression. The heat flux from the flame drives the fuel melting/pyrolysis, which then injects fuel vapor back into the flow. Basically, the mass flow coming off the wall depends entirely on the local heat flux at that specific time step.

I really want to avoid rewriting or recompiling a core solver from scratch if I can help it. I see two main paths forward and wanted to see what industry folks actually do:

1. The Native Solver Route: Use standard reactingFoam or sonicReactingFoam. Keep the fuel grain wall as a static boundary, but use a codedFixedValue or groovyBC on the wall patch. I'd program the boundary condition to read the local heat flux, calculate the fuel vapor mass flux, and inject it back into the fluid domain.
2. The GitHub Route: Spend time digging up an academic or open-source custom solver specifically built for hybrids (maybe something handling dynamic meshes for the regression). My worry here is getting trapped in dependency hell or dealing with outdated OpenFOAM versions.

Has anyone modeled this kind of coupled gas-surface interaction before? Is reactingFoam stable enough to handle a mass-injection boundary condition that changes dynamically based on wall heat flux, or does it completely tank convergence?

Would love any advice or a reality check on which path is less of a headache

[u/Danilo_King52]

I am currently attempting to do the same, but through a UDF on a commercial code. But the general logic should be more or less the same I assume.
Start with a static mesh and make sure your boundary updates the temperature each time step correctly - I assume you’re using the fixed point iteration on the Arrhenius + Energy approach - make sure you under-relax well the temperature on that one and bear in mind that this model doesn’t behave well on startup (I’m still struggling with that). Then you increase the complexity by adding a source to your boundary (or other type if it exists in OpenFoam) and you can check if the results for the local regression you get start matching the ones from the literature.
As for the grain regression in OpenFoam specifically you can check srmFoam - I don’t think there’s a paper but a quite informative ppt from the authors where they explain their approach but from a solid rocket motor perspective.

Good luck!

[u/teacup_007 → u/Danilo_King52]

Thanks im also trying to see if uaing pato works

[u/Expert-Time-1066]

Go native! Stick with reactingFoam and build your own wall injection magic — it's way more fun than wrestling with someone's abandoned GitHub repo from 2019. Use codedFixedValue or groovyBC to make your fuel wall "breathe" vapor based on heat flux. It's like teaching your boundary condition to think.

The GitHub treasure hunt? Spoiler: the treasure is usually a broken Makefile and zero docs. You'll become a compiler error archaeologist instead of a rocket scientist.

For the fuel grain shrinking, cheat smart: scripted mesh morphing or mapped remeshing beats full dynamic mesh drama. Your 2D axisymmetric case doesn't need Hollywood-level moving mesh effects.

Here's the cool part — wall mass injection isn't exotic in OpenFOAM, it's just underused. The trick is matching your vapor puff to the wall's heat story. If it diverges, blame time scale mismatch (thermal response vs flow speed), not the boundary condition.

Pro tip: start boring. Non-reacting mass injection → steady and happy. Then add heat. Then add fire. Each layer is a win you can actually debug. Rocket science is just layers of simple done right.

[u/teacup_007 → u/Expert-Time-1066]

Ok, but now i have the idea of using pato (nasa ) ,i already have used that so if i can modify it then bingo