Cipres Science Gateway

How To Use XSEDE (formerly TeraGrid) Resources

XSEDE resources are made available by the US National Science Foundation as part of its mission to provide cyberinfrastructure for the advancement of Science. XSEDE Science Gateways offer any scientist the opportunity to easily access some of the best computational resources in the world. While free to users, the XSEDE resources are costly, and they should be used in a manner consistent with conservation as well as with scientific achievement.

PLEASE NOTE: Demand for the CIPRES Science Gateway has been very high. As a result, we have implemented a set of policies to insure equal access to all users. Please review our use policies here.

We have set up some guidelines to help users operate our Systematics codes to give the best wall time performance (you get the results faster) while at the same time making efficient use of the machine.

The addition of these new resources will expose you to unfamiliar behaviors when things go wrong. There is no way to avoid it, but we will keep a list of warnings and messages that might seem strange to a regular user. If you see a message you dont understand, let us know. We provide some tools to monitor job progress. If your job fails, the most efficient way to describe the problem to us is shown here:

Configuring Your Job for optimal running:
XSEDE resources improve performance by dividing up jobs into multiple individual processes, and mapping them across many processors. We have benchmarked the codes offered in the CIPRES Science Gateway to determine how jobs of various sizes can be run most efficiently.  We have distilled this information into a few user-parameters that describe your data set. At present we rely on our users to manage this manually. To use the resources efficiently, users must enter the following parameters in the interface prior to submitting. Using the correct settings will help insure our ability to continue this work.

Parameters user must set:

Setting the maximum time for your job:
The time you enter in this box sets the number of clock hours the job will be allowed to run. The time you enter is the limit in clock hours from the time your job begins to execute. The clock does not always start immediately when you submit, but when your job reaches the end of the queue and begins to run. This value is one parameter that impacts how your job is queued. Long jobs usually sit in the queue for longer periods of time.  The best strategy is to try to enter the shortest time for your run without having your job “time out.” 

How long can I run?:
Tools running “on XSEDE ” may be configured to run for up to168 hours.

How long will my job run?  For many programs, you can try to figure out how long your run will take by performing some test runs with the data set you are analyzing. You can, for example, make two test MrBayes runs that require only a few generations (I usually use 1000 and 10000), take the run times, and make a line through them. The slope gives you the time per generation for this data set on this resource. Similarly, you can run bootstrapping tools for a few generations to get an idea of how long the run will take. Use the test queue (see below) for this purpose.

Use the Test Queue to your advantage:
The test queue is a common feature for large HPC resources. Each of the TG resources we use has a test queue. The idea is to allow very short runs just to be sure you have the command line correct. That way, you avoid waiting in the queue for 8 hours, only to receive a trivial error due to a duplicate taxon label, or submission of a Nexus format matrix to RAxML when it finally begins to execute. So, the first time you create a job, set the time to some number less than 0.5 hours and submit. The test queue is (almost) always pretty fast, and you will discover your errors immediately.  Once you have it worked out, you can use the “Clone” feature to open the job up, set a long time limit and deploy.

Return to Login Page

Program specific information:

MrBayes:

If you do not use a MrBayes block in your input file, most of the decisions are made automatically, depending on settings the user configures in the interface. Just enter the number of characters your matrix at the top of the form. The value you enter can be approximate, as long as it is pretty close.

If you submit an input file with a MrBayes block (which we recommend), configuring the run is slightly more complex, because the MrBayes block contains a lot of configuration information that the application does not yet “read”.

RAxML:
We offer a hybrid version of RAxML (V 7.2.8) , created by a collaboration between Alexandros Stamatakis and Wayne Pfeiffer. There are two interfaces: an advanced interface for users who are comfortable with all of RAxML options, and a Black Box interface that reproduces the Black Box interface (at phylobench.vital-it.ch). With either interface, most of decisions are made automatically, based on settings the user selects (advanced interface) or pre-set values (Black Box interface). However, both interfaces require the user to enter the number of characters in the the matrix. The value you enter can be approximate, just make sure it is pretty close.

RAxML requires input files in relaxed Phylip format .

GARLI:
Garli is parallel only for runs involving bootstrapping. There are no requirements other than to set a time limit for the run. GARLI accepts NEXUS and relaxed phylip format as input.

BEAST:

BEAST accepts XML configuration files as input. These are created by the user with the program BEAUti on their local resources, and uploaded to the CIPRES Gateway. The jobs are run using BEAST/BEAGLE when possible. BEAGLE provides a significant speedup of BEAST jobs.

Known Issues:
Sometimes jobs will fail at the interface between BEAST and BEAGLE. The error message will indicate a failure to parse the input file. To overcome this error, just check the Do not use BEAGLE box on the interface.

MAFFT:
MAFFT aligns a collection of sequences in fasta format using a variety of algorithmic techniques.

Known Issues:
MAFFT can align very large data sets. Sometimes the output data can grow very large, and jobs will terminate prematurely. In every case to date, this is when individuals attemtp to align genome scale sequences that share little homology. The result is a 500 mb output file, where none of the sequences overlap significantly, and most of the characters in the output files are dashes.