How it works

With Atebion You Can
About Us
Our Services
Pathology Costing
Contact Information

Modelling flowchart

Because of our claim that the software we are presenting is a modelling program, it would be natural to demonstrate how it works using some kind of “typical” software modelling process.  Although every “typical” process in reality is unique, a simplified common scheme might be presented in the way shown in Figure 1 below.



Figure 1. “Typical” modelling flowchart.


Links in “red” represent the first iteration in the model development where the main data structures are identified/designed/implemented and the main relationships between the model data are “coded”.

“Yellow” and “Green” represents subsequent iterations aimed at improving the model consistency and the degree it reflects the original task.

Following the flowchart for this kind of modelling process we can roughly identify three major types of errors which can be introduced in the model during the different stages:

Modeller (Human) misunderstands the initial task. Under certain circumstances it can be hinted at by software.

Breaches of software limitations. Software should highlight all such cases.

Random implementation errors.  In other words “human factor” plus “computer has no imagination”. Here the role of software in eliminating at least some of them is absolutely crucial.

Using the flowchart above we are now going to build a model using our software.

Task definition

We need to manage the overheads on three different sites: HOME, OFFICE and CARAVAN.  The overheads consist of two items: HEATING and ELECTRICITY.

Structuring model data

Before we start to create the data structure for the task above let us briefly introduce the main interface objects and how they are visualized in the main interface window.

The main interface objects are Folders, Variables and Equations.


Folders (e.g. worksheets in spreadsheets) allow you to bring together data (Equations and/or Variables and/or other Folders) that in your model share some common characteristics. 

Each Folder has a unique name that is CASE SENSITIVE. 

Folders are arranged in an alterable tree- like structure, similar to file manager and are purely a navigational aid to locate information more easily. 

There is no representation of cross-links between Folders in different branches in the Tree. You have complete freedom to choose your own criteria in allocating data to Folders. 


Variables are arranged in a sheet structure where every cell represents a variable.

The user creates each Sheet.  All Rows and Columns are given a unique CASE SENSITIVE name within that Sheet.  A unique name means that you cannot have two Rows with the same name or two Columns with the same name but we allow you to have within the same Sheet a Column and a Row with the same name that may also be the name of the Folder. 

Each Variable has the following attributes: Name, Known/Unknown Value, Maximum, Minimum and Comment.

In some programs variables are either inputs to the system or outputs from it.  An Atebion Variable is different.  A variable in Atebion is part of a relationship and at any given time its value may be known (in other words, it is an input) or unknown (it is an output) - but this is not determined at the time we construct the model.

If a value is set to “Known” then Atebion will understand it as a simple equation: Variable_Name  = Variable_Value. If Minimum and/or Maximum attribute(s) are set for some variable then Atebion will understand it as a simple inequality: Variable_Name  > Variable_Minimum ( > grater than or equal to).

Equations (Inequalities)

The Equations operate on variables, which are identified by their Folder Name, Column Name and Row Name.  Each identifier in the Variable name is enclosed in square brackets  [ ] (i.e. [Folder Name][Column Name][Row Name]).

Each Equation is simply written in a text form and consists of variable names linked by arithmetic operators or functions in a conventional manner.

Using syntax you can create a large number of equations, which follow the same pattern.  Equation syntax is just a means to assist you to write equations in shorthand.

Equations can reside in ANY Folder and are arranged as a list.

Note:  syntax is optimized for equations, which can be characterized as “tensor” operations and have a form such as:

Sum of two vectors of equal dimension: X[i] + Y[i] = Z[i] for i =1 to N.

Tensor multiplication: X[i] = SUM( Y[j] * Z[i, j], j = 1 to M) for i =1 to N or X[i] = SUM( Y[j, k] * Z[k, i, j], j = 1 to M, k = 1 to K) for i =1 to N and so on…


Main interface window

