Visualisation/handling of altlocs

[Tristan Croll]

Designating as "Core" and assigning to Eric, but is related to both core and graphics.

This is not urgent for me, but something that would be great to have available in time for ISOLDE 1.0b3. Would be great to have a visualisation mode that shows all altlocs present (would be particularly cool with atom/bond radii scaled according to occupancy), and an API call to set which altloc (where altlocs are present) currently responds to generic 'Atoms.coords' calls.

The point of this is that when model-building it's very important to be able to see where you have altlocs (because otherwise all you see is unexplained density). In terms of simulation it would be undesirable to have them all active at once (it's technically possible - one can designate sets of atoms as not interacting with each other - but keeping them well-behaved would be a pain in the neck). With the above, it would be very simple to implement the ability to switch between altlocs in a running simulation, allowing them to be fitted one at a time.

[pett]

I believe the core infrastructure for this is already in place. You can ask an Atom for a list of its altlocs, and you can directly get the coordinates based on the altloc. The Atom also has calls to get/set the "current" altloc is and the default coord() call returns coordinates based on that. Therefore it would seem that the work to accomplish this largely lies in the graphics code, so I have reassigned the ticket to Tom.

--Eric

[Tom Goddard]

As Eric points out there are already Python calls to change the current altloc for an atom.

For depicting more than one altloc position at a time and the bonds between altloc positions I don't think the rendering code can be adapted in any simple way to achieve that. The rendering code uses Atoms and Bonds collections and uses parallel array operations to efficiently produce graphics. It also uses per-atom radius, color, hide/show state. Vectorizing the operations when you want multiple altlocs looks far too complex. It seems more plausible to use a separate depiction of the non-current altlocs which is computed and rendered by separate code.

Here are a few of the complexities of depiction. Will pseudobonds between two atoms with N and M altlocs show all possible pseudobonds? Probably not. Probably would just show the pseudobond between the current altlocs. Would selecting a non-current altloc select just that altloc or would it select the atom and all altlocs of that atom? Probably all altlocs of the atom since we have no concept of a selection of a specific altloc. Which bonds will be shown between altloc positions? Eric says bonds should only be shown within altloc groups (ie. same altloc letter) and also from an altloc to a connected atom which has blank as an altloc but is not in the same altloc group. If a ribbon is depicted and multiple altlocs are shown and their are backbone altlocs would it show multiple ribbons? Probably not, that would be a rendering nightmare -- probably only atoms and bonds would be shown for altlocs.

Eric suggested the different altlocs could be copied to different coordinate sets and then we could render the different coordinate sets at the same time. We can't currently render more than 1 coordinate set of a molecule at a time but we have considered allowing that. This has fewer rendering problems but is still probably too complex. Eric points out that altlocs and multiple coordinate sets are not currently supported and are not part of the design of the current atomic structure classes.

I think the only way to handle simultaneous display of multiple altlocs in a reasonably simple way is going to be to make an extra structure model that has all the separate altloc groups as distinct atoms (with no altlocs) and bonds so that they can be independently hidden and shown. This can be done now without any changes to atomic structure APIs.

[tic20@…]

OK - from what you've both told me, it sounds like I'll be able to 
handle it fairly straightforwardly when the time comes. Not that much 
different in principle (and simpler in many respects) to my live atomic 
symmetry display: (a) separate drawing(s), probably not selectable but 
giving a tooltip with atom + altloc information on mouseover and a few 
event handlers. I don't see a lot of value in making altlocs directly 
manipulable - I'd just leave them static so the user has to actively 
switch the main model to the desired altloc in order to edit it.

On 2018-11-03 00:51, ChimeraX wrote: