Wall Clock
In the real world, everyone agrees on the progression of the same, infinitely accurate (at least in classical physics), Wall Clock.
Execution Clock
Executing a BRAHMS system (that is, integrating a dynamical system) means progressing its state along the timeline of the Execution Clock. In general, the Execution Clock may move much faster or slower than the Wall Clock.
Execution Stop Time
An execution will generally be given, a priori, a point in time of the Execution Clock at which to stop. This parameter can be specified as an integral fraction, or as a floating point value, since inaccuracy here is instantly apparent, but it is converted before use into an integral point on the Base Clock timeline.
Base Clock
Knitting processes together into a system requires that they agree on the time. In the world of finite precision, any clock is a trade-off between accuracy and range. In BRAHMS, we choose to ensure perfect accuracy, at the cost of limited clock range (we shall see that the range limit is unlikely to be limiting). The Base Clock, which implements the Execution Clock, is therefore an integral counter.
Base Sample Rate
The Base Sample Rate (BSR) is the sample rate (Hertz) of the Base Clock.
Base Sample Period
The Base Sample Period is the sample period (seconds) of the Base Clock.
Base Samples
Counts of the base clock.

Each Process and Data (Process output) specifies a sample rate, stored as a fraction for absolute accuracy. For Processes, these sample rates are specified in the SystemML document; for Datas, these rates are specified by the creating process (and will often match the Process sample rate, though this is not required). Given the integral Base Clock, BRAHMS can generate timing relationships between components with perfect accuracy. To understand these clocks better, review the GUI documentation.

Integral Base Clock

The use of an integral (rather than floating-point) Base Clock has pros and cons: it ensures accuracy and reduces the computational complexity of timing logic; on the other hand, range is limited by the width of the counters used (64-bit, in BRAHMS). However, to give an idea, if the BSR is 1GHz, the latest time on the Execution Clock that the Base Clock can represent is more than half a millenium after t=0. This is unlikely to be a limitation under most practical conditions. If this limit is reached, the framework will throw E_UNREPRESENTABLE.

A pathological system may have two processes with sample rates that are interrelated such that their lowest common multiple is extremely large, and in this case the amount of time that can be represented may be practically limited. For instance, if two processes have sample rates of 1GHz and 1GHz plus 1Hz, the BSR will be around 1EHz (ExaHertz, or 1018Hz), and the latest representable time becomes about eighteen and a half seconds. Such a system would still have to compute around 1.8x1010 steps to reach this limit. But if such a limit is reached in a practical situation, the only solution to execute the system in BRAHMS is to tweak the sample rates to avoid the pathological condition - this would not be expected to introduce much inaccuracy, with numbers of this order. Alternatively, the system can be computed in a series of shorter periods.

Calculating the Base Sample Rate

After all temporal components (Processes and Datas, but not Utilities) have been created, the BSR fb is calculated as the lowest common multiple of all component rates. In the simplest case of a system of one component with sample rate f, fb = f. For a system with two components with sample rates 2xf and 3xf, fb = 6xf, and so on.

Why should I care?

The BSR will not be of direct interest to the Process developer. However, if a Process needs to obtain the Execution Clock time whilst servicing an event (rather than just the period between services), the timing data time->now (in Base Samples) can be converted to seconds using the snippet provided at Temporal Parameters.

Relationship with the Wall Clock

The Execution Clock is not explicitly related to the Wall Clock by the framework. Components that interact with hardware may force a relationship of this sort, however. Neither is data on the Wall Clock propagated to the Component, but any Component can obtain this information from the OS (which obtains it from the hardware). Therefore, even an apparently pure software component can force a relationship with the Wall Clock if desired, by interacting with the hardware (motherboard) through the OS. If there is demand, a Wall Clock utility object could be generated fairly easily, simplifying this interaction.


One place that the Wall Clock does come into play is in performance assessment. BRAHMS times executions using OS utilities. Usually, individual calls during run-phase are not timed, since this will often slow execution (however this can be requested; see TimeRunPhase). To review performance, see brahms_perf or brahms_gperf.