Ignition
The program I am developing to design and optimize afterburners for hobby sized turbojet engines
What is Ignition?
Ignition is an app that designs and optimizes afterburners for hobby sized turbojet engines.
Background
Early in the Spring ‘25 semester, I lead the MachWorks Propulsion team on a development path for an afterburner for the team’s current engine. The calculations were somewhat simple, those being isentropic flow equations I had just learned in my courses, but being an engineer I had learned to code everything as it makes repeated calculations easy. Throughout the early months of the semester, a simple (~200 lines) MATLAB program was written that would handle the relevant calculations. This included combustion calculations (through this toolbox) along with plotting the geometry in a simple manner. Over spring break, wanting to expand my MATLAB skillset, I ported the script over to an app. The original functionality was retained, just in a package that was easier on the eyes. As the team returned, the list of features I wanted in the app grew. This started with a simple unit converter (thanks to JD Fiore) and grew to ambitious of a full stack designer app. After speaking with the team advisors, they suggested that I move the codebase over to Python as it has increase functionality and would be easier to make open-source.
Moving to Python
Fast forwarding to May ‘25, classes had just got out and I was overly optimistic with my newfound time. Having taken a simple intro to python course, saying I was prepared for the challenge would have been an understatement. Wanting to see how hard it could actually be, I copied the entire MATLAB code into an AI code generator and ran the output. It did not work. But it did give me a sense of how hard this was going to be. I deleted what was there and set out on learning python, and in the process finshing this project. I will admit that I spent a lot of the time relying on AI help to explain what exactly I was doing. I made a lot of beginner mistakes (subtle foreshadowing), but I was making progress. I must’ve worked for a week or so getting the app to a place where it could be considered an app. A lot of that time was going back and forth on which theme I wanted to use, but eventually I landed on something that looked decent. It has zero functionality, but it looked alright. Soon after I got tied up with some other personal projects, research and other personal matters so I ended up leaving the codebase for almost 2 weeks.
Having taken a nice break, I was reinvigorated to continue coding. It was here that I promptly learned why comments are good when coding. I read through my old work and understood almost none of it. It was also poorly arranged which didn’t help. I spent some more time learning best practices and once again decided to restart. This time I started by making classes, getting things sorted on paper before starting to code, and completely turned off the AI code assist. This time it was me and python. Things went a lot better this time, although it was much harder. I was able to get the app back to where I was before, this time, with parts of the functional code. I was able to get the Unit Conversion Toolbox finished, and the basis of the main code working.
Working out bugs
It took me some time to work out this funny little quirk of the app. There is a section of the code that was solving for a symbolic variable. And I will admit the main reason for it is because I was too lazy to rearrange the equation. It wasn’t particularly hard, I just didn’t want to do it. Well, the library that I had been using was slowing things way down. I realized this because on pressing ‘start’ the app would freeze for a few seconds before snapping back into place. I tried to get multithredding and multicore processing working, but nothing worked. I had spent about a day on this and was ready to accept that it was just going to have to live like that, when and AI suggestion was made to use a different library. Figured it couldn’t hurt and so I tried it. After implementing an internal timer, I found out that the load time had gone from ~5sec before the change to 0.01sec after the change. That was a huge dopamine hit as it had tripped me up for some time.
Issues with finishing implementation
Wanting to bring the app back to it’s MATLAB baseline and move on for the summer, I turned my attention toward the combustion analysis. In MATLAB, a toolbox made this fairly trivial. I had to reach out to the toolboxes’ developer since it wasn’t working quite right, but it turned out to be an undocumented bug that he was working through. No worries, should be simple enough to do the same thing in python right?
I began looking into Cantera, a well-known research level combustion solver. It was way more complicated than I had anticipated. It didn’t help that the fuel choice of our afterburner was a well known but difficult to simulate fuel. Jet-A is a widely used fuel that is simply a more refined kerosine. Well as I had learned in my thermodynamics class, there are hundreds of different formulations of Jet-A. This change so much that even between refineries of the same company there will be differences. Not great for me but nonetheless this problem has been encountered and solved before. You can use a simpler version of a slightly different fuel that holds the same characteristics as Jet-A. Problem is that Cantera needs a reaction file to tell it how the fuel combusts and all the resources for this information look like they’re straight out of the 80s. I reached out to a Mechanical engineering professor at my university (Virginia Tech), and he was able to supply me with the proper files I need. Turns out it’s still not that simple. The file he gave me resulted in an estimated final temperature different of ~400F. This difference was too large to be chalked up to slight reaction mechanism differences.
Moving forward
So that brings us to the present. The app is mostly finished but still not useable. Working through the combustion analysis has proven itself much larger of a challenge than I had hoped. Furthermore, I have added CFD integration into the list of features. The optimization aspect will likely have to be done last and so I have put it off for now (totally not because it will be hard and I don’t want to deal with it yet). My plan is to use a program called OpenFOAM to run flow simulations. While I haven’t fully explored it, I imagine that having everything work within one program (that is not having to export geometry to a CAD program, then export the step file to a CFD solver) will save some headache for the user (although it will make things harder for me). From the limited information I’ve seen on OpenFOAM, it can do the simple flow simulations I am looking for automatically through the python API. My hope is to have a dedicated section of the app for viewing and interacting with the CFD work but that might not play out how I would like.
The future of Ignition
This journey has been one of mostly failure, setbacks, and redos, but it has certainly taught me a lot. While I started college hoping I would never have to code, I did learn how powerful it can be despite it not seeming so for aerospace engineering. This program has ballooned way past it’s orignial intent but I hope that by time I am done with it, the MachWorks Propulsion team will have to spend little time designing and developing the afterburner and more time making it real. I have less than a year until I graduate at the time of writing this and I am not sure the app will be finished by then. Between classes, senior design projects, graduate school applications, research and more, I don’t know how much time I will have to dedicate toward this effort. Past that I am not sure my involvement with it’s development will continue once I move on from the team. In any case I hope it can be useful to someone someday.
Notes:
If you are interested in keeping up with the development of Ignition, or at some point would like to be involved in it’s creation, check out my Github Repo