DRIFT: a physics-informed ODE model of how condensates enter cells

A virtual cell for the first minutes of condensate entry

The project describes itself as a physics-informed virtual cell model for simulating the cellular uptake of biomolecular condensates, or BMCs. The README expands the scope: membrane mechanics, signaling pathways, intracellular trafficking and uncertainty analysis, all in one framework, aimed at the uptake behaviour of micro and nano sized BMCs.

That is a specific scientific question with a specific scope. The audience is a computational biologist or a physical scientist who wants to explore how a droplet of biomolecular condensate gets into a cell, and who wants to vary its physical properties and the cell's signaling machinery and see what changes.

The framing as a virtual cell matters. This is not a training pipeline and not a structure prediction tool. It is a dynamical model: the README describes it as a physics based ODE model of BMC uptake, and the analysis layer lets you perturb parameters and observe the system.

The scientific framing also sets a bar. A framework that claims to model uptake is making a claim about biology, and the interesting question for an adopter is not whether the code runs but whether the parameters and the module coupling reflect anything you would defend in a paper. That is what the parameter directory and the benchmarking and sensitivity features exist to support.

Four coupled modules and four signaling pathways

The model couples four modules, and the README lists them precisely.

Cell mechanics covers wetting, contact angle and interfacial energy, which is the physical side of the story: how a droplet deforms against a membrane, how much it wets, what that costs in energy. Membrane signaling covers SNARE, ESCRT, Glycoprotein and PIK3C, the four pathways that the model treats as the routes by which a cell handles the condensate. Membrane state tracks integrity and lipid order, referred to as GP in the outputs list. Intracellular trafficking runs from the plasma membrane to the endosome and then to the lysosome or the cytoplasm.

The last module is where the modelling claim is strongest, since delivery efficiency is the quantity the README says the framework predicts, from physical properties and signaling dynamics jointly.

The four pathways also show the design choice the framework makes. Rather than modelling one uptake route in detail, it models four in parallel and lets the analysis layer compare them, which is what the Pearson correlation analysis and the knockout simulation are for. The CRISPR knockout simulation is the sharpest tool here: it lets you ask which pathway matters by removing it and rerunning, and the README lists it as one of the outputs of the model analysis script.

Four scripts, one dependency install

The usage section is a set of four entry points, and the dependency list is short enough to install in one line.

pip install numpy pandas scipy matplotlib openpyxl

Python 3.10 or later is the stated requirement. There is no package to build, no configuration file and no service to start. Each script is run directly.

The core BMC simulation is the first one, and it is the only one you need to see the model work:

python bmc_core_model.py

Its outputs are listed in the README: simulation data as an .xlsx file, wetting dynamics, contact angle, interfacial energy, the four pathway activities, membrane integrity and the intracellular BMC distribution. So the deliverable of a run is both numbers and the figures that go with them.

The second script is the analysis layer:

python model_analysis.py

That one covers sensitivity analysis, the CRISPR knockout simulation, prediction for other droplet compositions, the Monte Carlo uncertainty analysis and parameter reference tables. The third extends the time horizon:

python drift_simulation_3600s.py

which simulates an early phase from 0 to 300 seconds and long term dynamics from 0 to 60 minutes, and reports pathway dynamics, membrane mechanics, GP dynamics, intracellular trafficking and steady state module composition. The fourth is the correlation study:

python pearson_analysis.py

performing Monte Carlo parameter perturbation, Pearson correlation analysis, heatmap visualization and correlation tables written to .xlsx.

The design is deliberately script oriented rather than a library with an API, which keeps the dependency surface small and makes each analysis reproducible by re-running a file.

The repository layout no longer matches the README

Here is the inconsistency worth flagging before anyone tries to reproduce the results.

The README documents a repository structure of four flat Python files at the root: bmc_core_model.py, model_analysis.py, drift_simulation_3600s.py and pearson_analysis.py, plus an outputs/ directory and a figure1/ directory. Those are the names used in every command in the usage section.

