Muhammet Emir Fil · Computational Engineering Science Open to a HiWi position

Computational Engineering Science · RWTH Aachen

Muhammet Emir Fil

I build physics simulations, then check whether they agree with something I can trust.

A textbook formula, a published benchmark, or real measured data. Below are the forward models, the inverse and optimisation problems built on top of them, the fixes I have sent upstream, and the software I ship.

Open to a HiWi position at a computational chair
Multiphysics Hub · car · CFD · bending bridgelive
Fig. 0 · one real-time simulation in your browser: a four-wheel car, a 2D aero flow, and a deflecting bridge. ✓ the JS matches my Python to 1e-13 it is auto-driving the line right now · take the wheel with the arrow keys ↑ ↓ ← →
01

Simulations, verified

Each project has the code (Python, mostly NumPy), a short PDF write-up explaining the method and where it is checked, and for most of them a demo that runs in the browser with no server.

Multiphysics Hub: real-time double-track vehicle dynamics with a live g-g friction circle, wheel loads, a 2D aero flow panel, and a bridge that deflects as the car drives over it

Multiphysics Hub

✓ vs Python

Vehicle dynamics, CFD and structural dynamics in one

You drive a car around a track in the browser, and three simulations run under it at once: a four-wheel car with Pacejka tyres, a 2D fluid that I run around the car body to get drag and downforce, and a bridge that bends when you drive over it. I wrote each model in Python and checked it, then ported it to JavaScript so it runs live; the two versions agree to about 1e-13 for the car and 1e-9 m for the bridge. This one ties together the three projects below.

Vehicle dynamicsCFDStructural dynamicsReal-time JS
BridgeTwin dashboard: trucks weighed live from the bridge's own response, with per-truck error bars and a recovered-versus-true accuracy plot

Bridge Weigh-in-Motion

✓ vs KW51 data

An inverse problem with quantified error bars

If you put strain sensors on a bridge, you can weigh the trucks driving over it by working backwards from how the bridge bends. I built the forward simulation (a beam under a moving, bouncing vehicle) and then the inverse that recovers the axle weights. The inverse is ill-posed when two axles are close together, so I added Tikhonov regularisation, and a Bayesian version for a calibrated error bar. I checked the forward model against Frýba's closed-form solution, and tested the monitoring idea on 16 months of actual measurements from the KW51 bridge.

Inverse problemsFinite elementsBayesian UQRegularisation
Optimal racing line: minimum-lap-time optimal control, racing line coloured by speed versus the centreline, a g-g diagram sitting on the grip limit, and the speed profile along the lap

Optimal Racing Line

✓ vs skidpad

Trajectory optimisation

Instead of drawing the fastest line around a track by hand, I set it up as an optimal-control problem and let a solver find it. I used arc length along the track as the variable, discretised it with direct collocation, worked out the Jacobians by hand, and solved it with SciPy. On a 2.4 km track the optimised line comes out 8.1 percent faster than following the centreline, and I checked the lap time against the closed-form skidpad result.

Optimal controlDirect collocationNonlinear programmingVehicle dynamics
2D Navier-Stokes solver: the von Karman vortex street behind a cylinder at Re=100, its periodic lift and drag coefficients, and the shedding-frequency spectrum giving a Strouhal number

2D Navier-Stokes Solver

✓ vs Ghia

Computational fluid dynamics

I wrote a 2D incompressible Navier-Stokes solver from scratch (staggered grid, projection method, an immersed cylinder). It reproduces the standard Ghia lid-driven-cavity benchmark and shows the von Kármán vortex street behind the cylinder. Then I ran it backwards as a vortex flow-meter, reading the flow speed off the frequency at which the wake sheds vortices.

Navier-StokesProjection methodImmersed boundaryFSI
02

Open source, merged

I send fixes back to the scientific-computing tools I use. Three have been reviewed and merged, in one case by the project lead.

03

Software I ship

Beyond the research projects, I build and ship apps that real people use. Same habit as the simulations: keep it honest, offline, and checkable.

study-scrum: exam-semester planner showing weighted grade targets and a day-by-day study schedule

study-scrum

Exam-semester planner

A calendar app that plans my own exam semester day by day. It reads each course's topics and how often they show up on past exams, then lays out a spaced, exam-weighted schedule across the weeks so the last week is not chaos, and drops every study block into my phone calendar as an alarm. Plain JavaScript, offline, with the planning engine checked against invariants in Node.

Planning engine · PWA · offline · .ics reminders

FR · DEEncoreA1 · offline

Encore

A language-learning app I built for my mother

I built a small language app so my mother could start learning German (A1), and to keep my own French from rusting. React Native / Expo, fully offline, with real recorded voice audio, a 13-lesson A1 course, short games and progress tracking. It runs on her phone, and I can sync her progress remotely.

React Native / Expo · offline · private

04

Writing

NOTEWhen a 95 percent interval is 0 percent reliable, on why a calibrated confidence interval can still miss the true weight almost every time once model error is in play.