The Main View in Atebion is split into 3 separate viewable Segments (see Figure 2).


Figure 2. Main interface window.


The Tree Segment - top right.

Variable Segment  - top left.

Alterable Lower View Segment where you can swap between Equations, Exchange, Graphics and Functions by using the display buttons on the Middle Toolbar. 

Each Segment can be re-sized as required by dragging the blue partition lines or using the Segment Size buttons on the Middle Toolbar, these buttons will take your chosen Segment to full size and back to your dragged size.

The data structure for the task proposed

Going back to the task formulated in section 4.2, the data structure will consist of one folder containing the sheet with three columns and three rows as shown in Figure 3.


Figure 3. Task data structure. 

Building relationships

All the main relationships between the model’s variables can be presented for each site in the form:

Heating + Electricity = Total

In other words they have the same pattern.

Using the equation syntax briefly described above and a few “point-and-clicks” we can create the first iteration of the model in the form as shown in Figure 4.



Figure 4. Main task relationship.


Here there is an immediate advantage to such an approach:

In one short, observable form we actually coded three (or much more in real models) “basic” relationships, as shown in Figure 5 where we used the “Test equation” command.

Note: “Forced” use of the “proper” names for the objects makes it possible to “read” equations almost like plain text.


Figure 5. Testing equation.


Certain syntax “rules” automatically prevent us from trying for example to “add” part of a row with three cells to part of a row with only two cells, as shown in Figure 6.


Figure 6. Syntax Error.


First calculations

Before we start to present how a model can be validated using different approaches let us say a few words about how the math engine works.

A short description of the math engine’s general calculation algorithm

Math engine approaches all task through the following major steps:

First of all it splits every algebraic equation into the so-called “Polished form”.

Secondary it tries to “chop” the initial algebraic system into a number of subsystems, which seems to be possible to solve in a consequent order (in other words it builds a indicator matrix for the algebraic system and tries to present this matrix in the block-triangle form).

Finally it tries to solve every subsystem in the order proposed by the first step.  If a solution is found, it analyses the Jacobi’s matrix for the current subsystem: if that matrix is special then it raises a warning (which will be translated to the user after the calculations are completed) and after this moves on to the subsequent subsystem.  The solution of the just completed subsystem will be used as “inputs” for the following ones (sometimes it may repeat the second step for the remaining part of the algebraic subsystem).


Direct calculation of total overheads

Enter values for the first two rows and set their cells to “Known”.  After pressing the “Calculate” button the model will be calculated and we receive the message “Solution found, number of solutions = 1” (See figure 7).


Figure 7.Dialog after calculation were completed.


After loading the solution the results of the calculation will appear in the sheet as shown in Figure 8.


Figure 8.Results of calculation are loaded in the model.


At this stage there are no significant advantages over conventional spreadsheets besides the fact that repeated typing of different data in the known cells will not accidentally “screw up” formulas because there are no formulas associated with cells.  It is hard to treat this as an advantage because in conventional spreadsheets the same result will be achieved by setting up an appropriate cell protection.

Calculating reversed scenarios

Now we will play a slightly different game: in each column make a different row unknown with the other two set to new known values and calculate (see Figure 9).


Figure 9. Input for reversed scenario.


The results are shown in Figure 10.


Figure10. Results for reversed scenario.


We were able to find the answers for the task that is considered in conventional spreadsheets as completely different and needs to be “recoded” by changing not just values but also adding re-arranged formulas in correspondent cells.  In our model all we did was swapped Known/Unknown attributes in a couple of cells and typed in new values for Known variables. We did not touch any equation.

Validating model

Here we will show how some random errors maybe highlighted by the program.

Validation and diagnostics: excessive number of equations

Playing with the model we switch all cells in the first column to Known, see Figure 11.


Figure11.Execive number of equations.


Because values in the first column will still satisfy the main balance equation, it should not prevent the math engine from finding a solution.  But after calculation, in line with the message that a solution was found, we also receive a tip that some part of the model seems to be “strange“ as shown in Figure 12.


