Moving Off-screen Windows in Windows 7

Has this ever happened to you?  You do something with your monitors and suddenly Matlab or another program opens a window off your screen and you have no idea how to get it back on the screen?  This is a pretty common occurance if you have a laptop and frequently switch from a multi-monitor to single monitor setup.  I found this handy fix on the MS forums (here).

Moving the window around is as simple as holding down the windows key and pressing the left or right arrow keys.  The window will be automatically docked to one part of the screen or another, moving it back on screen!

Common PBS Batch Options

PBS is a handy cluster scheduling software, usually wrapped around a grid manager like MOAB.  It’s useful in that you can submit options to the command line, or using a batch script.  Arguments placed on the command line when calling the qsub command will take precedent over those in the script, so a general script may be built and then tested or varied by varying the options on the command line.  PSU has a pretty good guide to get you started using the PBS system, and can be read here.  However, there are some other options which are exceptionally useful for the moderate user.  In particular, the ability to pass the current environment, set up email notification, and redirect output are handy things to be able to use and modify.  An example script and header are presented below:

#!/bin/csh                                                 #Using the C-Shell
#PBS -N SimpleScript                              #Give the job this name.
#PBS -M              #A single user, send notification emails there.
#PBS -m a                                               #Send notification of aborts <a>.
#PBS -V                                                  #Pass the current environment variables to the job.
#PBS -l nodes=1:ppn=1                            #Request a single node, single core for this job.
#PBS -l walltime=96:00:00                         #Request a maximum wall time of 96 hours [HH:MM:SS format].
#PBS -o output/$PBS_JOBNAME.out        #Redirect STDOUT to ./output/$PBS_JOBNAME.out
#PBS -e error/$PBS_JOBNAME.err           #Redirect STDERR to ./output/$PBS_JOBNAME.err

env                                            #Echo the environment (variables)
cd $PBS_O_WORKDIR              #PBS starts your job in your home directory, cd to the submit/work directory
echo -n CWD:; /bin/pwd              #Echo the current working directory path
echo PBS_JOBNAME is live…    #Print to STDOUT (really, the file declared above) the job is live…
sleep 30                                    #Sleep for 30 seconds, then exit.

In this case, I’ve configured the job to be named “SimpleScript,” to email the user “” if the job aborts, to use the same environment as the one that the qsub command was issued from, requests 1 node and 1 processor on that node, a maximum run time of 96 hours, and to redirect the error/output messages to separate directories under my working directory.  Clearly this is a very simple example, given that it prints some basic info, pauses and exits.  If you were going to run a process or other program, you’d put your commands in place of the sleep command.  However, it provides a cut/copy example of commonly used options that you can include in your own batch scripts.  In case you want to modify those options, there’s a brief review of the most commonly changed ones below.  For a more complete list, head to the NCCS’ listing on common PBS options:

Commonly Used Options:

These options can either be present on the command line a-la:
qsub -N SimpleScript -j oe <batchScriptFile>

Or included in the batch script file using the PBS Flagging macro: #PBS as in:
#PBS -N SimpleScript

Recall, that you can mix and match options on the command line and in the batch script, but be aware that the command line options override those in the batch file.

[-N] Name: Declares the name of the job.  It may be up to 15 characters in length, and must consist of printable, non white space characters with the first  character alphabetic.

[-o] Output File Path: Defines the path to, and name of, the file to which STDOUT will get redirected to.

[-e] Error File Path: Defines the path to, and name of, the file to which STDERR will get redirected to.

[-j] Join STD* streams: Declares if the standard error stream of the job will be merged with the standard output stream of the job.

An  option  argument  value  of oe directs that the two streams will be merged, intermixed,  as  standard  output.   The path and name of the file can then be specified with the -o option.

An  option argument  value  of  eo  directs  that  the two streams will be merged, intermixed, as standard error.  The path and name of the file can then be specified with the -e option.

If the join argument is n or the option is not  specified,  the two streams will be two separate files.

[-V] Pass Environment: This option declares that all environment variables in the qsub command’s environment are to be exported to the batch job.

