# Presentation: 565099

## The Scientist’s Expert Assistant Simulation Facility

- Karl Wolf, Sandy Grosvenor, Jeremy Jones, Anuradha Koratkar, Connie Li, David Matusow

## Introduction

- What is the SEA Simulation Facility?
- Why the SEA Simulation Facility?
- Highlights of the internal design
- Current status
- Future Plans

## What is the SEA Simulation Facility (SSF)?

- The SEA project was a proof of concept to putting the “eye” back in to observation planning.
- SEA contains a number of visual modules that can be run independently from the core SEA (Target Tuner and Exposure Calculator)
- Adopted by the STScI for production use (as APT), expanding to more observatories in the future
- The SSF breaks down an observation into elements of the light path
- Standard, simple interface to encapsulate underlying models
- Interfaces are model/platform/observatory independent
- 100% Java

##  Why a Simulation Facility ?

- For Observers - determine how various parameters affect the data and scientific objectives.
- “Phase 0” tools for initial “framing” of observations
- Validate proposed observations ahead of time
- New complex instruments driving need for newer visualization tools
- For Observatory Staff - characterize and understand the telescope/ instrument/ detectors.
- Better analysis of instruments with fewer calibrations
- For the Archive User - understand the quality and limitations of a archival images.

## SSF Design Objectives

- Test interactive and innovative ways to look at a proposed observation
- Scalable
- Layer the complexity - simple on top, with access to “gory details”
- Emphasis on scientific fidelity
- Pluggable, generic programming interface
- Non-observatory specific
- Multi-platform
- Distributed if needed/desired
- Compatible with early SEA versions

## Simulation Pipeline

**Energy****DataSet**

**Energy****DataSet**

**Energy****DataSet**

**Energy****DataSet**

**Energy****DataSet**

**Energy****DataSet**

**Energy****DataSet**

**Energy****DataSet**

**Energy****DataSet**

**Energy****DataSet**

**Energy****DataSet**

**Energy****DataSet**

**Energy****DataSet**

**Energy****DataSet**

**Energy****DataSet**

**Energy****DataSet**

**Visualizers display EnergyDataSets at a point in the pipeline**
**Never change the EnergyDataSet**
**Each is independent and “hangs” off an EnergyModel**
**ImagingVisualizer displays simulated image in Target Tuner**

**Models some aspect of the light path**
**Applies changes to the EnergyDataSet**
**Independent (they don’t know about each other)**

**Simulation Meta Data**
**Container/model for accumulated energy rates (not counts)**
**By location, wavelength, “type” (source, noise)**

## SEA Simulation Facility (SSF)

**Buttons for controlling the potentially lengthy render processing**

**Graphical Representation of the user’s pipeline**

**Visualization Area (note two point sources with different magnitudes)**

## EnergyModel Editors

- User can tweak model specific parameters prior to a simulation run.
- Can be simple property editor (default) or as complex as desired

**TargetArea Editor**

**Detector Editor**

## EnergyDataSet

- One EnergyDataSet per pipeline per simulation run
- Defines the processing context and contains:
- Simulation Meta Data
- One or more EnergyDataLayers
- Passed to each EnergyModel when it is its turn for processing
- Goal: to accurately and efficiently contain the simulation data.
- Tradeoffs:
- Possibly Huge Memory requirements (4Kx4K detector = 16M values).
- Multiple Wavelength data for each cell (spectroscopy)
- Quick and easy access to data values.
- As resolution increases so do computational load and storage requirements

## Storage Solutions

**Smart EnergyDataLayers** optimize data storage needs by using a sparse matrix and storing double precision values rather than Wavelength arrays unless necessary
**Binning:**
- The Pipeline Detector defines the maximum resolution (one cell per pixel)
- Binning uses lower resolution for faster processing
- User may select a subset of the data to run at higher resolution for more accurate simulation

## Current Status of SSF

- Initial design / architecture complete (May-June 2000)
- Now implementing first build (since July)
- Looking at existing simulations to be incorporated into the SSF
- NGST Mission Simulator (NMS)
- HST simulation code (TinyTim)
- Starting to work with ESO
- ESO has existing library of their own simulation models
- SEA has strength/expertise in visualization software

## Future Plans

- Increased scientific fidelity and detail
- Complete the pipeline GUI and the internal API for manipulating pipeline elements
- Prototype visualization approaches/GUI enhancements
- Emphasis on user interactivity
- Trials with 3D imaging and layering
- Fully expect that some will bomb, others will succeed
- Develop interfaces/models for several astronomical and instrument/detector models
- Pipeline Splitting – the ability to compare two sets of parameters