PRESS RELEASE

BioTeam Launches MiniLIMS^TM for Ion Torrent PGM Sequencer

Marco Island, FL, February 15, 2012 – BioTeam Inc. announces the availability of BioTeam MiniLIMS for Ion Torrent Personal Genome Machine (PGM). MiniLIMS is a powerful Web-based Laboratory Information Management System (LIMS) built for scientists who want a cost-effective solution that is fast, simple and flexible.  MiniLIMS will be available for direct purchase through Life Technologies WebStore after March 15, 2012.

MiniLIMS is the first independent software solution to connect directly to the Ion Torrent Server. Tight integration permits automated data transfer, speeds data processing, and eliminates many sources of error. MiniLIMS captures NGS workflow processes including sample receipt, sample prep, planned experiments, and results viewing. This agreement expands the Life Technologies-BioTeam collaboration. BioTeam provides extended service and support for the Ion Torrent Server and Suite Software.

“The BioTeam has demonstrated market-leading knowledge of the Torrent Suite Software, that drives primary analysis of semiconductor sequencing, through their extensive work on both the Ion Torrent Grand Challenges and Torrent Server support services.  Their practical working knowledge of the underpinnings of the Ion Torrent software makes them a strong choice to consider when choosing a LIMS partner, “said Mike Lelivelt, Director of Bioinformatics and Software Products, Ion Torrent

“Effective data management is an ongoing challenge for NGS users with many still using spreadsheets. MiniLIMS helps PGM users quickly gain improved control of their NGS data and derive more value from their NGS-based activities,” said Stan Gloss, Managing Director, BioTeam.

Among MiniLIMS’ core capabilities are:

• Simplified Data Entry. Customize data entry and display – without programming – to exactly match your samples, reagents, workflows, and instruments. Data stored in spreadsheets can be quickly and easily uploaded.

• Automatic Loading of PGM Data. Data is imported from the PGM into MiniLIMS automatically, hyperlinking all the sample, run, and preparation details. Upload your own files, putting all the data you need in one place.

• Powerful Report Generation. Create custom reports to see the state of your experiments at any time; there are pages that show the history of all data in the system.

The new MiniLIMS Ion Torrent plugin extends MiniLIMS to work with PGM data. Round trip data management allows scientists to plan experiments from MiniLIMS and see results from the PGM load automatically. MiniLIMS can alert users when data appears or pages change. Routine experiments can be configured using templates so a new run can be setup with a few keystrokes. Results can be delivered to users using the same project and sample overview pages that support Bioanalyzer, Nanodrop, or other lab processes. A graphical overview provides a snapshot of recent runs and analyses.

To see the most recent screenshots of MiniLIMS for PGM visit:

http://biote.am/73

About BioTeam

BioTeam is a high performance consultancy, serving the needs of the life sciences community since 2002. Our expertise includes cluster computing, large scale data storage, cloud computing, and semantic LIMS development. For more information, please visit http://bioteam.net

A case study in transferring a life sciences IT infrastructure fully into the cloud

“Over the past few years, many life science organizations have dabbled in cloud computing and explored infrastructure-as-a-service, with varying degrees of enthusiasm and commitment. But one Connecticut company has decided to go for broke—transferring its entire IT infrastructure onto the Amazon cloud.   “

If you’ve been following my previous posts about the PHP API (starting here) you know a little bit about how MiniLIMS is exchanging data with the Torrent Server via the nicely designed RESTful JSON interface. What I’d like to show you here is how that data exchange is materializing in the MiniLIMS plugin.

First, I want to show you really quickly how you install the Ion Torrent plugin (assuming you have MiniLIMS installed at /var/www/minilims):

$ cd /var/www/minilims/plugins
$ sudo cp ~/Downloads/IonTorrent.tar.gz .
$ tar xzvf IonTorrent.tar.gz

That’s it. Using the runtime integration capabilities of PHP, the Ion Torrent plugin will be loaded the next time you access a MiniLIMS page.

Our 1.0 plugin release isn’t particularly glitzy, but it takes advantage of the Torrent Server API to provide some of the key things that our early users have been interested in: planned experiment posting; run and report retrieval; instrument status; and file and quality results delivery.

Planned experiments are a nice facility provided by the Torrent Server that allows you to define a PGM run outside of the tiny console on the instrument itself. By setting them up in MiniLIMS and posting to the Torrent Server, you can maintain data integrity by selecting predefined Sample and Project records.

A PGM Planned Experiment in MiniLIMS

Once saved, the Planned Experiment can be posted to the Torrent Server and, therefore, selected from the console.

As most lab scientists will attest to, the same basic experiment is run repeatedly with just a different sample and/or project. PGM Planned Experiments can be saved as PGM Experiment Templates that can be reused for common experiment types. When creating a new planned experiment, just chose a template from the available list and your form will be populated with it’s values.

Like the Illumina and Roche 454 MiniLIMS plugins, the Ion Torrent offering features a run loader. The Ion Torrent run loader retrieves Experiments (runs), Results (reports), Quality Metrics and Lib Metrics from the Torrent Server. As described in the previous postings, the data types closely follow the API arrangement. Data can either be retrieved via the regular cron job or by using the “Refresh data” button on the Torrent Server page.

