## 3 Methodology
### Experimentation
#### 3.2.3 Metric Calculation  
Each metric was individually programmed in Python3. The metric algorithms utilise information extracted from the generated process model and respective event log. In ProFIT, the process models are rendered using graphviz. A netgraph with text-based information is parsed from ProFIT to the graphviz renderer in order to visualise the process model. We used the net graph data as model interpretation for our algorithms. The source event log remained the same for both the miner and the metric algorithms. Each metric algorithm is split into phases which perform specific calculations and produce a numeric measure at the end. 1. _Calculation of Fitness_: Fitness is calculated according to Formula (1). The full flow of fitness calculation can be seen in Figure A1: * **Phase 1**: Input of event log, activity rate and path rate; * **Phase 2**: The event log is mined and the process model is generated. (The miner function performs filtering and cleaning of the netgraph for metric calculation); * **Phase 3**: Generation of a one-dimensional dictionary containing the source and destination of all activities in the model; * **Phase 4**: Generation of individual traces for each caseID and verification of replay via the process model. E.g., a trace is chosen from the event log and is traversed per caseID throughout the generated process model. If the trace is completely retractable from start to end, then the respective caseID is deemed fit (1), else it is deemed not fit (0); * **Phase 5**: Once all the caseIDs have been checked for replayability, the final formula of fitness is applied where the total number of traces that can be aligned with the model and log is contrasted against the total number of unique caseIDs in the log; * **Phase 6**: Generation of the percentage of fitness and output of final fitness. For every iteration in path rate and activity rate, the algorithm is executed from phases 1 to 6. In each cycle, all caseIDs are verified for their respective fitness. 2. _Calculation of Precision_: The precision of a model is by far the most complicated metric to be calculated, as there is a lot of ambiguity to deal with. The full flow of precision calculation can be seen in Figure A2. It is generated as follows: * **Phase 1**: Input of event log, activity rate and path rate; * **Phase 2**: The event log is mined and the process model is generated. (The miner function performs filtering and cleaning of the netgraph for metric calculation); * **Phase 3**: Generation of a one-dimensional dictionary containing the source and destination of all activities in the model; * **Phase 4**: Conversion of the one-dimensional matrix into a path matrix which uses _0s_ and _1s_ to indicate the existence of _\"Path\"_ and _\"No Path\"_ between all activities in the model. The matrix is used to generate all possible combinations from the model to verify existing and imaginary paths in the process model; * **Phase 5**: Generation of all possible combinations of traces in the **process model**. A permutation algorithm generates them in sets of two activities (AB, BC, AC, AA, BB, CC, etc.). Duplicates and redundancies are filtered before proceeding to phase 6;  
Figure 5: The variation patterns of process control features (R1 and R2). * **Phase 6**: The trace creator, generates all possible combinations of traces from the **event log** in pairs of two (AB, BC, AC, AA, BB, CC, etc.). Duplicates and redundancies are filtered. The generated results are used to check combinations that occur only in the process model and not in the log. This value is evaluated against the total number of traces in the event log. The raw precision value of the model is generated using Formula (2). As in Fitness, for every iteration of path rate and activity rate, the algorithm is executed from phase 1 to 6. The precision is likewise calculated at every iteration;
* **Phase 7**: Generation of the percentage of precision and output of final model precision.