Figure12. Math engine raised a warning.


In the diagnostic view we can see the math engine’s guess on the subset of variables/equations that cause a “disturbance”(see Figure 13).


Figure13. Strange diagnostic: number of equations is more than number of variables.


Here the math engine says that to find a value for [OVERHEADS][Home][Heating] it has more information than is actually needed.  Although a solution was found this time it raises a question about the logical consistency of the model.

Validation and diagnostics: no solution

Suppose we ignored the warning from the previous example.  Now assign a new value to the known variable [OVERHEADS][Home][Heating] (see Figure 14).


Figure14. Combination of known values makes it impossible to find a solution.


Now all values in the first column are still known but do not satisfy the main balance equation:

[OVERHEADS][Home][Heating]                 66

+                                                                  +

[OVERHEADS][Home][Electricity]              35

=                                                                  = (false)

[OVERHEADS][Home][Total]                     91

The attempted calculation will display the message “Solution NOT FOUND, however some values found”.


Figure15. Diagnostic: subset of equations contradicts each other.


Diagnostics will show us (see Figure 15) exactly the same “troubled” variable/equations we saw in the previous example but now the situation is different: the logical inconsistency in the model led to a situation where finding a solution is impossible.

Validation and diagnostics: insufficient number of equations

Imagine we panicked and switched the second and third cells in the first column to Unknown.  In this case, for the first column we still have a main balance equation but now the only additional information is: [OVERHEADS][Home][Heating] = 66 (variable is known). This information is insufficient to determine a definitive combination of values for the pair ([OVERHEADS][Home][Electricity],  [OVERHEADS][Home][Total]):

[OVERHEADS][Home][Heating]                 66               66

+                                                                      +                 +

[OVERHEADS][Home][Electricity]              0                (-66)

=                                                                  = (true)          = (true)

[OVERHEADS][Home][Total]                     66               0


Although a solution will still be found, the system informs us: “solution seems to be unstable or the number of such solutions is infinite” (see Figures 16, 17 and 18).


Figure16. WARNING: solution seems to be unstable.


Figure17. Diagnostic: unstable variables/equations.


Figure18. Unstable solution.

Detecting variables not included in the model

This example illustrates how omissions in the model can be detected.  Suppose we created the main balance equation only for the first two columns (see Figure 19).


Figure19. Equation does not cover all columns of interest.


In this case after calculation the total in the third column will display “N/A” because there is no information to make a guess at the value (see Figure 20).


Figure20. Total for third column is not calculated.


In general we provide the possibility to identify and navigate around cells whose values are not included in any relationship.  Such functionality in a conventional spreadsheet might be obsolete because usually it provides the user with an almost unlimited “canvas” where cells are already introduced, arranged in columns/rows and “emptied”.

Modifying model


 Expanding relationships

Suppose in addition to our “main” balance equation we also have knowledge that the electricity bill represents one half of heating.  To take this into consideration we add a new equation (see Figure 21).


Figure21. New “business rule” has been added.


Simultaneous system of equations

After previous modification of the model the number of “inputs” (Known) needed to calculate the remaining (Unknown) values is less than it was before.  In the example below we have decided that the following three are known:

[OVERHEADS][Home][Heating] = 66

[OVERHEADS][Office][Total] = 45

[OVERHEADS][Caravan][Electricity] = 45


The results of calculation can be seen in Figure 22.


Figure22. “Simultaneous equations”.


Note that the equations were not changed or re-arranged in any way as we decided what “inputs” were available.  We did not “code” the proposed algorithm for the task to be solved, we just typed in the “inputs“ and pressed a “button” to receive the answers we needed.

In working models it would be advisable to replace the 0.5 with a meaningful named variable from a separate sheet to allow easier editing and to make the model more transparent.

Back to Our Services