Hi Ryan,
Unfortunately, coordinates are the only attribute that works on a per-frame basis.  We hope to remedy that in Chimera 2, but we are nowhere near even an alpha release of Chimera 2 so that isn't really relevant here.  If you only need this for movie recording and your machine has a lot of memory relative to the size of these trajectories, then what you can do is sort of a riff on your workaround 2:  open the trajectory both as submodels and with MD Movie and copy the anisoU attribute on an as-needed basis with the per-frame scripting capability of MD Movie (Per-Frame/Define Script).  Here's a Python script you could use in the Define Script dialog to do the copying:

from chimera import openModels, Molecule
mols = openModels.list(modelTypes=[Molecule])
for m in mols:
if m.subid == mdInfo['frame']:
for pdbAtom, trajAtom in zip(m.atoms, mdInfo['mol'].atoms):
trajAtom.anisoU = pdbAtom.anisoU
break

You could add an aniso command after the copy via the runCommand method:

from chimera import runCommand
runCommand("aniso args-you-want...")

This is going to make trajectory playback sluggish, so is only really useful for movie recording I'd say.  Of course, showing the aniso surfaces was probably making playback sluggish anyway!

--Eric

                        Eric Pettersen
                        UCSF Computer Graphics Lab
                        http://www.cgl.ucsf.edu

On Nov 23, 2012, at 9:47 AM, Ryan Harrison wrote:

Dear Chimera team,

I've encountered a problem with atom.anisoU. Since class Atom is implemented in C++, and I don't have the technical sophistication or nerve to build chimera from scratch after the dire warning, [1] I seek council.

I'm using PDB ANISOU to store orientation information from a coarse grained model. Using PDB MODEL and PDB ENDMDL I output trajectory information. PDB atom coordinates and aniso change with each frame in the trajectory.

When visualizing a coordSet in the trajectory, atom.coord() updates as expected...
# m1 is a model with ANISO information
>>> m1.activeCoordSet = m1.coordSets[2]
>>> m1.atoms[1].coord()
chimera.Point(-0.268, 0.002, 0.08) # <~~~ As expected from PDB file
>>> m1.activeCoordSet = m1.coordSets[10]
>>> m1.atoms[1].coord()
chimera.Point(0.012, -0.276, -0.043) # <~~~ Changes as expected from PDB file

However, atom.anisoU does not update as expected [2, 3]. It is always the PDB ANISO information from the last model (last MD trajectory) in the file...
>>> m1.activeCoordSet = m1.coordSets[2]
>>> m1.atoms[1].anisoU # <~~~ ANISO for last model in PDB file, not model 2
array([[ 0.0296,  0.0182,  0.0201],
       [ 0.0182,  0.0844, -0.0055],
       [ 0.0201, -0.0055,  0.1258]], dtype=float32)
>>> m1.activeCoordSet = m1.coordSets[10]
>>> m1.atoms[1].anisoU # <~~~ Again, ANISO for last model in PDB file, not model 10
array([[ 0.0296,  0.0182,  0.0201],
       [ 0.0182,  0.0844, -0.0055],
       [ 0.0201, -0.0055,  0.1258]], dtype=float32)

The result is visualizations with proper coordinates (update properly for each frame in trajectory) but inaccurate ellipsoids (ANISO does not update; fixed as last frame / last model).

Work around 1 (Failed):
Since aniso takes spec atom-spec as an input, I tried specifying a model and position in trajectory. Unfortunately, this doesn't seem to be possible [4].

Work around 2 (Tedious):
Since aniso can take submodels, I import (cannot use nifty MD Movie tool) as sub-models instead of as a trajectory. I can then apply aniso to each submodel, which works as expected, and switch submodels on/off sequentially to make a movie (5). This is not ideal since I'm missing out on the ease of use of the MD Movie tool, and it's very cumbersome to move through a stack of submodels to emulate a trajectory.

Thank you for your time and please help!

Best,
Ryan