Torrent Server analysis result with link back to the Torrent Browser

MiniLIMS also provides lab personnel with a quick overview of the state of the instrument run and analysis based on the data from the most recent run. FTP status of the run and status of the currently running report (if there is one) is shown along with a list of the most recent runs and results.

Instrument overview showing status and recent results

End user results delivery is also made simpler by MiniLIMS. MiniLIMS projects, typically used to group user Samples, now include a summary of the results associated with your project. The summary has just about everything a discerning scientist would need: links to FASTQ and SFF files (zipped versions), drill-down links to full PGM Experiment and PGM Result pages, the full analysis reports on the Torrent Server and q17 and q20 read numbers.

MiniLIMS Project with PGM results table. More file links and q17/q20 results are available off page.

Remember when looking at these examples of the PGM plugin pages that MiniLIMS is end-user configurable. Though the data types used to supply a table result like the one above are fixed, specific columns can be added or removed, filters and sorting can be applied and new properties can be added to the Project definition to match your lab workflow.

Those are pretty much the key elements of the 1.0 plugin. We expect to have a couple more releases this year as MiniLIMS grows and we incorporate feedback from customers. If you’re going to AGBT, come find us.

In 2012 BioTeam will be offering two different classes – our popular “Fundamentals: Amazon Web Services for Science & Engineering” class along with a new 1-day course on practical systems and cloud orchestration that we are calling “Cloud Orchestration with Opscode Chef ”

Classes, dates and locations are as follows:

• (CANCELLED) Friday March 9, 2012:  Cloud Orchestration (in conjunction with XGen Conference & Expo in San Diego, CA USA)
• Sunday & Monday April 22-23, 2012 – AWS for Science & Engineering (in conjunction with BioITWorld in Boston, MA USA)
• April 27, 2012, Friday – Cloud Orchestration (in conjunction with BioITWorld in Boston, MA USA)
• May 18-19, 2012, Friday & Saturday – AWS for Science & Engineering (in conjunction with Biomarker World Congress, Philadelphia, PA USA)
• May 20, 2012, Sunday – Cloud Orchestration (in conjunction with Biomarker World Congress, Philadelphia, PA USA)
• June 14-15, 2012 – Thursday – Friday AWS for Science & Engineering in San Francisco, CA
• September 8-9, 2012 Saturday & Sunday AWS for Science & Engineering (in conjunction with MMTC Cloud Conference , San Francisco CA)
• September 14, 2012 – Friday – Cloud Orchestration (in conjunction with MMTC Cloud Conference , San Francisco CA)

Registration & More Information

http://www.healthtech.com/cloud

Our friends at Cambridge Healthtech Institute do all the hard work with training locations, logistics, advertising, enrollment and management. CHI should be considered the authoritative source for all training information and course details. For general questions not related to a specific scheduled class, feel free to contact chris@bioteam.net.

CHI’s primary page for the Amazon training class is http://www.healthtech.com/cloud and we’ll update this page if there is a separate course and enrollment page set up for the Chef Orchestration training.

• Ion Torrent Server API, I’d like to introduce you to the MiniLIMS API
• The MiniLIMS 4 column table and it’s PHP manifestation, the TypeInstance
• A quick round of applause for the Ion Torrent Server API

Bioinformatics has been notorious for the tension between public, supported access to data and algorithms and the often critical need to get under the hood. The ABI trace file and the Illumina output file system are good examples of data sources in which detailed internal access was necessary, but effective APIs did not exist and controlled, supported access was insufficient.

My approach to the data object portion of the API described below is to try to do some of both. I think I’ve found an accommodation of both structured access to the Torrent Server data objects and availability of the rawest form of data. If you know what you’re doing and are willing to take responsibility, take the raw data and go nuts. Otherwise, stick to the more managed parts of the API.

The Torrent Server RESTful API returns a JSON document that can be easily converted to a stdclass object via json_decode. If you’re not familiar with the stdclass, don’t feel bad; the only real documentation comes from third parties. It’s easy to understand, though; it’s what you get when you turn an associative array into an object. We’ll use this as the basis for the PHP API.

Here is an example of the JSON document returned by the previously described Torrent Server API, specifically for an instrument (“Rig” in Ion Torrent parlance):

JSON returned for an Instrument query

    $rigresult = json_decode($jsondoc);
        ...
    $rigresult->meta->limit == 20;
        ...
    $defaultrig = $rigresult->objects[0];
    $defaultrig->name == "default";

Easy, eh? We could probably just take these stdclass objects and convert them to MiniLIMS TypeInstances and we’d be done before lunch.

Yeah, you’re right. It’s a little too easy.

As I mentioned above, we’re going to try to provide some control and structure over the objects pulled from the server. This will not only help the general consumer of this PHP API, but it will also help the MiniLIMS system more clearly handle changes to the Torrent Server. Since you can’t add or change the methods of the stdclass, I’m going to use a wrapper object and call it PGMObject. From the PGMObject, more specific subclasses will be derived according to the Torrent Server types.

Before I describe the PGMObject, though, I’d like to use a subclass as an example of what I’d want to do. I’ll stick with the instrument data type since it’s relatively small.

