Common to all the areas that can run a rappture demonstration are a file called "tool.xml" and an "executable" (either a program specifically compiled to interact with rappture or a script written to interact with rappture). Those two items are the minimal requirements for rappture to do anything useful:
- the tool.xml file (the XML-based descriptor for the GUI created by rappture)
- a specially constructed executable (what rappture does when the simulate button is pressed)
Each tool.xml file is written to operate with a specific executable, and while it is possible to move a tool.xml file from place to place and to generate a rappture GUI in the new locations, the GUI will not do anything useful unless the appropriate executable is also present.
This type of use model does not apply to most of the image processing problems that will be run using Karst: for the most part, large data sets reside someplace on the system, and completely different image processing tasks are performed using the same data at different times during the analysis. While it is possible to replicate data sets in various different areas (or to tell certain programs where to find starting data), it is not practical to run each image processing job in a different area.
It should be clear from the above description of the standard way rappture works that creating GUI's to perform different jobs involves moving coupled pairs of tool.xml files and executables to the working directory. To facilitate this, we have created simple scripts that handle these details and that must be run before using a particular rappture GUI in a new area. These scripts are all named
setup_NAME.sh
where NAME is a valid "rappture'ized" program such as auto3dem, eotest, genericEMAN, refine, etc. Additionally, we offer a current listing of the available programs (and new GUI's can be created when requests are sent to the staff).
View our current list of available scripts to use with Karst
These setup scripts install the appropriate tool.xml file, Python script and ancillary documentation (e.g., the general descriptions for commands run via a rappture GUI) into the directory where the setup script is run. Any "ancillary documentation" is placed in a sub-directory called "docs," and existing tool.xml files are saved by giving them a unique new name (tool.xml.time_stamp). In the process of copying the tool.xml file into the current directory, the e-mail address of the user (e.g., user_name@indiana.edu) is inserted into tool.xml as the default e-mail address.
After successfully running a rappture application and submitting a job to the queue, two new files will exist:
an executable script: command_time_stamp.sh (or whatever name the users choses)
output from rappture: run[time_stamp].xml
At any point in the future, you can display the rappture GUI as it appeared when the job was submitted to the queue by typing:
rappture -load run[time_stamp].xml
on the command line. The displayed GUI shows your final inputs to the GUI and the final log file (both the job submission command and your jobs in the queue when this command was submitted).
You can see the current state of your jobs in the queue by typing "myQ.sh" on the command line at any time. You can also see a (very crude) estimate of when queued jobs will start to execute by typing "myRunTimes.sh" on the command line.
