Posts Tagged ‘Java’

3D-rendered molecular models on this blog: an update.

Thursday, January 16th, 2014

So much to do, so little time to do it. That is my excuse at least. Right from my first post on this blog in 2008 I have tried to enhance it using Jmol, a Java-based applet (normally indicated with the caption Click for 3D). This has been pretty stable for some five years now, but a recent spate of security-based releases of the JRE (Java runtime environment) for desktop computers has impacted, the latest of which was released yesterday (Java 7, V 51).  Put simply, when I started, an unsigned applet was fine. Now to run, it can only be a properly signed applet. Fortunately, there are two solutions:

  1. Install such a signed applet, and then invoke it correctly
  2. Replace the use of Java applets with one not dependent on Java. In the last 18 months an amazing effort to do this has resulted in  JSmol, which uses only JavaScript (which has nothing to do with Java despite the name).

I will shortly start the process of implementing solution 2 on this blog. Meanwhile I have started to implement solution 1 (which has the advantage that many of the surfaces I have included here, such as orbitals or NCI analyses, will render very much more quickly than with  JSmol). It involves replacing all instances of

jmolInitialize(‘../Jmol/’,'JmolApplet.jar’);

or

jmolInitialize(‘../Jmol/’,'JmolAppletSigned0.jar’);

with

jmolInitialize(‘../Jmol/’,'JmolAppletSigned.jar’);

I have identified 935 such instances, and am pondering how to automate this. Meanwhile, if you have a particular page which you would like to be processed quickly, do please get in touch.


PS. This is a classic (ugly) hack, but it might save me time. I uploaded JmolAppletSigned.jar V 14.0.5 and renamed it JmolApplet.jar (having moved the old one). Then I made one change to the script that invokes it (Jmol.js), changing the instance of "JmolAppletSigned" : "JmolApplet") + "0.jar"); to "JmolAppletSigned" : "JmolApplet") + ".jar");. Sorry to spill the guts of this blog onto this page, but one does occasionally need to tinker under the hood, and it might be of interest to anyone else trying to do this. Meanwhile, there are instructions here on how to install JSmol.

Publishing a procedure with a doi.

Wednesday, October 2nd, 2013

In the two-publisher model I proposed a post or so back, I showed an example of how data can be incorporated (transcluded) into the story narrative of a scientific article, with both that story and the data each having their own independently citable reference (using a doi for the citation). Here I take it a step further, by publishing a functional procedure in a digital repository[1] and assigned its own doi:10.6084/m9.figshare.811862.

The following HTML

<iframe src="http://wl.figshare.com/articles/811862/embed?show_title=1" height="443" width="500" frameborder="0"></iframe>

can then be incorporated into any Web page, including this post, to invoke the service. What does this do? It takes a pre-prepared Gaussian-style cube file containing values of the electron density of a molecule, and converts this into non-covalent-interaction (NCI) isosurfaces[2] (as described here). Two new two files, a .xyz coordinate file and a .jvxl isosurface file (see here for an example of its application) are written to the user’s local file space. These files in turn can be integrated into an interactive data presentation and this new object can have a doi.

So now we see how unique identifiers can be used with a digital repository to:

  1. Publish a data calculation and assign it a doi
  2. A script or procedure (as a Web Service) to convert the preceding data can itself be published and assigned a doi
  3. Step two is then invoked using that doi, and the output(s) can be also be raw into a digital repository, or wrapped beforehand in some manner to produce a visual presentation of this new data before being assigned a doi
  4. All three components, if needed, can now be cited in a narrative article describing the science, and this too of course may (after peer review) also receive its own doi
  5. The first three components can, if needed, be transcluded into the fourth to create the final composite appearing in the journal (or blog post as here). 

So below is this service. You can either use it here, or simply resolve the doi above into a separate web page. This version uses Java, and so you have to be prepared to answer questions about security etc. An alternative version not using Java (based on JSmol) is probably too slow; sometimes the procedure has to convert 300+ Mbytes of Gaussian cube, and take about 30 seconds to do so.

At any rate, if you have read any of my posts which show NCI isosurfaces, and wondered how to do it for yourself, here is your chance!