PGM Instrument PHP class

There are 4 things I’m trying to accomplish here:

1. PGMInstrument extends PGMObject, the class that will handle all of the common functions
2. The properties array that is populated in the constructor lists the valid property names for this object so that we can check them.
3. The required array allows me to check for required fields in the validation method (coming up shortly)
4. The defaults array allows me to set defaults for a particular field.

This really is the essence of the distinction between one PGM object and another- a list of properties and the characteristics of those properties. How those properties and their characteristics are used can be defined in the base class for the most part by iterating through these arrays.

Below is a screenshot of the PGMObject interface (a collapsed object view from an Eclipse editor window).

PGMObject interface (collapsed object view in Eclipse)

First, I want to point out the constructor and the getJson/setJson methods. If you use the TorrentServer object (we’ll see that one soon) to retrieve a PGMObject from your Torrent Server instance, you can just grab the JSON document and do with it as you will. More often than not the object representations will be very handy, but, if you need low level access, it’s yours.

This JSON document represents a single one of the objects returned by the Torrent Server. A URL query typically returns an array of matching objects along with a {meta} document that can be used to support paging. The document maintained by these objects is a single data object with no associated meta.

If you don’t want to work with the raw JSON, you have two choices for interacting with the data values; either getPropertyValue/setPropertyValue or getters and setters for the individual properties.

The getPropertyValue/setPropertyValue method works just like the MiniLIMS methods of the same name; a property name and value are passed for setPropertyValue and just a property name for getPropertyValue. These are really handy for treating PGMObject subclasses generically and, particularly, for iterating through the full property list. If you wanted to write an HTML table you could do this:

$id  = "5";                           //An experiment id from the Torrent Server
$exp = $tserver->getExperiment($id);  //$tserver is a TorrentServer object

$html   = "<table><tr><th>Property</th><th>Value</th></tr>\n";
foreach($exp->getProperties() as $prop){
  $html .= "<tr>";
  $html .= "<td>" . $prop . "getPropertyValue($property) . "</td>";
  $html .= "</tr>\n";
}
$html  .= "</table>\n";

Property-specific getters and setters are nice to have for data objects like these. Popularized by Java, get/set methods for accessing object members allows for controlled access, but can be incredibly tedious to write for the most common case of simply getting or setting the attribute. The __call function is a special PHP object method that is called when an undefined function is called on an object. By having this function look for getters and setters that match the set of valid properties for the PGMObject, we can write one chunk of code to handle all of the routine get/set calls. Of course, if you want to do any special handling in a getter or setter (e.g. make something a computed value), you can define that function for your PGMObject subclass; if the method is explicitly defined, the __call function won’t get called.

Here is a chunk of __call where the parameter $name is the name of the function being called and $arguments is the array of argument names and values:

  public function __call($name,$arguments){
    if (!isset($this->properties)){
      throw new Exception("PGMObject cannot function without a properties list");
    }
    $matches = array();
    if (preg_match('/^get(.*)/',$name,$matches)){
      $prop = lcfirst($matches[1]);
      if (in_array($prop,$this->properties)){
        if (!isset($this->object)){
          if (isset($this->json)){
            $this->parseJson();
          }
          else {
            return "";
          }
        }
        return $this->object->$prop;
      }
    }
...
}

that allows you to do this:

$id  = "5";                           //An experiment id from the Torrent Server
$exp = $tserver->getExperiment($id);  //$tserver is a TorrentServer object

$chiptype   = $exp->getChipType();

without explicitly defining the getChipType() method.

The final “value-add” that we place on top of the PGMObject is the isValid() method. This is primarily to support objects that are being pushed to the Torrent Server (like a PlannedExperiment object). In the base class, this function goes through the $required array and makes sure that all of the properties listed have a value. If they do not, the method returns a null value and stores a message in the $validationErrors array.

This snippet shows how to use it:

$pexp = new PlannedExperiment();
$pexp->setId("5");
$pexp->setSample("Fish blood");
$pexp->setPlanPGM("default");
if (!$pexp->isValid()){
  print "Planned experiment is not valid for the following reason(s):<p/>\n";
  print implode("<p/>",$pexp->getValidationErrors());
}
else {
  $tserver->putPlannedExperiment($pexp);
}

Long-winded though this was, I hope the essential point is clear. I’ve tried to accommodate both raw(ish) access to the Torrent Server data objects and an object-oriented structure that can support controlled access, while at the same time minimizing the amount of routine coding.

In the next post, we’ll examine the TorrentServer class, whose purpose is to provide access to a Torrent Server, much like a traditional database object broker.

Excerpt:

In most organizations, the human resources of bioinformatics are a regular source of tension. Unless you’re particularly lucky, you can be plagued by politics, illogical decision making, disappointment, and low productivity. While you can have these problems in a properly-balanced organization, there are certain org charts in which they are endemic. 

The full article can be read at it’s online home:

http://www.bio-itworld.com/issues/2012/jan/unstable-equilibrium-bioinformatics-org-chart.html

Background & Disclaimer

