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

Managing pyiron jobs #191

Closed liamhuber closed 1 year ago

liamhuber commented 1 year ago

This aim's to address one of Joerg's concerns in #189:

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.

This issue runs headfirst into the tension between ironflow's objective of being functional and the fact that pyiron jobs are really, really not functional. Specifically, the problem here lies in comparing the name+input of an ironflow node to serialized input of an existing pyiron job of the same name. This might be straightforward if we could hash the input data as proposed by Sam, but right now we still can't.

So the current setup was intended to rigidly ensure that from within ironflow the user could not not tamper with any pyiron jobs that they had not themselves created. For example, deleting jobs (with the job node's remove button) would only work if it was deleting a job that node had already created that session. Imagine this restriction were not in place and that we had two calc nodes using the same job node; we could run the first, then go over to the second and remove the first's job, silently corrupting its data!

In the long run I think there are good solutions to this, ranging from a more rigorous interface that exploits IO hash comparisons right over to a better alignment of the underlying pyiron model with ironflow in terms of how data storage is treated (i.e. some of the directions we're currently heading with "pyiron 1.0").

Right now though, the criticism is well taken that job management is a huge pain. As a sort of compromise, here I extend the Project node to give an interface for job deletion. This is "restricted" behind an enable_remove boolean input, so users can't just accidentally or hastily hit the remove button and start killing things -- IMO this is analogous to the previous restriction that the user had to type something like gui.selected_node.outputs.values.project.remove_jobs(), but now it's a little more convenient and exists inside the gui framework.

The node now looks like this:

Screen Shot 2023-04-14 at 14 14 25

And if you open the control panel these are the defaults:

Screen Shot 2023-04-14 at 14 14 32
github-actions[bot] commented 1 year ago

Binder :point_left: Launch a binder notebook on branch _pyiron/ironflow/managing_pyironjobs

review-notebook-app[bot] commented 1 year ago

Check out this pull request on  ReviewNB

See visual diffs & provide feedback on Jupyter Notebooks.


Powered by ReviewNB