GreenSpec DSL

A programmable sustainability simulator where energy systems are defined, tested, and optimized using a custom rule-based language with real-time visualization.

Comment

About the Project

Inspiration

The idea for this project came from observing how complex sustainability, energy optimization, and system simulations are often hidden behind technical tools that are hard to visualize or reason about. We wanted to create a clear, interactive, and scriptable simulation environment where energy behavior can be seen, tested, and verified—not just calculated. The goal was to bridge the gap between logic-based simulations and human-understandable feedback.

What We Learned

Through this project, we learned:

  • How to design a domain-specific language (DSL) that is both expressive and readable.
  • Managing real-time state synchronization between a script engine and a live dashboard.
  • Handling manual vs automatic control modes without unintended side effects.
  • Designing smooth, non-jarring animations for simulations instead of abrupt state changes.
  • Debugging complex issues like circular imports, race conditions, and unintended background execution.

How We Built It

The project is built in Python and consists of several key components:

  • GSDsl (Domain-Specific Language):
    A custom scripting language to define energy rules, checks, simulations, and logs.
  • Interpreter & Runtime Engine:
    Parses and executes scripts step-by-step while reacting dynamically to state changes.
  • Curses-based Dashboard:
    A terminal UI that visualizes energy levels, trends, alerts, anomalies, and logs in real time.
  • Simulator Engine:
    Handles gradual energy transitions (increase, spike, optimize, stabilize) to ensure smooth and realistic behavior.

Mathematically, energy transitions are handled incrementally to avoid sudden snaps: [ E_{t+1} = E_t \pm 1 \quad \text{until target is reached} ]

This ensures smooth animations and accurate runtime reactions.

Challenges We Faced

  • Preventing the simulation script from running in manual mode.
  • Ensuring automatic optimization decreases energy gradually, not instantly.
  • Avoiding feedback loops where the runtime fought against the simulator.
  • Resolving circular import errors between interpreter, simulator, and runtime modules.
  • Making sure visual indicators (like color states) correctly reset after alerts.

Each of these challenges required careful architectural separation and strict rules about who controls energy and when.

Final Outcome

The result is a clean, extensible energy simulation platform that supports:

  • Script-driven verification
  • Manual experimentation
  • Real-time visualization
  • Smooth, realistic energy behavior

This project demonstrates how simulations can be both technically rigorous and human-friendly.

Built With

Share this project:

Updates