References

  1. H.S. Rzepa, "Script for creating an NCI surface as a JVXL compressed file from a (Gaussian) cube of total electron density", 2013. https://doi.org/10.6084/m9.figshare.811862
  2. E.R. Johnson, S. Keinan, P. Mori-Sánchez, J. Contreras-García, A.J. Cohen, and W. Yang, "Revealing Noncovalent Interactions", Journal of the American Chemical Society, vol. 132, pp. 6498-6506, 2010. https://doi.org/10.1021/ja100936w

The blog post as a scientific article: citation management

Monday, February 27th, 2012

Sometimes, as a break from describing chemistry, I take to describing the (chemical/scientific) creations behind the (WordPress) blog system. It is fascinating how there do seem increasing signs of convergence between the blog post and the journal article. Perhaps prompted by transclusion of tools such as Jmol and LaTex into Wikis and blogs, I list the following interesting developments in both genres.

  1. Improved equation display for Chemistry Central articles using MathJax  This is a way of rendering equations in the pages of both a Blog  and a journal article. This blog is now so empowered, although in fact I employ few equations on these pages.
  2. Citation management and meta-data gathering. This blog plugin takes the form of a numbered citation[1] as here, and which converts the specified DOI to a listing at the bottom of the post in the manner of a conventional scientific article (conventional document citation managers such as EndNote do this as well). It is actually much more than that, since the plugin automatically uses the CrossRef API to retrieve metadata for the quoted Digital Object Identifier (DOI), thus enhancing the metadata associated with the post and its discoverability. Dublin-Core is already present in the post as well as FOAF output, and I occasionally trawl using the Calais archive tagger (although this is not very good at finding chemistry tags).
  3. I installed Chemicalize a year or so ago. This scans the blog text for chemical terms, and adds a hover/popup image of structures it identifies (it is also responsible for the occasional doubled Gravatar image you may see here! Apologies!).
  4. I noted the addition of ChemDoodle to this blog previously. There may be newcomers which I need to track down to this type of non-Java based molecular rendering.

So you can see that building a chemical/science-savvy blog can be great fun! It is also significant that science/chemistry publishers are starting to do this. I bring only one example to your attention, although this introduces a host of other issues that perhaps I should leave for another post.

References

  1. H.S. Rzepa, "The past, present and future of Scientific discourse", Journal of Cheminformatics, vol. 3, 2011. https://doi.org/10.1186/1758-2946-3-46

Mobile-friendly solutions for viewing (WordPress) Blogs with embedded 3D molecular coordinates.

Sunday, December 11th, 2011

My very first post on this blog, in 2008, was to describe how Jmol could be used to illustrate chemical themes by adding 3D models to posts. Many of my subsequent efforts have indeed invoked Jmol. I thought I might review progress since then, with a particular focus on using the new generations of mobile device that have subsequently emerged.

  1. Jmol is based on Java, which has been adopted by Google’s Android mobile operating system, but not by Apple’s IOS.
    • An Android version of Jmol was recently released, to rave reviews! I do not know however whether the Jmol on these posts can be viewed via Android. Perhaps someone can post a comment here on that aspect?
    • HP has just announced it will open source WebOS, but it seems Java will not be supported so probably no Jmol there then.
    • Windows 8 Mobile (Metro) also seems unlikely to support it either.
  2. Apple has been prominent in touting HTML5 as a Java replacement. In practice, this means that any molecular viewer would be based on a combination of Javascript and WebGL technologies.  Whereas Java is a compiled language, Javascript is interpreted on-the-fly by the browser. Its viability has been greatly increased by very large improvements in the speeds that browsers interpret Javascript nowadays, but this speed is unlikely to ever match that of Java. The real issue is whether that matters. The other difference is that whereas a signed Java applet allows data to escape from the security Sandbox (and into eg a file system), Javascript is likely to be much more restrictive. These two properties mean that Javascript/HTML5 implementations make a lot of use of server-side functionality; in other words a lot of bytes may have to flow between server and mobile device to achieve a desired effect (and the user may have to pay for these bytes via their data plan).
    • One early adopter of the Javascript/WebGL HTML5 model has been ChemDoodle, which I illustrated on this blog about a year ago. I have tidied up the recipe for invoking it since then, and this is given below for anyone interested in implementing it. As of this moment, one essential component, WebGL, is only available to developers of Apple’s IOS system, but I expect this to become generally available soon. When that happens, ChemDoodle components on this blog will start working.
    • A new entrant is GLmol, an open source molecular viewer for Apple’s IOS. A version is also available for Android. I may give a try at embedding this into the blog.
