Default settings should be managed by the SimulationModule

[jgroehl]

Define abstract method in SimulatioModule class

[jgroehl]

lets use this for the main documentation which parameters the adapter needs

[TomTomRixRix]

• Set default component settings in adapters and global settings in PipelineModule by defining an abstract method get_default_settings() and overriding this in the individual adapters.
• Document which Tags are used by each adapter and what the sensible defaults are
• adjust the examples so that they don't need to specify all settings anymore
• test if specified settings override the default settings
• adjust available test if necessary

[TomTomRixRix]

In PR #358 I've now implemented a way to set default component settings for the adapters and default global settings. I think before proceeding further with the documentation, examples and tests it would make sense to have a meeting where we go through this list and check if all default values are sensible and if no default parameter was forgotten.

Furthermore three questions came up:

1. Should processing components also have default settings?
2. Would it make sense to treat all settings as a read-only configuration? Then we would have to find a new solution for the wavelength and simpa_output_path in the simulate method which are currently stored in the global settings during simulation. Passing them as an additional argument to the run method of the pipeline elements would be one option.
3. Would it make sense to have a list of required (component) settings for each adapter which can be checked in the beginning of each adapter and a warning or error can be logged if something is missing. Then the user would have a better overview which of these required settings are already set by default and which they have to set manually. This should of course also be included into the documentation of each adapter.

[jgroehl]

This does not seem to have been finished as of yet.
Are there plans to wrap up the work on this at some point?

[TomTomRixRix]

I think it still makes sense to implement these changes. But we would need to find answers to these three questions and decide which values would be sensible defaults. While we could do this in a GitHub discussion, it's probably more efficient having a meeting/call to discuss this.