A few observations on dimensional analysis, environmental physics, and PCT modelling
I have followed this exchange with considerable interest. The discussion of whether the environmental quantity q_i and perception p are “the same variable”, and whether dimensional analysis is useful, raises a practical question: how do we specify a model so that its physical meaning and computational results are unambiguous?
I would like to approach this from the perspective of control engineering and dynamical systems.
1. Dimensional analysis is not a formality
John Graham is right to raise the question of the coefficient k_i and consistency of units. When we relate quantities with different physical dimensions, we need a transformation that accounts for that difference. Equality of numerical values alone does not establish the physical identity of the quantities.
The loss of Mars Climate Orbiter in 1999 is a useful warning against overlooking units. Thruster impulse data were supplied in pound-force seconds (lbf·s), while the navigation software expected newton-seconds (N·s). [1]
This example requires an important qualification: the two units have the same physical dimension but different scales. Dimensional analysis alone would not have detected the error. Unit conventions and conversions also needed to be checked. A model must address both.
In a simple PCT model, we distinguish:
q_i — an environmental quantity, such as position, force, or voltage;
p — an internal perceptual signal, with a specified representation and scale;
p = f(q_i) — the input function relating the two.
For a linear input function, we write p = k_i · q_i, with the coefficient satisfying the dimensional relation [k_i] = [p] / [q_i].
Writing p = q_i can be a valid simplification when the scales or normalisation are appropriately defined. I use this assumption in my own calibration example. It does not, however, eliminate the distinction between the role of the environmental quantity and that of the perceptual signal. An identity input function is a specific modelling assumption that should be made explicit.
The system’s action changes the environment and, through the input function, affects perception. Preserving these relationships in the model makes it clear what reaches the comparator and how action affects the measured quantity.
2. From a spreadsheet to a numerical experiment with explicit checks
A spreadsheet is a valuable tool for exploring a control loop. A correctly implemented method with a fixed time step can also produce reliable research results.
The requirements for computational reliability remain the same, regardless of the tool:
- Numerical error control. An excessively large step can distort the dynamics or introduce artificial instability. We need to check whether reducing the step or tightening the tolerances materially changes the result.
- Explicit handling of discontinuities. Values immediately before and after an event must be distinguished, and discontinuities must be accounted for during integration. This applies to adaptive solvers as well.
- Explicit limits on action. If we are investigating actuator saturation or the accumulation of integral state while the output is saturated (integrator windup), these effects must be represented in the model. Changing the solver does not remove them. [2]
- Reproducibility. Another researcher should receive the equations, parameters, initial conditions, disturbance protocol, and numerical settings needed to check the result.
RK45 helps control local error by adapting the step size, but it does not guarantee that the model is correct or that the method is suitable for every system. [3]
Automating these checks and making the complete experiment available are my reasons for developing a dedicated research environment.
3. A practical example: Livia — PCT Research Laboratory
Over the past few days, I have brought a working prototype with a browser interface into operation:
Livia — PCT Research Laboratory
I am developing it so that researchers can define and test models without writing their own solvers, while keeping assumptions explicit and computations open to inspection.
The current implementation includes:
- A compiler using restricted expression trees and dimensional analysis. It checks the declared dimensions of signals and derivatives. A dimensional inconsistency in an equation or comparator causes the model to be rejected. This checks dimensional consistency; it does not automatically establish physical validity.
- Distinct roles within the loop. The engine distinguishes the environmental quantity
q, perception p, comparator input pc, reference signal r, and error e = r - pc. This makes it possible, for example, to hold the signal available to the comparator constant while continuing to measure the actual modelled perception.
- Matched experimental conditions. Normal operation (
live), held output (output_held), and held comparator input (feedback_held) are each computed both with and without the disturbance. These interventions allow the roles of action and current perceptual feedback in the model’s response to be examined.
- Event handling and accuracy checks. The engine splits integration at scheduled event boundaries, records values on both sides, and compares trajectories with calculations made under tighter solver settings.
- Metrics and export. The researcher receives measures including a disturbance suppression ratio and recovery time, together with a package containing the model, protocol, data, and code for repeating the calculations outside the browser.
In a simple integral-controller calibration example, the functioning loop compensates for the disturbance, while compensation disappears under either ablation. The exported trajectory was checked against the known analytical solution; the maximum difference was approximately 2.76 × 10⁻⁹. This verifies a specific numerical case. It is neither an empirical validation of a psychological mechanism nor a validation of the entire tool.
Livia remains a prototype under active development. Before opening it for testing, I am refining package verification, the criteria for confirming reproduction, and report readability. Access is deliberately restricted while I prepare the Zenodo deposit and documentation.
4. A proposed next step
I believe PCT would benefit from accessible tools that let us translate conceptual differences into explicit differences in equations and then test their consequences.
I would welcome suggestions for models, disturbances, and edge cases on which to test Livia, particularly cases with known solutions or clearly specified predictions. I am equally interested in cases where the tool should report a limitation, an unresolved result, or failure to meet a criterion.
My aim is for a researcher to be able to share a complete experiment alongside the diagram and interpretation: assumptions, equations, disturbances, results, and a way to reproduce them. That is the standard I am working towards with this project.
Luk 
Technical references
- NASA, Mars Climate Orbiter: mission overview and Phase II investigation report.
- MathWorks, Anti-Windup Control Using PID Controller Block.
- SciPy,
solve_ivp documentation.