Transforming Research into
Production-Ready Software
We partner with national laboratories to turn complex scientific models and research code into accessible, reliable applications that practitioners can actually use.
Our Approach
Scientists and researchers create groundbreaking models and algorithms, but research code isn't production software. It's often written to prove a concept, not to be deployed at scale or used by non-experts.
We bridge that gap. We take validated scientific models and build them into proper applications with robust architecture, intuitive user interfaces, comprehensive testing, and reliable deployment infrastructure.
The result: tools that engineers, analysts, and decision-makers can actually use in their daily work.
What We Build With
Each stack below shipped in the project listed with it. For HyRAM+ and HELPR we evaluated six GUI frameworks against written requirements before picking one.
Cross-platform desktop
HyRAM+, HELPR
High-performance compute
FFIAM
Real-time 3D
FFIAM
Web platforms
ForgeSolar
Packaging & deployment
FFIAM, HyRAM+, HELPR
Validation
FFIAM
Case Studies
Three projects with Sandia National Laboratories.
HyRAM+
Hydrogen Plus Other Alternative Fuels Risk Assessment Models
The problem
Assessing hydrogen infrastructure risk means modeling release behavior, flame physics, failure probabilities and consequences. The people who need the answers are facility planners, code officials and safety engineers, not software developers.
What existed
Experimentally validated physics and probabilistic models in Python 3, built on the scientific stack (NumPy, SciPy, matplotlib), driven by a desktop interface written against a C# GUI framework that had since been retired.
Why adoption stalled
The interface was tied to a discontinued framework and a single platform, and reached the Python analysis layer through fragile GUI-to-backend integration. macOS users had no supported way to run it.
Our role
We surveyed six GUI frameworks against what the project needed: Python 3 integration, Windows and macOS support, stateful save and load, unit conversion, and licensing Sandia could accept. Concurrent analyses and undo/redo were on the wish list. Qt with PySide won, partly because we could reuse the framework we had already built for HELPR. We then designed and built the replacement interface.
The result
A cross-platform HyRAM+ on a supported Python stack. The interface and the analysis code are both Python now, so the fragile bridge between them is gone.
HELPR
Hydrogen Extremely Low Probability of Rupture, part of the HyBlend initiative
The problem
Deciding whether existing natural gas pipelines can safely carry hydrogen blends is a probabilistic fracture-mechanics question. Hydrogen infrastructure planning depends on it, and it takes specialist expertise to run.
What existed
Fatigue and fracture models in Python that could run parallel probabilistic computations, but only as research code.
Why adoption stalled
The intended audience was pipeline engineers and analysts, not Python developers. With no simple installer and no interface, only the people who wrote the models could run them.
Our role
We surveyed six GUI technologies against the project's requirements: support for Python's scientific libraries, display of textual and visual output, an installation method a semi-technical user could follow, and acceptable licensing. Multi-platform support and interactive charting counted as secondary goals. We selected PySide with Qt and built the cross-platform desktop application on it.
The result
A modular desktop application where users vary hydrogen volume fractions and operating parameters and see which ones drive structural integrity. The Qt and PySide foundation built here was later reused for HyRAM+.
FFIAM
Full-Field Irradiance Analysis Model
The problem
When a concentrating solar power field sits in standby, reflected sunlight forms high-irradiance regions in the airspace above it. Those are a hazard to aircraft and to birds. Working out where that flux concentrates means evaluating the entire field volume, not just the receiver.
What existed
The earlier Tower Illuminance Model (TIM) established a navigable 3D interface for this class of question, but assessed the receiver rather than the full airspace. Nothing assessed the full airspace volume, which is what safety and permitting questions need.
Why adoption stalled
Volumetric irradiance at field scale is expensive to compute. Planners also need to change the aim strategy, date and time, and reporting threshold, and see the hazardous region move.
Our role
We developed FFIAM for Sandia: a C++/CUDA analysis library with a parallelized CPU path for machines without a GPU, shipped Docker-containerized behind a one-command quickstart. We built both workflows on top of it. Data is the pyffiam Python module, which produces heatmaps, time-resolved animations, flight-path radiant-exposure plots and tabulated summaries. Visualization is a real-time Unreal Engine renderer for the field and its flux voxels. We validated the results against ray-traced comparison and against UAS measurement campaigns at the National Solar Thermal Test Facility.
The result
FFIAM V3.0 evaluates field radii up to 1.6 km and 300 m of airspace height, over 11,000 heliostats and roughly 300 million voxels per analysis at 2 m resolution, with 1 m resolution available for smaller fields. Operators compare single-point, ring, and constant-vector standby strategies to find the configurations that preserve the most navigable airspace.
Engagement
Three years, ending in 2026 with the open-source release of FFIAM V3.0 through Sandia's OpenCSP.
Have research code like this?
A working model nobody outside the team can run, or an interface on a framework nobody supports. Each project above started that way.
Get in Touch