It seems that the 3D molecular viewing options are certainly increasing, but at the moment there is some uncertainty in performance, compatibility and the ability to extract molecular data from the “sandboxes“. This last comment relates to the re-usability of data, which I particularly value.

Although this post has focussed on embedding and rendering molecular data into a blog post, the same principle in fact applies to other expressions. Perhaps the most interesting is the epub3 e-book format, which also supports Javascript/HTML5, and which seems likely to be adopted for future interactive e-books. Indeed, it should be possible to fully convert an interactive blog created using this technology to a e-book with relatively little effort. I have also illustrated here how lecture notes can be so converted.

If you get the impression that the task of a modern communicator of science and chemistry is not merely that of penning well chosen words to describe their topic, but of having to program their effort, then you may not be mistaken.


Procedure for creating a 3D model in a WordPress blog post using ChemDoodle.

  1. As administrator, go to
    wp-content/themes/default

    (or whatever theme you use) and in the file header.php, paste the following

    <link rel="stylesheet" href="../ChemDoodle/ChemDoodleWeb.css" type="text/css">
      <script type="text/javascript" src="../ChemDoodle/ChemDoodleWeb-libs.js"></script>
      <script type="text/javascript" src="../ChemDoodle/ChemDoodleWeb.js"></script>
       <script type="text/javascript" language="JavaScript">
      function httpGet(theUrl)
       {var xmlHttp = null;
       xmlHttp = new XMLHttpRequest();
       xmlHttp.open( "GET", theUrl, false );
       xmlHttp.send( );
       return xmlHttp.responseText;}
       </script>
  2. From here, get the ChemDoodle components and put them into the directory immediately above the WordPress installation. They are there referenced by the path ../ChemDoodle as in the script above. You can put the folder elsewhere if you modify the path in the script accordingly.
  3. Invoke an instance of a molecule thus;
    <script type="text/javascript">// <![CDATA[
    var transformBallAndStick2 = new ChemDoodle.TransformCanvas3D('transformBallAndStick2', 190, 190);transformBallAndStick2.specs.set3DRepresentation('Ball and Stick');         transformBallAndStick2.specs.backgroundColor = 'white';var molFile = httpGet( 'wp-content/uploads/2011/12/85-trans.mol' );var molecule = ChemDoodle.readMOL(molFile, 2);         transformBallAndStick2.loadMolecule(molecule);
    // ]]></script>
  4. The key requirement is that the body of the script (starting with var) must not contain any line breaks; it must be a single wide line. So that you can see the whole line here, I show it in wrapped form (which you must not use);
    var transformBallAndStick2 = new
    ChemDoodle.TransformCanvas3D('
    transformBallAndStick2', 190,
    190);transformBallAndStick2.specs.
    set3DRepresentation('Ball and Stick');
    transformBallAndStick2.specs.
    backgroundColor = 'white';var molFile =
    httpGet('wp-content/uploads/2011/12/85-trans.mol');
    var molecule =ChemDoodle.readMOL(molFile, 2);
    transformBallAndStick2.loadMolecule(molecule);
  5. The key data will be located in the path wp-content/uploads/2011/12/85-trans.mol which you should upload. Note that only the MDL molfile is supported in this mode (which makes no server-side requests). One can use eg CML, but this must be as a server request.
  6. If you want multiple instances, then you must change each occurrence of the name of the variable, e.g. transformBallAndStick2 to be unique for each.
  7. If you want to annotate the resulting display, server-side requests are again needed. I do not illustrate these here, but there is an excellent tutorial.

Science publishers (and authors) please take note.

Monday, October 24th, 2011

