Modularity

Our ambition is to make the current version of AeoLiS more modular. Specially, we want the architecture of the software to consist of well-defined components (modules) that integrate with each other through well-defined interfaces. This will allow us to add new features more easily and to make the software more robust and easier to extend.

For example, the current version of AeoLiS is organized in a single class, the AeoLiSRunner. This class is responsible for the execution of the model. It is also responsible for the reading of the input files, executing the solvers, and writing of the output files. This makes the code difficult to understand, extend and test, see Fig. 19.

AeoLiS architecture — Fig. 19 UML class diagram of the model.py file.

Suggestions for improvement

We have some ideas about how to improve the modularity of the code. However, we are still working on the details of this architecture. If you have any suggestions, please let us know by opening an issue in our GitHub repository or by proposing improvements to the code via pull requests.

Reduce the amount of repeated code by using abstractions. For example, some of the solvers implement similar algorithms. We could implement an abstract class that implements the common parts of the algorithms and then extend this class to implement the specific algorithms of each solver.
Reduce the number of tasks the `AeoLiSRunner` and AeoLiS classes are responsible for. This could be achieved by moving some of the code inside those classes to independent functions or modules. This will make the code easier to understand and test.
Organize code based on components. For example, Fig. 20 shows a flowchart of a modeling step in the AeoLiSRunner. We could use each colored-box in the flowchart to refactor the source code into separate components, each one with a well-defined interface that connects to the other components.

Step Flowchart — Fig. 20 Flowchart of a modeling step in the AeoLiSRunner.