TesLab is a computational experimentation platform for engineering research. It combines reproducible simulation, explicit experimental protocols, scientific governance, and immutable research records to evaluate historical engineering concepts using modern computational methods. Its first experimental program investigates adaptive resonance tracking in coupled resonant systems inspired by Nikola Tesla's documented work.
TesLab shares several principles with modern model-based engineering: explicit system models, reproducible simulations, traceable assumptions, predefined validation criteria, and evidence-driven decision making. Rather than focusing solely on numerical simulation, the project treats the entire experimental lifecycle—from hypothesis definition to closure report—as a first-class engineering artifact.
TesLab originated while I was developing BrainIAc, an independent computational neuroscience research platform focused on adaptive biological systems. When i saw the Tesla Challenge while navigating on Dassault's web sitcomputational science , it led me to ask a broader scientific question: could some of Nikola Tesla's documented engineering concepts have measurable relevance beyond electrical engineering, particularly in biological or cellular contexts?
Rather than introducing those ideas directly into BrainIAc, I chose to create a separate research platform. TesLab allows those engineering concepts to be investigated independently, through reproducible simulation and explicit experimental protocols, before considering whether any validated mechanism could justify a future biological study. This separation preserves the scientific integrity of both projects while allowing potential connections to be explored only if supported by evidence.
TesLab — First Research Update: From Tesla-Inspired Questions to Reproducible Experiments and an Interactive Virtual Twin
In my original post, I introduced TesLab as a computational experimentation platform for investigating engineering concepts inspired by Nikola Tesla's work through reproducible simulation, explicit experimental protocols, scientific governance, and traceable research records.
The Open Tesla Challenge was the initial catalyst for the project, but TesLab has since developed into a broader independent research program.
My objective is not primarily to reproduce Tesla's inventions visually, nor to demonstrate that his ideas necessarily have applications beyond electrical engineering.
The question I am interested in is more open-ended:
What happens when Tesla-inspired engineering concepts are reconstructed as explicit computational models and subjected to modern, falsifiable experimental methods?
Some ideas may survive that process. Others may fail. Some may reveal interesting engineering mechanisms without having any relevance outside their original domain.
And, eventually, a small subset might justify asking whether an analogous mechanism is worth investigating in another kind of adaptive system.
That last possibility is particularly interesting to me because TesLab originated while I was developing BrainIAc, my independent computational neuroscience platform.
But I deliberately keep the two projects separate.
The intended path is not:
Tesla concept → assume biological relevance → implement it in BrainIAc
but rather:
Tesla-inspired concept → engineering model → validation → controlled experiments → evidence → only then, if justified, formulate a separate biological hypothesis
TesLab therefore acts partly as an experimental filter.
Since my original post, the project has now completed its first full research cycles.
First research program: coupled resonant systems
I started with one of the most obvious themes associated with Tesla's engineering work: coupled resonance.
The first model is intentionally modest.
Rather than immediately attempting to reproduce the complete complexity of a physical Tesla coil, I implemented a lumped model consisting of two inductively coupled RLC resonators.
The reason for starting there was methodological: before adding spark gaps, nonlinearities, high-voltage effects, geometry-dependent electromagnetic phenomena or more realistic components, I wanted a baseline whose behavior could be understood and independently validated.
The simulator was therefore tested against analytical and numerical expectations before its output was used as scientific evidence.
Validation includes normal-mode frequencies, damping behavior, energy conservation and accounting, numerical convergence, deterministic reproducibility, failure detection, and other numerical invariants.
Only after that foundation was established did the experimental work begin.
EP-001 — Continuous excitation
The first experimental program investigated the coupled system under continuous sinusoidal forcing.
Among its results, EP-001 established the characteristic coupled-mode structure of the simulated plant and provided the continuous-excitation baseline for later experiments.
It also became a much larger investigation into measurement-only adaptive resonance tracking.
Several controller architectures were explored.
That investigation did not end with the positive adaptive-control result I originally expected.
Different approaches failed for different reasons: acquisition latency, reference invariance, observation-window requirements, and ultimately the relationship between the plant's relaxation timescale and the time available for control.
One particularly important software defect was also discovered during this work.
A variable-frequency drive had originally been evaluated as:
V(t) = V0 sin(ω(t)t)
against an absolute simulation clock.
That expression is correct when frequency is constant, but changing ω instantaneously while retaining absolute t introduces an artificial phase discontinuity.
The drive implementation was corrected to maintain an accumulated phase satisfying:
dθ/dt = ω(t)
with:
V(t) = V0 sin(θ).
Experiments affected by the defect were explicitly marked suspect and rerun rather than silently replacing their previous results.
Some controller behavior improved dramatically after the correction, but subsequent experiments still identified genuine architectural and observation-timescale limitations.
Ultimately, the adaptive comparison originally intended by EP-001 could not be executed under its own measurement-only and timing requirements.
The hypothesis was therefore left unresolved, rather than being converted into either a success or failure after the fact.
For me, that became one of the most useful outcomes of the first program.
TesLab had already been designed around the idea that an experiment should be allowed to reject the researcher's expectations.
EP-001 was the first time the project actually had to do it.
A new question emerged
The controller investigation also made me reconsider what was fundamental about the resonant behavior I was observing.
Under EP-001, the coupled modes had been characterized while the system was continuously driven.
That raised a simpler question:
Are those modes genuinely properties of the coupled plant, or are they partly consequences of the way I am exciting and observing it?
That question became EP-002A.
Instead of continuously forcing the primary resonator, I initialized the system with stored electrical energy and then removed the source entirely.
The coupled system was allowed to evolve through its natural free-ring response.
Same plant.
Different excitation protocol.
No resonance-tracking controller.
No continuously imposed drive frequency.
EP-002A — The same modes emerge from the natural response
For the nominal coupled system, analytical theory predicts two normal-mode frequencies:
Lower mode: 91.287 kHz
Upper mode: 111.803 kHz
The frequencies independently recovered from the simulated free-ring response were:
Lower mode: 91.287 kHz
Upper mode: 111.784 kHz
Corresponding relative errors were approximately:
3.34 × 10⁻⁶ for the lower mode
and
1.73 × 10⁻⁴ for the upper mode.
Both are far below the experiment's predefined 3% acceptance tolerance.
This was an important result for the project.
The same coupled-mode structure appeared under two fundamentally different excitation protocols:
continuous forced response in EP-001
and
source-free natural response in EP-002A.
Within the validated lumped model, this supports the interpretation that these modal frequencies belong to the coupled plant itself rather than being artifacts of the original forcing protocol.
Modal population depends on the initial state
EP-002A also investigated something slightly different:
The eigenfrequencies may belong to the plant, but how strongly each mode is populated can depend on how energy is initially introduced.
First, I tested simple scale invariance.
With primary-capacitor initial voltages of 1.0 V and 3.7 V, the measured modal amplitude ratio was:
A+/A− = 0.747348
in both cases.
The relative difference was approximately:
2.2 × 10⁻¹⁵.
This is consistent with the scale invariance expected from the linear model.
Changing the direction of the initial state—primary-only versus secondary-only precharge—produced a much smaller but measurable difference.
Rather than simply declaring that difference meaningful, I checked it against an independent lossy state-space modal decomposition.
The analytical projection predicted approximately:
0.167% relative difference
while the simulation's finite-duration, Hann-windowed spectral measurement produced:
0.156%.
The two quantities are not mathematically identical observables, so I do not expect bit-identical agreement. But their close quantitative agreement supports the interpretation that the measured state-direction dependence comes from the lossy modal structure of the plant.
The analytical verification is kept as a separate repository-local analysis artifact rather than embedding another eigensolver inside the simulator simply to validate itself.
Following the energy throughout the burst
The free-ring experiment also provides a useful energy-accounting problem because there is no continuous source injecting energy after initialization.
For the nominal Stage-A experiment:
56.0% of the initial stored energy was ultimately delivered to the modeled load.
The remaining energy was accounted for through primary resistance, secondary resistance, and residual electromagnetic energy at termination.
I deliberately do not compare that 56% directly with the continuous-drive efficiency value obtained in EP-001.
They use different energy denominators and describe different physical situations, so presenting one as an improvement or regression over the other would be misleading.
More importantly, energy accounting was evaluated throughout the complete free-ring trajectory rather than only at its endpoint.
The maximum normalized closure residual over the entire burst was approximately:
7 × 10⁻⁷.
Within the present model and numerical tolerances, the observed decay therefore requires no additional hidden damping mechanism beyond the losses already represented by the plant.
The observables themselves changed
Moving from continuous forcing to free-ring excitation also demonstrated something conceptually useful.
Some measurements survived the change of protocol.
Others stopped having a meaningful definition.
Continuous drive-to-response phase lag, for example, is no longer an appropriate observable when there is no continuous drive.
Instead, the free-ring experiment naturally introduces quantities such as:
- burst duration,
- initial stored energy,
- modal frequencies,
- modal amplitude ratios,
- energy partition,
- free-decay behavior.
This influenced the next stage of TesLab's architecture.
Rather than deciding in advance what a Tesla-coil visualization should display, I wanted the experimental work to establish which observables were actually meaningful first.
Only then did I build the virtual-twin interface.
From experimental evidence to an interactive virtual twin
TesLab now has an interactive C++/OpenGL/ImGui scientific visualization environment for the coupled-resonator model.
The visualization is deliberately downstream from the physics.
It does not maintain its own copy of the simulation model and does not calculate alternative physics for presentation purposes.
The architecture is approximately:
Validated physical model
↓
Experimental execution
↓
TeslaCoilSnapshot
↓
Interactive virtual twin
The TeslaCoilSnapshot contract exposes the authoritative instantaneous simulation state to observational consumers.
The same interface is used for both continuous-drive and switched free-ring regimes.
This allows the virtual twin to visualize the electrical state, energetic quantities, operating regime and numerical status without giving the visualization direct access to simulator internals.
Running the experiments interactively
The virtual twin is now a real-time application rather than a prerecorded visualization.
Experiments can be:
Run
Paused
Stopped
Reset
and viewed at different presentation speeds.
Changing the presentation speed does not change the validated numerical timestep. The simulator simply executes the appropriate number of fixed physics steps between rendered frames.
This is particularly useful for the free-ring experiment because physically interesting energy exchange and decay occur on timescales that are too fast to inspect comfortably at literal real-time presentation speed.
The interface also supports screenshots and video recording directly from the application.
Continuous excitation
This sequence shows the coupled system under continuous sinusoidal excitation.
The electrical traces, energy accounting and 3D representation all originate from the evolving numerical state.
Switched free-ring response
This sequence shows the source-free natural response used by EP-002A.
The visible beating and decay are not scripted animation.
They emerge from the same coupled differential equations used by the experiment from which the modal frequencies and energy measurements were obtained.
The animated particles between the primary and secondary are intentionally schematic: they represent inductive energy exchange visually, not literal charges travelling between the electrically isolated conductors.
Separating live state from scientific evidence
I also added an Evidence Mode.
This distinction is important to me.
The live virtual twin consumes instantaneous simulation snapshots.
Experimental conclusions do not.
Recovered spectral peaks, modal amplitude ratios, hypothesis dispositions and other accumulated results are produced by experiment-level analysis and stored as evidence.
I therefore keep those two paths structurally separate:
live simulation state ≠ post-processed experimental evidence
The visualization can display both, but it should not blur the distinction between them.
A principle that emerged from this work is:
The visualization observes the experiment; it does not define the physics or manufacture the evidence.
The research record matters as much as the final screenshot
TesLab's research workflow currently follows approximately:
Research question → predefined protocol → validation → execution → amendments/corrections → evidence → closure
One of the things I wanted to test when starting this project was whether that degree of scientific governance would actually remain useful once experiments became complicated.
EP-001 and EP-002A provided a fairly strong test.
There were successful hypotheses.
There were negative results.
There was a real simulation bug.
There were experiments invalidated by that bug and rerun.
There was an interpretation of modal weighting that initially used an unjustified threshold and was subsequently replaced by a proper analytical calculation.
There were controller architectures that looked promising and were eventually rejected.
Those events remain visible in the research record.
I do not want TesLab's history to contain only the final result after everything messy has been removed.
The corrections are part of the evidence for why I trust the conclusions that survived them.
Where TesLab stands now
The first continuous-excitation investigation, EP-001, is closed.
The first switched/free-ring investigation, EP-002A, is also closed.
The coupled-resonator numerical foundation has dedicated validation for its major numerical and physical invariants.
The simulation now exposes a stable snapshot/output contract.
And the interactive virtual twin can execute and visualize both experimental regimes through the same observational architecture.
But I do not consider the Tesla-coil program finished.
The present system is still deliberately simplified.
Possible future investigations include more realistic switching behavior, finite gap resistance, recharge/breakdown/quench dynamics, nonlinear effects, higher-fidelity electromagnetic models, or entirely different Tesla-inspired systems.
Which of those deserves implementation should depend on the next research question—not simply on which feature would make the visualization look more impressive.
The Open Tesla Challenge and the broader purpose of TesLab
The Open Tesla Challenge provided the initial reason for me to start looking seriously at Tesla's engineering work.
I am very happy that TesLab can also participate in that challenge.
But the competition is not the primary objective of the project.
TesLab is not being developed around a particular software stack or around optimizing a submission for judging.
I want to use it as an independent computational laboratory for exploring Tesla-inspired engineering questions.
If that produces something useful for the challenge, that's a welcome consequence.
If an experiment produces a negative result, I want to keep it.
If a promising Tesla-inspired idea turns out not to survive controlled simulation, I want TesLab to tell me that too.
And if the most interesting next question eventually has little to do with what makes the strongest competition submission, I intend to follow the research question.
Why BrainIAc is still part of the long-term motivation
TesLab originally emerged while I was developing BrainIAc, my computational neuroscience research platform for studying adaptive biological systems.
That origin still matters, but I want to be precise about what it means.
I am not claiming that the resonant behavior currently demonstrated in TesLab has biological relevance.
And TesLab is not intended to prove that Tesla's engineering ideas apply to cells or neural systems.
The separation between TesLab and BrainIAc exists specifically to prevent that conclusion from being assumed.
Instead, I am interested in a much longer research path:
Tesla-inspired engineering concept
↓
TesLab computational reconstruction
↓
physical/numerical validation
↓
falsifiable engineering experiments
↓
identify a robust mechanism, if one actually exists
↓
ask whether an analogous mechanism has a scientifically plausible biological counterpart
↓
formulate a new, independent BrainIAc research question
Most mechanisms investigated in TesLab may never cross that boundary.
That would be a perfectly valid outcome.
What would interest me is finding one that earns the right to cross it.
What TesLab is becoming
At the beginning, TesLab was mostly an idea:
use modern computational methods to investigate Tesla-inspired engineering concepts without assuming in advance that those concepts work, generalize, or have applications elsewhere.
The first research cycle has made that idea much more concrete.
TesLab now combines:
validated numerical models,
explicit experimental protocols,
reproducible execution,
amend-only evidence records,
independent analytical checks,
negative-result preservation,
and an interactive scientific virtual twin connected to the same simulation state that produces the evidence.
The 3D representation is useful because it makes the system easier to explore.
But it is not the end goal.
The goal is the experimental process behind it:
reconstruct the mechanism, validate the model, ask a precise question, run the experiment, preserve what actually happened, and let the evidence determine what deserves to be investigated next.
That is the direction I intend to continue exploring with TesLab.
From desktop application to research platform
Since completing the first research cycle, I've also finished the first web interface for TesLab.
Rather than exposing simulator internals directly, the browser communicates through a versioned HTTP API backed by a stable C ABI and Python ownership layer.
The first web version is intentionally minimal: create a simulation session, execute it, reset it, inspect the current state, and close it.
The purpose of this first slice was not visual richness, but architectural validation. It independently confirmed that the complete chain, from browser to native solver and back, operates correctly through explicit interfaces rather than shared implementation details.
This architecture now allows multiple future interfaces (desktop, browser, analysis tools, automation) to consume the same validated simulation engine without duplicating physics or diverging implementations.
The simulator is now also accessible through a browser-facing API. The first web interface is intentionally minimal and exists to validate the complete browser → API → native solver execution chain before richer visualization is added.
TesLab — Second Research Update: From Experimental Platform to an Experiment Workbench
When I first introduced TesLab, the project revolved around a simple idea:
Can Tesla-inspired engineering concepts be reconstructed as explicit computational models and investigated through modern, reproducible scientific methods?
Since then, TesLab has completed its first experimental programs, established a validated numerical foundation, and gained an interactive virtual twin for exploring those models.
The next stage was less about adding another visualization, and more about changing how experiments themselves are performed.
TesLab has now completed its first Experiment Workbench workflow.
Instead of treating simulations as isolated executions, the platform now supports the complete path from experiment definition to reproducible evidence.
From running simulations to running experiments
The original desktop application was built around executing one simulation and observing its behaviour.
That remains useful, particularly while developing or exploring a model.
But scientific work rarely consists of a single execution.
Instead, it usually follows a sequence such as:
Research question
↓
Experiment definition
↓
Execution
↓
Evidence publication
↓
Review
↓
Replay
The objective of the recent work was to make that complete workflow executable inside TesLab.
Defining an experiment
The first implemented workbench slice deliberately stays small.
Rather than exposing every simulator parameter immediately, it allows selecting one predefined experimental condition from the validated EP-001 protocol.
The browser therefore defines an experiment rather than directly manipulating simulator internals.
This minimal interface intentionally mirrors the existing experimental protocol instead of inventing a second way to describe the same study.
Native execution remains authoritative
Submitting the experiment does not execute any physics inside the browser.
Instead, the browser communicates through the versioned HTTP API to the Python backend, which orchestrates native execution.
The numerical simulation still runs inside the validated C implementation that produced the original experimental results.
The web layer defines the experiment and supervises execution.
The C implementation remains the single authority responsible for the experiment itself.
Immutable publication
When execution finishes successfully, the result is not simply displayed.
It is published as a new immutable research artifact.
That artifact enters exactly the same evidence system used by every previous experiment.
Nothing special exists for "web experiments."
Browser-triggered experiments and batch-generated experiments become identical research objects once published.
Immediate evidence review
As soon as publication completes, the browser automatically opens the newly created artifact.
The existing artifact browser immediately becomes the review interface for the experiment that was just executed.
This was an important architectural milestone for me.
The web interface does not maintain its own representation of experimental results.
It simply becomes another client of the existing immutable evidence architecture.
Replaying the experiment
The browser can now replay the recorded trajectory directly from the published artifact.
Playback controls, synchronized numerical readouts, and the trajectory plot all operate on recorded experimental data rather than a live simulation.
The replay system deliberately distinguishes recorded measurements from interpolated visualization.
Each recorded sample remains individually identifiable while the connecting line exists only to improve readability.
Exploring different observables
Different physical quantities can be reviewed without rerunning the experiment.
The trajectory viewer allows switching between:
Primary current
Secondary current
Primary capacitor voltage
Secondary capacitor voltage
while replaying exactly the same published experiment.
Changing the visualization never changes the underlying evidence.
Only the observation changes.
Browser execution becomes part of the same research record
One aspect of this work was especially important to me.
A browser-triggered experiment now follows exactly the same lifecycle as experiments executed from native tools:
Experiment definition
↓
Native execution
↓
Immutable publication
↓
Artifact discovery
↓
Evidence review
↓
Trajectory replay
The browser is therefore no longer just a remote control for the simulator.
It has become another entry point into the same reproducible experimental workflow.
Reliability before features
Completing this work also required validating behaviour beyond successful execution.
The workflow was verified against:
repeated deterministic executions
publication of newly created artifacts
automatic artifact discovery
trajectory replay of the newly published evidence
browser recovery after genuine backend failures
preservation of previously selected evidence when execution fails
and verification that replay uses the newly generated artifact rather than coincidentally identical earlier runs.
The objective throughout has remained the same:
The scientific workflow should remain reliable even when execution does not succeed.
Where TesLab is going
This work also clarified the direction of the platform.
Earlier versions naturally resembled a simulation console.
The current architecture is increasingly organized around something broader:
an Experiment Workbench.
The goal is no longer simply to execute simulations through a browser.
The goal is to define experiments, execute them through validated numerical models, preserve their evidence, compare results, and review those experiments later through the same reproducible workflow.
The current implementation is intentionally modest.
It executes one experimental condition at a time.
Future work will gradually extend this toward parameterized studies, multi-run experiments, comparison workflows, and richer evidence exploration, while continuing to use the same immutable publication pipeline already established.
Looking further ahead
TesLab still serves the same long-term purpose that motivated its creation.
It is not intended to prove that Tesla's engineering concepts apply outside electrical engineering.
Instead, it provides a controlled environment in which those ideas can be reconstructed, validated, tested, and challenged through explicit experiments.
Only mechanisms that survive that process should earn the right to motivate new research questions elsewhere.
That remains the philosophy guiding both TesLab itself and its relationship with BrainIAc.
EP-001 Experiment Workbench Complete
The previous TesLab update introduced the first complete browser-driven experiment workflow: a single predefined EP-001 condition could be executed through the native solver, published as immutable evidence, automatically discovered, reviewed, and replayed from its recorded trajectory.
The next milestone was to determine whether that architecture could scale from one execution to an entire scientific study without introducing a second execution path or a separate evidence system.
That work is now complete.
TesLab can now execute the complete EP-001 Fixed-Drive Characterization study — 35 predefined experimental conditions — organize the resulting immutable artifacts into a Study, and use those artifacts directly for scientific review and comparison.
From individual experiments to complete Studies
The previous workflow already established:
Predefined experiment
↓
Native execution
↓
Immutable publication
↓
Evidence review
↓
Trajectory replay
The new work extends that same pipeline rather than replacing it:
EP-001 Study
↓
35 predefined conditions
↓
Independent native executions
↓
35 immutable published artifacts
↓
Study organization
↓
Scientific review and comparison
No new scientific authority was introduced for Study execution. Each condition still passes through the same native execution and immutable publication pipeline established in the previous update.
Scientific Studies
For EP-001, a single browser action can now launch the complete fixed-drive characterization protocol consisting of 35 predefined experimental conditions.
Each condition is:
executed independently
published independently
durably recorded
grouped into the Study
individually reviewable
Study execution was designed to remain crash-safe throughout the entire sequence while preserving immutable evidence for every condition that completed successfully.
Scientific review
Execution is only the beginning of the workflow.
The Experiment Workbench now supports reviewing an entire Study scientifically.
Current capabilities include:
execution-status matrix
η result matrix
per-profile summary statistics
comparison between any two experimental conditions
signed parameter differences
synchronized trajectory overlay
trajectory replay through the existing evidence viewer
These review capabilities derive their information entirely from the already-published immutable artifacts. No secondary scientific authority or duplicated result store is introduced.
Two-condition comparison
Any two published conditions from a Study can now be compared directly.
The comparison view presents:
identities of both experimental conditions
signed parameter deltas
synchronized trajectory overlay
all four recorded electrical signals
comparison derived directly from immutable published evidence
This extends the Workbench from experiment execution and evidence review into direct comparative scientific analysis.
Immutable evidence
Every published artifact remains independently inspectable.
From any Study it is possible to navigate directly to:
Study
↓
Artifact
↓
Experimental summary
↓
Recorded trajectory
↓
Replay
Every visualization shown by the browser originates from the exact artifact produced during execution, maintaining complete traceability between experimental execution and scientific review.
Verification
The Workbench was verified at multiple levels throughout development.
Automated verification
Backend: 255 automated tests
Frontend: 288 automated tests
Clean TypeScript compilation
Successful production build
Real-browser verification
Every major workflow was then verified against a running backend using real published artifacts.
Verified end-to-end:
browser-triggered experiment execution
complete 35-condition Study execution
immutable artifact publication
Study organization
scientific review
η matrix
two-condition comparison
synchronized trajectory overlay
trajectory replay
comparison replacement
failure preservation during backend interruption
clean recovery after backend restart
Browser verification was treated as an additional verification stage rather than a demonstration. Several issues were discovered during these real executions, corrected, and then re-verified before the Workbench was considered complete.
Current status
The EP-001 Experiment Workbench is now complete.
The single-experiment lifecycle established in the previous milestone has now been extended to the complete EP-001 Study level:
35-condition Study execution
durable Study organization
study-wide result matrices and summary statistics
direct condition-to-condition comparison
signed parameter-difference analysis
synchronized trajectory comparison
navigation from Study-level results back to the exact immutable evidence artifacts
All of these capabilities operate on the same native execution and immutable publication architecture established previously; the Study layer does not introduce a second scientific authority or duplicated evidence store.
This completes the experimental infrastructure required for the EP-001 Fixed-Drive Characterization study.
The Experiment Workbench is now available as the execution, evidence, and scientific-review foundation for subsequent TesLab research programs.
