Projects

• 

  The Pillar Paradox

  2026

  A social-force simulation and evolutionary search testing when pillars help—or harm—crowds moving through a door.

  A pillar in front of an exit can make a panicking crowd leave faster. It can also turn an ordinary evacuation into a permanent jam. The interesting problem is not whether the paradox exists in one simulation. It is why it appears, where it stops, and whether a search can find a layout that is useful without being dangerous.

  I built a social-force crowd simulator, used evolutionary search to place circular pillars, and then extended the project by treating the simulated crowd as both a fluid and a granular material. The final study contains thousands of matched simulations across door widths, crowd sizes, desired speeds, pillar gaps, and multi-pillar patterns. Every reported winner was evaluated on crowds the search had never seen.

  The result is less like a design recommendation than a map of a trade-off. A tuned pillar can raise a one-metre door's capacity by about 20%, lower the pressure concentrated around the exit, and cut long stalls in half. But its useful position sits beside a sharp failure region, and the larger search did not discover a layout with a large gain for both calm and pushing crowds.

  The room is 12 by 12 metres with a one-metre door in its right wall. Each person is a disc with radius 0.25–0.35 m and mass 80 kg. The simulator follows the social-force model introduced by Helbing, Farkas and Vicsek: each person is driven toward the exit, repelled before contact, and compressed and dragged by friction after contact.

  $$ m\dot{\mathbf v}i = m\frac{v0\mathbf ei-\mathbf vi}{\tau} + \sum{j\ne i}\mathbf f{ij} + \sumW\mathbf f{iW} $$

  The desired speed $v0$ is the control for how hard the crowd pushes. At low values people approach the door calmly. At 5 m/s they continue trying to accelerate even when the crowd in front has nowhere to go. Contact and tangential friction then stabilize temporary arches across the opening. This creates the classic faster-is-slower effect: after a point, increasing the desired speed makes the room empty more slowly.

  The simulator is intentionally small enough to inspect. A scenario fixes the room, door, desired speed, people, pillars, and random seed. Paired comparisons use the same seed with and without a pillar, so the initial crowd is identical and only the geometry changes.

  base = Scenario(desiredspeed=5.0, seed=101) pillar = base.with(pillars=[(10.5, 6.0, 0.53)])

• 

  Fuego.Earth

  2026

  A browser-based wildfire platform that turns fuels, terrain, and weather into fire-spread simulations and risk maps.

  A fire-spread model is not useful just because it runs. Someone has to choose a place, supply the right terrain, fuels, and weather, wait for the computation, and understand what the result does and does not say.

  Fuego.Earth is an attempt to make that whole chain usable from a browser. I built it with My Tran, Álvaro Galván, and Sofiia Bilyk at Minerva University. A user can place an ignition point on a map, choose a date and duration, run Cell2Fire or FARSITE, and replay the estimated spread hour by hour. The platform also produces ensemble and relative-risk maps for questions that a single perimeter cannot answer.

  I worked mostly where the scientific code became a dependable product: simulator inputs, spatial and temporal correctness, probability runs, API behavior, caching, deployment, and the contracts that connect those pieces.

  The visible interaction is simple. Pick an ignition point, choose the simulation window, and press run. Behind that click, Fuego.Earth has to collect and reconcile several kinds of evidence.

  LANDFIRE provides fuel models and terrain for the selected area. Weather comes from sources such as HRRR and Open-Meteo. Other products add satellite observations, land cover, land-surface temperature, and roads. These sources were not designed to fit together. They arrive in different coordinate systems, resolutions, time zones, file formats, and definitions of missing data.

  The first version let too much of that complexity leak into the fire engines. A fix for one data source could quietly change another path. A layer could look plausible on the map while being shifted by a few cells. Weather labels could be one interval away from the values actually used.

  We eventually gave the system one internal contract. Extraction modules download raw data. Processing aligns every layer to a common grid with the same extent, resolution, coordinate system, and missing-data rules. The result is a Landscape. Products consume that object instead of knowing where each file came from.

  That boundary mattered more than any one model. It made spatial alignment testable, let multiple products reuse the same prepared landscape, and kept the API thin. It also made provenance possible: an output can say which source, time window, and transformation produced it.

• 

  U.S. Airport Sentinel Network

  2025

  A stochastic model of 620 U.S. airports that tests where pandemic surveillance can buy the most time.

  I built this project around a simple question: if the United States could monitor only a few airports for a new disease, which ones should it choose?

  It was my final project for CS166 at Minerva University.

  My first guess was betweenness centrality. Airports that sit on many shortest paths looked like natural sentinels. After 10,500 stochastic epidemic runs, that guess was wrong. Airports with the largest outgoing passenger flows detected outbreaks around day 30. Betweenness took until day 67. Random placement took until day 86.

  The 56-day gap came from moving the same surveillance capacity. It did not require more tests or more staff.

  I combined 2024 domestic traffic data from the U.S. Bureau of Transportation Statistics with airport and route records from OpenFlights. The resulting graph has 620 airports. Each airport is a node, each direct route is an edge, and expected passenger movement sets the edge weight.

  The graph matters because "busy" is only one way for an airport to be important. An airport can handle many passengers, connect otherwise distant parts of the network, or send a large flow of people outward. I tested those properties separately.

  Each airport also runs a stochastic SEIRD model. Its population moves between susceptible, exposed, infectious, recovered, and deceased states. On every simulated day, passengers travel first. Local disease transmission happens after they arrive.

  Travel is probabilistic. The number of passengers on a route is drawn from a Poisson distribution, and their health states are sampled from the population at the origin airport. This lets an exposed or infectious traveler start a distant outbreak before the origin looks badly affected.

