Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Managing pyiron jobs #191

Merged
merged 12 commits into from
Apr 26, 2023
Merged

Managing pyiron jobs #191

merged 12 commits into from
Apr 26, 2023

Conversation

liamhuber
Copy link
Member

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

@liamhuber liamhuber requested a review from JNmpi April 14, 2023 21:32
@github-actions
Copy link

Binder 👈 Launch a binder notebook on branch pyiron/ironflow/managing_pyiron_jobs

Save a version of the workflow that is un-run, and remove the commentary about units
@review-notebook-app
Copy link

Check out this pull request on  ReviewNB

See visual diffs & provide feedback on Jupyter Notebooks.


Powered by ReviewNB

@liamhuber liamhuber added the format_black Invoke black formatting CI label Apr 26, 2023
@liamhuber liamhuber merged commit c360fbf into main Apr 26, 2023
@liamhuber liamhuber deleted the managing_pyiron_jobs branch April 26, 2023 19:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
format_black Invoke black formatting CI
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants