Engineering case studies

The constraint

IH-TESEO is the group's hydrocarbon-spill model: Fortran, OpenMP, Lagrangian particles carrying weathering chemistry. Its particle budget was the ceiling on every study it was used for — resolving slick boundaries and filaments around complex coastlines requires high particle density. Increasing capacity required preserving numerical precision and physical behavior exactly, ensuring weathering chemistry results remained identical to the original model.

What I did

• Re-engineered the particle core so the model simulates ~50× more particles than its predecessor, with the weathering processes fully validated against the original with full numerical accuracy.
• Reworked the parallel execution in OpenMP so existing simulations finish up to 4× faster while scaling to substantially larger particle ensembles.
• Implemented netCDF input and output, so runs now interoperate directly with standard ocean-data and geospatial tooling (xarray, GDAL, QGIS) without bespoke converters.
• Wrote the model's automated test suite and wired it into CI/CD with GitHub Actions — regression-guarding the numerics on every commit.

What I am building now

The same engine is being extended beyond hydrocarbons into sediment transport — hindered settling and bedload transport. Hindered settling depends on the local concentration of particles, and a purely Lagrangian model has no concentration field of its own.

So I implemented a Lagrangian → Eulerian → Lagrangian framework: particles are binned onto a grid to produce the Eulerian fields the concentration-dependent physics needs, the process is evaluated there, and the result is carried back onto the particles. Lagrangian resolution is preserved where trajectories matter, while the model gains awareness of the plume around each particle.

The constraint

Operational forecasting requires continuous, reliable execution without manual intervention. The pipeline must gracefully handle upstream data delays, partial downloads, and automated quality checks to prevent faulty input from triggering cascading model failures.

What I did

• Built and operate an automated forecasting system running unattended in production, ingesting and processing up to 100 GB of high-resolution oceanographic data per day.
• Produce daily ocean-current and sea-level forecasts for two distinct regimes: the open Cantabrian coast and the estuarine environment of Santander Bay.
• Containerised the hydrodynamic models with Docker — ROMS and Delft3D here, SFINCS for the climate-scenario work in Case 03 — ensuring reproducible execution across machines and consistent results over time.
• Post-processed model output with GDAL and the Python geospatial stack, publishing products that downstream users can open in standard tools.

The constraint

A country-wide digital twin of coastal and estuarine flooding, built to assess exposure under climate change rather than to forecast day to day — nothing here runs on a daily cycle. Coverage means sweeping a scenario space: roughly 500 climate-change scenarios per region, ~20,000 simulations in total. At that size, scenario generation, cluster scheduling and raster post-processing all have to be automated or they become the bottleneck.

What I did

• Prepared and executed the SFINCS flood model across ~20k scenarios entirely in an HPC environment, scheduled with SLURM — coastal and estuarine flooding, region by region, climate scenario by climate scenario.
• Drove the whole scenario-generation phase with GeoPandas, building roughly 500 climate scenarios per region programmatically and traceably.
• Post-processed output with GDAL: generated flood rasters, transformed and rescaled them, and joined them with results from other regions into a single comparable surface — then analysed cases in QGIS.
• On the pollutant side, designed and executed statistical analyses of dispersion under multiple initial and seasonal conditions using Python, Dask and xarray.

The constraint

Onboarding mainstream users into Web3 applications requires eliminating friction around browser extensions, network selection, and manual key management. The account abstraction layer needed to handle creation, security, and multi-chain transactions transparently within host applications.

What I did

• Designed, built and owned Glyph end to end — an open-source embedded-wallet widget built on multi-chain EVM infrastructure, letting users create and manage wallets and transact ERC-721 NFTs and ERC-20 tokens across multiple chains (TypeScript, React, viem/wagmi, WalletConnect, Privy).
• Shipped the open-source Glyph SDK so third-party developers could embed the wallet in their own applications.
• Built the backend services behind it: end-user management, customer-support tooling, and usage reporting.
• Integrated tokenproof verification into ticketing web applications for large events (e.g. ApeFest), including token-gated access to perks and merchandise under high event traffic.

The constraint

Live event access control demands near-zero latency, robust offline capability, and strong cryptographic verification. Systems must process high volumes of attendees smoothly, even on low-end devices with intermittent network connectivity.

What I did

• Designed, implemented and scaled Go microservices (REST and gRPC) to issue verifiable credentials representing accounts, event tickets and discount coupons, signed server-side with the platform's master (root) key, across tens of thousands of accounts and thousands of unique devices.
• Built a configurable rules engine deciding eligibility at entry — verifying tokens, ticket validity, and custom criteria — running cryptographic, logical and blockchain checks in under 2 seconds.
• Developed cross-platform Android and iOS shared libraries in Go that hold each device's own ECDSA key pair, wrap an issued credential as a Verifiable Presentation and sign that envelope with the device key, optimised for low-end hardware.
• Verified both signatures server-side on every presentation — the envelope against the device key and the credential against the root key — so tampering and QR-code reuse both fail closed.
• Implemented credential synchronisation between backend services and mobile devices at high sustained throughput.
• Operated infrastructure live during major events: handling thousands of users per minute during purchases and hundreds of asset validations per second.
• Released open-source tooling for crafting and sharing verifiable credentials.

The constraint

Mass-spectrometry instrument data was distributed across tens of thousands of plain-text files totalling around 20 GB. Nothing downstream could use it until it was parsed, cleaned and structured into a dataset, and the per-file volume ruled out doing that serially.

What I did

• Built ETL pipelines on AWS — S3, Lambda, Step Functions and Batch — to consolidate, parse and prepare instrument data for machine-learning workloads, processing the full dataset efficiently and scalably.
• Used a serverless, step-orchestrated shape deliberately: the work is parallel per file, so the pipeline fans out and a malformed file fails one branch rather than the run.
• Developed a REST service exposing instrument metadata as RDF triples against a defined ontology, enabling graph-based fleet queries.
• Presented monthly progress to technical and non-technical stakeholders through Jupyter notebooks, keeping the work aligned with operational decisions.

The constraint

A separate effort from Case 06, on its own dataset and its own pipeline. Unplanned downtime on a mass spectrometer is costly and disruptive in a way scheduled service is not, so the question was whether an instrument could signal an upcoming failure far enough ahead to act on.

What I did

• Built the dataset and pipeline for this problem specifically — distinct from the ML-preparation work in Case 06, since failure prediction needs sequences labelled against failure events rather than general-purpose instrument data.
• Trained an LSTM predicting instrument failure within a given time window at ~70% accuracy, turning telemetry into an actionable maintenance signal.
• Matched the model to the decision it fed: the output schedules a service visit, so a false positive costs an early call-out rather than an outage.

The constraint

Multiple airlines, one platform, and customer records duplicated across SQL systems and a legacy SOAP service. Two key requirements: unify data access across disparate sources and guarantee strict tenant isolation so no airline can access another's records.

What I did

• Built ETL workflows that cleaned, parsed and consolidated data from SQL databases into MongoDB and Elasticsearch, indexing records for fast queries across unified customer profiles.
• Developed a REST service wrapping a SOAP customer-data source to power a duplicate-detection web app for airline operators.
• Recorded operator decisions as training labels, incorporating human-in-the-loop feedback into the workflow to train a deduplication model.
• Implemented SSO and JWT-based authentication and authorisation with strict per-airline data isolation.