tile command ignores volume models

[Elaine Meng]

Currently it just ignores any maps if you have both atomic and map models, and if you have only map models, it gives a message
“no structures found for tiling”

Would it be difficult to generalize to include volume models?

[Conrad Huang]

The main issue with tile is figuring out which model's positions are dependent on other models. For example, the reason only atomic structures are used is to avoid moving surfaces (which will move with the atomic models automatically). I don't know how volume models are related to others and do not want to disconnect related models. Can someone who knows explain how one can tell which models share the same transformation (either using the same matrix or via the model hierarchy)?

[goddard@…]

There is no sharing of position matrices in ChimeraX, only the hierarchy of models needs to be considered.  The thing to avoid is tiling model A and B where B is a child of A.  So the first idea is that only top level models should be tiled.  There is a command argument class TopModelsArg that gives only models that are not children of other specified models.  A possible problem with this is if you have an NMR ensemble 1.1, 1.2, 1.3.... and say "tile #1" it would just tile the grouping model #1 not the children.  You would have to say "tile #1.1-25".  Maybe that is ok.

[Conrad Huang]

Is there a way to tell whether a model is /strictly/ a grouping model? 
That is, an atomic structure model may have surface model children, but 
it also has its own graphics; but opening an ensemble generates a top 
level model that has /no/ graphics.  Is there some way to distinguish 
between them?

On 7/11/2019 12:27 PM, Tom Goddard wrote:

[goddard@…]

We don't have any definition of a "grouping model".  It is not as simple as whether the model has triangles, for example, a Structure model has no triangles -- the atoms are a child drawing, bonds are another child drawing, missing segment pseudobonds are a child model.  Similar situation for Volume model, it has no triangles.  All its rendering is from child models for contour surfaces, and child image rendering models.

We could define a model type called Group and use it when we open NMR ensembles.  But there may be gray areas.  We really need an operational definition of what a "group" is if we are going to have commands treat groups in a special way.

[Conrad Huang]

The main question is "what models /should/ be moved by the "tile" 
command?"  The current incarnation assumes that only specified atomic 
structures should be tiled.  (This may not be quite right: for example, 
if you specify two ensembles, you may want the two ensembles tiled, not 
all their submodels.)  Surface models are explicitly ignored since they 
should move with their associated atomic structures.  (Probably 
incorrect: independent surface models are ignored.)  So I am really 
looking for a more general answer to the main question.  Unfortunately, 
I don't think there is one right now.

The simplest alternative is to add volume models as "tile-able" models. 
Another is to ignore "containing" models (models all of whose submodels 
are also specified).  I like the former just because I know what it will 
do and when it will fail.  The latter is more general and therefore less 
predictable in its failure modes.  Unless someone has another proposal, 
I'll implement the simple workaround.

On 7/12/2019 9:40 AM, ChimeraX wrote:

[goddard@…]

The tile command should work on all model types.  I think the simple and usable definition is to use TopModelsArg -- in other words the models argument has removed from it any models that also have an ancestor model specified.  This is for example what the move and turn commands use for their models keyword argument, and the "view position" command also uses it.  Basically every command we have that moves models uses TopModelsArg to avoid moving both parent and child models.  So I think that should be used for consistency, and because it has the best behavior.

[pett]

I guess you could special case the situation where TopModelsArg returns exactly one model (presumably a grouping model). In that case you would tile the child models.

[Conrad Huang]

Those are the heuristics that I was trying to avoid, both because they come back to bite you when they're applied in in unexpected ways (like tiling volumes during demos) and are hard to document.

Eric's special case is actually critical, since ensembles are almost always tiled using only the parent model and not all of the submodels. I committed a change for "tile" to handle atomic structures and volumes. I can make the change suggested here if people feel strongly about it.

[Elaine Meng]

fixed, at least in my relatively simple test cases