Added a Python GUI

[Mohamed-Dhouioui]

This pull request introduces a python GUI replication the Rust one to the nanover-protocol repository:

Changes

Add a New Python GUI:

• Implemented a new user interface using Gradio. Please install the library to use I by running pip install gradio

• Created functions to run and stop simulations with various configurations.

• Added a detailed Jupyter Notebook (examples/basics/using_GUI.ipynb) explaining how to use the new GUI.

Features implemented:

• [x] Running from Xml Files
• [x] Running from recordings
• [x] Specify Server Name
• [x] Specify Server Port
• [x] Specify Frame interval
• [x] check box to include velocities
• [x] check box to include frames
• [x] Record trajectory and shared state (both should be selected or none, for the moment we can't record just one)
• [x] Check box to start simulation paused

Features missing:

• [x] Simulation FPS
• [x] Force Interval
• [x] Record statistics
• [x] Statistics FPS

[Ragzouken]

Perhaps the notebook ought to be renamed to "server ui" or "runner ui" or something more descriptive?

[Ragzouken]

As discussed offline, we can drop these options + ui elements:

• Force Interval
• Record statistics
• Statistics FPS

We don't see a usecase for force interval independent of frame interval, and it complicates the implementation for work done etc. We don't use the statistics from rust, but can reintroduce whatever we may need later when debugging etc.

[Ragzouken]

I've hooked up the simulation fps option

[hjstroud]

FYI, the .traj and .state files I used that didn't work were ones generated via the gui for a previous simulation that I recorded: maybe it could be a problem with the way the GUI writes the files?

[Mohamed-Dhouioui]

These are the most recent edits in this commit ddf1661:

• Added a link to Gradio in the notebook
• Fixed the error for file extensions not being accepted

I couldn't find a solution that would fit the UI on the entire notebook output cell without a major change in the code. So, I am keeping it this way since it can also be opened as a standalone web app. To answer your question about uploading multiple simulation/recording file, this UI is capable of that as far as I have tried but you are welcome to test it.

[hjstroud]

Have just tested this, and I could load multiple recordings at once (trajectories and states) as well as a simulation xml, but I noticed some weird behaviour when I did this:

• When I connected to the server, the first simulation was always a recording, no matter which order I defined the files in: is this expected behaviour?

• When I loaded the files with the "From Recording" box checked, the following was printed to the terminal:

  Simulation started with type: settings: {'simulation_type': 'From recording', 'input_files': {...

  where there is only one "simulation_type" (i.e. from recording) but two distinct types of simulation (one xml and two recordings). Also, when I did this and then tried to load the simulation xml from within NanoVer iMD, there was a force (not defined in the input file) being applied to the system that looked the same as the force applied in the recording: could these somehow be being confused as it thinks it's supposed to be a recording?

• When I repeated the procedure but loaded the simulation with the "From xml" box checked, I got an analogous message:

  Simulation started with type: settings: {'simulation_type': 'From xml', 'input_files': {...

  where again there is only one "simulation_type" (i.e. from xml) but two distinct types of simulation (one xml and two recordings). This time the simulation file behaved as normal (although it was still a recording that seemed to be loaded first (or possibly the xml with a fictitious force, but when I went back onto the xml simulation everything seemed fine.

We've talked about these in person. If this can be fixed (and tested to make sure it works!) then I think I'm happy with how the GUI is.

[Ragzouken]

This issue may be relevant too: https://github.com/IRL2/nanover-protocol/issues/303

[Mohamed-Dhouioui]

With this commit 378c6b8 I have fixed the output message and replaced the printing of simulation type with a list of currently loaded files. However, for the interaction forces that are not cleaned when changing between a recording playback and a simulation, I've tested this outside the GUI with the OmniRunner.wit_basic_server() module and it showed the same behavior. So, I believe this is a bug with OmniRunner not the GUI. I have created an issue for #302 and detailed the steps to recreate it.

[Ragzouken]

Issue with the interactions/avatar etc persisting should be fixed on main. Try merging main in and testing that everything is fine now.