Oxygen Un-Earthed

My project would seek to turn the series of reactions we developed freshman year into a viable chemical process. Then, it would compare that process to existing alternatives such as the process demonstrated by the Mars Oxygen In-Situ Resource Utilization Experiment (MOXIE) from technical, economic, and practical standpoints. My final product was originally to consist of a technical report of my findings prepared using LaTex and a digital simulation of the full process I would design using an open-source reaction engineering platform. I was excited to take on this project because it would focus on my passions in engineering, science, and computer programming while challenging me to learn new mathematical concepts such as computational fluid dynamics. It would give me the opportunity to explore a personal interest in humanity’s multiplanetary future through the lens of those passions.

Getting started was the easy part. I opened up the paper entitled CHEMICAL, MINERALOGICAL, AND PHYSICAL PROPERTIES OF MARTIAN DUST AND SOIL by D. W. Ming et al. from NASA’s Johnson Space Flight Center that I had used freshman year to validate iron oxide as a reactant. Now, though, I was concerned with all of the metal oxides present in the regolith. I prepared a spreadsheet detailing each material and its concentration that I would use for kinetics calculations later. This set of data tables also lended itself nicely to the creation of the geochemical composition pie charts that appear in my final paper.

Then, I turned my attention to finding flowsheet software and attempting to build a process simulation. I began with DW-Sim, but quickly found that the integrated database mainly featured organic compounds, and certainly did not include the niche metal oxides I was working with amongst its inorganic offerings. I tried installing the notorious “thermo” and “chemical” python libraries, which the software could reference, being an open-source python build, but my compound search still returned no results. I experimented with building the compound profiles myself using SMILES strings and data from NIST and PubChem, but found that the way the software calculates many of the compound thermal properties is based on boiling point, which many of my metal oxides lack since they decompose long before they boil. Without that data point, the software could not generate my custom compounds. I tried two more process simulators: COFE and Dyssol. I was particularly optimistic about Dyssol because it is specifically designed for reactions with a granular solid reactant, as I have. However, these programs, too, lacked the necessary compounds. It turns out, transition metal oxides are not a particularly well characterized set of compounds, and there just are not too many data out there sans iron oxide data from the steel industry. It’s why I later had to focus most of my computations on the metalloid oxide SiO2, which thankfully makes up about half of the Martian regolith. Looking back now, if I had reached that conclusion earlier in the process, I probably could have stuck to using DW-sim, which would have been substantially less work, and could have been dynamic rather than the static model I developed. But I also would have learned far less, and as I mentioned in my presentation, I took this project on as a means of learning. The way things turned out, I became highly skilled in python, I learned some graduate-level chemical engineering, and all of the learning I did about things like rate laws ultimately benefited me when I took and passed the CLEP Chemistry examination, meaning I would be exempt from General Chemistry 1 and 2 and their corresponding labs during my undergraduate career. And so it was that I decided since many of the compounds I needed just were not available in mainstream software, I would build my own simulation in python.

Before I could do that, though, I needed some idea of what I would actually be simulating. I went through several iterations before eventually deciding a fluidized bed would be the optimum means of reacting the Martian regolith with hydrogen gas. But I knew nothing about simulating them. I naively assumed I would be able to rely on simple collision theory, and quickly found out otherwise. I found a textbook on fluidized bed design from the University of Michigan College of Engineering from which I learned the Kunii-Levenspiel Model, an experimentally developed mathematical framework for designing fluidized beds. Although it is the widely accepted model for fluidized bed design, there remain a number of holes. Fluidized beds involve turbulent flow, and at the time of writing this, the Navier-Stokes Equations do, in fact, remain a Millennium Problem. We just struggle to understand the complexities of fluid dynamics, inherently a key player in fluidized beds. Plus, chemical kinetics remains largely understood only in an experimental capacity. The result is that while the model provides the best characterization humans have developed up to this point, there are cases where values simply must be assumed, and select cases where elements of the model prove quite inaccurate. Nevertheless, it represented the best path forward.

As I taught myself the model, I began to work on my paper. Realizing how much more work I now had to do than I thought I would, I wrote my paper in Docs rather than LaTeX for convenience and to save time, which was then becoming a serious constraint as the new year approached. But at the end of winter break, I had mostly finished designing the electrolyzer, the other component of the plant I would work on, and I had nearly completed my python model. After many late nights (or perhaps I should say early mornings) writing code, I was ready to test the program. I debugged for a few days, correcting several errors before eventually getting stuck on some strange values and two undefined functions. Finally, one night, my father suggested I just test one function at a time using example problems from the textbook I had used to learn the model. And so it was that I tore the program down into its most basic pieces and began to check and fix functions. Having rebuilt the program, this approach had it working within 24 hours. So, there was a valuable lesson here. To quote my father on that night, “you have to make one piece work at a time…if you try to fix the whole thing at once, you're doomed.” In any case, the program evaluated more than 1.8 billion possible designs and, depending on the number of people to support specified, returned between 3.1 million and 50,000 solutions. I was ecstatic.

When I opened up the spreadsheets to analyze the data the next week at school, I found the values to be outrageous. Having checked each function, I knew that there should not be an error in my Kunii-Levenspiel Model implementation. If there was an error in the code, a scenario which is entirely possible and cannot be ruled out as a cause or partial cause, it should be elsewhere in the program. I also began to consider other sources of error; Mars’s lower gravity would result in a dimensional inflation for a given inflow velocity, and given that the Kunii-Levenspiel Model was experimentally developed here on Earth, it is possible many of the regressed constants just do not hold up for applications in alternate gravitational conditions.

I learned so much about so many things as part of this capstone project, not the least of which is the engineering mindset. I have an ability to imagine and see how something could work in its entirety, which often leads to me working as fast as I can to bring that vision to reality in ‘one fell swoop.’ Sometimes, I overlook the necessity of taking things ‘one step at a time,’ an approach that ultimately goes much farther in terms of efficiently yielding a successful finished product and a detailed understanding of that product. I am proud of what I accomplished with this project, but I am even more proud of what I learned. To quote myself at the end of my presentation, “experience is the greatest teacher.”