Split functionality into different files

[alchemyst]

The current workflow is 1. edit the config file 2. run the script. This has issues with for instance automating running the script for different sets of components in an automated fasion.

I recommend the following idea:

1. Have only things which will change very infrequently in the config file. At the moment this is the path to the data.
2. Use program arguments to specify things like the components to be run and split out the parts which plot data and the parts which calculate data. I recommend a system of having a file for each case (components + model). This plays well with Dropbox as it doesn't touch the old files if you're working on a new system.
3. Write separate programs or one program with optional arguments for all the plotting parts. This also enables you to plot stuff quickly after simulation without having to rerun the program.

This gets rid of many conditionals in your simulation program, making it a lot cleaner. Your main.py is a step in the same direction, but I think you will find splitting the plotting code from the calculation code with a data file in between makes a lot of the logic easier.

[alchemyst]

See #26 for how point number 2 above could be implemented.

[Stefan-Endres]

Basically my idea was to have both argline passed either here
bfde812#diff-a15fc2cbdf6b0301e50f73116ee658acR20

or in the main.py directly after the directly after the ImportData() class init (before the inputs are actually used to read the data) which I think would be easier to write, this is messier, but will allow for both running from commandline/IDE scripts and by just editing the config files (so anyone new to the project doesn't have to run from the command line to simulate a non-default system).

I will definitely split the plotting.

[alchemyst]

This may be useful for handling the non-technical users. Also note you can run the program with arguments without using the command line. See how for spyder and for PyCharm

[alchemyst]

Also note, even if you prefer the idea of editing a file to set the simulation parameters, that it will be a good idea to separate out the slow-changing config stuff from the simulation setup stuff. I recommend having one config file for stuff like paths and then having separate files for each simulation case you want to run. A good mental test is to thing whether it will be possible to run two (or more) sets of simulations at the same time with the system you consider.

[alchemyst]

Have a look at this project from another student of mine to see how the "case config" system works. This way we can add many different cases which we can re-run one by one or all at once if we want to excercise the code, rather than having to edit the single config file repeatedly to get all the results we need. He is using json files (also built in to the standard library) to store the case configuration. This matches closely with your current dictionary-based format.