[-m] – mail options: Defines the set of conditions under which the execution server will send a mail message about the job.  The mail_options argument is a string which consists of either the single  character “n”, or one or more of the characters “a”, “b”, and “e”.

If the character “n” is specified, no mail will be sent.

For the letters “a”, “b”, and “e”:

  • a  mail is sent when the job is aborted by the batch system.
  • b  mail is sent when the job begins execution.
  • e  mail is sent when the job terminates.

If the -m option is not specified, mail will be sent if the job is aborted.

[-M] User List: A list of users to send email notifications to.  The user_list argument is of the form:

If  unset, the list defaults to the submitting user at the qsub host, i.e. the job owner.

[-l , ‘ell’] – resource_list: Defines resources required by the job and establishes a limit to the amount of resource that can be consumed.  The list can be of the form:
Common arguments for this flag option are “walltime” and “nodes”.  The walltime sets the wall clock limit for the job, and is of the format HH:MM:SS.  Check with your sysadmin to see if there’s a maximum limit on this time.  The nodes argument defines how many cores you want the script to grab.

[-a] – date_time: Declares the time after which the job is eligible for execution. The date_time argument is in the form:

Where  CC is the first two digits of the year (the century), YY is the second two digits of the year, MM is the two digits for the month, DD is the day of the month, hh is the hour, mm is the minute, and the optional SS is the seconds.

Environment Variables Available to Job:

You can use these variables in your scripts as though they already exist in your environment; PBS sets them up as soon as your job starts running.

PBS_O_WORKDIR – the absolute path of the current working directory of the qsub command. You must ‘cd’ to this directory if you want to work in the folder you submitted the job from.
PBS_JOBNAME – the job name supplied by the user.
PBS_O_HOST – the name of the host upon which the qsub command is running.
PBS_SERVER – the hostname of the pbs_server which qsub submits the job to.
PBS_O_QUEUE – the name of the original queue to which the job was submitted.
PBS_ARRAYID – each member of a job array is assigned a unique identifier (see -t)
PBS_ENVIRONMENT – set to PBS_BATCH to indicate the job is a batch job, or to PBS_INTERACTIVE to indicate the job is a PBS interactive job, see -I option.
PBS_JOBID – the job identifier assigned to the job by the batch system.
PBS_NODEFILE – the name of the file contain the list of nodes assigned to the job (for parallel and cluster systems). This file is particularly useful if you want to log in to remote machines for parallel debugging.
PBS_QUEUE – the name of the queue from which the job is executed.

PBS_JOBNAME – the job name supplied by the user.

Virtual Machines for Remote Code Development

Setting up a Virtual Machine [VM] for Remote Code Development

Many times you’ll be asked to develop applications on remote machines.  Generally these machines are running some flavor of Linux or Unix (*nix systems).  Often, this can be quite complicated for those who are unfamiliar with using command lines or the “vi” editor.  This guide will get you started using a virtual machine to run a Linux operating system on your Window’s PC, and will help alleviate some of the headache associated with remote development.

I’m suggesting the use of a VM for remote development as opposed to separate SSH and X-Server forwarding software such as Cygwin because the VM gives you access to a lot of the software and features of the remote machines on your local machine.  Even things like LaTeX become readily available.  I’m suggesting setting up a local development area because once you’ve “cut your chops” on remote development, you’ll appreciate being able to rapidly develop code locally and then push updates to the remote machines for ‘production’ runs.

This guide will help you get up an running with the VirtualBox VM, with a version of CentOS (a popular flavor of Linux).  CentOS comes with software packages which are directed at software development, such as Eclipse, and contains features available on large cluster systems.  You’ll even be able to install openmpi, and be able to program and test parallel applications, if you so choose.

Installing VirtualBox

VirtualBox is a pretty well-supported, open-source piece of software.  The homepage is located at, and contains links to installers as well as users guides and documentation.  You’ll need to download the Host Software as well as a Guest OS.  The Host software, (VirtualBox) runs the virtual machine (the Guest).  Just like a standalone computer, you’ll need an OS to run on the Guest.  Here’s a quick link to their download page:

