PCA-app, connectivity in view.xyz

[Lars Skjærven]

there are some issues with the protein connectivity when visualizing PCs and modes. see e.g. the normal modes of the default protein (4q21).

[Barry Grant]

I will add this to the list - just pushed improvements for view.pdb() that makes it much more robust and useful. I intend to do similar things to view.xyz() with Shashank help and connectivity. Thanks for posting here.

[Barry Grant]

Should note that I have not merged view.pdb() with feature_shiny yet as the app view.pdb() call may need slight adjustments.

[Barry Grant]

Note this should now be fixed by passing a larger d.cut value to view.xyz() or indeed other view family functions. This d.cut is used by calpha.connectivity() to set the upper limit on connected atoms. e.g.:

modes <- nma( read.pdb("4q21") )
m7 <- mktrj.nma(modes, mode=7)
view.xyz(m7, col=vec2color(rmsf(m7)))

view.xyz(m7, col=vec2color(rmsf(m7)), d.cut=9)

I am keeping this issue open as a reminder until we update the shiny pca-app code...

[Lars Skjærven]

Hmm.. the view.xyz function passes which frame to calpha.connectivity ? It probably uses frame 1 which is the one which is furthest extrapolated. Setting d.cut=9 might work, but I'm afraid it might connect atoms which shouldnt be connected.

Therefore I would like to do:

> trj <- mktrj(pc.xray, pc=1, rock=FALSE)
> con <- calpha.connectivity(as.xyz(trj[9,, drop=FALSE]), d.cut=5)
> view.xyz(trj, con=con)
Error: formal argument "con" matched by multiple actual arguments

Here the use of frame 9 ensures that non extrapolated coordinates are used.

I have a solution for the "multiple actual arguments" in the nma set of functions. e.g. by using something in the direction of:

bh.names <- names(formals( build.hessian ))

dots <- list(...)
bh.args <- dots[names(dots) %in% bh.names]

do.call('build.hessian', c(list(xyz), bh.args))

It's a bit of a hassle, so perhaps another solution would be to give a frame index as arugment somewhere? sor that con = calpha.connect(trj[ind, ])

[Barry Grant]

Thank Lars. I will look into this more, but just to note quickly that the way calpha.connectivity() works attempts to minimize the spurious connection problem in that it will never connect non sequential calpha atoms.

The d.cut=9 above was just a silly extreme example and in reality it should be somewhere between 3.8 and 5. However, I wanted to demo that you can try d.cut=100 in the example and everything still looks great, e.g.

view(m7, col=vec2color(rmsf(m7)), d.cut=100)

Obviously, if there were gaps that were less than d.cut apart then we would connect them and this is after all the purpose of d.cut here.

To answer your question on which fame is passed to connectivity() (and onward to calpha.connectivity() if appropriate): it is the first frame if no gaps are present otherwise we calculate it for every frame. The later is important for pdbs$xyz for example. So for nma and pca results it is just the first frame. If we make view methods for nma and pca type objects I guess we could try to figure out the average frame and use this - good idea?

I will look into the "multiple actual arguments" issue, which for 'con' is a bit more complicated as view.xyz() in its current form likely still calculates connectivity even though this arg was passed in dots so hence the duplicate. So the fix is probably a bit of checking and the exclusion of calls to connectivity()

One related new thing here, that might be useful more generally, is the arg.filter() function within view.pdb() and view.xyz(). This little utility function attempts to be useful for sensibly passing dots to multiple (sub)function calls within a function without having to explicitly check on all arguments - particularly if you want to reset a (sub)function calls default args only when the user has not included this argument within dots.

Basically, arg.filter() builds on your nma function example above and allows the optional re-setting of default function parms if not explicitly requested in dots, which was the issue I was facing here with a number of these calls with different visualization styles etc.

[Barry Grant]

Resolved, opened a separate issue for the con multiple args bug

[Lars Skjærven]

Thanks! This looks good Barry. I've added d.cut = 6 to the pca-app for now. Looks much better now. For the nma and pca functions the middle frame created by mktrj(rock=FALSE) will be the non-extrapolated one so one could just use that one instead of averaging (if I'm not misunderstanding something here).

Thanks for the tip on arg.filter. Will keep this in mind and possibly update the nma functions with this.