This blog page attempts to clean up and organize the scattered notes I maintain on how to build Grid Engine on various platforms. This post in particular is talking about Open Grid Scheduler version 2011.11 as built on CentOS 6.2 (a binary clone of RedHat Enterprise Linux RHEL 6.2).

First round of notes will cover building on x86-64 but I’ll also try to document the same process for building 32bit executables as well.

Another reason for this document is that many of the online instructions for building Grid Engine take the “easy” way out by skipping the compilation of various features, services and subsystems. In particular I don’t like refusing to compile with Java just because it’s easier and I actually like having the java-based GUI installer present on my systems.

Skipped Build Items  

The primary goal is to build as much of Grid Engine as possible. At this stage, the only things we are skipping are:
•    ARCo
•    sgeinspect binary
•    Hadoop/Herd integration

Every other feature, service and 3rd party executable should be covered.

Differences between 6.2 and prior versions of CentOS and RHEL  

The primary difference is that our 6.2 OS includes an updated version of OpenSSL that breaks Grid Engine compilation. This document covers the patch necessary to complete the build on RHEL 6.2 and CentOS 6.2.

Build Environment  

Unless stated otherwise, assume that the build environment is a bare-bones CentOS 6.2 machine where I’ll be building SGE as user “root” and installing many of the external dependencies into /opt/

Required Linux OS Packages  

I started with a stripped down bare-bones CentOS 6.2 VM and had to install the following distro packages. I can’t claim 100% that these are all the RPMs you will need but it’s probably fairly comprehensive:

$ sudo yum -y install "openmotif openmotif-devel openmotif22 openssl-devel openssl-static make gcc \
autoconf pam-devel libXpm  libXpm-devel ncurses ncurses-devel unzip texinfo"

Download Open Grid Scheduler 2011.11  

From the website: The 2011.11 release includes new features (e.g. Berkeley DB spooling improvement: removed dependency on NFSv4, hwloc support, GPU integration, ARM Linux port, gmake upgrade, Linux 3.0 support, etc), together with other enhancements and bug fixes.

See the release notes for more info!

# mkdir /opt/opengridscheduler-src
# cd /opt/opengridscheduler-src
# wget http://sourceforge.net/projects/gridscheduler/files/GE2011.11/GE2011.11.tar.gz/download?use_mirror=superb-sea2
# zcat GE2011.11.tar.gz | tar xvf -

Download & Install External Dependencies

There are a ton of them. Have patience.

Java, $JAVA_HOME and $PATH alterations

Visit http://www.oracle.com/technetwork/java/javase/downloads/index.html and grab a Java JDK. I used JDK 7u2 for x86-64 and selected the .tar.gz version for download.

# cd /opt/
# gunzip jdk-7u2-linux-x64.tar.gz
# tar xvf jdk-7u2-linux-x64.tar
# ln -s jdk1.7.0_02/ java

By making a symbolic link between /opt/jdk1.7.0_02 and /opt/java we can more easily set $JAVA_HOME to something convenient like “$JAVA_HOME=/opt/java”.

We need to set some environment variables and PATH settings next. I chose to do this by making an /etc/profile.d/sge-build.sh entry with the following contents. How you set your path and environment variables depends on your personal preference and what shell you use. Note that the sge-build.sh file also includes info about Java ANT  and JUNIT .jar files that will be installed later on.

## Java
export JAVA_HOME=/opt/java
export ANT_HOME=/opt/ant
export CLASSPATH=/opt/junit/junit3.8.1/junit.jar:/opt/ant/lib/ant.jar
export JUNIT_JAR=/opt/junit/junit3.8.1/junit.jar

 ## Path Tweaking
export PATH=$PATH:$JAVA_HOME/bin:$ANT_HOME/bin

ANT

Visit http://ant.apache.org/index.html and grab Apache Ant. The version used in this document is 1.8.2.

# cd /opt/
# gunzip apache-ant-1.8.2-bin.tar.gz
# tar xvf apache-ant-1.8.2-bin.tar
# ln -s apache-ant-1.8.2 ant

JUNIT

This is another dependency of the various Java bits within Grid Engine, in this case I’m using junit-3.8.1:

# cd /opt/
# mkdir junit
# cd /opt/junit/
# wget http://downloads.sourceforge.net/project/junit/junit/3.8.1/junit3.8.1.zip?use_mirror=superb-sea2
# unzip junit3.8.1.zip

We will need to reference the location of junit.jar in CLASSPATH and a few other locations, those are documented elsewhere on this page.

JavaCC

This is another dependency of the various Java bits within Grid Engine, this time from http://javacc.java.net/:

# cd /opt/
# mkdir other-sge-deps
# mkdir other-sge-deps/java
# cd /opt/other-sge-deps/java/
# wget http://java.net/projects/javacc/downloads/download/javacc-5.0.tar.gz
# gunzip javacc-5.0.tar.gz
# tar xvf javacc-5.0.tar

The configuration parameters that point to javacc are documented elsewhere on this page, the primary setting is within the build.properties file in the source directory.

IzPack 1.4.4  

We need IZpack which is apparently a nice cross-platform Java tool for bundling application installers. I think,  but am not 100% sure, that this dependency is required to build the graphical SGE GUI installer.

