Use fisbatch to Submit an Interactive Job  

The fisbatch command is depreciated as of November 12, 2020.  It will be removed from service on April 26, 2022.



The salloc command is recommended in place of fisbatch.  See the salloc tutorials and guide below



Salloc Video Demonstration


 Click on the image below to see a short, basic demonstration of using salloc 





Using Salloc with Screen


This is a guide to using the Linux command 'screen' with salloc, so that you can close the tab with salloc running and be able to reattach to it later on. 


Note: This will work on OnDemand, but if you are doing it from your machine, we recommend doing a small test to confirm that your job is not interrupted when closing a window before trying it with an important computation. Try this with a simple computation, close the window where you started the job, and run "squeue -u [your username]" to check if your job is running.



The image below links the first part of a two-part demonstration of using salloc with screen. There is a guide after the following images, as well.


Salloc with Screen Demonstration-Part 1



The image below links the second part of a two-part demonstration of using salloc with screen. There is a guide after this image, as well.



Salloc with Screen Demonstration-Part 2





Salloc with Screen Guide


The following is a step-by-step guide for using salloc with screen. The included screenshots will closely resemble what was done in the above two-part demonstration video. These screenshots have descriptions beneath them in small font.


First, create the screen with a tag by entering the command "screen -S [tag name]".


Above is a screenshot of a terminal window. In it, the user is in vortex2 and “screen -S tag” was typed, which will create the screen and tag it with just the word tag. Return has not been hit yet.



After hitting return, the window will go blank, but you will still be in the same Vortex as before and the same directory as before. Enter the “salloc” line, specify the partition, QOS, number of nodes, number of cores per node, the time you need, and whatever constraints you may need for your job. 


After hitting return, you may wait some time for the resources to be allocated. The time you wait depends on what resources you need. When the job is ready, you'll be given a compute node (or several, if your job uses multiple nodes).


You can enter the node with "srun --jobid=[Job ID] --pty /bin/bash". If your job uses multiple nodes, you can enter the node you want with "srun --jobid=[Job ID] --nodelist=[Node Name] --pty /bin/bash". Once you are in the node, use the needed commands and scripts for your job.


This screenshot is in the same window as before. A screen was created and in it, salloc was used to create a job in the debug partition with exclusive access to one node and 12 cores for one hour. Once the node was ready, srun was used to enter the node. The correct directory was entered.

A command was used to run a script called omp-matrix2, which calculates dot product, and have it write to a file called omg-matrix2.out, the "&" at the end of the end of the line made it possible to continue using the terminal while the script runs. "top", which returns information about the job's performance, was typed but return has not been hit yet.


This screenshot is in the same window as before. In it, "top" has been used, so the performance of anything running on the node is shown. This includes the user, as well as root. The top row shows omp-matrix2 under COMMAND. This is the job that was sent earlier. At the time of the screenshot, it had been running for about one minute and the %CPU was 99.7 which means the job was running efficiently at that point. "top" updates automatically until it is exited with "q". 



If you are using OnDemand, you can close the tab if and when necessary. Your job should continue running. This should work if you close the window on your machine, as well, but we recommend doing a small test in screen to be sure. Try with a simple computation, close the window, run "squeue -u [username]" to see if the job is running.


When you need to reattach, enter the same vortex front end machine within which screen was opened. Use "ps -ef | grep [username]" to see your processes. Screen should be listed. 

Note: This will not be the case if you are in a different vortex front end machine.


Use "screen -ls". This will return the names of pages with screen. The page with the screen within which the interactive job was started should have the tag it was given when created. Use "screen -r [page name]" to reattach to the screen.


This screenshot is in a new terminal window. The one used before had been closed. The user is in vortex2 like before and "ps -ef |grep testuser" was used. Screen is among the processes returned. "screen -ls" was used and returned the page for a screen. It has "tag" in it's name, which is the tag the screen created earlier was given, and it says (Detached) next to it. "screen -r 238451.tag", which will attach to the screen on that page was entered, but return was not hit yet.


This screenshot is in the same window as before. The command to reattach has been used, so "top" is back on the screen. At the time of this screenshot, "omp-matrix2" had been running for over twelve minutes, meaning it hadn't been terminated due to closing the tab used before and the %CPU was 99.7 which means the job was running efficiently at that point, too.


This screenshot is in the same window as before. It was taken after "q" was used to exit "top". Typing "exit" and hitting return took the user out of the node, then was used again to end the job. It will terminate the screen if used again. 


This screenshot is in the same window as before. The screen was terminated. This returned the user to what was seen before reattaching. A message that screen was terminated was given.


This screenshot is in the same window as before. "ps -ef | grep testuser" was used. Neither screen nor salloc are listed among what was returned because they were both exited.



You will probably want to do something other than just return to the same monitoring. This was just to demonstrate that a large, complicated interactive job can be started with salloc and when it's done within screen, it is possible to get back to it even if the tab was closed.