MVS: IHM support

[dsehnal]

Description

Adds better support for I/HM structure in MolViewSpec

• Support coarse components
• Support spacefill representation
• Support element_granularity in component expressions
• If no color theme is specified explicitly, use Mol*'s defaults instead
• Add atom.ihm.has-seq-id symbol to the query language

https://pdb-ihm.org/cif/8zz1.cif with crosslink restraints:

Actions

• Added description of changes to the [Unreleased] section of CHANGELOG.md
• Updated headers of modified files

[midlik]

Looks fine but some things are not clear to me - see comments.
Also, have you tested if the new selections work in all possible contexts (I mean, as inline component, as *_from_uri, as target for primitive...)?

[midlik]

Here we are making sure MVS is pretty much Molstar-specific and no one will ever implement it for any other viewer.

[dsehnal]

I disagree. You can still implement explicit colors. And this could be defined as expected behavior (= colors determined by viewer if not specified explicitly).

And we focus on iterating on color in "MVS 2.0".

[dsehnal]

I have an alternate solution to support "vendor extension" to do that. Thanks for the feedback.

[midlik]

I thought the original idea was that a MVS view should look roughly the same in all viewers.
With this, a representation node without specified color can look very different in different viewers.
So as a user, I might think I have created a beautiful view where each chain has a different color, but then I load it in PyMOL it will be all magenta because default per-chain coloring was just Molstar's implementation detail.

[dsehnal]

You are right, I will implement the auto mol* coloring as a custom extension on the color node.

[midlik]

Does this mean that if label_seq_id is not present, it will select from both atomic and coarse parts of the structure?

[dsehnal]

Actually, we can completely remove element_granularity in this case and just use the ihm.hasSeqId.

[midlik]

Hmmm, if we can remove element_granularity, let's do it. One thing less for the user to worry about.

[dsehnal]

Also, have you tested if the new selections work in all possible contexts (I mean, as inline component, as *_from_uri, as target for primitive...)?

My goal was to make this work with the primitives here. @midlik you wrote this code, so do I need to change anything else for things you mention to work or is this fine? Can also do this in a separate PR.

[midlik]

Also, have you tested if the new selections work in all possible contexts (I mean, as inline component, as *_from_uri, as target for primitive...)?

My goal was to make this work with the primitives here. @midlik you wrote this code, so do I need to change anything else for things you mention to work or is this fine? Can also do this in a separate PR.

If we remove element_granularity, it should work in all context, i think.
If you want i can test it (just ping me once you remove element_granularity)

[dsehnal]

If we remove element_granularity, it should work in all context, i think.
If you want i can test it (just ping me once you remove element_granularity)

@midlik
Ready for re-review/testing. Thanks

[midlik]

I'm getting errors when trying to use beg_label_seq_id and end_label_seq_id:

p.distance({ radius: 1, start: { label_asym_id: 'A', beg_label_seq_id: 607, end_label_seq_id: 609 }, end: { label_asym_id: 'A', label_seq_id: 58 } }); // atomic-atomic

even though the residues i'm targeting are atomic, not coarse.

I think this could be solved by implementing something like MolScript.structureQuery.atomProperty.ihm.hasOverlapWithSeqIdRange (pls give it a better name), which would take start and end argument (both can be omitted) instead of just one seqId.

[midlik]

And getting the same kind of errors with any auth_* fields (auth_asym_id, auth_seq_id).

Not sure if these can be implemented for coarse models, but at least they should keep working for the atomic portion of the structure, while returning an empty selection from the coarse portion (+ print warning), IMHO.

[midlik]

This completely breaks the repr, instead of just not coloring:

const repr = struct.component().representation({ type: 'spacefill' });
repr.color({ color: 'blue', selector: { auth_asym_id: 'C' } }); // breaks everything

repr.color({ color: 'blue', selector: { label_asym_id: 'A', label_seq_id: 81 } }); // works nicely
repr.color({ color: 'blue', selector: { label_asym_id: 'A', label_atom_id: 'XXXX' } }); // colors whole chain :(, should color nothing

[dsehnal]

I think this could be solved by implementing something like MolScript.structureQuery.atomProperty.ihm.hasOverlapWithSeqIdRange (pls give it a better name), which would take start and end argument (both can be omitted) instead of just one seqId.

@midlik added this

[dsehnal]

This completely breaks the repr, instead of just not coloring:

const repr = struct.component().representation({ type: 'spacefill' });
repr.color({ color: 'blue', selector: { auth_asym_id: 'C' } }); // breaks everything

repr.color({ color: 'blue', selector: { label_asym_id: 'A', label_seq_id: 81 } }); // works nicely
repr.color({ color: 'blue', selector: { label_asym_id: 'A', label_atom_id: 'XXXX' } }); // colors whole chain :(, should color nothing

And getting the same kind of errors with any auth_* fields (auth_asym_id, auth_seq_id).

Not sure if these can be implemented for coarse models, but at least they should keep working for the atomic portion of the structure, while returning an empty selection from the coarse portion (+ print warning), IMHO.

This is expected behavior currently and would break in "native" Mol* code, will possibly adjust in the future.