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

Isolated BandsData will raise exception when running verdi data bands list #3811

Closed
unkcpz opened this issue Feb 27, 2020 · 6 comments · Fixed by #3817
Closed

Isolated BandsData will raise exception when running verdi data bands list #3811

unkcpz opened this issue Feb 27, 2020 · 6 comments · Fixed by #3817

Comments

@unkcpz
Copy link
Member

unkcpz commented Feb 27, 2020

bands = load_node(<bands_node>)
bands_clone = bands.clone()
bands_clone.store()

will cause verdi data bands list break.

File "/home/unkcpz/pyProject/aiida_core/aiida/backends/djsite/queries.py", line 178, in get_bands_and_parents_structure
    struc_pks = [structure_dict[pk] for pk in pks]
File "/home/unkcpz/pyProject/aiida_core/aiida/backends/djsite/queries.py", line 178, in <listcomp>
    struc_pks = [structure_dict[pk] for pk in pks]
KeyError: 230

Although I have no idea whether it is reasonable to have BandsData node without structure as its ancestor, this is still a case to consider. but I don't know which of the following measures is more reasonable

  1. forbid users from creating BandsData instance without set a StructureData as its ancestor node.
  2. when running verdi data bands list show None as its formula value.

I am in favor of the second personally.

@ltalirz
Copy link
Member

ltalirz commented Feb 27, 2020

Thanks @unkcpz for pointing this out. I agree with your assessment and would vote for 2.

Mentioning @giovannipizzi and @sphuber for comment.

@greschd
Copy link
Member

greschd commented Feb 27, 2020

Agree with option 2, I'm fairly certain I've created BandsData without associated StructureData in some places.

@sphuber
Copy link
Contributor

sphuber commented Feb 28, 2020

This really depends on the original design of BandsData. If it really needs an associated StructureData then option 2 would be a bit of a workaround. But given that one can already created a separate BandsData object, interfaces should not except, so I would also vote for option 2

@ltalirz
Copy link
Member

ltalirz commented Feb 28, 2020

Thanks for the input - @unkcpz this is the "go" signal ;-)

@unkcpz
Copy link
Member Author

unkcpz commented Feb 29, 2020

I make a PR. but one thing need to be discussed, when a bands object is cloned, its StructureData should also be cloned? Maybe this behavior is what users expected when calling the .clone() function.

@greschd
Copy link
Member

greschd commented Feb 29, 2020

I don't think it should clone the StructureData. Looking at the code, the "linked structure" is anyway just determined through a query for the closest ancestor, and .clone() definitely shouldn't do any node linking - the graph relationships of the clone should be up to the calling code (e.g. in the caching code).

That makes me wonder, though, if that linked structure is always the right one. It looks for the closest parent, but for example if a calculation creates both structure and bands in one step, the correct structure might be a sibling node.

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

Successfully merging a pull request may close this issue.

4 participants