Left to dry by iotbx_pdb_ext.input.construct_hierarchy()
Hello all, This seems like it should qualify as a bug. If I have an instance of iotbx_pdb_ext.input and I create a hierarchy with construct_hierarchy(), then I must retain the reference to that hierarchy or apparently I can never get it back:
hierarchy = my_pdb.construct_hierarchy() def some_local_scope_function(a_pdb): local_hierarchy = a_pdb.construct_hierarchy() some_local_scope_function(my_pdb) […] RuntimeError: atom has another parent atom_group already.
Wouldn't better behavior just return the previously constructed hierarchy given that multiple hierarchies can't be made? If each atom apparently remembers to which atom_group it belongs (and presumably on up), then shouldn't it make sense that an iotbx_pdb_ext.input be able to remember it's own hierarchy and produce it upon demand? Looking at a iotbx_pdb_hierarchy_ext.root, I don't find a reference to the iotbx_pdb_ext.input from which it was created. So, although passing around a hierarchy might be the obvious work-around, the end-user still needs to do some accounting if said user wants to track which roots belong to which inputs, and vice versa. James
On Mon, Mar 25, 2013 at 2:15 PM, James Stroud
This seems like it should qualify as a bug. If I have an instance of iotbx_pdb_ext.input and I create a hierarchy with construct_hierarchy(), then I must retain the reference to that hierarchy or apparently I can never get it back: ... Wouldn't better behavior just return the previously constructed hierarchy given that multiple hierarchies can't be made? If each atom apparently remembers to which atom_group it belongs (and presumably on up), then shouldn't it make sense that an iotbx_pdb_ext.input be able to remember it's own hierarchy and produce it upon demand?
Yes, and that is actually something we were planning to fix very soon. (In fact, Richard, since I'm about to start breaking the Phenix installers anyway, this week would be a great time...) -Nat
participants (2)
-
James Stroud
-
Nathaniel Echols