Tulane Visit - Day 2 - User Interface Storyboarding

Location: Conference RoomDate: 30 May 2006 14:09Present: Brock Tice, Rob Blake, Clint Sieunarine, Matthew Mascord, Umar Farooq

Overview

The key thing is to have a simulation set, a set of parameters that could be used as a base unit, set it up to submit a job, and the ability to check the status of the job. If pacing, get the restart file resulting from the pacing at the end, and bring that back as the basis of a new simulation.

New Simulation Page

There would be a page to create a new simulation based on a series of parameters. There would be the ability to select a template at the top, or save the current inputs as a template. There would be pull-down dialogs for the model, electrode configuration (this would need to be configurable), waveform, and depending on which waveform was selected there would be different options e.g. start time, end time, amplitude, tilt, and maybe a repetition count. Also needed would be start time, end time, and timestep for the simulation as a whole.

After this it would be possible to specify name to keep track of the simulation, and some sort of go button. This could allow the specification of where to submit, or keep it automated. This dialog would cover everything except electrode and model set up. People are going to change ionic models, since there are so many options, and adding options all the time, something as simple as a text box for other options would be a catch

all for everything. Record as freetext. The web interface would build a boundary file and a parfile to be fed into memfem.

Status Page

Normally (i.e. without the VRE), visualisation mid-run would involve going to find the output directory, copying data files produced, at least the latest couple, to the local machine, visualise them locally, and delete. When running 40 simulations at once, this can be very time consuming. If jobs were submitted through the VRE, it would be possible to monitor the status of the job. A list of jobs could show job number, name, cluster, CPUs, %done, status (timestep, start end, etc) and it would be possible to select one and look at the status, and if possible take a snapshot image of the heart from all 6 directions to see the current status. It should be possible to stop the job, erase it (with appropriate warn dialog), or pause.

Every cluster has a way to retrieve the status of a job given a job id. Most of the jobs write out to the end of a file, the current timestep. To get the snapshot image, it would be a matter of looking for the output file with the highest number, render the image off screen and display it. It's possible to execute system commands on the cluster over ssh.

Completed Jobs Page

After the job is finished, it's entry would move to a list of completed jobs. This might include different information e.g. the size of data set. A list as before, and again some ability to select one, and download the data. Data could be downloaded raw, or as a movie, activation map, optical mapping phase data if there are enough timesteps (requires

1 millisecond timestep resolution). Finally, and most importantly, there would be the ability to continue the simulation. This would send the user back to the new dialog but starting from the restart file from the previous simulation. This would create a new simulation linked back to the old one (a continuation of the old simulation).

Multiple pacing stimuli can be performed in one run. However, memfem has to be stopped if different timesteps are required. Usually a different timestep is used for the shock, so memfem has to be stopped after the pacing stimuli. This isn't a problem as it's a natural breakpoint. Usually a restart file is created after 8 pacings, and then for example 40 simulations performed using that restart file. When 'Continue' is clicked, all the parameters from the old simulation would be copied except the boundary file, start time and end time. The start time of the new simulation should be set to the end time of the old simulation.

Priorities for Prototype Development

The first step would be to get the status of something that is already running. This is the highest priority and everyone is likely to find that useful. The second step should be allowing jobs to be submitted through the interface. It's easier to track the job if it is submitted through the interface.

Before the job submission page is completed, the new dialog should allow a job id and working directory to be specified. This will allow the status page to look up the status of the job on the cluster and tell the snapshot program where to find the output data for the simulation.

Downloading data through the VRE isn't high priority, the VRE could just give a sample scp command that could be copied and pasted into the command line. Moving data in and out of SRB would be good. People generally run on only one cluster because so hard to keep track of data across clusters.

Rob needs to hack out a prototype version that would generate a snapshot image based on the current timestep. The web interface would run this command and copy the file back over ssh. The snapshot program would just output into data directory for the simulation:

python script -n point50 point50.t50 -o Job#_t50.jpg

The script would first check to see if the file exists, otherwise it would generate it.

Aside: currently when using the command line, it's hard to see which job is which because the unix status command has only 6 characters to name jobs, so depending on how the job is submitted, it can be the first 6 letters from the submission script. It is necessary to look at the output files which are numbered according to the job right now on aries.

Each user would log in under their own username, and would see their own experiments. Experiments are rarely shared between people as there is an overhead in setting up the

simulation, and it's in people's heads where their data is. It's usually easier to do everything yourself than try to explain it to someone else. For now, the prototype will just have one user.

Other Requirements/Comments

It may get confusing if the user is running more than one vulnerability grid study. Jobs might get confused in the status page. It may be useful to be able to tag simulations. At the moment people would only be working on one study at a given time.

As an alternative to a completed jobs page, the completed jobs could be added to the status page, and shown at the bottom.

Tulane don't have access to teragrid. They were recently access given to Louisiana Optical Network Initiative but don't really need them. HPCx and NGS are going to be the big ones. HPCx can be tweaked to use Globus. Asking Rene (Tulane cluster manager) to use Globus Brock: might be worth looking into.