Engineering--like science--is more of an art than a science. It's a matter of making approximations and judgments that exist in isolation, but that work together to create a coherent whole. Enlightenment thought is focused on the balance between the individual components of a system and its integration with the world at its full scale: it does not arbitrarily privilege one scale or the other, saying that only the components are real or only the whole is real. Everything is real.
When designing a system that involves different kinds of physics--in this case fluid mechanical, mechanical, electrical, and optical--there is a dance we undertake to create the integrated end product, which like any work of art we don't know the shape of until it's complete, and knowing when it's complete is the deepest art of all.
In the case of my upper-room UV CR box design, I've been playing with fluid mechanics this week, which has made me feel stupid. I've fiddled a bit with the open-source fluids simulation program OpenFOAM for the past year, but haven't gone into in depth until this week.
It has... a steep learning curve.
While the docs are OK I am reminded that the company that supports the package makes a lot of its money off training and consulting, and the tutorials--which are plentiful--are often written on the assumption that the user already understands the terminology, of which there is a great deal, much of it subtle and full of shibboleths.
One of the main goals of Enlightenment thought is to create descriptions of reality that are usefully precise, and it turns out that reality is fairly uptight about the degree of precision required to be useful, to the extent that I'd argue the more forgiving and flexible a set of ideas are--that is, the less stupid they make the average person trying to use them feel--the more likely they are to reflect the entirely human needs of their creators, and the less likely they are to say anything useful or interesting about any other part of reality.
Fluid flow is among the most fiercely unforgiving aspects of reality that humans have attempted to give useful description to. The Navier-Stokes equation--which is our primary mathematical description of fluid flow--results from a sequence of reasonable steps that an intelligent undergrad can follow with relative ease. These steps involve imposing conservation of mass and momentum on an element of the fluid, where "an element" is an abstract little cube of fluid in the midst of the flow, differentiated from the rest by nothing other than our attention to it. The equation that results from these reasonable steps has terms in the square of the fluid velocity, which produce all of the gloriously non-linear complexity we see when air or water moves, from fluffy clouds to tumbling waterfalls.
Heisenberg famously said on his deathbed that he was going to ask God two questions: "Why relativity? And why turbulence?" He went on to say he expected to get an answer when it came to relativity. Me, I'm not going to ask anything: if there's an afterlife, we'll know the answer to the mystery that lies beyond the quantum veil simply by the fact of being there. If there isn't, we won't. Either way, there's only one way to find out, by performing the experiment.
Fluid mechanics--even turbulence--is less mysterious than quantum mechanics. There is nothing in the Navier-Stokes equation that violates the laws of non-contradiction or causality. But even at the mundane level of complexity that it describes, it's still pretty complex.
OpenFOAM and other similar packages are designed to tease answers out of this complexity, but to do that they require us to learn to speak the language of reality, not the made-up magic that comes to us naturally.
In the case of OpenFOAM, the language is the case: there is a collection of files that describe the situation--the "case", in OpenFOAM parlance--that we want to simulate. Each of these has its own foibles, and the formats for the files that describe cases have changed enough in the past two years that a case that runs fine on last year's version won't run at all on this year's, while some of the documentation hasn't been updated since 2017.
Ergo, the whole experience has been a bit daunting, and it reminds me of the value of feeling stupid.
"Embrace the stupid" should be the mantra of science and engineering, in the same way "embrace the suck" is a mantra for soldiers: "the idea of being emotionally comfortable while being physically uncomfortable" translates well to the idea of being emotionally comfortable while mentally uncomfortable. Confused. Uncomprehending. Stupid.
I feel stupid a lot.
This is something I recommend: get out of your comfort zone. Go out there and feel stupid. Incompetent. Incapable.
You'll learn things.
First off: who your friends are. They're the ones who support you, who appreciate what you're doing even when it's not very good.
Second off: who the genuinely decent, kind, people are. They're the strangers who see your stumbles and don't laugh.
Third off: what you are actually capable of. It might not be as much as you'd like, but it will certainly be more than if you did nothing.
Whether or not I'm much of a fluid mechanic is still up in the air.
OpenFOAM is a collection of programs that use different approaches to solve the Navier-Stokes equation under different constraints. I wound up using "icoFoam" for this work, because it's the program I could get to run based on an example that was sufficiently close to what I was interested in. After I learned more about the system I realized it was the wrong program to be using for this problem. It'll work, but a more experienced person would have chosen simpleFoam instead. Stupid me.
Any fluids program has three basic things that the user needs to communicate to the machine: what the geometry of the problem is, what the boundary conditions are, and what the physical properties of the fluid are.
The geometry of the problem is not just the shape of the walls but the nature of the mesh, which is a 2D or 3D grid of points that are used as the basis for solving the equations. A fine grid results in a more stable, accurate, solution. A coarse grid results in a faster one. Modern solvers have ways to specify "grading" of the grid so it's finer in some places and coarser in others, ideally matching to the complexity of the fluid flows in those regions. It's fair to say that I'm still learning the language of mesh specification in OpenFOAM.
Boundary conditions are another whole world of opportunities to feel stupid. My problem has a fan in it, which you can specify in OpenFOAM with a "fan curve" file, that connects the pressure across the fan to the flow rate through it... except depending on the solver you're using the way the pressure is specified is different in a way that I sorta understand from decades-long-ago fluids courses, but am going to require more reading before I really get, if I ever do. Embracing the stupid requires accepting that there may be things you never get, and that's OK.
Physical properties should be the simplest thing, but there are weird internal couplings that I'm not sure I understand, although I can work the equations to get sensible values. I've not tried varying them yet, which I really should do, as varying things is a good way to find out if you really understand something: if the results vary in a way that you can predict, you probably understand. If not, then you have a learning opportunity.
The result of all this flailing about is the diagram at the top of this post. The geometry is still approximate: rather than the fan sticking up into the volume it is simply modelled as a surface element, which is good enough for going on with. The image shows the streamlines of the flow, which I computed in the stupidest possible way: another advantage of embracing the stupid is that you're open to use stupid approximations that are in fact good enough, and save you loads of time.
One of the many things I learned in this process is that I'm way too stupid to use paraview, the VTK-based program that is the recommended tool for visualizing OpenFOAM results. Maybe one day, but honestly it was easier for me to convert the output files to VTK format and process them myself.
The streamlines only tell part of the story: streamlines define the course of the air through the unit. The other part is: how long does it take the air to travel this course? The analysis process that produces them can be used to answer this question, and the answer is a second or three, which can be used in conjunction with a simple model of the lamp as a linear light source to find that the average optical energy experienced by particles travelling along these streamlines, which is between 7 and 40 mJ/cm**2, depending on the streamline.
These are good numbers. The literature suggests 2 mJ/cm**2 as the minimum value for 99% kill, so I'm well above that, and into the range where there is no detectable covid at all.
It's worth pointing out that a minor bug in the analysis code resulted in a value ten times lower than this, which made it look like the whole idea was a bust the first time I ran it.
Did I feel stupid?
Sure, but who cares?
I rechecked things, not minding if I found an error, because errors happen, and did indeed find one. Although I'd thought of a couple of ways I might improve things if the first value turned out to be correct.
What I wrote before I found the error was:
"So: is my brilliant idea dead in the water?
Maybe!
It's still better than nothing, but I'd really kind of like it to be more effective. The literature suggests that 2 mJ/cm**2 is the minimum target for 99% kill. Is there a way to improve things? Or am I just stupid? It wouldn't be the first time.
Stay tuned!"
I'll re-recheck the results--I have a simpler program that I've run for other problems in the past, and intend to run it to compare to OpenFOAM--and see if things hold up. Getting usefully precise descriptions of reality is hard. Feeling stupid is part of the process, at least for me.
Persistence is necessary regardless, and embracing the stupid makes persisting easier.