Modules of an interactive simulation framework can provide their own specific GUI, allowing end users to conveniently interact with the module. More explicitly, providing a GUI is optional meaning that a module must not be forced to provide a frontend2 . This would allow, for instance, module developers to test module backends before devoting efforts into the development of a frontend. Overall, these specialized GUIs must be presented to the end user in a consistent manner, meaning that the module-specific frontend is embedded into the main framework’s GUI upon the end user’s behest.
The framework must also support the utilization of several modules and the monitoring of the modules’ readiness state. In this context readiness relates to the availability of the potentially required input data of a module. More concretely, only modules which have their input dependencies satisfied can be made active, meaning that the end user is allowed to interact with the corresponding module. The framework is required to automatically evaluate the readiness state of each module and activate/deactivate them accordingly. In turn, each module must be given the ability to investigate whether the available data provided by other modules is suitable to satisfy its specific requirements and, based on this evaluation reports, its state of readiness to the framework.
Also, simulation tools usually generate output messages during the execution, such as the convergence information during a solver process. The framework must provide a centralized message output element to provide the end user with a centralized spot of output messages, further increasing usability. In addition, the ability to reroute output streams, such as C++’s std::cout, to such an output window is required. Such a mechanism allows to non-intrusively transfer output data from a simulation module to the framework’s centralized message element.