Pymol-remote support for biotite's AtomArray's

[Croydon-Brixton]

Hi @padix-key ,
I was wondering whether support for viewing AtomArray's in pymol-remote would be something that's of interest? (Disclaimer: I'm the developer)

In a nutshell, I envision being able to send AtomArray's from code to a pymol session or receiving a state as AtomArray from pymol. Maniupulation in either of the two (biotite/pymol) could then be transferred to the other. That pymol session may be running on the same machine, or it may run on a remote machine (e.g. in the setup where code is run on a cluster, say a university hpc or cloud provider and pymol is run locally on a laptop).

There may be a way to integrate ammolite nicely too.

This could be made an optional dependency (like dssp is for example). Luckily pymol-remote itself has no dependencies other than python built-in s, so would be very easy to integrate.

[padix-key]

There is currently a discussion about integrating Ammolite into Biotite (#709). Ammolite also handles the conversion from AtomArray to PyMOL objects, so this functionality is actually existing. So in my opinion the question is how do we tell Ammolite (or the potentially upcoming biotite.interface.pymol) not to run a PyMOL command locally, but to defer it to pymol-remote.PymolSession.do(). A potential solution would be some additional intermediate PyMOLCaller layer (name is WIP, I just made it up 😉) that can be overriden to inject pymol-remote in this place.

I can get back to you when I have the bandwidth to migrate Ammolite to Biotite, so we can align on this topic to find an elegant solution.

[Croydon-Brixton]

That sounds good to me! Thank you for the update :)

[padix-key]

The new PyMOL interface is almost done: #749. As next step I will test a few ideas using pymol-remote.

[padix-key]

Here are my findings:

The intermediate layer mentioned above already implicitly exists - it is pymol.cmd:
In all relevant places commands in biotite.interface.pymol are run using pymol.cmd, where pymol may either be the module itself (for an interactive session) or a PyMOL object (library mode) (see startup.py for further details). In case of pymol-remote PymolSession could offer a cmd attribute as well. This means for example PymolSession.cmd.show("sticks") would actually call PymolSession.do("show sticks").

Then PymolSession would only need to be passed to biotite.interface.pymol.get_and_set_pymol_instance() and it should work out of the box.

The most challenging part would probably be transferring AtomArray to the remote PyMOL session. Currently biotite.interface.pymol creates a chempy model (https://github.com/schrodinger/pymol-open-source/blob/27c28cb4b3a7590895437c15c428784b5b455125/modules/chempy/models.py#L134) from an AtomArray and loads it in PyMOL via cmd.load_model().
Luckily a chempy model can be pickled to ship it to the remote PyMOL session:

import biotite.interface.pymol as pymol_interface
import biotite.structure.info as info
import pickle

molecule = info.residue("NAD")
model = pymol_interface.to_model(molecule)
data = pickle.dumps(model)

model = pickle.loads(data)
molecule = pymol_interface.from_model(model)

However, this would mean that PymolSession.cmd.load_model() would need

1. to transfer the pickled chempy to the remote PyMOL session,
2. unpack it there and
3. call load_model on the chempy model, which in contrast to other PyMOL commands cannot be represented as string.

[padix-key]

By the way, I really like that pymol-remote allows communicating with an interactive PyMOL session and how well it works. Currently even if you run biotite.interface.pymol.launch_interactive_pymol(), the session only becomes interactive after all commands have already been run. Not to mention the issues interactive PyMOL has when run from a Python script (see https://github.com/biotite-dev/biotite/blob/55aab440195db9a2a1ea952ce0b2237d3eb4609a/src/biotite/interface/pymol/__init__.py).
So I think pymol-remote would have a real benefit here.