accuracy and get_average_distance_wrt_reference_structure()
Dear IMP,
While playing around with the tutorial, I noticed that the accuracy calculation errors out:
imp_tutorial/rnapolii/analysis/accuracy.py
Traceback (most recent call last): File "accuracy.py", line 43, in <module> pr.set_reference_structure(reference_rmf,0) File "/home/jmintser/IMP/imp-2.6.2_release/lib/IMP/pmi/analysis.py", line 898, in set_reference_structure particles_resolution_one = self._get_structure(rmf_frame_index,rmf_name) File "/home/jmintser/IMP/imp-2.6.2_release/lib/IMP/pmi/analysis.py", line 524, in _get_structure IMP.rmf.link_hierarchies(rh, self.prots) File "/home/jmintser/IMP/imp-2.6.2_release/lib/IMP/rmf/__init__.py", line 501, in link_hierarchies return _IMP_rmf.link_hierarchies(*args) _IMP_kernel.ValueException: Number of children doesn't match the number of representation nodes at Rpb1. They are 4 and 3 respectively. [2, 8, 1432, 1585] vs [Beads(representation, n3), Rpb1_Res:1(representation, n9), Rpb1_Res:10(representation, n1433)]
WARNING No frames were loaded from file "HierarchyLoadLink52" even though objects were linked or created.
As far as I understand this is because the representation details in the native.rmf3 do not exactly match those of the modeled system. This got me thinking about how the native.rmf3 was generated in the first place. The only way I can think of making a native rmf3 is to essentially run the modeling script keeping everything rigid and not shuffling the initial configuration. Is there no way to compare the model to an existing pdb if one exists without worrying about reproducing the representation exactly?
Thanks much, Julian
On 09/15/2016 03:37 PM, Julian wrote: > While playing around with the tutorial, I noticed that the accuracy > calculation errors out: ... > _IMP_kernel.ValueException: Number of children doesn't match the number > of representation nodes at Rpb1. They are 4 and 3 respectively. [2, 8, > 1432, 1585] vs [Beads(representation, n3), Rpb1_Res:1(representation, > n9), Rpb1_Res:10(representation, n1433)]
By "playing around", I take it you changed something fundamental? This shouldn't happen if you just run the tutorial as-is.
> As far as I understand this is because the representation details in the > native.rmf3 do not exactly match those of the modeled system.
Right, the representation has to match otherwise the (rather simplistic) script cannot determine which pairs of particles correspond in the two models. This isn't something we've worried too much about since usually we don't know the "right answer" anyway. If for some reason you wanted to compare different representations, first you'd have to figure out how to map one onto the other. In *some* cases this is straightforward (e.g. it's pretty easy to coarse grain an atomic model).
Ben
I downloaded ftp://salilab.org/tutorials/imp/rnapolii/analysis.tar.gz from the tutorial and ran that against the native.rmf3 in the data directory from git So, my guess is analysis.tar.gz was created from an earlier version that might have had a slightly different representation defined.
Either way, you answered my question.
Thanks, Julian
On Tue, Oct 4, 2016 at 3:49 PM, Ben Webb ben@salilab.org wrote:
> On 09/15/2016 03:37 PM, Julian wrote: > >> While playing around with the tutorial, I noticed that the accuracy >> calculation errors out: >> > ... > >> _IMP_kernel.ValueException: Number of children doesn't match the number >> of representation nodes at Rpb1. They are 4 and 3 respectively. [2, 8, >> 1432, 1585] vs [Beads(representation, n3), Rpb1_Res:1(representation, >> n9), Rpb1_Res:10(representation, n1433)] >> > > By "playing around", I take it you changed something fundamental? This > shouldn't happen if you just run the tutorial as-is. > > As far as I understand this is because the representation details in the >> native.rmf3 do not exactly match those of the modeled system. >> > > Right, the representation has to match otherwise the (rather simplistic) > script cannot determine which pairs of particles correspond in the two > models. This isn't something we've worried too much about since usually we > don't know the "right answer" anyway. If for some reason you wanted to > compare different representations, first you'd have to figure out how to > map one onto the other. In *some* cases this is straightforward (e.g. it's > pretty easy to coarse grain an atomic model). > > Ben > -- > ben@salilab.org https://salilab.org/~ben/ > "It is a capital mistake to theorize before one has data." > - Sir Arthur Conan Doyle > _______________________________________________ > IMP-users mailing list > IMP-users@salilab.org > https://salilab.org/mailman/listinfo/imp-users >
participants (2)
-
Ben Webb -
Julian