Change sym command default to avoid confusing graphical clones

[Tom Goddard]

As Elaine points out and user Yakhomba experienced the sym command default behavior of making graphical clones instead of distinct copies of molecular subunits can lead to a lot of confusion when subsequently using commands like matchmaker and most others that don't know about clones. Perhaps it would be better to change the sym command default to make copies instead of graphical clones. This would greatly using it for virus capsids. Could have the default smart and make copies for fewer than 9 copies and clones for more.

Begin forwarded message:

From: Elaine Meng
Subject: Fwd: [chimerax-users] Problem with C2 symmetric assemblies
Date: November 30, 2020 at 1:13:43 PM PST
To: Tom Goddard
Cc: meng Elaine

Hi Tom,
People are constantly being confused by the graphical clones... at least, that's what I'm blaming this problem on. I'm not crazy about "copies false" being the default, although I can see the problems with "copies true" making ChimeraX slow if there are too many atoms.

I tried it with Yaikhomba's symmetry command, which would make half of the dimer in #1 a graphical clone

open 1be3
sym #1 assembly 2 newModel false
open 3cx5
light simple
preset licorice

Matchmaker #2 onto #1 looks OK, but matchmaker #1 onto #2 leaves the graphical clone out by itself, e.g. the above commands followed by

mm #1/C to #2/C

I don't know if that is a bug or just a limitation of using the graphical clone approach.

I didn't want to get into that confusing discussion so I just said he needed to use "copies true" and deal with the additional model, or fetch bioassembly in the first place.

Elaine

Begin forwarded message:

From: Elaine Meng <meng@…>
Subject: Re: [chimerax-users] Problem with C2 symmetric assemblies
Date: November 30, 2020 at 1:00:32 PM PST
To: "Y. Mutum" <ym337@…>
Cc: "chimerax-users@…" <chimerax-users@…>
Reply-To: ChimeraX Users Help <chimerax-users@…>

Hi Yaikhomba,
I think you need to use

sym #1 assembly 2 copies true

Otherwise the symmetry partner will only be a graphical clone, not a true atomic copy. As I understand it, you need full atomic copies to do various analyses and calculations on the coordinates.

That will give you #1 original 1be3, and #2.1, #2.2 1be3 symmetry partners. If you don't want #1 then use command "close #1".

Then in commands you can specify the two copies of chain C, for example, as #2.1/C and #2.2/C. If there was just a graphical clone, as from the sym command you used, there is no way to specify the two C chains from two copies of 1be3 separately, since one of them isn't "real."

(B) Alternatively, if you must have the dimer as a single model: since ChimeraX does not yet have a "combine" command, you would need to open the assembly as a single model, e.g. from PDBe:

open 1be3 from pdbe_bio

<​http://rbvi.ucsf.edu/chimerax/docs/user/commands/open.html#fetch>

This will give you both assemblies #1.1 and #1.2, and you know that you only want assembly 2, so you would still need to close #1.1. Then finally you would have assembly 2 as a single model, #1.2. Unfortunately there is no way to get only the assembly you want if it is not the first one.

#1.2 from PDBe will have unique chains. For example, the other copy of chain A is chain AA.

I hope this helps,
Elaine

---

Elaine C. Meng, Ph.D.
UCSF Chimera(X) team
Department of Pharmaceutical Chemistry
University of California, San Francisco

On Nov 30, 2020, at 11:13 AM, Y. Mutum <ym337@…> wrote:

Hi

I have a a C2-symmetric pdb: 1be3 and have created a symmetric assembly using the command.
sym #1 assembly 2 newModel false

The idea is to superimpose Chain /C of 1be3 and its symmetry partner with that of 3cx5 (corresponding chains -C and N) to get of deviations b/w the chains.
However, when I try to 'match #1/C with #2/C, then I am getting only half of the C2 symmetric assembly superimposed. Is there a way to superimpose both of the chains-C of 1be3 to 3cx5?

I could open the model 1be3 twice and then superimpose to the equivalent subunits (chains C and N) of 3cx5, one at a time. But the resulting superimposed assembly 1be3 (from 2 different models) is not going to be the C2 symmetric.

In short, for 1be3: pdb, is it possible to rename the symmetry mate with different chains and get the C2 symmetric assembly as a single model? Say, for this new 1be3 C2-symetric assembly, you rename the second symmetry partners chains - Chain C as C1, Chain B as B1 for example in that new model. The idea is to have a C2 symmetric model with different chains, so that it can be compared with other models easily.

Thanks
Yaikhomba

_
ChimeraX-users mailing list
ChimeraX-users@…
Manage subscription:
​https://plato.cgl.ucsf.edu/mailman/listinfo/chimerax-users

[Tom Goddard]

Begin forwarded message:

From: Elaine Meng
Subject: Re: [chimerax-users] Problem with C2 symmetric assemblies
Date: November 30, 2020 at 3:13:56 PM PST
To: Tom Goddard

There is already some confusing conditionality between the "copies" and "newModel" options, so I lean against putting even more conditionality into the command. Another (similar) alternative is to make the links in the Log assembly table use "copies true" for assemblies with less than N copies, or that would add up to less than N atoms. That might be clearer, because then people could see "copies true" in the command echoed to the Log... however, I'm guessing it would be hard to do, if there isn't a simple way to tell ahead of time the total number of atoms or copies in an assembly.

I already devoted a lot of real estate to explaining graphical clones in the main structure analysis tutorial. So the work has already been done in that respect, and maybe it is good to explain it anyway, because later they might want to look at atomic interactions between capsid subunits and will need to know to use "copies true" if they want to do that.

I'll just try to remember that matching/aligning is another situation where the graphical clones can be confusing.

Elaine

[Tom Goddard]

The code that creates the assembly table in the log does not know how many copies each assembly has. It would be possible to dig it out but is not clear how hard that would be.

[Tom Goddard]

Forgot to add Elaine to this ticket.

[Elaine Meng]

One more idea is to simply modify the assemblies table shown in the Log when opening mmCIF.  I'm thinking it may be useful just to add another column at the right with a clickable link "atomic copies" or "full atomic copies" in each row.  The links on the left ("1" "2" etc.) would continue to behave exactly as they do now.  This would vastly increase accessibility of "copies true" to people who aren't going to go look at the manual, and tells them what they would be getting.

[goddard@…]

I am not keen on the idea of offering both clones and copies in the assembly table.  I really think clones are for advanced users and should take some effort or need to get clones.

What do you think of the following idea.  Change the default of newModel to true.  I think this is usually desirable and simplifies the current behavior where the copies option influences the default for newModel.  Then have the copies option default be smart, clones for large numbers of copies (say more than 12) and copies otherwise.  The idea is to only get clones when you probably want them because you are looking at a virus capsid or some other very large multimer.

[Elaine Meng]

Oh, I misunderstood your preference.  I'd thought you wanted to err on the side of graphical clones to avoid slowing down the display.  newModel is already default true in almost every situation, the most common one being mmCIF models, regardless of the copies option.  It is only default false for the rarer case of user-specified symmetry.  So if always default true, it would be easier to document, but operationally for most users be the same as it is now.

The problem with newModel true is that it's also confusing and/or bothersome to people to have the original model hidden and potentially subject to any further manipulations (and potentially slowing down calculations), which is why that user specified newModel false.  I can see there are reasons to keep the original model, but personally I'd almost always prefer to replace the original model, use the original model number for the new assembly (potentially with submodels), and not be bothered by a hidden original model.

I am OK with your smart copies (true if <13) approach.  Not sure how best to implement the recommended behavior for new models, however.  Possibilities are to have a "replace true" or "keepOriginal false" default.

[goddard@…]

Ok.  I'm not 100% sure I agree that it is better that default sym behavior would replace the original model.  For instance, if there are 2 assemblies and I show the first, I think I would be unpleasantly surprised to find my original model gone and now I can no longer show the second without reopening the original model.  Likewise if instead of assemblies I am specifying explicit symmetry I think I really don't want the original to be removed.  I guess removing the original could work if the sym command allowed you to then operate on the assembly to change it into some other assembly.  But that sounds like new code which will be difficult to make right since some assemblies actually delete chains.  Even getting the sym command to simply replace the existing model and use the same model number is something current options do not support and would require new code, though not very difficult.

So I think trying to change the newModel behavior in addition to the copies default behavior, while nice is turning this into a bigger project.  So I guess I am still in favor of my original proposal to adjust the copies default.  Further enhancement to change the newModel behavior so the original model is deleted would need more figuring out of the use cases and whether it is feasible to do well.

[Elaine Meng]

OK.  Should I consider it done (copies true if assembly has <13 copies of the asymmetric unit)?  If so I will change the tutorials and docs to handle your new smart-copies behavior.  I don't remember how much the tutorials will need to change, might not be that much.  It was worse before when I used an APBS ESP map and relied upon having the graphical clone to color both subunits correctly when the map really only covered one subunit.  However, now I just fetch the bioassembly and use Coulombic coloring.

[goddard@…]

Not done yet.  Maybe I will try it today, but other more pressing problems may intervene.  Will post to this ticket when it is done.

[Elaine Meng]

Forgot to say, I definitely understand there are cases where model-replacement would have disadvantages.  It's just that in MY use cases, simple multimerization of small-to-medium-sized proteins, I think replacement would be better. Since you're the developer, however, you have majority rule.  :-)

[Tom Goddard]

Thanks! I want to make sym work reasonably for all common uses which of course also tends to make it a bit inconvenient for all uses. I use sym both for making small multimers and also for large multimers like virus capsids. It is annoying to have to close unneeded models like an original asymmetric unit but ChimeraX has no way to know what the user intends so should accommodate the different common use cases and spread the burden around.

[Tom Goddard]

Fixed.

Default for copies option is now true for 12 or fewer copies and false for larger numbers of copies.

If you are interested in the enhancement to make the sym command able to make assemblies without keeping the original asymmetric unit, ie just replacing the asymmetric unit with an assembly model that uses he same id number then make a separate ticket. I think it will be tricky to allow doing that and allow trying more than one symmetry.

[Elaine Meng]

OK will think about adding a ticket to replace model.  That would not allow trying more than one symmetry, it is for people who know which assembly they want.  To try a different assembly, they would need to open the original structure again, generally no problem for the majority mmCIF fetch case.