Spacial Orientation Changes Made to Protein [Move Tool] Effects Voids/Burials/Exposures

[Formula350]

This is something that I have noticed for awhile now, but due to the puzzles I've been playing (them being puzzles 1350 and its previous two variants), I hadn't been able to properly documented it outside of them in order to illustrate it is not tied to one puzzle type or design. Now that they are finished and I've moved on to a completely different puzzle, I've taken a moment to collect additonal evidence.

First, I'll explain a bit more on what exactly is occurring. Our proteins float in a 'space' that allows us to work in three dimensions and rotate our view. Technically speaking the X, Y and Z Axis should not influence anything on our designs as far as I'm aware. It should be as if we're operating in a vacuum, or perhaps a liquid suspension, but the point being that which way our protein is facing shouldn't matter. Keep in mind that there are two ways to change your view of your protein. The primary method is through rotating the camera through mouse clicks in the empty parts of the screen. THAT method is not the cause of these anomalies. The second way is by means of the "Move Tool", which is brought up by clicking on a segment in Classic Interface, or by pressing the 3 key on the number-row in Selection Interface, which brings up the purple 4-Way Directional Arrows ⍆ and the 2-Way Rotation Arrows ⤹. This is primarily something we use on portions we have made cuts to, for rotating just that part in an effort to align things better. However, there are also times when rotating the entire protein is needed, such as with Electron Density puzzles, when trying to get a base alignment in the ED Cloud. Note: changing the 'coordinates' of the protein in the workspace (holding CTRL or SHIFT while using the arrows) does not cause these results, it is only the standard Move Tool usage that does.

[Report continues in the comments]

[Formula350]

Allow me to outline what it takes to accomplish this (see: recreate similar results), even though it is incredibly easy to accomplish.
You will need to have certain View settings turn ON so here is a View Options Checklist:
☑ Show exposed
☑ Show voids
☑ Show expected residue burials
Once you have those enabled, with a protein design loaded that has zero cuts in place, begin by making a note of where there are AA Exposures, Burials and Voids. Once you have a mental note of a few, click on a segment or press 3 (depending on your Interface as outlined above). Often times all you'll need to do is make a single "tick" directional adjustment of the protein to invoke a noticeable difference in at least one of the three aforementioned visual aids; all three occurring is not rare!

Here are some examples I've collected and am including as attachments, to help illustrate the vast changes taking place.
Please note the changes that are circled in both the Before and After images… (All images are at 50% but can be clicked to view at original size)
1350 Design: Before

1350 Design: AFTER

The changes I've highlighted in the above are not as severe as other experiences I've had, but still hits the trifecta. The Xes denote where a Void has disappeared, just to help while viewing. Also I made sure to include the Segment Information window, which shows that there are no score impacts by this, as such highlighting that this is mostly a visual anomaly.

1351 Design: AFTER (What I consider to be 'better')

1351 Design: BEFORE (What Foldit considers Best)

I say that it is "mostly" a visual anomaly because there IS something going on that Foldit does consider when it calculates your "Best Score" (all three kinds). For example, in my next two shots you'll see how I spent some time rotating and getting what I would consider to be the Best, yet Foldit still considers my pre-Move Tool tinkering to be. However, in the majority of my other experiences my Best before working is overwritten by a result after my futzing about. Again, no score change is present. Wiggling and Shaking are not affected.

To conclude this report I'll outline why I feel this is worth looking into… We learn early on that there are these Voids and Exposures that we want to eliminate because they are "bad", and we need to do whatever it takes to remove them. People have created recipes to help us in accomplishing those feats, either by tugging on exposed AAs to try and turn them inwards, or like Timo's VoidCrusher to… well do as advertised: crush voids out of your design! Before this, I trusted that where a Void was being displayed on my screen, was indeed an area that I needed to address because there was a significant enough 'pocket' where water (or whatever) could penetrate. Similarly, that an AA being flagged as Exposed was, in fact, one that did not have proper cover or was not turned inward enough. However, after all of this, now I question if what I'm doing really is what will result in the best protein. I call it into question now, since I can accomplish the same thing with a tenth of the effort, just by rotating the darn thing a bit. When an AA is shown as an "Expected Burial" one moment, but "not" the next; an area to have massive Voids, but gone after a simple rotation; or an Exposure to be easily hidden by a shift left or right… I can't help but wonder if it's not better that I do that which imposes no negative scoring and work from there, as opposed to making changes to backbone to accomplish that and have a score be impacted negatively (large, or small)?

In short? Our design workspace in Foldit should be looked at as being unbiased towards our design's orientation, having there be no discernible Up or Down, when it is seeming like there IS an up and a down. As a final verbal example: The All-Sheet puzzle we had recently, if I flipped my design 180deg, the exposures on one side, now became exposures on the other side.

If this is caused by our workspace being made up of multiple "Tiles" of 'x'-size, then it would seem like either the Tiled approach needs re-thinking -or- that the Tile sizes need to be increased by two or three fold. Unfortunately, I have no idea what the actual purpose of these "tiles" are in the first place, but they do seem to be influencing the playability to a degree (such as with ED Maps and, in that case, can indeed impact scoring).

Thanks for your time!

[My basic system specs- OS: Windows 10 Home 64 ver.1511 build 10586.218, CPU: AMD FX-9800P APU w/ Radeon iGPU]

[Formula350]

Two more screenshots, still the same chain of puzzles as 1350, but a different design.
(As before, click for fullsize)

1344 Design: Before (This was the one where we had to bury the -phobics)

1344 Design: AFTER

[Formula350]

Addendum:
Just to make it clear in case there may be confusion… The interface you're working in (Selection/Classic) does not actually matter, neither does if you only have only some of the segments selected when in Selection Interface. So long as there are no Cuts currently in place anywhere, so that you're rotating the entire puzzle, you'll be able to reproduce everything outlined above with ease.

In my examples I opted to show that even a single solitary "tick" of the Move Tool can result in considerably large changes in Voids, Exposed and Burials. Making large rotations/turns will make just as potentially big of impact, and in some instances even bigger. As I had mentioned above, the Sheet-Only puzzle we had recently played I was able to make tons of Exposures vanish by changing my design's orientation in the workspace.
-Exposures in general, in my experience so far, see the least changes; however, it all depends on the design as well.
-Burials will often change, sometimes only one, sometimes a few, and sometimes two will trade out even if they're on different sides of the design.
-Voids are far and away the most prominent in what changes, not just in size, but in number, and locations. They have been known to appear in a place that you may not have been experiencing voids during your work, but after rotating a bit will suddenly show a large one to appear there.

[bkoep]

Hi Formula350, this will not be a comprehensive answer to your question, but might shed some light on our dilemma. The short answer is that these visualizations represent real concepts that we'd like Foldit players (especially beginners) to think about when folding a protein; but the visualizations themselves are poor quantitative measures, and cannot be improved without slowing down Foldit considerably. You're better off relying on the Foldit score (and residue sub-scores) for close scrutiny of your model.

The three visualizations you've pinpointed here (i.e. voids, exposed and buried residues) all rely on calculations of "solvent accessible surface area"—or "SASA," for short. For every atom in the protein structure, we have to calculate how much of its "surface" is packed neatly against other protein atoms, and how much of it is exposed to empty space (assumed to be vacuum inside the protein, and implicit solvent outside). This is actually a very important concept in modeling proteins; the burial (that is, reducing SASA) of hydrophobic atoms is thought to be the greatest force that drives protein folding.

The thing is, SASA calculations are generally expensive (slow)—expensive enough that they are avoided completely in the Rosetta scoring function. Instead we rely on faster, but rougher approximations of "solvent accessibility" when scoring models. Unfortunately, these other approximations do not lend themselves to visualization; although, they are robust against rotations/translations in the Cartesian coordinate system.

I'm actually unfamiliar with the code for these visualizations, but I'm guessing they rely on coarsely-discretized space (i.e. voxels) to very-roughly approximate SASA. Naturally, this will be sensitive to small rotations/translations in the coordinate system. Maybe a dev can chime in here, but I don't want to distract them from other, more pressing problems.

[Formula350]

Hi bkoep, thanks for taking the time to respond, nevermind read my long post! :D

As someone with… well a bit of high-school Biology about 20 years ago, that all made perfect sense and does shed more light on the situation than one might think.

On that note, while I haven't but a tiny bit of trivial coding knowledge and isn't enough to know whether this would be a viable solution, but I do have one nonetheless… actually I guess a few variations.

With these being computationally expensive calculations, I guess the first thing that comes to mind would be that if they were added, to offload those on to a another core to perform, which in Rosetta that'd definitely be where OpenCL would come in handy. However, I don't think we'd need any more complex a system added, so then I'd think having it only update those three thing after/during a Wiggle or Shake. while even simply providing that as a game option, "B.E.V. Updates: Performance|Costly|Manual Updates" (manual being like the Run Filters button), unfortunately that wouldn't account for when there are Cuts in play. With that being said, some form of If/Then configuration where it's looking for Cuts. I won't pretend this is proper coding (seriously, nobody laugh, I'm referencing Wiki here! haha), but in my head it's something like:
IF ProteinHasCuts = 1, AND SegmentsSelected != First+Last
THEN MoveToolUpdatesVisualAides = 1
ELSEIF ProteinHasCuts = 0
THEN MoveToolUpdatesVisualAides = 0

Just in case that doesn't compute (pun intended), I was aiming for, that if there are Cuts and the entire protein has not been Selected, then when using the Move Tool the visual aides for Burials, Exposures and Voids will update like they do now. Otherwise if there are Cuts but the entire protein is selected, or there are no Cuts at all, then the visual aids remain static as they do like while moving/rotating the camera view.

Just my –comparatively very depreciated– two cents. :P

Pre-posting update… For laughs I showed my friend my ""code"", and this is what he spat out, given he DOES have some coding knowledge (whether correctly formatted, I have no idea lol):
if ((ProteinHasCuts == 1) && (SegmentsSelected != First + Last)) MoveToolUpdatesVisualAides = 1;
else MoveToolUpdatesVisualAides = 0;