Switch to using matplotlib's object-oriented API

[willfurnass]

Using the stateful API (functions and attributes of the matplotlib.pyplot module) correctly gets increasingly tricky as a libraries that depends on matplotlib grows larger.

MuMoT's use of matplotlib would be cleaner if something like the following were adoped:

• For non-multi MuMoTview instances a Figure and Axes pair are instantiated in __init__() using plt.subplots() unless an Axes instance is passed as a param to __init__(), in which case a reference to the associated Figure can be found via the Axes ref. The references to the Figure and Axes are stored as instance attributes (e.g. as self._ax and self._fig).
• Subsequent plotting and changing of aesthetics in other MuMoTview (or non-multi subclass) methods could be done by calling methods of self._ax or self._fig (rather than the stateful plt.plot/plt.gcf()/plt.gca()/plt.clf()/plt.cla() etc).

My knowledge of how the parts of mumot/view.py fit together is still rather shakey. What issues can others foresee with the above? Would a positive side-effect be that self._figureNum would be redundant? How would the above work with MuMoTmultiViews?

[joefresna]

It seems a good solution to me.
The stochastic views (SSA and multiagent) also give the possibility to change graphical representation via GUI, but I believe the view can update the plot by just referring to axes as you propose.

e.g. see function in

MuMoT/mumot/views.py

Line 3498 in 5ef6f7a

def _updateSimultationFigure(self, allResults, fullPlot: bool = True, currentEvo: Optional[Dict] = None) -> None:

that calls the function self._initFigure() for each graphical visualisation change.

For multiControllers the process 'should' work the same... I think in this case the multiView, when constructs the child-views, should assign them the correct pointer to its _ax and _fig