You’ll want to head over there and download the latest version of VirtualBox for Windows Hosts (x86/amd64).  This is the VM software that will manage your virtual machines.  At the time of this writing, VirtualBox is at version 4.1.8.  They have a pretty solid install guide in their manual, located here:

Go ahead and install VirtualBox, and configure a new virtual machine.  A good video guide (though slightly dated) is provided below.  When they get to the step where they determine the size of the hard drive, they use dynamically-sized storage.  You’ll want to change it to fixed-size; around 20 gigabytes or more if you can handle it.  Our settings will be for Red Hat (the core Linux within CentOS).  We’ll get to installing an OS on the virtual machine shortly.

Installing an OS to the VM

Congratulations! You now have a computer running within a computer.  This is where things may become complicated if you’ve never installed an OS before.  It’s become much easier than in the past, and there’s a pretty good video posted on YouTube with an example walkthrough.  You’ll want to make sure your computer is connected to the internet before you start the install.  Virtualbox will automatically connect to the net, and the OS installation will grab some packages from the net if you tell it to.  Around 3:15 in the video, you’ll see an example of the package selection screen.  You’ll want to select the “Software Development Workstation” option.

Installing Additional Software: VirtualBox Guest Addons

Now that the OS is up and running, you want to be able to fully use all the fancy features and graphics packages of VirtualBox to maximize its performance and ease of use.  This is done through the VirtualBox Guest Addons.  It will allow you to “fullscreen” the VM, as well as some other nifty tricks.  Technically this is optional, but it really should be required.  A walkthrough is provided byVirtualBox, and can be found here:

Simply follow the provided instructions for Guest Additions for Linux. Since we’ve installed CentOS, we’re using a variant of Red Hat Enterprise Linux (RHEL), so scroll to the specific instructions for CentOS, Red Hat Enterprise Linux and Oracle Enterprise Linux.  A video walkthrough is provided below:

Configuring Remote Display

This is where things get easy.  Since you’re running Linux in the VM, you’re basically already set up to push GUIs and windows back to your local machine from the remote one.  All it takes is the command:

ssh -Y <username>@<remote-system>

The -Y option for ssh allows the remote system to forward X11 data (GUIs, windows) back to your machine.  Pretty easy, right?  Log in to a machine and type xterm to push a remote terminal window back through your ssh connection to test it.


First, I’d like to note that a virtual machine is useful for running multiple OS for various reasons, however you take a hit to performance due to the virtualization layer.  Most modern computers are multi-core, which allows your primary OS to offload the virtualization to one core, and run calculations with the other.  This alleviates some of the performance hits, but does not remove it completely.  Some newer Intel systems can use specialized hardware to improve performance and even use the 64-bit (x86_64) versions of OS.  Such optimizations are beyond the scope of this guide, but if there’s enough demand I’ll write a more in-depth version including it.

Installing Additional (Optional) Software: Netbeans

While the Software Development Package comes with an Integrated Development Environment (IDE) called Eclipse, my personal IDE-du-jour is Netbeans.  Eclipse is more versatile when it comes to languages, but if you’re a C/C++ developer, Netbeans is also pretty convenient.  It is a little simpler to configure for remote development, and is easier to switch between local and remote.  If you wish to familiarize yourself with Eclipse, a good resource can be found here and at the Eclipse website, here.

From inside your remote machine, head over to and download the install script for the “All” version.  Remember where you download it, as you’ll have to navigate to the script on the command line. Installation instructions can be found here, but remember to perform these commands as “su” using the sudo command:

sudo chmod +x <installer file name> sudo ./<installer file name> 

During the installation, agree to the licenses, and if you’d like feel free to install the Glassfish server and Apache Tomcat packages.  If you don’t know what they are, you probably don’t need them, unless you’re deep into open-source development and web environments for Java.

Once installed, you’ll be able to find the software in the Applications->Programming menu.

Installing Additional (Optional) Software: OpenMPI

You can do this one of two ways: through the Add Software GUI, just search for openmpi and it’ll come up in the list of packages.

or on the command line, by running:

sudo yum install openmpi openmpi-devel