Google Drive Released

Today Google released a Dropbox competitor called Google Drive and is offering 5GB free storage with the possibility to update to more storage for prices much better then Dropbox.  I will test it out for syncing my Papers library and if it works I will consider switching.  I might be held back by the lack of an iPhone App and I have not seen if it is possible to encrypt easily folders on the google disk. With regards to cryo-EM it is cool to see that there is also an API so hopefully it will expoited by the googleCL project so we can have a python based method to interact with google drive so we can easily integrate it into the EMAN2/SPARX workflow.

Working Remotely with EMAN2 on OSX

I do a lot of work from home in the evening by working remotely. Normally this is not a problem as a lot of the image processing software that I use is command line based (i.e. SPARX and Spider). EMAN2 is a different story as, although, it does have all the command line options you need it does also have a beautiful GUI. The GUI in EMAN2 uses native Mac graphics and, therefore, cannot be exported over a SSH connection like X11 windows. However, OSX has a great screen sharing feature that allows you to share the screen of your remote Mac.  My firewall, however, blocks all inbound connections except SSH so a helpful tip is to tunnel you screen sharing connection (VNC) over ssh. To do this first activate screen sharing in the System Preferences of your remote Mac (in sharing panel). Then assuming you can ssh to the remote machine you just enter in the terminal of the local Mac: 

ssh -p PORT -L 5901:localhost:5900 -N -f -l username my.remote.machine

where:

PORT=your ssh port (22 is standard)
username = your username on the remote machine
my.remote.machine = host name or IP address of the remote machine

enter your password and then to activate the screen sharing just open your Safari browser and enter the following url:

vnc://localhost:5901

and the screen sharing sharing application should start automatically. Note in the above command the -f option puts the ssh command into the backgroud on the terminal.  Therefore to close the connection either let it time out or type:

ps ax | grep ssh 

and find the PID of the above command and kill it with:

kill PID

SPARX: data_n

In SPARX one useful feature is the creation of virtual stacks.  As defined on the EMAN2 wiki a virtual stack is a 'BDB stack with its own metadata, but the binary data taken from the (filtered) list of stacks'. Basically for SPARX this means that the virtual stack you create with the e2bdb.py command consist of only the metadata (i.e. parameters stored in the header like xform.projection, group, active, or ctf_applied ) while the images data is only linked to and remains in the original stack.  This is possible because the image data does not change (unless you apply the CTF to it) and, therefore, allows you to save disk space because the image data is kept only in one place.  One note of caution is that if you do apply CTF to the virtual stack it will alter the image data in the original stack and you will lose the non-filtered image data. In anycase I found virtual stacks to be a useful tool when I am doing a multi-reference based refinement and want to separate out specific groups to process them further.

For me the virtual stacks initially were a bit confusing because it meant that there was some book keeping involved in tracking which images in the virtual stack corresponded to which images in the original stack. This become more complicated if I made a virtual stack from an existing virtual stack.  However, I just realized that this is done automatically  if you used the command:

 e2bdb.py bdb:#stack --makevstack= bdb:#stack_new --list=list_of_projections

in the header a data_n attribute is created and this corresponds to the image position in the original stack. Therefore in the virtual stack there is always the information that can point you back to the original stack.  Also above I mentioned that I made virtual stacks from existing virtual stack but I don’t think this is the best way, basically it is more straight forward to always use the original stack as the input data for the e2bdb.py command.

Bad Project : Just for Fun

I thought this was just to true not to link to. I think we have all passed through a similar situation.

PyMOL: matrix_copy

One challenging aspect of aligning 70S structures is that generally the coordinates for the all components is divided between two separate PDB files each containing one of the two subunits (i.e. the 30S or 50S subunits).  In this sense it is easy to align the 50S subunit of one 70S ribosome to the 50S subunit of a second ribosome, or the 30S subunit of one 70S ribosome to the 30S subunit of a second ribosome. However, aligning the 30S and 50S separately like this does not necessarily faithfully reconstruct the 70S unit after the transformation of the individual subunits; as often the 30S moves relative to the 50S when ribosomes in different functional states are compared.  Therefore what you want to do is transform the entire 70S ribosome unit (30S and 50S subunits) based on the transformation matrix generated by aligning the 50S subunits of two 70S ribosomes.  The difficulty here is in getting the 30S to move along with the 50S.  Previously I used to deal with this by either merging the 30S and 50S subunits into a single PDB file, or object/selection in PyMOL.  This sometimes tended to make problems downstream because individual proteins/RNA chains would have duplicated chain identifiers.  

There is an easier way to do this however with the matrix_copy command in PyMOL.  PyMOLs documentation states this command ‘copies a transformation matrix from one object to another’. To use it you first align two 50S subunits using the align command, for example:

align 2xqe & c. A, 2wri & c. A

after which you simply copy the transformation matrix of the aligned object (2xqe in the above example) to the corresponding 30S subunit (2xqd  is the pdb file containing the 30S subunit corresponding to the 50S subunit in 2xqe):

matrix_copy 2xqe, 2xqd 

(the format for the command is: matrix_copy source_name, target_name)

The really cool thing is that matrix_copy does not only work on PDB files but can also be applied to density maps.  This means that if you have two un-aligned density maps that both have molecular models fitted to them you can align the maps by first aligning the molecular models (PDB files) with the align command and then copying the matrix of the aligned model the corresponding density map.