MOTIVATION

  1. GUI PREFERENCES VARY: There are users with varying personal preferences for graphical user interfaces (or key typing vs. mousing) including those that do every thing from the command line. Therefore any Graphical User Interface (GUI) should not be totally disconnected from the Command-Line Interface (CLI), but rather be built upon it.
  1. CODE FAMILIARITY VARIES: There are users with varying levels of experience with the code (even among developers who may know parts of the code really well and other parts not at all). Therefore, when codes are brought together there should be ways of exposing the "rules" or parameters to set up a code component in a way that can be read-in by the GUI program.
  1. LESS OPERATIONAL ISSUES: It is understood that there is a need to help users better deal with the mundane operational issues that deter from the science endeavors.
  1. INCLUSIVE OF THE NOVICE: In the interest of creating useful simulation frameworks, the idea of being inclusive of "novice" users (where novice does not mean naive, just new to some aspect of the framework) so that the investment to get basic results is minimal. This reduces the hurdle to try out the framework and allows more potential adopters to see the value and time savings.
  1. INTEGRATED APPLICATION: There is a recognition from users to have an integrated interface that is a starting point to introduce users to the framework. Because of this integration of interface features, we call our application FacetsComposer, where ...

            Composer = Setup + Run + Output + Visualize + Help

FEATURES

Validation of Input BEFORE Code Execution

The FACETS input file DESCRIPTION is composed of a set of XML files so that are easily read into the Composer at start-up. This description allows for...

  • Validation, currently validating...
    • Component Hierarchy (containment)
    • Component Setup Attributes and Kinds
    • Attribute Types (int, real, string, vectors, choices)
    • Component/Attribute "requiredness"
  • Color-Coded Editing
  • Context-Sensitive Palette of Components/Attributes
  • Context-Sensitive Help

Working on...

  • Much more validation possible
  • Other "auxiliary" input files can be edited/visualized.

Framework Execution To Help Novice Users Become Power Users

The power user works with commands and script in the login shell, to execute components within the framework. We are trying to duplicate this rudimentary workflow in an assisted way with checks for the novice user by building scripts for the user and using SSH to execute them remotely.

Some services to help users with runs...

  • Get ENVIRONMENT variables correct
  • Handle Batch System interaction (submission & status)
  • Setup MPI parameters
  • Ensure that all files are present (or copied to remote run location)

We are using our experience with local systems (PBS, Linux Clusters, Parallel Applications, etc.) to build a system that will work for FACETS. The SSH plumbing is done and the framework-related setup is under way.

Embedding Powerful Visualization Windows

Powerful visualization tools by nature present the user with a large number of features. This is often overwhelming for the user that is more familiar with the physics, than with visualization terminology and conventions. The Composer approach is to take the VisIt code base and embed pre-configured visualization windows that give the user some indication of what is going on in the data.

  • Remote & Parallel Visualization Through VisIt
  • Default Visualization Views Pre-Constructed for user
  • Full VisIt Capability Present For Power Users.

Context Sensitive Help

The HELP in the Composer application is...

  • HTML-based (allows for reused of documentation)
  • Sensitive to the context of what the user is doing (F1 key press)
    • Any open file is known
    • If file is opened, then the cursor position in editor is known
    • Any execution host information selected is known