Netlogo pauses after plotting in Python, need to close plot to continue

Question

My code pauses after plotting in python, and won't continue until I close the plot.

I am using matplotlib for plotting.

to plot-in-python
  (py:run   
      "import matplotlib.pyplot as plt"
      "time = [0, 1, 2, 3]"
      "position = [0, 100, 200, 300]"
    
      "plt.plot(time, position)"
      "plt.xlabel('Time (hr)')"
      "plt.ylabel('Position (km)')"
      "plt.show()" 
  )
end

Answer 1

Q :
_{" My code pauses after plotting in python, and won't continue until I close the plot. "}

A :
The result is a natural product, as the matplotlib enters into a .show()-method, which blocks ( until closed ) and the whole Python Interpreter ecosystem stops until such happens. Without using the plot inside this "interactive"-(Python-blocking) mode and if instead rather storing the final produced graph-scene into a PDF or otherwise formatted file, later inspectable using a non-blocking viewer, the whole ( py:run ... )-scope will terminate as expected, without a "hanging"-Python blocking and the NetLogo-world can continue its evolution-flow further on.

Q :
_{" I was hoping to have the figure remain up and update with each loop of Netlogo (this is because the figures in Netlogo are not great). I understand that .ion() is supposed to create interactive plots (i.e., updatable plots), but for whatever reason it does not work for me... Am I foolish to try and use Python in this way with Netlogo? – belief-desire-intent 2 hours ago "}

A :
Well, I would not consider such a desire to have live-graphs be foolish for a single moment. The key is, how to achieve this to happen.

In late 70-ies, there were wonderful inventions that have sprung out of the "Island of positive deviation" that has evolved inside Palo Alto Research Center (and its spin-offs like PARCplace systems). We owe a lot to these smart people, hired by then to work for this XEROX research facility. Concepts of modular interactive GUI, word-processing software, Smalltalk language, computer mouse and many other inventions took place right there.

The GUI concepts, having many-actors, some of which are machine-driven, some of which are reflecting man-machine interactions, -like your wish to have NetLogo generating live-graphs, that live inside Python-matplotlib exosystem- were indeed hard to program until PARCplace people brought in a methodic concept of principal separation of responsibilities - into an MVC-system :
where
M stands for MODEL: the part, that keeps state-full representation of the Problem-under-Review,
V stands for VISUAL: the part, that generates visual representation of the PuR-state, and
C stands for CONTROLLER: the part, that collects Man-Machine-Interactions and all other "sensors", based on which the PuR-state ( The Model ) gets continuously ( well, in some sort of discrete time-ordered events collecting and reflective-processing manner ) updated.

This had to have been said first, so as to now be able to claim, that your wish is leading to a so called "distributed"-form of the MVC-model, where NetLogo is doing M-odel part, driving the multi-agent evolution of the PuR-state, and commands the "remote"-GUI-V-isual part and has to receive inputs ( if any would be intended to be so ) from the again "remote"-GUI-C-ontroller.

This might sound awful, yet not so ugly, if compared with a mess if we would try to implement the same need in some less consolidated & time-proven fashion.

Given the powers of NetLogo, we can use ( py:run ... )-scope(s) to actually provide all the needed glue-logic for such a "distributed"-GUI-MVC system.

We can
(a) inject NetLogo M-odel updates using (best only one) non-blocking ( py:run ... )-scope,
(b) keep one (or more, if need be) Python Interpreter(s) on our localhost or even on some remote network host(s) as the V-isual handler, showing the graph(s), and
(c) keep one (or more, if need be) Python Interpreter(s) on our localhost or remote network host(s) as the C-ontroller, that feedback(s) another NetLogo non-blocking ( py:run ... )-scope(s), that receive(s) "remote"-inputs (if any needed) to consume them inside the NetLogo M-odel update loops.

No matter how complicated this might sound, it will work, using any of the available localhost located Python Interpreter single-session or multi-Python Interpreter sessions, be them all localhost colocated, or even network-distributed, using distributed-computing tools that we can just plug-in, be it pynng, pyzmq to provide a new breed of smart transport-services to allow otherwise autonomous nodes to setup a "macro-scale" distributed-MVC and communicate smoothly all needed changes, composed as messages.

If going a bit more professional into it, there are also other NetLogo native tools for better and smoother ( less prone to choppy stick-slick-stick-slick control-loop ) ways how to implement "remote"/"distributed" co-integrated GUI-s. Just mentioning a built-in HubNet model, a lightweight Java / Scala-extension to better & smoother serve the M-odel to V-isual (semi-persistent)-links ( without weaknesses of ( py:run ... )-scope(s)' relying on and limitations carrying Python Interpreter (local|remote)-process & IPC management ( control-loop latency + jitter thereof can annoy & matter, if the MVC-loop thus looses more of its "tightness" of loop )

• remote-process updating GUI tip
• co-integrated GUI tip
• remote GUI .mainloop() controller tip
• "tightness" of control loop tip