Support of 'enma' in view.modes()

[Xinqiu Yao]

It would be great if we can easily inspect the mode vectors obtained from one particular structure in the results of ensemble NMA. Current function view.modes() only supports input of 'pca' and 'nma' class. Can we have it to support 'enma', too, or do we already have such a function? A possible update could have a style like:

view.modes(modes, ind=10, pdb=pdb, mode=7, ...)

Does it make sense?

[Lars Skjærven]

Jepp. We have mktrj.enma() to generate a trajectory, so an equivalent view.modes() would be nice yes.

How about renaming this to view.nma(), view.pca(), view.enma() etc etc. ?

[Barry Grant]

Also can we have the returned coordinates from the various mktrj.() functions be of class "xyz" please. This will make the rgl based view.() functions life easier.

Please do not rename any of these pymol or vmd functions to view.class() as these already exist on the feature_visualize_dataframe that will soon get some love and be integrated for the next release.

[Xinqiu Yao]

I think current name view.modes is fine. We just need to have a check of input 'modes' and if is 'enma', create a tmp simplified 'nma' object with U and pdb or xyz components only. What do you think?

[Lars Skjærven]

but you will need some additional input arguments. e.g. both mode inds and structure inds.

[Xinqiu Yao]

Right. What about using ind as argument for structure ind and mode the mode ind, as shown above? Both default values can be set to NULL. A little bit long list but should work fine...

[Lars Skjærven]

I think a separate function would make more sense in this case. It's also good for keeping the code tidy. I see the point with the name crash with the visualize branch that Barry pointed out. So if we reserve view.class for the RGL stuff, can we use something else for these pymol functions? how about just pymol.class (pymol.dccm, pymol.nma, pymol.pca, pymol.enma ....) ? ugh

[Xinqiu Yao]

That's going to be inconsistent with e.g. view.cna() and view.cnapath(), which launch VMD... If we do separate these functions, it is better to keep the generic name view. I think it does not conflict with "view" functions in visualize branch, does it? In master, we don't define 'generic function' and so each 'view.nma', 'view.dccm', 'view.enma', etc. is individual function. When visualize branch is merged, these functions become methods of view() automatically.

Also, we could potentially update all view. functions to use internal RGL engine in future, so making their names consistent for now would be good. Sensible?

[Lars Skjærven]

Ok. I agree. So to list all, that would be

• pymol related: view.nma, view.enma, view.pca, view.dccm
• cna related: view.cna, view.cnapath,
• RGL related: view.pdb,

would this make it difficult for the RGL stuff ?

[Barry Grant]

Yes this would make it difficult.

There is great value in some of these existing pymol and vmd functions and they should be maintained. However, it is my intention with the view() family of functions to not rely on vmd and pymol but rather use rgl(), or whatever new technology comes along in the future, within R itself to get a quick and insightful 3D view of whatever data would prove useful.

These view functions will not replace in-depth and highly functional molecular viewers that should be launched seperately (i.e. not tie up an interactive R/bio3d session). We currently have view.pdb(), view.xyz(), view.pdbs() and view.cna() that already cover most of these cases. For example NMA and PCA output can be viewed with view.xyz() after calling mktrj().

Lars suggestion of vmd.cna(), pymol.nma() is my preference for going forward.

[Lars Skjærven]

Alright. This makes sense too. So then:

• pymol.nma, pymol.enma, pymol.pca, pymol.dccm
• vmd.cna, vmd.cnapath,
• view.pdb, view.xyz, view.nma, etc

[Xinqiu Yao]

Okay, it works fine to me, too. Let's mark it as To do task.

[Xinqiu Yao]

This will include several function name changes and so better be put in a major release.