# What is the cost to use the RCE?

The RCE is free to use for qualified individuals in the pursuit of social science research, within certain limits.

If your needs exceed the capacities of the shared RCE environment, we can work with you to establish dedicated RCE resources for your exclusive use. If you are planning a large project, please contact us prior to your grant application so that we can assist in budgetary estimation.

The standard limits and costs of allowances in excess are outlined in the RCE Service Level Agreement (SLA).

# How do I get an account, or get help?

For fastest service, please email directly support@help.hmdc.harvard.edu. Or, you may also call 617-495-4734 (x54734) from 9AM-5PM weekdays.

If your question is not answered here on our RCE support website, you may also find the information you need on our User Services website, which covers topics relating to the HMDC RCE and other services provided by the IQSS Technology Services group.

For a list of all IQSS services, including statistical Research Technology Consulting and Public Computer Labs, please visit http://www.iq.harvard.edu/services.

# Will MPlus be available on the RCE?

Unfortunately, licensing for MPlus is complex, and places an undue financial burden on HMDC. From the MPlus developers:

Mplus was not developed for more than one analysis to be run on the same computer at the same time.

This is the exact opposite behavior of what the RCE is designed for, so at this time we cannot offer MPlus on our research cluster.

# Is there temp or scratch storage available?

Yes, the top-level /scratch directory on our batch nodes is the same as using /tmp. On our interactive nodes, /scratch is a separate 1TB shared storage space.

Top level scratch space is world-writeable and -readable (Unix 1777 permissions). User created directories are only owner writeable/readable (1700) or owner/group (2770) if you are a member of a research group.

In either case, if you need several gigabytes of storage, please request a project directory.

• Do not store any Confidential Information in scratch/temp.
• Any files written to scratch/temp will be deleted after 2-4 weeks.
• Do not use the scratch space for permanent storage.
• Each server has a separate scratch/temp. If you need shared space for a distributed batch job, please request a project directory.

# How do I use compressed data with R?

R supports two primary ways of accessing compressed data. This allows you to keep your data files on disk compressed saving space, and often time (since the file I/O saved by compression is often more expensive than the cpu cycles it uses).

If you are storing your data in native format, simply use the compress option of save:

tst.df=as.data.frame(cbind(1:10,2:11)) # just some testing data save(tst.df,file="test.Rbin", compress=T) # save a compressed R file

load("test.Rbin")

To access any other kind of file with compression, simply use gzfile("") around the file name:

write.table(tst.df,gzfile("test.dat.gz")) # write a compressed file read.table(gzfile("test.dat.gz"),row.names=1)# read it back in

Files compressed using the gzfile method can also be compressed and uncompressed using the UNIX gzip and gunzip commands (respectively).

# My Stata batch job keeps running even after a fatal error!

When running a Stata .do file on the batch cluster via condor_submit_util, you have to add some additional arguments in order to get your job to stop when Stata encounters an unrecoverable error (which is probably the behavior you want).

The command line below runs Stata with the example file my_dofile.do:

@condor_submit_util --executable /usr/local/bin/stata-se --arguments '-b /my_dofile.do' --noinput

# How do I automate actions when connecting to the RCE?

To configure your user account such that every time you connect to the RCE, some action is performed:

1. Write a script that performs the desired action. The scripting languages available in the RCE include BASH, (/bin/bash), multiple versions of Python (/usr/bin/python) and Perl (/usr/bin/perl).

2. Copy this script to the directory ~/.rce/startup with the command cp [scriptname] ~/.rce/startup/. If the directory does not exist, create it with the command mkdir -p ~/.rce/startup.

3. Make sure the permissions on your script permit execution; to ensure that this is the case, run the command chmod +x ~/.rce/startup/[scriptname].

Your script is run every time you connect to the RCE.

Note: Be sure to test your script; a misbehaving script can prevent you from being able to connect to the RCE! In particular, your script must not require any keyboard input or other interaction with the user; it will not be able to communicate with you while it is running, and you will not be able to connect to the RCE while your script sits waiting for input.

# Firefox or Thunderbird won't start!

The error Firefox is already running usually indicates that you must remove lock files before you can launch Firefox. To resolve this problem:

• If you are working inside the HMDC RCE navigate to ApplicationsRCE UtilitiesClear Firefox Locks or Clear Thunderbird Locks. Then, try launching Firefox or Thunderbird again.

• If you are not working inside the HMDC RCE, type the following command via a terminal to delete the Firefox lockfiles: rm -f ~/.mozilla/firefox/*.default/{lock,.parentlock}

# What are the technical specifications of the RCE?

The RCE is divided into three parts:

1. Login nodes: These servers provide a graphical or command line interface to the meat and potatoes of the RCE, the Interactive and Batch cluster. It operates like a personal desktop environment, but is not meant for running jobs.
2. Interactive cluster: Run memory intensive jobs on these COD (compute-on-demand) nodes that require user interaction.
• Size: 8 homogenous servers
• CPU: Intel Xeon E5_2630 with 12 cores (24 counting hyper-threading) @ 2.3 Ghz
• Memory: 250 GB each (2 TB total)
3. Batch cluster: For jobs that do not require babysitting, and speed is king.
• Size: 5 homogenous servers
• CPU: Intel Xeon E5_2690 with 16 cores (32 counting hyper-threading) @ 2.9 Ghz
• Memory: 125 GB each (1 TB total)
• Each batch job process is allocated 1 CPU core and 4GB of RAM