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

Improve plumpy integration in aiida-core #6754

Open
agoscinski opened this issue Feb 11, 2025 · 4 comments
Open

Improve plumpy integration in aiida-core #6754

agoscinski opened this issue Feb 11, 2025 · 4 comments
Labels
design-issue A software design issue

Comments

@agoscinski
Copy link
Contributor

agoscinski commented Feb 11, 2025

This is a collection of issues regarding plumpy that are not well fleshed out but I think they should at least be mentioned somewhere to keep track of it. I will edit this issue to be more precise in language once working on them.

plumpy WorkChain not correctly used in aiida-core

There is plumpy.workchains.WorkChain but is not really used in the aiida.engine.WorkChain. It is used as typehint in the Stepper classes, therefore the plumpy WorkChain should be an Interface or Protocol that aiida WorkChain should implement.

Issues with nest-asyncio

By switching from nest-asyncio to greenlet (see unkcpz/plumpy#39) we can solve test_disconnect timeout problem (see aiida-core tests/manage/test_manager.py::test_disconnect) and the python recursion limit issue, and most importantly it allows us to use calcfunctions in an unblocking manner.

Improved save and load interface

Refactor of save and load to make it work better pickled data unkcpz/plumpy#33 we can thus support some of the functionalities of workgraph regarding pickling more natively in aiida-core.

plumpy WorkChain not correctly used

Why do we have plumpy.workchains.WorkChain if it is not really used in the aiida.engine.WorkChain. It is used as typehint in the Stepper classes, so it seems to me that plumpy WorkChain should be an Interface or Protocol that aiida WorkChain should implement.

@agoscinski agoscinski added the design-issue A software design issue label Feb 11, 2025
@unkcpz
Copy link
Member

unkcpz commented Feb 11, 2025

Refactor of save and load to make it work better pickled data unkcpz/plumpy#33 we can thus support

I guess there were historical security consideration that yaml is used for se/de things storing in checkpoint (pinning @giovannipizzi @sphuber for confirmation). After move to pyyaml 5.4 we use UnsafeLoader anyway to support all kinds of user data, for the security point of view it is similarly not very secure. But since the checkpoint is cleaned up when the node is sealed it is "fine". It was mentioned in #3709 (comment) that we should strip the checkpoint when import data from archive. But I believe it is not yet implemented in the aiida-core?

There are some differences between storing the checkpoint items into yaml and into pickle, when I tried to move from storing checkpoint from yaml to pickle.

  1. The pickle also stores some environment information, so the full benchmark is required to see how much size increase when using pickle.
  2. The yaml format store the pointer to where the function can be called and passing the parameters to call after recreate the class and function later. It means the change of code of workchains/calcjobs are taking effect after restart the daemon. While if the objects are pickled, restart daemon will not help. Actually this is quite good since once the workchain is launched, it is natural to expect the behavior is unchanged (this part I am not so sure, correct me if I am wrong).

After all, store the object like process itself and run_fn into pickle make it possible to run process without adding it to python path, which is one of powerful feature manifest by workgraph. It deserve a native support from aiida-core and use the same mechanism to store checkpoint.

@unkcpz
Copy link
Member

unkcpz commented Feb 11, 2025

By switching from nest-asyncio to greenlet (see unkcpz/plumpy#39)

Also want to mention the idea here is partially inspired by #4876 (comment) to use greenlet to run synchronous code in asynchronous.

-                result = process.execute()
+                result = await_or_new_loop(coro_executor(process.execute))

what we actually need is running the asynchronous code in the synchronous, which is inside execute() call. It can then fully solve the nested event loop problem and bridge two color of functions.

@sphuber
Copy link
Contributor

sphuber commented Feb 12, 2025

. It was mentioned in #3709 (comment) that we should strip the checkpoint when import data from archive. But I believe it is not yet implemented in the aiida-core?

At the very least there is an implicit guarantee because only terminated processes can be exported and when a process terminates, its checkpoint is removed. But this is just a soft guarantee that is easily skipped. But I vaguely remember that there might be an explicit check in the export code to drop the checkpoint attribute when exporting. Should be easy to find.

@unkcpz
Copy link
Member

unkcpz commented Feb 13, 2025

At the very least there is an implicit guarantee because only terminated processes can be exported

That is true, but if someone really want to put malicious code in the data node it is easy to go around.

But I vaguely remember that there might be an explicit check in the export code to drop the checkpoint attribute when exporting.

Right! I thought it was only in export code which surely is implemented but not for import. But actually it is already there in

if data.get('node_type', '').startswith('process.'):
# remove checkpoint from attributes of process nodes

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
design-issue A software design issue
Projects
None yet
Development

No branches or pull requests

3 participants