Recursive methods documentation

[louispt1]

I've put together a minimal first draft of documentation for the recursive methods. For now I've tried to keep it as lean as possible, so I am expecting to expand this.

Further ideas I had were:

• General
  • Explain what a calculated graph is (do we have an explanation in the docs of how the final graph is calculated via refinery, present, hourly, future?)
• Modules
  • Include gquery examples
  • Describe submethods/ goals in more detail?

Closes #227

[mabijkerk]

I have made some first changes to the docs. I will continue with the review, but already have some thoughts:

• I have added stop conditions and type (with or without losses) per method. I think it would be good if you check and complete these @louispt1.
• I'm not too sure about explaining a calculated graph. What I am interested in however is explaining where these methods are used: in queries and initialisation. Can we give a general explanation about this or, even better, should we add it to each method?
• Lastly, I'm still struggling a bit to understand when we need recursion without losses, but I still hope to figure that out myself.

[mabijkerk]

Finally, I like the simplicity of the structure you chose to represent the examples, but it does not really match other graph examples that we have. For example in the "Always-on battery parks":

I would like to see if we can add a similar example for each method and then a clear query that shows the method result for the sample graph. For example:

V(energy_torrefaction_wood,sustainability_share) = 0.947

[louispt1]

A couple of things I'm unsure about:

• I think real examples displayed neatly like for the always-on battery park can be useful, but each module has multiple methods, and making all of these examples would take quite a bit of time. Moreover, when they become outdated they will take a lot longer to 'maintain' because you have to completely remake a new image unless we have a software which saves these drafts?
• I think adding where every method is used could also lead to some maintenance issues, unless we are sure those queries will be reliably used on those locations. For some things like the dashboard items it could make sense, but maybe a more general description of use for each 'module' rather than each method would work better?

What do you think @mabijkerk? and if you'd still like the graph representations, what tool did you use to make yours?