How nativegate actually works, in public.
Write-ups on the generator, the container a generated service runs in, and what it takes to expose forty-year-old Fortran as a REST + MCP service without rewriting it. Also mirrored as GitHub Discussions on the repo, if that's where you'd rather read or reply.
First contact: wrapping netlib specfun end to end
The generator pointed at someone else's 1996 Fortran: regenerated in CI on two OSes, 14 pinned values, three real defects found and fixed. The numbers agree to 16 digits.
Read the post →Exposing petroleum engineering models through Python
PVT correlations and well indices as callable functions and HTTP endpoints — the units, the session, and the regression baseline shape the API.
Read the post →How to containerize legacy scientific software
What the runtime image needs, what must match the orchestrator, and what correctness rules a container cannot fix.
Read the post →Fortran 90/95 to Python: practical considerations
Modules, KIND parameters, derived types, assumed-shape arrays — easier to bind, with a decision to make per construct.
Read the post →Fortran 77 to Python: what actually changes
Fixed-form columns, implicit typing, COMMON state and NumPy array views — modernized at the boundary only, with numerical sameness promised.
Read the post →How to wrap legacy Fortran with F2PY
The practical sequence for old decks: scope, expand, decide intent, build, test against known answers, then everything downstream.
Read the post →F2PY: when it works and where it stops
A plain evaluation of NumPy's wrapper: the cases where it's the right call, and the honest list of what it leaves to you.
Read the post →Legacy scientific software modernization: a practical guide
Three inventories, interface-first exposure, and the traps that stall rewrites of validated scientific codes.
Read the post →How to deploy a legacy engineering model as an API
Stateful models, one-call-at-a-time semantics, and what the generated service gives you — and deliberately doesn't.
Read the post →Modernizing legacy engineering software: why big rewrites fail
Rewrites transfer decades of invisible discipline decisions by hand, with no oracle. Interface-first modernization with a numerical baseline works.
Read the post →From a Fortran reservoir model to a Python API
A walkthrough of the committed example: 4,800 lines of unmodified Fortran, a verified service, and the two details that decide correctness.
Read the post →Modernizing legacy petroleum engineering software
PVT decks, COMMON blocks, and validation as the asset: why petroleum software is the hard version of the modernization problem.
Read the post →f90wrap vs nativegate: Python interfaces vs a full modernization workflow
f90wrap handles modern, object-shaped Fortran better than we do. An honest comparison of where that scope stops and a full pipeline begins.
Read the post →F2PY vs nativegate: which should you use?
F2PY is NumPy's own tool and remains the right choice for many jobs. An honest comparison of scope — bindings vs the whole modernization workflow.
Read the post →Fortran to Python: a practical modernization guide
The boundary layer is mostly solved. Where the work actually piles up: intent, COMMON state, builds, packaging, and evidence the numbers didn't move.
Read the post →How to modernize legacy Fortran without rewriting it
Keep the numerics, replace the interface. The five-step path from a validated deck to a package, an API, and a verified numerical baseline.
Read the post →Non-root by default: the container a generated service actually runs in
Every service ngate generates runs as an unprivileged, explicit UID —
matching the Kubernetes manifests it also generates, not fighting them.
Generated bindings, not hand-written ones
pybind11 and f2py already solve the C++/Fortran-to-Python boundary. The hard part was never writing bindings by hand — it's everything around them.
Read the post →