There is one small problem though. My working build environment seems to explicitly use an ancient version of IzPack that is not even available for download any more on the http://izpack.org/downloads/ website. Given that my build environment works with version 1.4.4 and I seem to also have much more modern versions laying around in “_disabled/” folders I’m guessing that SGE has a dependency on this specific (and old) version.

For convenience  I’ve uploaded version 1.4.4 here for others to use if needed:  http://bioteam.net/wp-content/uploads/misc/Izpack-1.4.4.tar.gz

# cd /opt/
# wget  http://bioteam.net/wp-content/uploads/misc/Izpack-1.4.4.tar.gz
# gunzip Izpack-1.4.4.tar.gz
# tar xvf Izpack-1.4.4.tar

The specific places where we mention the Izpack location in the SGE build & config files is highlighted elsewhere on this page.

BerkeleyDB version 4.4.20

It’s actually important to use this (old) version of BerkeleyDB. It’s the last version that supports RPC spooling to a remote BDB database and the SGE build process assumes that this functionality is present. In addition, there have been some indications on the mailing list that internal use of BDB for berkeley-db based spooling also assumes behavior and technical features associated with the older versions of the code.

Visit http://www.oracle.com/technetwork/database/berkeleydb/downloads/index.html and follow the link to “Previous Releases” where you can find the 4.4.20 version.

You will see below that we are building with “–enable-rpc” and installing into /opt/berkeley-db/ which is where the BDB bin/ and lib/ directories will end up.

# mkdir /opt/berkeley-db
# mv db-4.4.20.tar.gz berkeley-db/
# cd berkeley-db/
# gunzip -c db-4.4.20.tar.gz | tar xvf -
# cd db-4.4.20
# cd build_unix
# ../dist/configure --prefix=/opt/berkeley-db/ --enable-rpc
# make
# make install

Patch Grid Engine 2011.11 Source to support OpenSSL-1.0.0  

If you see this error, you are hitting an issue with openssl-1.0 on your system:

You can see the bug report and patch at this URL:  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=622849 and you can download the actual patch via this URL:  http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=10;filename=622849-openssl.patch;att=1;bug=622849

Place the patch file one level above the GE2011.11 source/ folder:

[root@grunt GE2011.11]# ls -l
total 1140
-rw-r--r--.  1 root root    6763 Jan 12 14:38 622849-openssl.patch
-rw-rw-r--.  1 dag  dag     5403 Nov 14 14:01 Changelog
-rw-rw-r--.  1 dag  dag  1121679 Nov 14 14:01 Changelog.SGE
drwxrwxr-x.  7 dag  dag     4096 Nov 14 14:02 doc
drwxrwxr-x.  2 dag  dag    20480 Nov 14 14:02 review
drwxrwxr-x. 12 dag  dag     4096 Jan 12 14:30 source

Now patch the actual ./source/libs/comm/cl_ssl_framework.c file …

[root@grunt GE2011.11]#  patch -p1 < 622849-openssl.patch
patching file source/libs/comm/cl_ssl_framework.c
[root@grunt GE2011.11]#

Customize the aimk.site file  

The local file aimk.site file contains site-specific information about where your external dependencies are installed.

