First steps to make protocols scheduler agnostic #1011
Conversation
t-reents
force-pushed
the
fix/slurm_independent_protocols
branch
from
844efbb
to
142b74c
Compare
It would be great to also add this to the documentation in addition to the docstrings. I noticed that the
Deprecation warnings are ignored by default in Python (https://docs.python.org/3/library/exceptions.html#DeprecationWarning). A user has to enable them manually to see them. I think a |
The current protocols implicitly rely on the `Slurm` scheduler by specifying the number of machines in `metadata.options.resources`. This can cause problems when using different schedulers in combination with `get_builder_from_protocol`. Here, we add this information to the documentation and add a warning that the options need to be explicitly specified in future versions.
t-reents
force-pushed
the
fix/slurm_independent_protocols
branch
from
142b74c
to
e5f1148
Compare
|
Hi @sphuber ! Sorry for picking this up just now. I added a general description of the Moreover, I realized that the issue of the protocols depending on SLURM also applies to the other workflows, not just the |
In addition to the previous changes to the `pw` `WorkChain`s, this commit adds a warning to all the other `WorkChain`s that provide the `get_builder_from_protcol` method.
This commit adds some general remarks about the `get_builder_from_protocol` methods in the `How to - Workflows` section.
t-reents
force-pushed
the
fix/slurm_independent_protocols
branch
from
538bc59
to
300e4cc
Compare
Addresses #1010
The current protocols implicitly rely on the
Slurmscheduler, thus causing errors when users try to use ad different one, e.g. SGE as described in the issue.Here, the documentation of the
get_builder_from_protocolmethod is extended to make the users aware of this behavior. Moreover, a warning is added in case no explicitresourcesare provided via theoptionsargument, as this will cause errors in future versions.@sphuber @mbercx Suggestions for a different phrasing or place where to put the additional documentation are very welcome. Moreover, I used a
UserWarningbecause aDeprecationWarningsomehow didn't appear. I'm not sure whether they are filtered at some point?