-
Notifications
You must be signed in to change notification settings - Fork 14
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
♻️ decouple override settings of builder #382
♻️ decouple override settings of builder #382
Conversation
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## master #382 +/- ##
=========================================
Coverage ? 50.69%
=========================================
Files ? 16
Lines ? 1803
Branches ? 0
=========================================
Hits ? 914
Misses ? 889
Partials ? 0
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
faacdc0
to
f49fd4e
Compare
Hi @superstar54 @AndresOrtegaGuerrero, I think this PR is starting shaping. Before go into more deep test, I hope you two can have a look if this make everything much clear. |
aiidalab_qe/workflows.py
Outdated
self.ctx.current_structure = self.inputs.structure | ||
self.ctx.current_number_of_bands = None | ||
self.ctx.scf_parent_folder = None | ||
|
||
# logic based on the properties input |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe add some logic if properties is None, in that scenario is just a single point ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, if the properties list is an empty list, there is nothing actually running.
I try to move the logic outside of the workflow. In this workflow, the sub-workflows are run as independently as possible.
Not sure this is a good strategy, worth to discuss.
Hi @unkcpz Thanks for refactoring the code. One comment on the
|
@superstar54 thanks!
True, I didn't add it yet. Will add it. |
@unkcpz just FYI in case it's useful, when I was refactoring my app in similar vain, I've chosen to use Dataclasses to hold the combined settings of the various input widgets. I've found it really useful to ensure that all the settings are processed. Of course QeApp is quite a bit more complex than my app, but perhaps it might be useful here as well. See for example code in this file. Would be happy to hear what you think. |
7a84df3
to
c39eb86
Compare
c39eb86
to
b997299
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Quite a big PR, so I didn't look into every line of code in much details, but it all looks great! Much cleaner, great work @unkcpz!
I still left some comments/questions, but will already approve.
d15f8d7
to
17a18b4
Compare
Hi @superstar54 @AndresOrtegaGuerrero, this PR is ready from my point of view. Can you have another look at it? Thanks! |
In the last meeting , we discussed about if we should consider backwards compatibility should be consider, because from now on, more changes should be consider ? |
To supplement @AndresOrtegaGuerrero's message: I mainly raised the fact that maintaining backwards compatibility is perhaps an undue burden. I don't think there are that many heavy users yet who would lose any important data with this change. I think our policy until further notice (or until public release, tbd) should be to throw backwards compatibility to the wind so we are not limited in making improvements to the interface, and the code does not become more difficult to maintain. |
No problem, I can remove the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @unkcpz, Thanks for implementing this. I added a few special suggestions to the review.
Here are some general comments:
_update_settings
method is added for each setting, but these methods are not called. Thus, when loading a previous calculation, widget values are not restored in the GUI.- In the test, the app tested as a whole in the submit step (kind of integration test). It's nice if you also add tests for each setting (unit test), e.g. workchain, smearing, especially to override the value and then test it.
pass | ||
return sdir | ||
def generate_upf_data(): | ||
"""Return a `UpfData` instance for the given element a file for which should exist in `tests/fixtures/pseudos`.""" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Where is this folder tests/fixtures/pseudos
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is useless, at least for test here. I copy the fixture from qe plugin and I think it is also not used there. Open a PR at aiidateam/aiida-quantumespresso#933, let's see if it passes all tests.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The fixture is used in aiida-quantumespresso
for sure, but not necessary here, so I update the docstring only.
) | ||
return url, token | ||
with tempfile.TemporaryDirectory() as dirpath: | ||
for values in elements.values(): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is not necessary to generate the whole pseudo family. Selecting a few elements is enough for the test.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since there is no much code for this function and the upf file is actually a fake file of every element, I think it is okay to keep it as it is.
|
||
return execute | ||
@pytest.fixture(scope="session", autouse=True) | ||
def sssp(aiida_profile, generate_upf_data): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is this sssp
fixture used for? In the builder, we only need to pass the name of the pseudo family, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When creating the builder, it calls get_builder_from_protocol
from aiida-quantumespresso and it require to having pseudo family set.
But it is true the fixture is not need to be loaded explicitly here since it is already load from conftest.py
for the session scope.
@pytest.fixture() | ||
def workchain_settings_generator(): | ||
"""Return a function that generates a workchain settings dictionary.""" | ||
from aiidalab_qe.app.steps import WorkChainSettings | ||
|
||
def _workchain_settings_generator(**kwargs): | ||
workchain_settings = WorkChainSettings() | ||
workchain_settings._update_settings(**kwargs) | ||
return workchain_settings | ||
|
||
return _workchain_settings_generator | ||
|
||
|
||
@pytest.fixture() | ||
def smearing_settings_generator(): | ||
"""Return a function that generates a smearing settings dictionary.""" | ||
from aiidalab_qe.app.steps import SmearingSettings | ||
|
||
def _smearing_settings_generator(**kwargs): | ||
smearing_settings = SmearingSettings() | ||
smearing_settings._update_settings(**kwargs) | ||
return smearing_settings | ||
|
||
return _smearing_settings_generator | ||
|
||
|
||
@pytest.fixture() | ||
def kpoints_settings_generator(): | ||
"""Return a function that generates a kpoints settings dictionary.""" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These three fixtures share the same pattern. Is it possible to generate the settings using one fixture?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It can I assume but will make the code even not easy to understand. It can be a settings_generator
with passing workchain
, smearing
or kpoints_settings
with the kargs. Sometimes it is not bad pattern to repeat some code if it makes things clear and easy to implement. I'd argue to keep in this way.
npool: 1 | ||
parameters: | ||
CONTROL: | ||
calculation: scf |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The calculation
should be bands
. Please check this file.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is an issue found with running on aiida-quantumespresso==4.2.0
. After discussing with @superstar54 offline, we think bump the aiida-quantumespresso version to 4.3.0
fix this issue and the change can be included in this PR.
|
||
if ( | ||
self.smearing_settings.override_protocol_smearing.value | ||
and self.workchain_settings.electronic_type.value == "metal" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please remove the condition for metal
here. Otherwise, the user can still set the override in the GUI, but will find it not working in the calculation. You can disable the override in the GUI when the structure is a metal
.
By the way, the smearing should also work for the insulator, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
By the way, the smearing should also work for the insulator, right?
No, if select insulator, the occupations
is set to fixed
, the smearing and degauss are not in the input.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Everything looks fine to me!
Per @superstar54's comment:
I tried with using builder_parameters to recover the widgets, but it is a bit more complicate than I thought. The problem is the key store in the builder_parameters extra attributes are not same for the key used in setting widgets. There are a further step to convert the paramters from setting widget to builder_parameters, to bring it back I think we need a more systematical way to do it and I prefer to do it in a separate PR. If you agree, I’ll merge it. Moreover, when I look at the refactored architecture in #383, setting widgets directly from builder_parameters is not ideal since it bring the entanglment between viewer and controller which is we want to avoid from first place. Instead, we need introduce and use the dataclass for all the settings object and having bilateral converters between setting wdigets and builder_parameters and having this dataclass in the middle. @superstar54 is working on introducing the new "plugin-like"way of adding new properties calculation, and it will be handled in the new design by the get and set methods of the panel. |
5094e97
to
deda4ba
Compare
misc: docstring and authors to AiiDAlab team Test added
Remove are XXX by fixes or create OP mild dependencies
workaround r-andres bump AWB to released 2.0 (#394) `aiidalab-widgets-base` 2.0 is released, the version is bump here. Jinja2 and importlib are from aiida-quantumespresso, therefore the version is loosely pinned. The pybtex has to be added to work around the installation issue. Move module imports from __init__.py of package to app modules (#393) Remove report legacy support pinning qe plugin so test pass
deda4ba
to
9a92cc9
Compare
address #383
XXX
notations.second test for insulator be more specific, and test only some of the parameters.set_parameters
for loading the process to widget._update_settings method is added for each setting, but these methods are not called. Thus, when loading a previous calculation, widget values are not restored in the GUI.will be addressed in Using update_settings to recover setting widgets from process #397 or by new plugin design of @superstar54