My current aimk.site has the following customizations (note that the info below is not the entire file, just the lines that I have added or changed..

Berkely-DB settings in aimk.site:

# BERKELEYDB_HOME the directory where the include and lib directory of
# Berkeley DB is installed
#
set BERKELEYDB_HOME = /opt/berkeley-db/
set BDB_INCLUDE_SUBDIR =
set BDB_LIB_SUBDIR =
set BDB_LIB_SUFFIX =

OpenSSL settings in aimk.site:

## dag (set values for openssl libs and include files)
set OPENSSL_SOVERSION = 1.0.0-10
set OPENSSL_HOME = /usr
set OPENSSL_LIB_DIR = /usr/lib64
set OPENSSL_EXTRA_LIBS = "-lkrb5 -lz "

JUNIT settings in aimk.site:

set JUNIT_JAR = '/opt/junit/junit3.8.1/junit.jar'

Customize the build.properties file  

This file is where we set parameters related to the building of the java componants

JUNIT edits:

# junit jar file classpath
libs.junit.classpath=/opt/junit/junit3.8.1/junit.jar

JavaCC edits:

javacc.home=/opt/other-sge-deps/java/javacc-5.0

Customize the ./clients/gui-installer/nbproject/project.properties file  

Yeah there is probably a better or cleaner way to do this but I found I had to edit the clients/gui-installer/nbproject/project.properties file in order to fix some issues with finding a certain iZpack/ant.jar file and the Java SWING layout stuff. Here are my changes

SWING edits in project.properties:

#Swing layout
#libs.swing-layout.classpath=${izpack.home}/../swing-layout-1.0.3.jar
libs.swing-layout.classpath=${izpack.home}/swing-layout-1.0.3.jar

ANT edits in project.properties:

#Ant
#libs.ant.classpath=${izpack.home}/../ant.jar
libs.ant.classpath=/opt/Izpack-1.4.4/ant.jar

Hack up the aimk build file  

Note: We are really not supposed to be doing this but it’s rare that I’m able to get through an SGE build without making minor alterations to the actual “aimk” compile script. This is where we can also get into personal preferences about how to build software so your own experience may be different,

Here are my edits…

I’m pretty sure this edit is meant to get around the fact that our libcrypto OpenSSL files are in “/usr/lib64″ instead of “/usr/lib” and the KFLAGS additions are meant to proactively avoid a new and different compile error that I forgot to document in my notes …

Near line #370 in ./aimk:

#set SECLIBS_STATIC    = "$OPENSSL_HOME/lib/libssl.a $OPENSSL_HOME/lib/libcrypto.a"                                                     
#set KLFLAGS           = "-L$OPENSSL_HOME/lib"                                                                                          
set SECLIBS_STATIC    = "$OPENSSL_HOME/lib64/libssl.a $OPENSSL_HOME/lib64/libcrypto.a"
set KLFLAGS           = "-L$OPENSSL_HOME/lib64 -lkrb5 -lz"

This next edit I believe is required to let the ‘qtcsh’ binary build properly, it complains unless we add “-ltermcap” …

Near line #3043 in ./aimk:

# Dag hack for qtcsh on CentOS 6.2 ...                                                                                                                      
# set SGE_LIBS = "-lsge -lpthread"                                                                                                                        
set SGE_LIBS = "-lsge -lpthread -ltermcap"

Build Grid Engine from Source  

Whew! Now that all the pre-requisites, patching and hacking is done Grid Engine should ideally build smoothly from scratch at this point.

Refer to the README.build and README.aimk text files if needed. The commands that follow are taken straight from the build docs.

 Prepwork

# ./aimk -only-depend
# scripts/zerodepend
# ./aimk depend

 Build binaries & manpages

# ./aimk
# ./aimk -man

Hack up the scripts/distinst binary staging script  

The “distinst” script is used to stage the newly built binaries into a location where the “mk_dist” script can finally start building .tar.gz archives for distribution. We need to make a few edits to it first …

Edit Line #718 of scripts/distinst & set insthadoop=false to prevent failure due to missing “herd.jar”:

insthadoop=false

Edit near line #1551 to fix location of the libcrypto.so.1.0.0 file (it’s looking in lib/ instead of lib64/ )

Note the two separate edits where we make changes from “lib” to “lib64/” below …

  elif [ -f $OPENSSLBASE/lib64/$libname ]; then
    #libname=$OPENSSLBASE/lib/$libname                                                                                                        
    libname=$OPENSSLBASE/lib64/$libname
  fi

Edit the scripts/distinst.site configuration file  

We need to configure some values here to fix some OpenSSL and Berkeley-DB values.

# Base directory where the openssl binary and libraries reside
OPENSSLSOVERSION=1.0.0
OPENSSLBASE=/usr/

# Base directory where BDB resides
BERKELEYDBBASE=/opt/berkeley-db/

Stage the distribution binaries by running the scripts/distinst script  

I decided my staging location was going to be “/opt/opengridscheduler-src/distinst-base/” so first we do:

# mkdir /opt/opengridscheduler-src/distinst-base/

And now we can actually run the distribution staging script!

# ./scripts/distinst -v -allall -bin -libs -basedir /opt/opengridscheduler-src/distinst-base/ -vdir GE2011.11

Build Grid Engine binary distribution archives  

Now we can actually build distributable Grid Engine archives. The documentation recommends a symbolic link be placed inside your distinst “basedir” that points back to the “mk_dist” script:

# ln -s /opt/opengridscheduler-src/GE2011.11/source/scripts/mk_dist /opt/opengridscheduler-src/distinst-base/mk_dist

# cd /opt/opengridscheduler-src/distinst-base

And now we can actually run the command:

# ./mk_dist -vdir GE2011.11 -version GE2011.11 -common -doc -bin linux-x64

Check /tmp/sge6_dist/ for the new archives  

Never had time to track down, change or care about this but by default it seems that “mk_dist” is placing our new binaries into /tmp/sge6_dist/ …

If things actually worked you should see something like this:

[root@grunt distinst-base]# ls -l /tmp/sge6_dist/
total 30384
-rw-r--r--. 1 root root 28162103 Jan 12 17:31 ge-GE2011.11-bin-linux-x64.tar.gz
-rw-r--r--. 1 root root  2946660 Jan 12 17:31 ge-GE2011.11-common.tar.gz
[root@grunt distinst-base]#
[root@grunt distinst-base]#

… and these are the standard “courtesy binary” archives that many of us are long familiar with.

The first picture shows a couple of Drobo storage arrays. The second image is a screen capture showing BioTeam running it’s own MiniLIMS product as an embedded application hosted directly inside the Drobo storage array. Cool huh?

The idea that an inexpensive and super easy-to-use storage appliance can easily be made to natively host scientific data management software is pretty fascinating. There are a ton of high-end storage solutions for large-scale genome platforms but you don’t hear a lot buzz about small, simple and clever things targeted at single researchers or single instruments.

Disclaimer

This blog post is intended simply to highlight something cool that we were able to do while hacking and experimenting on our own time. The freedom to fool around with stuff like this is one of the reasons I love coming to work every day.

Just to be clear:

• This is not a product
• This is not officially sanctioned or supported by anyone
• It’s a neat proof of concept, nothing more.

Meh. Whats the big deal?

Storage systems have been adding internal horsepower rapidly for years now. This internal power is necessary to run additional services and features such as encryption, replication and data-deduplication etc. that the market has been demanding.

That’s old news. It’s also nothing new to learn that storage vendors have often been obtaining this performance by leveraging the commoditization wave seen with standard  server technologies and chipsets. Sure they still differentiate themselves & juice their core storage engines with proprietary engineering, silicon and hardware but more and more of them are running core functions on standard tech that IT pros are well familiar with.

As the price/performance of mass-market server technology increases it becomes easier and easier to put “more power” into infrastructure items like network switches and storage arrays.

In addition to the increasing use of mass-market hardware inside these devices, more and more of them are running internal operating systems that are either 100% Linux or very “unix-like” inside.  Anyone who has been root on an Isilon cluster or Panasas storage brick will have seen this first-hand.

Once you have hardware CPU cycles to spare and an internal OS that can pretty easily run common development tools, libraries and applications the next logical question becomes “what other software can I run directly inside this environment?”.

This, also, is not anything new. My first experience with this a few years back was seeing how Isilon embedded software from Aspera into their arrays so that their broadcast media clients could more easily sling HD video streams around the world.

Ok, so why the blog post?

Because Appliance!

Getting MiniLIMs to run as an application inside a Drobo storage array is cool and worthy of a minor blog writeup for the following reasons:

• Several vendors have “application aware” infrastructure & datacenter products but these are often targeted at big enterprises and for support/profit reasons they are often locked down to hosting only a certain set of software products. It’s hard to wedge your “own stuff” into these platforms

• DIY & rackmount Linux storage servers can easily handle this use case (for instance our 120TB Backblaze Pod) and there are tons of other options out there for people who want to build real servers that can both run applications and internally provide a ton of storage capacity. Companies like Silicon Mechanics have all sorts of suitable offerings. The problem? Most of these systems completely fail the “easy-to-use appliance” test.  They are great systems but they need to be purchased, integrated and supported by IT professionals if they are going to succeed in a research or scientific environment.

• The notable thing in our mind is that we were able to place our scientific software inside a storage device that was designed from Day 1 to act as a simple appliance. No IT expert required. The Drobo units are notable for being dead easy to setup, manage and use. In addition, Drobo goes out of their way to encourage 3rd party developers to create “DroboApps” that run on their architecture.

It’s not inconceivable similar “smart storage” devices  could replace traditional PC-based laboratory instrument control workstations.

As storage units get smarter and more capable the need for a dedicated Windows PC attached to an instrument or Genome Sequencer becomes less important.

We particularly like the idea of a small storage appliance that is capable of natively hosting scientific and data management software – there are a lot of instrument-attached use cases that come to mind.  Something like this seems attractive for single-instrument genomics environments or labs where dedicated research IT staff may not be easily available.

I’ll end this post with a few more Drobo pictures just to really highlight their “small appliance” nature …

More Info:

• BioTeam MiniLIMS information
• Drobo “DroboApps” information

BioTeam maintains it’s internal company IT infrastructure across a distributed mix of servers hosted both “in the cloud” as well as within our own offices and colocation cages. We’ve long been using Opscode Chef to “orchestrate” our cloud systems and recently have found it invaluable for automatic configuration management of our own local servers and VMs.

This blog post is just a quick one-off article to highlight how well Chef plays with non-cloud systems including local virtual machines that BioTeam is running via Citrix XenServer. It was so easy to spin up a new VM (“staff.bioteam.net”) and then use a single Chef one-liner command to bootstrap the server to configure user accounts, install new software (denyhosts) and adjust the configuration of the /etc/sudoers file that I wanted to screencast and share the process.

First things first …

Thanks to Steve Danna for publishing a CentOS-6 bootstrapping template script. In the screencast below where you see me typing the “knife bootstrap …” command I’m directly invoking the bootstrapping script for CentOS 6 systems that Steve put on github.

Screencast Ahead

In the video recorded below we start with a CentOS 6.1 Linux system. The VM was created from a pre-existing barebones XenServer template and really just contains a minimal operating system and network stack with almost no installed software.

Normally in “Xen” land, I’d fire up the new VM from a template and then do manual sysadmin “stuff” to the server to make it do what it needed to do.

For this particular server (“staff.bioteam.net”) we really just needed a few things to start with:

• Create BioTeam staff user accounts
• Upload and install individual BioTeam staff SSH keys so they can login securely
• Add the appropriate BioTeam user accounts to the /etc/sudoers file so they can elevate access when needed
• Install, configure and start the ‘denyhosts’ service to block SSH password guessing attacks

And wouldn’t you know … BioTeam ALREADY has Chef recipes to do all those things because we need them on just about every cloud server we create.

The screencast below simply shows how I can do all the tasks listed above via my personal Mac OS X laptop with a single call to the Opscode Chef CLI tool named ‘knife’. The exact command used was:

 $ knife bootstrap -d centos6-gems --ssh-user root \
 --run-list "recipe[users::sysadmins], recipe[sudo], recipe[denyhosts]" \
 staff.bioteam.net

It’s literally that easy.

The video below is not edited for time in any way. It really does take less than 4 minutes to take a ‘barebones’ CentOS system, install all the software dependencies, build and configure chef, download the cookbooks and runlist and then “process them”. The end result is 100% automated provisioning of a new server while I check Facebook in another browser window.

And for people new to Opscode Chef this is a great example of how powerful and flexible these “infrastructure orchestration” systems have become. The Chef client running on the new server is doing far more than just simple installs of software from remote repositories. Of course it’s doing that but it’s also installing personal individual SSH keys, editing the contents of the /etc/sudoers file and installing, configuring and starting a new network security service (denyhosts). Try doing that amount of “custom” server config work using a “golden image” or Kickstart type method!

Note: The text-heavy screencast may best be viewed directly on youtube.com, particularly in the “big” 720p HD version …

• Ion Torrent Server API, I’d like to introduce you to the MiniLIMS API
• The MiniLIMS 4 column table and it’s PHP manifestation, the TypeInstance

I’d like to suggest a quick round of applause for the RESTful Ion Torrent Server API. I feel funny doing so; it’s like applauding a common sense activity like using a cross walk and not running across the street. API calls via URLs that return JSON text objects really should be the default these days. Sure, maybe you’re in some glacially-paced industry that just made the move from CORBA to SOAP and are thrilled with the readability of bloated XML documents. But for everyone else, GET/POST operations that communicate via lightweight JSON encoded text is just so sensible. Every modern language, and even command line tools like curl, can use a RESTful API; most can encode/decode JSON in a single line. It’s particularly useful for things like real-time instrument monitoring where an AJAX call can get you the current status without reloading a page.

The icing on this cake is the meta-data. The Torrent Server API delivers an object overview at the root and type details under a “schema” path for each data type in the same RESTful form. It’s not going to be directly useful for the MiniLIMS PGM classes, as I’ll described below, but it’s very handy for those of us that abhor reading documentation.

The URLs of the Torrent Server API reflect the hierarchy you’d expect for accessing data from the instrument. Here’s the URL to access a particular experiment, the Torrent name for an instrument run:

The root of the URL is pretty self explanatory: /rundb/api/v1 is the entry point into the API. Though it is certainly nice of them to include the version, if you’re going to do that, a “latest” URL that redirects to the latest version can also be helpful.

The next part, experiment, is the object type. If you only go this far in the path, you’ll get a full listing of all experiments. If you include the final path component (3 in this example) you’ll be accessing a single object using the internally generated id.

The request parameters come in to play in a number of situations. Though only the one format is supported, and it should be the default regardless, they insist that you include the format=json parameter. Beyond this, request parameters can be used to filter results, find by name, sort the returned documents, and support paging of results. For example, if you don’t know the internally generated id of the experiment, you can ask for it by name:

http://<torrent-server>/rundb/api/v1/experiment/?format=json&expName=R_2011_09_01_15_58_12_user_B15-410-r124922-bst9_lib909_run2-ms

You might have noticed the lack of any login credentials in the URL. Torrent Servers do require logins, but it’s http basic authentication. As a result, most URL-handling code can deal with it, including the curl binary. I’ll show you the PHP code later.

This is the JSON document returned by the above URL (marked up a bit by a Chrome plugin):

Torrent JSON for experiment/3

Pretty straightforward, eh? Things are well formed and id and ‘resource_uri’ are included. One small annoyance is that most fields are camel case, but there are a few underbar word separators. API should clear that up, though.

As an aside, the data that I’m showing comes from an Amazon EC2 instance setup by Adam Kraut here at The BioTeam. Besides being a guru at all things Cloud, including Master Chef credentials, he’s been spinning up these instances for the Ion Torrent Grand Challenge competitors. They’ve been really handy for development.

The schema urls provide great typing guidance for each of the elements for a particular document. Here’s a partial schema for the experiment type.

Schema for experiments

A great thing to have available- if you’re in to strongly typed systems. Except for the “nullable” field, most of this is kinda pointless in our situation. PHP isn’t strongly typed and, even if it were, MiniLIMS itself treats everything as name-value pairs. Any value checking has to be done in decoupled validation code. The schema also provides a list of filtering and ordering fields (not shown in the screenshot above). This also is unlikely to help us much because we’re going to slurp the data wholesale into MiniLIMS and will take care of searching and sorting with our own mechanisms.

Among the request parameters that can be used are limit and offset. The combination of these two can support a “paging” functionality. If, for example, we weren’t storing the experiment records in MiniLIMS itself, we might want a paged display of, say 20 at a time. For page 1, we’d use limit=20&offset=0; for page 2, we’d use limit=20&offset=20. Again, we’re going to be pulling the data into MiniLIMS to get tighter integration for our end users, so we’ll be able to pass on this as well.

The results: field in the experiment shown above is a URI, clearly pointing to a document of another type. This foreign-key-like pointer is important for tying the data together, but is going to add a minor wrinkle to the API development.

I swear, code is coming soon. Now that we have some of the background, in the next post, I’ll walk through the design of data objects in our API.

Next post in this series:

• Adding a coating of civilization to PHP stdclass with the PGMObject base class