pyiron / ironflow

Prototype of a graphical user interface for pyiron (unstable)
https://mybinder.org/v2/gh/pyiron/ironflow/HEAD?labpath=example.ipynb
BSD 3-Clause "New" or "Revised" License
16 stars 2 forks source link

Issues and suggestions #189

Closed JNmpi closed 1 year ago

JNmpi commented 1 year ago

Thanks for the recent developments, @liamhuber. I could successfully install and run ironflow on my local computer. The response time of the GUI is now fantastic. It doesn’t feel like any further performance optimization is needed.

When running ironflow I encountered a few issues. Probably you are already aware of them. Nevertheless, a list of the ones I encountered is appended below:

liamhuber commented 1 year ago

The response time of the GUI is now fantastic. It doesn’t feel like any further performance optimization is needed.

Super! I anticipate for graphs with many ontologically-empowered nodes, making new node connections will be slow, but certainly for the sizes of graph we're playing with now it also feels fast to me.

ironflow crashes without an error message, often related to clicking on show

I run into this ~1/day when I'm working on ironflow, but have yet to find a situation where the error is consistently and reproducible. I think it is related to my cleanup of orphaned ipywidgets widgets, but absent a way to consistently produce the error I've avoided dealing with it. Please let me know if you run into a situation which causes this bug in a reliable way! Otherwise it's on my radar but not the highest priority.

the job output etc. exists only when running the job from scratch. Reloading appears to be not working. Also deleting does not remove the jobs. I had to do this manually by creating a project object in the jupyter notebook.

I wouldn't quite describe this as a "feature not a bug", but it's pretty close... In the near-term I hope to avoid job creation entirely (e.g. with pyiron_lammps), so I have no imminent plan to fix this.

A helpful snippet instead of creating a project is just to select the project node and use gui.selected_node.outputs.values.project.remove_jobs(silently=True, recursive=True).

Extending the AtomisticOutput node to include transpose and get a specific item...

Good idea!

JNmpi commented 1 year ago

Thanks for your prompt reply. Concerning the issue with ironflow crashing. I somehow manage to crash it after a few clicks. I found a reproducible way to crash it. The list of steps below:

The last click crashes ironflow reproducibly. In my example, the jobtable shows only a single job. I hope this helps and you can reproduce the error.

liamhuber commented 1 year ago

Thanks for your prompt reply. Concerning the issue with ironflow crashing. I somehow manage to crash it after a few clicks. I found a reproducible way to crash it. The list of steps below:

  • open the example notebook and open the gun
  • click show on project
  • click on jobtable in the output window
  • click again on jobtable to deactivate table
  • click on show in the project node

The last click crashes ironflow reproducibly. In my example, the jobtable shows only a single job. I hope this helps and you can reproduce the error.

Ok, I think I tracked the source of this down and it's a bit embarrassing. I track and log widgets created and then manually delete them when their parent object gets shut down. This is done in a decorator that basically keeps track of how many widgets were created in the course of a given call and appends them to a list. The problem arose when none were created, and I did a slice some_list_of_widgets[-0:]. Of course, this is perfectly equivalent to some_list_of_widgets[0:], and radically different from when the slice is some non-zero number, e.g. [-1:] vs [1:].