The actual top level of the repository looks different. It contains five numbered directories, 01_core_simulation_300s/, 02_pathway_module_v2/, 03_extended_analyses/, 04_drift_revision_3600s/ and 05_parameters/, along with four root scripts named differently: 1. CORE_ODE.py, 2. MONTE_CARLO.py, 3. 3600_WINDOW.py and 4. PEARSON_CORRLATION_ANLYSIS.py. Note the misspelling in that last name, and note the numbered filenames with spaces and dots in them, which need quoting when invoked from a shell.

The numbering in the directories is informative. 01 covers the 300 second core simulation, 02 is a second version of the pathway module, 03 holds the extended analyses, 04 is a revision for the 3600 second window, and 05 holds the parameters. The directory names describe the same stages the README describes, which suggests the work was reorganised into stages after the README text was written.

So the four commands in the README may not exist under those names in the current tree. Anyone evaluating this project should map the documented commands onto the current layout before planning around them, and 05_parameters/ is the directory to inspect first, because in a physics informed model the parameter table is the model.

Uncertainty analysis and knockout as first class features

Most simulation code of this kind ships a solver and leaves the analysis to the user. DRIFT does not, and that is where its value sits for anyone doing research rather than demoing a picture.

The Monte Carlo uncertainty analysis is the core of it. The model has many parameters, and a single trajectory tells you little about whether a conclusion depends on a plausible value or an arbitrary one. Perturbing parameters repeatedly and reporting distributions answers that.

The Pearson correlation analysis builds on the same idea. It perturbs parameters, correlates the resulting pathway activities against the intracellular distribution, and produces heatmaps and correlation tables. Given the README's claim that the framework predicts delivery efficiency from physical properties and signaling dynamics jointly, a correlation study over Monte Carlo runs is the natural way to interrogate that claim, and the pairing of the two scripts is the most interesting design decision in the repository.

The knockout simulation is the other lever. Because the four pathways are modelled in parallel, removing one and rerunning gives a direct answer to a causal question, which is more informative than a correlation between two quantities that may both follow from something else.

The benchmarking of droplet parameters and the sensitivity analysis complete the set. Together they are what turn the framework from a demonstration into something you can argue with, and they are the reason the parameter directory matters as much as the solver.

An unknown licence is the adoption blocker

The repository's licence field records an unknown value, and unlike most of the projects in this space, the top level listing contains no LICENSE file. There is no copyright holder statement and no grant of use in the tree.

That is a concrete problem rather than a technicality. The README's stated purpose is investigation and modelling, but a model that people cite, extend or fold into a pipeline needs a licence that says who may do what. Without one, the default position in most jurisdictions is that others hold copyright and no permission is granted, which is the opposite of what a research codebase usually intends.

It also has a knock on effect for the tooling around it. Automated licence checks across a dependency list will report an unknown identifier, and an organisation that requires a recognised licence before a repository can be used as an input to a project will need a human answer first.

The other adoption signals are thin but not negative. The repository is not archived, the last push was on 2026-08-03, and it publishes no GitHub releases, so there is no tagged version to pin to and no changelog to read. There is no test directory and no continuous integration entry in the top level listing, so the scripts have no automated check that they still run.

None of that makes the science wrong. It makes the packaging unfinished, which is a different problem and one the maintainer can still fix.

Editorial conclusion

Use DRIFT if you need a runnable in silico model of biomolecular condensate entry into cells, since the model couples membrane mechanics, four signaling pathways and intracellular trafficking and the scripts run with nothing but numpy, pandas, scipy, matplotlib and openpyxl installed. Do not adopt it as the basis for derived work until the licensing is settled, because the repository records an unknown licence and no LICENSE file appears at the top level, and do not rely on the README's file names, since the repository root has been reorganised into numbered directories and differently named scripts. Before you run anything, verify two things: which of the two layouts you actually have, because the documented commands and the checked in file names disagree, and whether the parameter values in 05_parameters/ are the ones your scenario needs, since the model is only as good as that table.

Frequently asked questions

Official sources

1. Issues
2. README
3. YiLi-2020/Drift on GitHub