Pressure Evolution System

Pressure Evolution System is an experimental physics simulation framework built from first principles in C. It is not centered on solving one predefined problem. Its purpose is to create a consistent simulated environment, apply physical laws to it, and study the behavior that emerges as the system grows in complexity.

The project currently includes gravitational forces, drag, collisions, multi-body interaction, telemetry, and early numerical integration work. Future development extends toward orbital systems, larger dynamic simulations, physical hardware integration through ESP32 devices, and digital-twin-style experiments that connect simulated behavior to real inputs and controllers.

Why I built it

I began this project because I wanted to understand simulation below the level of an existing engine or framework.

A simulation can look simple from the outside: define objects, apply equations, advance time, and display the result. In practice, every part of that process introduces decisions about numerical stability, precision, timestep size, state representation, scaling, validation, and software architecture. Building the system in C exposes those decisions instead of hiding them behind an engine.

The larger motivation is my belief that simulation is one of the most expansive uses of computing. Artificial intelligence can interpret patterns and generate responses, but simulation can create an internally consistent world in which behavior develops from rules, constraints, and interaction. That makes it possible to observe systems that are too large, dangerous, distant, expensive, or slow to study directly.

PES is my place to investigate that idea without forcing the work toward a product or immediate practical outcome.

The idea behind “Pressure Evolution”

The name describes both the simulated systems and the codebase itself.

Inside the simulation, bodies evolve under pressure from gravity, drag, collisions, initial conditions, and other forces. Behavior is not scripted in advance. It emerges from consistent rules acting over time.

The software evolves in the same way. New requirements create pressure on the architecture:

• adding more bodies pressures object management
• longer simulations pressure numerical stability
• orbital motion pressures the integration method
• larger experiments pressure performance and memory decisions
• hardware integration pressures timing, communication, and state synchronization
• better analysis pressures telemetry and data structures

Rather than designing an oversized framework before those needs exist, I document each pressure as it appears and allow the architecture to evolve in response. The project therefore studies two systems at once: the physical model being simulated and the engineering system required to support it.

What exists today

The current simulation core represents bodies using properties such as position, velocity, mass, and accumulated force.

Each simulation step:

1. evaluates active forces
2. updates acceleration
3. integrates velocity and position
4. resolves collisions and boundaries
5. records telemetry
6. advances the system state

The project currently supports:

• constant gravitational acceleration
• mutual gravitational attraction between bodies
• general force accumulation
• air resistance
• ground collision behavior
• multi-body motion
• structured telemetry exported for analysis
• simple validation through expected trajectories and event timing

The existing implementation is deliberately small. Its value is that the behavior can still be traced from equations to code to measured output.

Numerical integration

Numerical integration is one of the central learning areas of the project.

A continuous physical system must be approximated through discrete timesteps. Even when the force equation is correct, the simulated result can drift, gain energy, lose energy, or become unstable because of the integration method.

The first versions use simple step-based integration to establish the simulation loop and validate basic motion. Future development will compare improved methods such as RK2 and RK4, especially for orbital systems where small errors accumulate over long periods.

This part of the project is not only about selecting a better algorithm. It is about observing how timestep size, computational cost, stability, and accuracy change what the simulation can reliably represent.

Emergent behavior

The long-term purpose of PES is to create experiments where the interesting result is not explicitly programmed.

Examples include:

• stable and unstable orbital configurations
• resonance between multiple bodies
• energy drift produced by different integration methods
• collision chains and cascading changes in momentum
• sensitivity to small changes in initial conditions
• behavior that becomes visible only after long simulation periods

The project is most valuable when the output surprises me while still being explainable through the rules of the system.

Observational simulation projects

PES is intended to support focused observational studies built on top of the same core framework.

Potential investigations include:

• comparing orbital stability under different numerical integrators
• studying the behavior of two massive bodies orbiting one another
• observing how distant measurement points respond to changing gravitational systems
• testing how perturbations alter an otherwise stable orbit
• examining how accumulated numerical error changes long-duration simulations
• modeling simplified digital twins of physical systems with known inputs and measurable outputs

These experiments would not claim the fidelity of professional astrophysics or engineering software unless the model were properly validated. Their purpose is to turn physical questions into executable systems, then study the consequences of the assumptions encoded within them.

Embedded and hardware-in-the-loop direction

The embedded phase will connect the simulation to ESP32 hardware.

The initial goal is not to build a complete hardware-in-the-loop platform immediately. It is to establish the foundations required for one:

• bidirectional communication between the simulation and microcontroller
• physical controls that alter simulation parameters
• sensors that provide real-world input
• telemetry displayed through physical outputs
• timing and synchronization between simulated and embedded state
• repeatable experiments involving both software and hardware

This direction could eventually support digital-twin scenarios where a simulated system and a physical controller influence one another. The ESP32 work therefore extends the same central question: what new behavior appears when another constrained system is introduced into the loop?

Documentation as part of the system

Documentation is not an afterthought in PES. It is one of the project outputs.

I document:

• the assumptions behind each physical model
• equations and their software representations
• architecture changes
• numerical limitations
• failed approaches
• validation methods
• telemetry results
• new pressures placed on the system
• the reasoning behind each major evolution of the codebase

The goal is to preserve how the system changed, not merely what the final code became. A clean final architecture can hide the constraints, mistakes, and discoveries that produced it. PES is intended to retain that history.

What I have learned

The project has shown me that simulation engineering is not primarily about drawing convincing motion. It is about maintaining consistency between the conceptual model, mathematical formulation, numerical approximation, software architecture, and observed result.

I have also learned that small implementation choices can alter the behavior of the entire system. A timestep, force order, collision rule, or integration method can produce results that look plausible while being physically wrong. This makes validation and telemetry as important as the simulation itself.

Working in C has reinforced the relationship between abstraction and control. It makes expansion slower, but it also forces every structure, interface, memory decision, and simulation step to be deliberate.

Most importantly, PES has changed how I think about software architecture. A framework should not expand only because more features are imagined. It should evolve when real system pressure reveals that the current structure can no longer represent, measure, or control the behavior being studied.

Current limitations

The project is still in early experimental development.

Current limitations include:

• a small and mostly static object model
• basic numerical integration
• simplified collision handling
• limited automated validation
• no completed orbital experiment suite
• no active ESP32 communication layer
• no established unit system across every planned scenario
• no claim of professional scientific fidelity

These limitations are part of the documented state of the system, not features disguised as future tense.

Next pressures

The next development stages are expected to include:

1. dynamic object creation and management
2. consistent simulation units and parameter configuration
3. RK2 and RK4 integration
4. orbital mechanics experiments
5. stronger automated validation
6. improved telemetry and visualization
7. ESP32 communication and control experiments
8. reusable scenario definitions
9. larger observational studies built on the simulation core

The exact architecture is intentionally not fixed in advance. Each stage will introduce new pressures, and the framework will evolve according to what the experiments actually require.

What I’d do differently

I would establish validation and comparison experiments earlier.

The first implementation focused on getting forces, motion, collisions, and telemetry working together. That was useful, but it meant the simulation architecture began evolving before a complete testing strategy existed.

If restarting, I would define several reference scenarios at the beginning: constant acceleration, projectile motion, two-body attraction, energy conservation, and orbital stability. Each architectural or numerical change could then be measured against those scenarios immediately.

I would still keep the project experimental. The goal is not to avoid every wrong turn. It is to make each wrong turn observable, explainable, and useful to the next evolution of the system.