Trim tool

[alcor29]

The trim tool needs to have a smaller sphere, or we should be able to determine the radius of the sphere with a slider. Currently it trims areas we don't want to work on.

[rmoretti]

My understanding of the trim tool is that it's based on the residues you have selected. More residues selected = bigger trim sphere.

If you're using the sphere selection tool (Ctrl-Shift-Left Click-Drag), then you should be able to control the size of the sphere by how much you drag. You should be able to see how many residues will be selected by the highlight.

One thing you may notice is that the trim tool adds "padding" residues in addition to the ones you selected. Those should just be the residues one before and one after each stretch in the segment, and are just included to make sure that when you untrim your protein backbones match up. – Though playing around with it, I do note that they might be slightly more flexible than they need to be, though I'm not the one who has worked extensively with this.

[Sandrix72]

Is it any plan to include the trim instruction into foldit commands to handle it via recipes?

[ichwilldiesennamen]

Referring to Moretti's post: is there a way to get rid of these "padding" residues? The reason why I am asking is that they are basically useless for me. When I trim a selection I leave the most outside segments mostly untouched anyway afterwards. Then I get less problems/point-drop when I untrim. But these padding-residues just expand the complexity of the protein and especially distance-checks in recipes can take much longer due to them. For a selected 80 segments I typically get around 100 segments after trim. This is a significant additional amount which is a noticeable performance-break for me.
Also, I have noticed that after trim the segment indices get renumbered. Of course I understand that this is necessary because after trim we have less residues and Foldit can just have consecutive indices in the segments. But the segments are just concatenated and subsequent rebuilds for example may potentially act on wrong sequences because after untrim the segments get reordered again. This could also lead to clashes/point-drops after untrim. I find this a bit dangerous. It should not be a problem when you only work on the "inner" segments of a trimmed solution though. Even though it is hard to tell where the "inner" segments end.
But my main problem with this is: how can one derive the relation between the indices of the segments before trim and after? Especaily since these padding-segments are added? Basically I am asking for a way to find the same segment before and after trim. Due to this reordering this is not an easy task. I have a workaround for the moment but I cannot imagine that this is the intended way (if there is one at all). It would be great if you could provide some feedback on this.

[rmoretti]

The padding residues are a trade off to make sure that things line up properly when you untrim. If we didn't add them (and then lock them down), then we'd either have to lock-down the edge residues within your selection (which would leave your selection much less flexible than you may have intended), or we'd have to leave the edge residues unconstrained, which means that unless you were exceedingly careful you'd have horrible energies when you untrimmed the pose. We played around with a number of different approaches, and the padding approach was the compromise which had the best usability. We don't have a mechanism to change the behavior, and it's not likely something we'd add.

The residue numbering is sequential, and the renumbering is required by the Foldit internals (because you're technically working on a structure with fewer residues). I don't think we have any sort of facility to translate the numbering, but it should be all the residues in your selection in the same order they were, just without the gaps. The padding residues will also be there, and there will be a padding residue for every residue in the selection which is polymerically connected to a residue outside the selection. (That is if you have a selection of residues 5,6, 9, & 11, padding residues of 4,7,8,10 & 12 will be added, and then they'll be renumbered to 1-9, in the same order they're originally in the structure.) Note that no padding residues are added if the selected residue is at the edge of a chain (e.g. if there's a chain from 1-56 and one from 57-98, then if you trim a selection including residue 57, then 56 should not be added as a padding residue.)

[ichwilldiesennamen]

Thanks for the infos. The way you explain it It all makes sense to me. I would have liked to try though the locked-down outside segment-version. Because for me these segments are really completely useless (except as a boundary limit for more inside segments) and I try to leave them untouched anyway in the trimmed protein. Because for me the effort of fixing up the interface after untrim is not acceptable. Especially if the puzzles are really large this can be quite a burden. Even a simple shake can take a long time with this. And as it is now, the outside segments of the trimmed protein are completely free to move per default and they "think" that outside is free space. So they have a tendency of "wanting to change" if they are not frozen/locked. But even frozen segments can move. This is why I would have liked to see if this version with the locked-down segments would have behaved better for me. Anyway, thanks for the explanation.
The segment numbering also makes sense. Even though I have found a (for me) easier workaround to identify segments. I anyway only need to identify very few so I will stick to that I guess because it already works for me.

[jeff101]

In Puzzle 2494, if you Tab on each segment and look at its Segment Information, you can get:
1: Glutamine PDB#: A 244
2: Glycine PDB#: A 245
3: Glycine PDB#: A 246
…
121: Phenylalanine PDB#: A 364
122: Asparagine PDB#: A 365
123: Glycine PDB#: G 246
124: Threonine PDB#: G 247
…
239: Lysine PDB#: G 362
240: Histidine PDB#: G 363
241: Phenylalanine PDB#: G 364
242: [Unknown] PDB#: X 1

If the Trim Tool were used, would it only change the far left #'s in the lines above?
Would what began as Lysine PDB#: G 362 at segment 239 still say Lysine PDB#: G 362
even if its segment number changes from 239 to something else, like say 89?
If this is the case, using the PDB#'s could help map the pre-Trim segment #'s to
the segment #'s after Trim is used. Is there a LUA command to read the PDB#
(like G 362) for a particular segment #? If not, why don't you make one?