Interactive Jobs and Debugging🔗

While batch jobs are the preferred way to interact with the cluster, they are not conducive to development/experimentation/debugging.

For these cases, an interactive job allows for much more flexibility when writing, testing or debugging code.
These jobs provide you with command line access to a virtual machine running on theselected cluster node.

When writing scripts for long runnings jobs the best practice is to first run the entire job with a small subset of the data you need to process.

This allows you to catch errors that may arise without exhausting your resource allocations for the queue.
This data can then also be used for debugging when a problem arises and thus support quickly iterating your job script to get your analysis running as fast as possible.

Try it yourself:

Print a summary of the salloc command options and note options to specify the length of a running job, the number of CPUs to use, the amount of memory and the partition to run the job on
Solution
```
# NOTE: You need to escape the or (|) in your regex otherwise bash thinks its a pipe
salloc --help | grep 'time\|cpu\|memory\|partition'
```
Allocate an interative job for 5 minutes with 2 CPU cores, 1G of memory on any available parition (HINT: the all partition uses smallest node matching your requested resources)
Solution
```
salloc -c 2 --mem=1G -t 0:05:0 -p all
```
Once your job gets allocated, navigate to your group directory and list the files there (solution assumes you have setup environment variables as in Environment Setup Tutorial)
Solution
```
cd $BHK # replace with the path to your group directory if you haven't setup envrionment variables in the Environment Setup Tutorial)
```