I propose developing a web-based CFD code with an architecture designed around composing physics models from simple building blocks, using an interpreted Domain Specific Langauge (DSL) based on Lisp. This would allow for complicated problems like RANS turbulence models to emerge naturally rather than require extensive rewriting of code. The Lisp DSL layer allows a user to describe the physics they want in a mathematically general way, such that it resembles symbolic maths, but under the hood the code is translated to fast, compiled, CPU-optimised loops. The proof of concept below demonstrates the operator-based architecture that makes RANS a straightforward extension.
The working proof of concept, including an interactive visualisation.
In the workbook above, the code describing the physics looks as follows:
j(define dye-equation
(equation dye-field
(ddt dye-field density)
(div dye-field density velocity-field)
(laplacian dye-field diffusivity)
(scalar-point-src [-1 0] 0.1)))The key domain ideas are those of "operators" and "fields", for example "laplacian" takes a list of fields and is responsible for using those to contribute to a system of equations. By keeping all the components as dumb and atomic as possible, turbulence modelling and advanced multiphysics coupling is very much within reach.
Beyond the physics benefits there are significant workflow advantages to the web and code-based appraoch to CFD, over traditional native applications that are UI-based. Primarily, it means CFD work can be easily shared, fully transparent as to the exact setup used, and meta-CFD processes like optimisation algorithms that run many convergence cases become possible. I've written more on this in Further Information.
Scope and Outcomes
I'd stick to 2D CFD to keep things manageable, and aim to provide a fully-featured experience for at least one case that's actually useful for engineers, like flow over an aerofoil. I have a reasonably clear idea of what needs to be done to get there and how I'd do it, but that is probably beyond the scope of this proposal.
One main outcome I'd like to spin the project narrative about is trying to setup the exact same problem in a traditional CFD code and my web-based one and then discuss the pros and cons.
Budget
I'd put the budget towards hosting costs for the website. Or even more fun would be to put together a thrifted web server from a decommissioned office PC from 2018 with a decent CPU (~£80), 64Gb of RAM (~£50) and a 1Tb SSD (~£50) and a few months of a static IP address to sit in the corner of a room and chug away. Other than that programming is free.
Further Information
I think I've slightly cheated by writing this up on a website so consider this the end of the A4 piece of paper. The rest is just helpful context.
Workflow Advantages
The cool workflow potential in such a system that I'd like to flesh out in an FYP are the following:
- It's Reproducible: If the full spec for a CFD procedure is just lisp code in plaintext then others can run it for the same result. The exact settings are not hidden in an opaque piece of software on someone else's computer.
- It's Self-Documenting: Given the literate programming paradigm (the combination of prose and code), CFD specs read like technical reports rather than esoteric code.
- It's Transparent: "What boundary conditions and discretisation method did you use?" becomes very easy to answer when it's browser based - just share a link to the actual workbook.
- It's Meta: You can still use classic programming control structures like loops and conditionals in your CFD spec so you could write a script that orchestrates multiple convergence jobs, for example an optimisation algorithm that seeks to maximise lift given some geometric parameters. This doesn't require a separate scripting environment - it comes for free when your CFD code is embedded into a full-fat programming language.
- It's Persistent: Being on the web there's a clear client-server (browser-web server) boundary, making the idea of sending long running jobs to persist on a server more natural, no need for a "don't switch off" sign on a computer. You could send heavy computational jobs (like the optimisation algorithm in point 4) to a job queue on the server and have a nice status UI in the browser, rather than ssh-ing into a computing cluster and running bash scripts.
Background
For some background, a number of threads came together this summer such that I'd have this idea. Firstly, I was looking to show off a basic interactive diffusion/convection solver in python that I'd written on my portfolio website, and so learnt about WebAssembly (WASM) and ported my code to Go to be able to compile it to WASM. As I was refactoring that code I found it increasingly annoying to have to recompile every time I wanted to tweak a parameter, and so I was inspired to write a Lisp interpreter to embed into the CFD code so I could tweak parameters at runtime rather than compile time.
The main inspiration for Lisp was that I'm working through the wonderful Structure and Interpretation of Computer Programs , which exposes the power of Lisp as a programming language for writing programs that program programs (metaprograms). What this means is that rather than starting with "what code do I need to solve this problem" you can instead begin at "what sort of code do I want to write to solve this problem", and then use Lisp as the basis for an elegant Domain-Specific Language (DSL) for your problem. This felt like a marvelous tool for specifying CFD procedures and so the concept for the project was born.