High-level G-Cubed Platform Overview

Introduction

G-Cubed is a comprehensive economic modeling platform delivered as a containerized Python development environment. The system combines industry-standard development tools with specialized economic modeling capabilities, providing researchers and economists with a powerful yet flexible simulation environment.

Built on VS Code and Docker, the G-Cubed platform utilizes containerization technology and adheres to the Dev Containers standard. This approach ensures a consistent user experience, and reliable and repeatable results, whilst enabling flexible deployment across various computing environments.

The platform also leverages the Git version control system to maintain strict version control, facilitate collaboration, and ensure reproducibility of economic models and simulations.

Our flexible system architecture enables organizations to choose deployment configurations that align with their specific security requirements, IT policies, and operational preferences without compromising on functionality or performance.

System Architecture

The G-Cubed architecture consists of three primary components that work together to provide a complete economic modeling environment:

G-Cubed Architecture

Front-end (User Interface)

VS Code serves as the user interface, providing a modern development environment for editing files, running simulations, and visualizing results. There is one instance per user.

This component can run:

  • On the user’s local machine
  • In a web browser (cloud-based)
  • In a virtualised environment

The front-end connects to the execution environment, which handles the computational workload of economic simulations.

Execution Environment

The execution environment is a Linux-based system running Docker, which assembles, hosts and executes the G-Cubed Dev Container. Key aspects include:

  • Linux Host
    • Used by the VS Code back-end to assemble and host containers
  • Docker Container
    • Encapsulates the entire G-Cubed runtime environment
  • Components
    • G-Cubed Python libraries and dependencies
    • Sym language compiler (built specifically for the runtime environment)
    • Economic models and simulation code
    • VS Code back-end with required extensions

This component can run:

  • On the user’s local PC (eg: running in Microsoft WSL, on MacOS, or a Linux workstation)
  • On-prem in a Linux server/virtualised environment, or
  • In cloud

This environment is considered ephemeral — data persistence is not guaranteed after a container is stopped. There is one instance per user, and users should regularly commit their work to the data repository.

Data Repository

A Git-based repository serves as the central storage location for:

  • Devcontainer definitions
  • Economic models and data
  • Simulation configurations
  • Python code and custom scripts
  • Sym language files

This repository ensures version control, facilitates collaboration between users, and provides a persistent storage mechanism outside the ephemeral execution environment.

This component can be hosted:

  • On Microsoft’s GitHub service
  • On another Git hosting service
  • On-prem on a dedicated Git repository hosting server, or
  • On-prem on a shared fileserver

Deployment Options

G-Cubed offers exceptional flexibility in deployment, accommodating various infrastructure requirements and security policies:

G-Cubed Deployment Configurations

The main categories of options include:

Pure Cloud Configuration

The McKibbin Software Group standard configuration.

  • Front-end: Web browser based VS Code
  • Execution: GitHub Codespaces
  • Repository: GitHub

Benefits: Zero local installation, accessible from anywhere, no maintenance overhead, complete Microsoft GitHub security model.

Hybrid Configuration

  • Front-end: Local VS Code (local PC or virtualised Windows environment)
  • Execution: Cloud-hosted virtual machine
  • Repository: GitHub or self-hosted Git

Benefits: Familiar local interface with scalable cloud computing resources.

Pure Local Configuration

  • Front-end: Local VS Code (local PC or virtualised Windows environment)
  • Execution: Local Docker environment
  • Repository: Remote GitHub or local Git

Benefits: Full control over execution environment, works in air-gapped settings.

Self-hosted Configuration

  • Front-end: Local VS Code (local PC or virtualised Windows environment)
  • Execution: On-premises server infrastructure
  • Repository: Self-hosted Git server

Benefits: Complete control over all components, compliance with strict security policies

McKibbin Software Group Standard Configuration

The standard configuration provided by McKibbin Software Group utilizes GitHub Codespaces for a fully cloud-based deployment:

  • Customer-specific repositories managed by McKibbin Software Group
  • Web browser access via GitHub Codespaces
  • Container components sourced from:
    • McKibbin Software Group repositories (devcontainer definitions, models, code)
    • Microsoft registry (base container images)

This configuration minimizes setup requirements while providing a complete and managed G-Cubed environment.

System Lifecycle

General overview of the Dev Container lifecycle. This may be customised depending on install type.

Installation Phase

  1. The Git repository containing devcontainer definitions, models, and code is cloned to the execution environment
  2. This one-time operation establishes the foundation for subsequent builds

Build Phase

  1. Docker retrieves base container images from the Microsoft registry
  2. Additional dependencies are pulled from McKibbin Software Group repositories
  3. The devcontainer is instantiated with all required components

Runtime Phase

  1. The Docker container starts running
  2. VS Code back-end processes initialize and install necessary extensions
  3. Git synchronizes with the central repository
  4. The G-Cubed environment becomes operational

Normal Operations

During regular usage, the container:

  • Maintains all required data and files for operation
  • Can be started, stopped, and reconnected to as needed
  • Should be regularly synchronized with the central Git repository
  • May retrieve additional files from McKibbin Software Group repositories for complex simulations

Rebuild and Update Process

  1. Container disposal or rebuild triggers a return to the build phase
  2. Updates to the G-Cubed implementation are pushed by McKibbin Software Group to the central repository
  3. Users pull updates and trigger container rebuilds to incorporate changes