Our goal was not simply to build another packing or scheduling algorithm. Instead, we set out to create an optimization system capable of understanding the structure of the problem itself and dynamically adapting its behavior as conditions changed.
Inspiration
Modern shipyards are among the most complex operational environments in the world. Thousands of heavy blocks must be transported, stored, stacked, and assembled while satisfying physical space limitations, equipment constraints, project deadlines, and dependency requirements.
Traditional optimization approaches often focus on a single dimension of the problem, such as packing efficiency or scheduling performance. However, real shipyard operations require both domains to work together. A spatially optimal layout can create scheduling bottlenecks, while a perfectly efficient schedule may require impractical transportation movements.
This challenge inspired us to explore a different approach: an optimization system that continuously interprets the problem landscape and adapts its search strategy accordingly.
What We Built
We developed a Regime-Aware Self-Regulating Optimization System (RASROS), a multi-layer optimization architecture that combines:
- 3D Best-Fit Decreasing constructive packing
- Resource-Constrained Project Scheduling
- Large Neighborhood Search (LNS)
- Simulated Annealing (SA)
- Tabu Search
- Genetic Recombination
- Multi-Armed Bandit Hyper-Heuristics
- Adaptive Entropy Injection
- Adversarial Search Mechanisms
- Regime-Aware Strategy Selection
- Adaptation Governance Controls
The system operates as a self-regulating optimization ecosystem rather than a fixed solver.
At the core of the architecture is a Problem Regime Detector that continuously analyzes runtime characteristics such as packing density, dependency depth, resource utilization, and spatial entropy. Based on these signals, the system classifies the current optimization landscape into regimes such as:
- Packing Dominant
- Scheduling Dominant
- Resource Congested
- Dependency Heavy
- Adversarial Tight
- Balanced
Each regime activates specialized optimization behaviors designed to target the dominant bottleneck.
Mathematical Foundation
The packing problem is modeled as a constrained three-dimensional placement problem.
For every pair of blocks:
$$ AABB(i) \cap AABB(j) = \varnothing $$
ensuring that no spatial overlap occurs.
Scheduling is modeled as a Directed Acyclic Graph (DAG):
$$ G=(V,E) $$
where every dependency must satisfy:
$$ Finish(parent) \le Start(child) $$
Resource allocation simultaneously respects crane capacity, transporter capacity, and operational feasibility constraints.
The hyper-heuristic layer uses an Upper Confidence Bound (UCB1) policy to dynamically select optimization operators:
$$ UCB_i = \mu_i + c\sqrt{\frac{\ln N}{n_i}} $$
where:
- $\mu_i$ is the observed reward
- $N$ is the total number of selections
- $n_i$ is the number of times operator $i$ has been selected
This balances exploration and exploitation throughout the search process.
Key Innovations
Regime-Aware Optimization
Instead of applying a single search strategy throughout execution, the solver dynamically shifts optimization focus based on detected structural bottlenecks.
Elite Multiverse Memory
Rather than maintaining a single elite archive, the system stores multiple elite populations corresponding to different optimization regimes. Controlled migration allows knowledge transfer without sacrificing diversity.
Adaptive Escape Mechanisms
To prevent premature convergence, the solver employs:
- Micro perturbations
- Macro structural shakes
- Regional resets
- Full layout rebalancing
These mechanisms help the search escape difficult local optima.
Adaptation Governor
One of the most important innovations is the Adaptation Governor, a control layer responsible for regulating adaptation itself.
The governor manages:
- Regime transition stability
- Entropy injection budgets
- Strategy switching frequency
- Elite migration policies
This prevents oscillatory behavior and ensures stable convergence throughout optimization.
Challenges Faced
One of the biggest challenges was managing the interaction between spatial packing and scheduling decisions.
Improving packing density often increased transportation distances, while scheduling improvements could reduce layout efficiency. Developing a feedback loop that allowed both domains to influence each other required multiple iterations of architecture redesign.
Another challenge involved search stability. Highly adaptive systems can become overly reactive, constantly switching strategies and disrupting convergence. The introduction of the Adaptation Governor was a direct response to this issue and significantly improved overall stability.
Scalability also presented difficulties. Naive collision detection scales poorly for large instances, so we implemented a Spatial Hash Grid that reduced collision checks from quadratic behavior to near-constant-time neighborhood queries.
Results
The final system successfully achieved:
- High-density packing layouts
- Strict feasibility compliance
- Zero collision violations
- Resource-aware scheduling
- Improved makespan reduction
- Stable convergence under adversarial conditions
Benchmark experiments demonstrated substantial improvements over baseline constructive heuristics while maintaining scalability for large industrial problem instances.
What We Learned
This project reinforced an important lesson in optimization:
The most difficult problems are often not solved by a single algorithm, but by a system capable of understanding when different algorithms should be applied.
By combining packing, scheduling, adaptive search, and self-governance into a unified architecture, we created a solver that continuously adapts to the structure of the problem it is solving.
The resulting framework demonstrates how optimization systems can move beyond static heuristics toward self-regulating optimization ecosystems capable of handling increasingly complex industrial challenges.
Future Work
Future extensions include:
- Reinforcement learning-driven strategy selection
- Distributed multi-node optimization
- Real-time digital twin integration
- Online operator generation
- Self-evolving hyper-heuristics
These directions would further strengthen the solver's ability to adapt to large-scale industrial environments and continuously improve over time.
The Grand Shipyard Optimization Solver is built as a highly synchronized, dual-layer engineering application. It blends a high-performance Native C++23 optimization solver at its analytical core with a fully responsive TypeScript/React 19 digital twin interface deployed on Google Cloud Run container architecture. Here is a detailed breakdown of the languages, frameworks, architectural layers, and technologies utilized to build this system.
- Core Languages & Tooling TypeScript (ES6+): Governs the functional business logic, component lifecycles, and real-time client-side solver engine. Types are strictly declared to map spatial models, scheduling graphs, and 3D coordinate transformations safely. C++23: Powering the native /solver/... engine. Utilizing template-driven data structures, standard algorithms, and high-performance layout vectors to parse structural 3D models, calculate Axis-Aligned Bounding Box (AABB) intersection maps, and evaluate combinatorial schedule sequences at native machine speed. Vite 6 + TSX: Acts as the ultra-fast build tool and development bundler, processing hot module layouts and fast assets serving. HTML5 & CSS3: Provides standard structure and custom SVG layout pipelines for visual renderings.
- Frontend Framework & Interface Design React 19: Utilized to build a declarative, modular, and highly interactive Single-Page Application (SPA). State hooks manage real-time optimization updates, timeline navigation, and rendering buffers. Tailwind CSS v4: Directly handles layout, responsive behaviors, and high-contrast color palettes (slate, charcoal, off-white) using clean utility classes. It is integrated directly via Vite's @tailwindcss/vite plugin. Motion (Framer Motion 12): Animates UI transitions, progress sliders, metric updates, and spatial state selections to guide user attention smoothly. Lucide React: Serves as a streamlined, vector-based icon library representing mechanical operations (cranes, trucks, grids, timelines).
- Core Analytical Solver Engines The optimization logic is modeled through a dual-engine layout, replicating heavy native calculations directly into a client-executable TypeScript equivalent for real-time visualization: A. The TypeScript Digital Twin Engine (/src/solver-engine/...) This acts as the web-executable counterpart to the C++ solver, allowing instant local recalculations: model.ts & objecitive.ts: Define physical attributes (weight, volume, deadlines, DAG dependencies) and evaluate multi-objective fitness scores (packing utilization, makespan efficiency, resource overlap). yard.ts (Spatial Hash Grid): Divides the shipyard coordinate boundary into uniform spatial hash cells (density buckets). It performs fast 2D boundary scanning to identify volumetric bottlenecks. packing.ts: Implements 3D Best Fit Decreasing (BFD) packing to stack elements while ensuring a rigid supportive contact surface for stacked blocks. scheduler.ts: Builds Directed Acyclic Graphs (DAG) representing logistics sequences, scheduling earliest-start movements with finite Heavy Lifting Cranes and transporter capacities. regime-aware.ts & adaptation-governor.ts: Classifies solver landscapes into behavioral regimes (e.g., Stacking-Bound, Scheduling-Bound, Dependency-Bound) and dynamically adjusts operators to break stagnation patterns. B. The Native C++23 Heuristics Solver (/solver/src/...) Upper Confidence Bound (UCB) Hyper-Heuristic: A Multi-Armed Bandit strategy choosing optimization operators based on past relative rewards. Elite Solution Pool (elite.hpp): Maintains the top-performing global optima under a multi-criteria sorting priority to prevent regressions. Simulated Annealing & Tabu Search: Explores localized coordinate adjustments and schedules moves to escape saddle points or local traps.
- Hosting, Infrastructure & Cloud Services Google Cloud Run: Hosts the application container. Cloud Run allows the containerized applet to scale dynamically, providing secure HTTPS layers for end-users. Docker Container Layer: Standardizes dependencies like Node, Nginx reverse proxies, environment setups, and GCC-compatible compilation utilities. Nginx Proxy Layer: Hard-routed within the Cloud Run context to proxy client communication exclusively through Port 3000 for secure, low-latency transport. process.env Security Management: Preserves operational keys and secrets server-side via Node environment injection, preventing client-side credentials leakage.
- Specialized Web Integration APIs Web-Standard Canvas API: Controls the isometric 3D yard visualizer, drawing blocks, crane coordinate paths, support structures, and the overlapping grid thermal heatmaps dynamically with fast canvas canvas updates. Recharts: A D3-based chart library used to display real-time numeric performance metrics (Convergence rate, resource load metrics, deadline compliance tracking). Google GenAI SDK (@google/genai): Integrated and prepped at version ^2.4.0 in the application root to enable deep semantic assistance or predictive sequence classifications using Gemini model API bridges if expanded.
- Architectural Summary of Execution Flow Physical & Temporal Inputs: The user adjusts blocks, crane reach coordinates, deadlines, or DAG hierarchies in the React UI. Construction Heuristics: The system parses inputs into a Topological Placer (3D BFD) and a Precedence-Aware Scheduler (RCPSP). Refinement Heuristics: The Regime Governor determines if the current layout is bound by spatial crowding or timeline blocks, assigning adaptive weights to Simulated Annealing or spatial distribution shufflers. Digital Twin Sync: The state transfers instantly to the Web Canvas and Gantt Scheduler components, updating metric panels and active heatmaps.
Built With
- c++23
- css
- css3
- html5
- lucide
- motion
- react
- tailwind
- typescript
- vite
