[FEATURE]: Create a central configuration file

[trevorb1]

Feature Request

We are beginning to end up with a lot of configuration options for all the different "features" of otoole, including validation, parameter and set definition, results, writing defaults, etc. It may be beneficial to harmonise all of these options into a single configuration file.

In addition to this simplifying the amount of arguments the user has to pass into otoole functions, this can provide an avenue for more extensive features to be added. For example:

• Create standard (configurable) plots of input and result data
• Automate the process of convert data -> build model -> solve model -> process results, through an otoole run command. In this process, the user could select a solver (with whatever solver options they like) and apply any OSeMOSYS GitHub hosted file they like (ie. the commonly used preprocessing script) via this central configuration file.
• Remove intermediate files the user does not need to interact with (*.lp, *.glp, *.sol, ect...), either automatically in the otoole run command, or via a separate otoole clean. The user can specify what file types should and should not be removed.
• ...

Is your feature related to a bug?

No response

Suggested Solution

No response

Additional Info

No response

[trevorb1]

On the otoole clean front, a couple thoughts come to mind on how to implement it:

1. A simple otoole clean function that removes all *.lp, *.glp and .*sol files in a folder. However, this may lead to unintended file deletions. Alternatively, the user could be prompted to confirm what files will be removed before the actual deletion occurs.
2. A clean function, along the lines of otoole clean <file1> <file2> …, where the user directly specifies the files (or file types) to be removed.
3. Adding a flag to the otoole results command (maybe something like --clean ) which would delete the *.sol file used in the conversion and a corresponding *.lp or *.glp file that had the same name.

The tricky part with this is that we want to avoid the command just being a simple wrapper for the rm <file1> <file2> … command. However, given that files can be named whatever they like, and that the files which would be good to remove also interact with the solver (*.lp, *.glp, *.sol), generalizing this process, while remaining useful for a user, may require some thought