I have for perhaps the last 25 years been urging publishers to recognise how science publishing could and should change. My latest thoughts are published in an article entitled “The past, present and future of Scientific discourse” (DOI: 10.1186/1758-2946-3-46). Here I take two articles, one published 58 years ago and one published last year, and attempt to reinvent some aspects. You can see the result for yourself (since this journal is laudably open access, and you will not need a subscription). The article is part of a special issue, arising from a one day symposium held in January 2011 entitled “Visions of a Semantic Molecular Future” in celebration of Peter Murray-Rust’s contributions over that period (go read all 15 articles on that theme in fact!).

Here I want to note just two features, which I have also striven to incorporate into many of the posts this blog (which in one small regard I have attempted to formulate as an experimental test-bed for publishing innovations). Scalable-Vector-Graphics (SVG) emerged around the turn of the millennium as a sort of HTML for images. To my knowledge, no science publisher has yet made it an intrinsic part of their publishing process (although gratifyingly all modern browsers support at least a sub-set of the format). Until now (perhaps). Thus 10.1186/1758-2946-3-46 contains diagrams in SVG, but you will need to avoid the Acrobat version, and go straight to the HTML version to see them. However, what sparked my noting all of this here was the recent announcement by Amazon that they are adopting a new format for their e-books, which they call Kindle Format 8 or KF8 (the successor to their Mobi7 format). To quote: “Technical and engineering books are created more efficiently with Cascading Style Sheet 3 formatting, nested tables, boxed elements and Scalable Vector Graphics“. This is wrapped in HTML5 to be able to provide (inter alia) a rich interactive experience for the reader. In fairness, there is also the more open epub3 which strives for the same. Other features of HTML5 include embedded chemistry using WebGL and the same mechanisms are being used for the construction of modern chemical structure drawing packages.

It remains to be seen how much of all of this will be adopted by mainstream chemistry publishers. Here, we do get into something of a cyclic argument. I suspect the publishers will argue that few of the authors that contribute to their journals will send them copy in any of these new formats and that it would be too expensive for them to re-engineer these articles with little or no help from such authors. The chemistry researchers who do the writing (perhaps composition might be a better word?) might argue there is little point in adopting innovative formats if the publishers do not accept them (I will point out that my injection of SVG into the above article did have some teething problems). For example, you will not find SVG noted in any of the “instructions for authors” in most “high impact journals” (or, come to that, HTML5).

If one looks at the 25 year old period, in 1986 all chemistry journals were distributed exclusively on paper. My office shelves still show the scars of bearing the weight of all that paper. Move on 25 years, and all journals almost without exception are now distributed electronically. I suspect the outcome in many a reader’s hands is simply that they (rather than the publisher) now bear the printing costs themselves (despite or perhaps because of the introduction of electronic binders such as Mendeley). But it will only be when the article itself grows out of its printable constraints, and hops onto mobile devices such as Kindles and iPads in the promised (scientifically) interactive and data-rich form, that the true revolution will start taking place.

A final observation: you will not readily obtain the interactive features of 10.1186/1758-2946-3-46 on e.g. an iPad or Kindle because the Java-based Jmol is not supported on either. But Jmol has now been ported to Android, and its certainly one to watch.

Embedding molecules in blogs: ChemDoodle, WebGL and SVG

Friday, December 24th, 2010

If you get a small rotatable molecule below, then ChemDoodle/HTML5/WebGL is working. Why might this be important? Well, the future is mobile, in other words, devices that rely on batteries or other sources of built-in power. This means the power guzzling GPU cards of the past (some reach ~400 Watts!) cannot be used. Rather than using e.g. a full power OpenGL library, one will use Web-based graphics libraries, which (to quote Wikipedia) extends the capability of the JavaScript programming language to allow it to generate interactive 3D graphics within any compatible web browser. A typical target device might be for example Apple’s iPad (for which the redoubtable Jmol, which is based on Java, is unlikely to ever work).

To find out if your device and its browser can support this type of graphical display, go to either this test page or this more general one (which at the time of writing actually gets the WebGL test wrong!).

I have deployed an earlier graphical methodology in other posts (SVG), which many browsers now support. This combination of HTML5, SVG and WebGL is the future! For its use on another blog, see here.