[chimera-dev] Linking Chimera with our molecular simulation tool-kit

[Eric Pettersen]

> On Oct 22, 2015, at 8:07 AM, Lianheng Tong <lianheng.tong at kcl.ac.uk> wrote:
> 
> Hi Eric,
> 
> Thank you very much for your prompt reply and help.
> 
> In terms of the interface, sorry for not have been very clear earlier. There are actually two code packages in question:
> 
> 1.  CP2K:  the main molecular dynamics simulation code
> 2.  tetr:  a tool that is used to construct and modify initial atomic structures which are used as inputs for CP2K.
> 
> The initial plan is to first link Chimera with tetr.  So that any geometry construction and manipulation can be viewed in real-time within the Chimera window, and any atomic selections within Chimera is automatically passed into tetr.  In this case the communication between tetr and Chimera ideally should be continuous, or at least, auto update every 1 second intervals.  So any more information on how I may achieve this will be of great help.
> 
> One way I am currently thinking of doing is to modify tetr into a library package—which shouldn’t be too difficult, and would benefit future use of the code anyway---and then build a python interface for it. This way, the interactive prompt can be built directly into the Chimera extension, and I won’t have to worry about doing continuous communications between Chimera and tetr.

There are a lot of upsides to the library approach, but one tricky part is compiling your library in such a way that Chimera will be able to dynamically load it on the various versions of each OS (that you support) that users will have.  You may have to use the same compiler and compiler version that Chimera uses, possibly along with various other settings.  We would certainly help out if you go that route.

Another option is to use Chimera as the “back end” to tetr.  You would have tetr start Chimera along with Chimera’s REST interface (by supplying the shell args “—start RESTServer”) and examine Chimera's startup output for the port to contact the REST server on.  REST communication is limited to normal Chimera commands, not Python, but you will receive notifications of models opening and closing, and changes in the selection.  The “list” command can be used to list currently open models, the contents of the current selection, and a variety of other things.  My guess is that being limited to the normal Chimera command set will not quite cut it for you, but I could be wrong.  The documentation for RESTServer is here:

http://www.cgl.ucsf.edu/chimera/current/docs/ContributedSoftware/restserver/restserver.html <http://www.cgl.ucsf.edu/chimera/current/docs/ContributedSoftware/restserver/restserver.html>

My best guess as what the best option in your scenario is, is that you basically use the one-shot case but don’t close the Popen to the backend tetr process.  Something in tetr’s output would need to mark that the output for a given command is complete (or the extension would have to know what, if anything, it cares about in the output and only read that far).  When another command needs to go to tetr, it’s just added to the Popen stdin, and then the output examined again for whatever info is desired, etc. 

> -------------
> 
> Now that you have mentioned CP2K,  I think it is also a very nice idea to may be link Chimera with CP2K, like the way Amber executables are linked. This way, full density functional theory calculations may be performed directly within Chimera window, and this would allow quantum mechanical geometry relaxations, viewing ground state electron charge densities, generate STM images etc, without the user having to leave Chimera.  In this case, I think the way one can achieve this is to:
> 
> 1. Using the tetr interface to generate an input file for CP2K calculation
> 2. Use Chimera to run CP2K in a standard Linux shell, with however number of processors defined by the user
> 3. After CP2K has finished execution, read in the relevant output from CP2K back into Chimera, for example, the xmol movie file for geometry relaxation, molecular dynamics, or electronic density files etc.
> 4. Chimera can then visualise those data in the normal way
> 
> In other words, it will be a one-shot or several-shot execution, and continuous interaction between Chimera and CP2K won’t be required.
> 
> Nevertheless, I think it makes sense for me to do this after the tetr interface.

I don’t know how long CP2K computations typically take, but if they typically take more than a minute you may need to run them in a separate thread, or via Chimera’s task manager, the latter of which would allow the user to quit Chimera and still keep running CP2K (or even save a session and come back later).

> -------------
> 
> tetr is a freeware and open source, and CP2K is an open source code with GPL license (http://www.cp2k.org).  I hope there won’t be any licensing issues I need to be careful about?

Our interpretation of GPL and GPL-like licenses is that if the software is a library that Chimera has to link against, even dynamically, then GPL would also apply to Chimera itself, which would be problematic (though LGPL would be okay).  If the software is a standalone executable that Chimera communicates with via interprocess communication, then the GPL license applies to just the standalone software (so source code for such executables would have to be openly available).  All this applies only to software we ship with Chimera.  Software/extensions provided by third parties on their own would not affect Chimera proper in any way.

> -------------
> 
> I am sure I will have many questions to ask you and other developers when I start working on the tetr interface.

Yep! :-)

—Eric


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://plato.cgl.ucsf.edu/pipermail/chimera-dev/attachments/20151022/7bfdd6f4/attachment.html>