• 

  Serbian News Aggregator

  2025-2026

  Collects Serbian news and measures how editorial signals survive across classical NLP and transformer models.

  The project began as a scraper. It became more useful when I treated the resulting archive as a measurement system: a way to ask what separates two newsrooms, how much of that difference is topic rather than style, and whether a model can reproduce the distinction.

  The analysis uses 2,304 articles published in January 2026: 1,963 from N1 Srbija and 341 from Biznis.rs. I developed it across three machine-learning assignments. They overlap heavily, so this page presents them as one cumulative study rather than three separate papers.

  The corpus, preprocessing, TF-IDF baseline, and most of the evaluation machinery recur in all three. The real progression is from prediction, to compression, to interpretation.

  I did not begin with a theory about editorial style. I began with a practical annoyance: collecting articles from different sites produces records that look similar but are never quite interchangeable. Each source has its own page structure, naming conventions, missing fields, and repeated boilerplate. Building the scraper forced me to decide what an article actually is before I could analyze one.

  Once the data was clean enough to compare, the first classification score was almost suspiciously high. That changed the project. “Can a model distinguish the outlets?” was no longer a very interesting question; clearly it could. The better question was why it could. Was it learning writing style, subject matter, author signatures, page furniture, or some mixture of all four?

  Each iteration therefore tried to remove one easy explanation. The first established a careful baseline under class imbalance. The second asked whether the signal was spread across thousands of terms or concentrated in a much smaller space. The third opened the model up: remove metadata, inspect coefficients and topics, compare contextual embeddings, and finally ask whether the learned distinction could be controlled during generation.

  Two Scrapy spiders walk each outlet's archive, follow article pages, and emit the same record shape for title, URL, timestamp, category, author, body, images, and embedded media. Source-specific parsing stays inside the collector. Downstream analysis sees one stable table.

  That separation is the part of the engineering I care about most. A crawler should be allowed to break when a publisher changes its markup without forcing every later notebook to change with it. The normalized article record became the boundary between acquisition and analysis. It also made failures visible: an empty author is a missing value; an empty body is a broken extraction.

• 

  Budgeter

  2024

  A small full-stack application for monthly budgets, transactions, and spending categories.

  Budgeter started with a modest goal: make it easy to see where a monthly budget is going without turning personal finance into a dashboard full of charts. A user can organize spending into categories, record transactions, and compare what has been spent with the budget that was set.

  The small scope made the project a useful place to think about the boundaries of a full-stack application. A budget is not just a number on the screen. It is connected to a user, a month, a set of categories, and the transactions that change each category's balance.

  The client is built in React and the API in FastAPI. The backend separates authentication, users, budgets, categories, and transactions into their own routes. SQLAlchemy maps those concepts to the database, while Alembic keeps changes to the schema reproducible.

  That separation matters most when a simple action crosses several parts of the system. Adding a transaction, for example, changes the history a user sees and the amount remaining in a category. Keeping the calculation in the API rather than recreating it throughout the interface gives the application one source of truth.

  I originally used Flask for the backend and later replaced it with FastAPI. The rewrite was less about raw speed than about making the API easier to understand: request schemas, route contracts, and generated documentation made mistakes more visible while I was still building.

  The project also taught me that a clean interface often depends on fairly unglamorous backend work. Database migrations, authentication, and predictable error responses do not appear in a screenshot, but they decide whether the interface remains simple as the application grows.

  View the source on GitHub

• 

  Passport Validator

  2023

  Extracts passport data from a scan, validates its machine-readable zone, and isolates the portrait.

  Passport Validator takes an image of a scanned passport and returns the holder's structured information together with a separate portrait image. The project focuses on the machine-readable zone, or MRZ: the two lines of standardized characters printed at the bottom of a passport identity page.

  Reading those lines is only the first step. OCR can produce text that looks plausible while changing a single character, and one character is enough to make a passport number or date wrong. The tool therefore treats extraction and validation as separate jobs.

  PassportEye locates the MRZ and returns its raw text. I then parse the fields myself according to ICAO 9303, including the document type, name, nationality, passport number, date of birth, expiration date, and country-specific optional data.

  The validator implements the ICAO check-digit algorithm for the passport number, birth date, and expiration date. Each check digit is calculated from the field that precedes it, so the program can report whether an extracted value is internally consistent instead of merely repeating the OCR output.

  The country code is resolved through pycountry, and facerecognition isolates the portrait from the page and saves it separately. The command-line entry point keeps the workflow simple: provide an image, parse and validate the MRZ, then extract the face.

  The useful lesson was that standards make ambiguous documents tractable. OCR alone gives probabilities; ICAO 9303 adds positions, field lengths, and checksums that can challenge the OCR result. Combining a statistical tool with deterministic constraints produced something much more useful than either approach alone.

  The project implements a focused subset of the standard rather than pretending to be a complete identity-verification system. It parses the fields present in the MRZ, validates three check digits, maps country codes, and preserves optional data without trying to infer what every country stores there.

  View the source on GitHub