telecogecoTwin · Jupyter notebook
Run the twin's code, cell by cell.
The same five stages as the whitepaper, as executable cells. Runs entirely on the generic rung: simulation, generic 3GPP defaults (uncalibrated).
What is inside
- 1Setup
- 2Load the estate data
- 3Build the estate: the TR 38.901 maths, plotted
- 4Calibration: differential evolution, the gate
- 5Inference: tilt sweep, a cell asleep
- 6Recap
Downloads
Three files, one estate.
twin walkthrough
The five stages as executable cells with the maths written out before each step: generate an example estate, build it, run the calibration search, then chain tilt and on/off configs through Estate.evaluate(). Outputs are baked in, so it reads without running anything.
Example topology
The fictional hex layout the notebook loads in stage 2: cell positions, azimuths and heights with generic field names. No operator data.
Example config
Per-cell electrical tilt and power for the example estate, the inputs the what-if stages change.
To run it
Five commands, one virtualenv.
git clone https://github.com/ugeco-opensource/ocp-auRu cd ocp-auRu/services/ocp-physics-digitalTwin python3 -m venv .venv .venv/bin/pip install -r requirements.txt -r notebooks/requirements-notebook.txt .venv/bin/jupyter notebook notebooks/twin_walkthrough.ipynb
The notebook imports the twin's own package, so it runs from a clone of the twin service in the open repository (opens in a new tab), where the walkthrough ships as notebooks/twin_walkthrough.ipynb. The two CSVs are the example estate it loads in stage 2: a fictional hex layout with generic field names (cell_id, cell_el_deg), no operator data.
simulation, generic 3GPP defaults (uncalibrated). Nothing in the notebook or its data comes from, or makes a claim about, any real network.
Prefer the HTTP service? The whitepaper's flow section drives the same stages through the FastAPI endpoints.