nansencenter / DAPPER

Data Assimilation with Python: a Package for Experimental Research

Home Page:https://nansencenter.github.io/DAPPER

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Keyboard input for Liveplot

yumengch opened this issue · comments

I notice that several issues in the Github are related to liveplotting.

I avoided the liveplotting module since beginning and I think I should take this chance to check it.

I made some tests under Windows Subsystem for Linux (WSL), which is a Ubuntu system.

  • I tested with the new param_estim.py with liveplotting. The function read1 blocks the update (the program pauses its running) until I provide keyboard input for figure update at each time step.
  • test_plotting does not require keyboard input in the runtime because it sets user_interaction to False and read1 always returns None.

This running result leads me to some design questions:
Is the blocking of program run by read1 done by intention?
If so:

  • Is the pause functionality still necessary? As the liveplotting does not continue unless an arbitrary keyboard input, except Enter, Space and i, is given.
  • It might not be necessary to print information about keyboard input if user_interaction is False.

If it is a bug:

  • I guess there is a problem with the non-blocking read in certain environment and I will check it in Windows environment as well.

Yes, liveplotting could use some brushing up. But it's also something that is hard to ever say is "finished". What you have pointed out is definitely a bug though (on WSL) .

  • The aim of read1 is to not block or echo
    I guess this isn't working on WSL. That is a bug. I have never had the chance to test it on WSL.
    I would prefer to have the issue fixed.
    But as you can tell from read1s implementation, this was not trivial, (though it was quite easy on Windows).
    If it cannot be fixed, then the pause option should be removed (and the plotting should play continuously) on WSL (and there should be a print-out stating that the plots cannot be paused/skipped on this platform).

It might not be necessary to print information about keyboard input if user_interaction is False.

Indeed, the printouts should be replaced by a statement saying that user_interaction has been set to False.

Here is a script I used to develop/test read1

I tested with real Ubuntu and it indeed is due to incomplete implementation of the WSL microsoft/WSL#3507. It turns out WSL is handy but not a full-blown Linux system.

I will see if I can find a workaround for this. Otherwise we should close this issue for the time being.

Great stuff!

If you cannot find a solution, it'd be great if we can detect WSL (the terminal provided by it, I guess) and print a warning message saying that pausing/skipping ain't possible

Closed by #62