External users can contribute to the framework in multiple ways including bug reporting and new tool implementation. As KTH_Toolbox} and KTH_Examples are public repositories, it can be easily done using GitHub pull requests. There are a few requirements each tool has to fulfil to be added to the repository. Each tool has to be written in Fortran77, has to be consistent with the framework modular structure and in an optimal way reuse existing modules to avoid code duplication. The bigger tools that perform multiple operations should be split into smaller ones, if standalone utilities could be extracted. It is important that the developers are familiar with frame module, as all the registering, timing and logging operations should be performed with interfaces provided by this module and its sub-modules.

Building the new module starts with defining the tasks, splitting the code into possible sub-modules and placing them in KTH_Toolbox directory tree structure. After the new directories are created, the toolbox_path.sh script located in the top toolbox directory should be updated and the new modules' paths should be added. For each of the tools, dependency with other modules has to be clearly defined by identification of the provided and required interfaces. There are at least three interfaces that have to be present for each module: subroutines providing module registration (###_register) and initialisation (###_init), and a function returning the initialisation status (###_is_initialised). A subroutine preforming module finalisation (###_end) is optional. A common practise is to also define a ###_main subroutine that could be called in userchk and would perform all the tool's operations. We follow here a naming convention, where all module's routine and global variable names start with a module acronym marked in this section as ###. This acronym is used as well by the framework logging system and allows to distinguish different modules' messages. It is worth mentioning that there are exceptions and not all the modules contain registration and initialisation subroutines. Good examples are the Comunication routines. and Math modules containing a set of useful routines, but not performing any specific tasks. These modules do not provide any run-time parameters or timers, so there is no need to add them to Frame module databases.

A registration means adding to the framework databases a module itself together with all the required timers, the run-time parameters and a run-time parameter section, and receiving a unique identification number for each of the registered objects. Both modules and timers are registered in a tree-like structure and have to provide their parent id. It simplifies writing a summary to the log file and allows to exhibit dependencies between modules. That is why registration starts with finding the parent id for both the module and the timer. In the case of the run-time parameters, a default value has to be provided during the registration step.

On the other hand, the module initialisation starts with an update of the run-time parameter values followed by the tool-specific actions. The last step is marking the initialisation to be completed by setting a module initialisation flag. The registration process requires a number of global variables to be defined, as each of the identification numbers has to be stored. Unfortunately, Fortran77 does not provide variable encapsulation, so all these variables have to be defined in common blocks. To make them available to other modules, the common blocks have to be declared in a separate Fortran77 include-file.

The module's code has to be self-contained, so that together with the used sub-modules it provides all the required operations including e.g., writing and reading tool-specific restart files. If the source code is present in the module, a template of compilation rules makefile_usr.inc has to be added. It has to use paths defined in toolbox_path.sh. When the user interface or the run-time parameter is defined, the corresponding templates of example.usr or example.par have to be present as well. Next, the general module documentation in FRAMEWORK.txt has to be generated. It should contain adequate sections mentioned in Toolbox page and clearly state module dependencies. The last step is the generation of a small example and adding it to KTH_Examples repository. Existing modules and examples provide the best guidelines for building new tools.