You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 10 Next »

Scenarios View

Displays user scenario(s). A scenario is similar to the concept of a project where it contains a collection of parts (input datasets, output datasets, etc) that are part of the scenario. Users will launch jobs on the HPC machines that run workflows using the inputs in their scenario and when a project completes, the outputs should be added to the users scenario. A user might have multiple scenarios open at once, close scenarios, or even delete scenarios from their scenario view (deleted from the view, but still in the repository) so we'll need to manage which scenarios are in a session and what is their current state (open/closed). For example, I might have scenario A, B and C stored in a local repository, but only A and B are loaded into my application.

Scenario

A scenario will contain user data specific to a scenario (or project). This will include datasets and a define service for launching HPC jobs. or

ScenarioBean extends CETBean implements Serializable, CETBean.TitledBean
private String title;
private String description;
private Set<DatasetBean> dataSets;
private RMIServiceBean serviceBean;

RMI Service Registry

The service registry contains all machine defined as available to the user for installing the PTPFlow plugins required to run HPC jobs and return status information to the client.

RMIServiceBean extends CETBean implements Serializable
// Service Info
private String name;
private String platform;
private String deployUsingURI;  // e.g. file:/
private String launchUsingURI;
private String installLocation;  // e.g. /home/user_home/ptpflow
private String rmiContactURI;
private int rmiPortLowerBound;
private int rmiPortUpperBound;
private int gridftpPortLowerBound;
private int gridftpPortUpperBound;
private Date installedDate;
private boolean running;

Repository View

Rather than a single repository view, this might actually be multiple views that are configured to show a particular type of data using a content provider that gets the data type from the tupelo contexts it knows about. For example, we might have something like "Data Repository View" that shows all datasets (e.g. input/output datasets) and a way to manipulate them (e.g. add tags, annotations, etc), "Scenario Repository View" that shows all defined scenarios, "Service Repository View" that shows defined RMI service endpoints for launching jobs, etc. This seems like too much disparate information to display in a single view.
A repository is anything that is used for storing data, scenarios, and beans that describe things.

Functional Requirements

  1. Import datasets that will be used as input to HPC workflows such as Mesh files, input files (e.g. mach number, poisson ratio, etc)
  2. Store output datasets
  3. Store scenarios
  4. Store defined RMI services
  5. Store known-hosts
  6. Other functionality?
  • No labels