Analyzing a High Energy Laser Modeling and Simulation Framework - PowerPoint PPT Presentation

Loading...

PPT – Analyzing a High Energy Laser Modeling and Simulation Framework PowerPoint presentation | free to download - id: 9838a-ZDk5M



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Analyzing a High Energy Laser Modeling and Simulation Framework

Description:

Analyzing a High Energy Laser Modeling and Simulation Framework. Computer Science Department ... Engineering-Engagement Modeling ... – PowerPoint PPT presentation

Number of Views:204
Avg rating:3.0/5.0
Slides: 25
Provided by: USNA1
Learn more at: http://www.usna.edu
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Analyzing a High Energy Laser Modeling and Simulation Framework


1
Analyzing a High Energy Laser Modeling and
Simulation Framework
Midn 1/C Eric Eckstrand SI495
Computer Science Department United States Naval
Academy Annapolis, Maryland, USA
2
Introduction
  • Our focus is on end-to-end lasing simulations
    that consider system performance
    modeling/assessment of weapon effectiveness from
    varying perspectives.
  • One simulation prospective Follow the physics of
    a shipboard laser's energy starting with
  • energy conversion from the ships fuel,
  • generation of the lasers light,
  • beam transport, etc, and
  • ending with illumination
    on target.

Proposed HEL MS architectures must fit into this
hierarchy, with data transfer facilities between
the levels as a design goal.
The military MS hierarchy pyramid.
3
Engineering-Engagement Modeling
  • Notional methodology for passing physics-based
    High Energy Laser (HEL) modeling results through
    to the mission-model level.

4
The Role of Software Engineering
  • Collections of such simulations must include the
    integration of a variety of laser devices, beam
    control technologies, and provide for atmospheric
    compensation considerations, and can be expected
    to contain significant overlap in functionality.
  • Software architectures developed for such
    simulations must be
  • extensible, and reusable
  • support data transfer between simulations to
    facilitate data traceability

Domain-Specific
65
Domain-Independent
Three Classes of
Software in a Typical
Software Application
20
Application-Specific
15
5
Component-based software engineering
  • Component-based software engineering focuses on
    constructing software from previously existing
    components in an effort to improve reuse.
  • Toolkits such as Carnegie Mellon Universitys
    Aesop System allow developers to mitigate
    disparities between assumptions made about a
    reusable component and the system in which the
    component is to be reused.
  • We analyze Northrup Grummans High Energy Laser
    Simulation End-to-End Modeling (HELSEEM)
    framework developed as part of the JTO HEL MS
    program.
  • The HELSEEM framework provides a message-passing
    based architecture for integrating dissimilar
    models, and supports the inclusion of both legacy
    and emergent modeling codes.

6
Northrop Grummans HELSEEM
  • Such frameworks can be either monolithic or
    modular.
  • Monolithic Approach
  • Northrop Grummans Approach
  • Modular Approach
  • Why?

High Energy Laser Software Simulation
HELSEEM
Laser
Target
Sensor
Propagation Method
Clock
Modeling framework must anticipate both future
refinements to the wave propagation model as well
as the emergence of competitive models with
varying levels of fidelity.
7
HELSEEMs Joint Message Passing System
  • HELSEEM provides a message passing bus,
    communication protocol, and message broker that
    together form the Joint Message Passing System
    (JMPS).
  • JMPS bus provides comm
    between components in sim.
  • Messages on bus are defined both by name and by
    the information contained inside the message.
  • Each component within the framework, including
    user-defined components, samples the bus for
    messages it can respond to.
  • Different components can be made responsible for
    getting the conditions that impact beam quality,
    actually computing the beam quality, and then
    displaying the resultant beam

8
Message Passing Hierarchy
  • Including a laser models code into the framework
    is a two step process, and involves building a
    shell of a propagation component for the new
    model and then integrating the model into the
    shell.
  • The JMPS protocols for propagating a
    wavefront can be viewed as a message passing
    inheritance hierarchy,
  • BlurPropagator redefines
    methods
    allowing for the default
    introduction of a low fidelity blur
    effect used to control output to
    the display.

9
Goal Integrating Legacy Laser Codes
  • Our goal was to consider the difficulty of
    integrating legacy laser codes within the HELSEEM
    framework.
  • The HELSEEM framework is written in Windows-based
    C and offers both
  • its own model of laser propagation, as well as
  • providing its users with a reuse-based capability
    of augmenting the framework with their own models
    of laser propagation
  • We incorporated a variant of NPSs Dr. Bill
    Colsons model for laser wavefront propagation
    through the atmosphere into the HELSEEM
    framework.

10
Propagation Component
  • Project Focus Replace HELSEEMs default
    propagation code with Dr. Colsons code

HELSEEM w/default propagation
Laser
Target
Sensor
Propagation Method
Clock
HELSEEM w/Colsons prop
Laser
Target
Sensor
Clock
Dr. Colsons Propagation Code
Propagation Method
11
Colsons model for laser wavefront propagation
  • Code used by NPS physics graduate students as
    part of intro to Free-Electron Laser coursework.
  • Input parameters define the propagation
    environment.
  • UNIX-based C program generates and progressively
    manipulates a laser wavefront.
  • Virtual lenses allow modeling various conditions
    such as thermal blooming

12
Incorporating Dr. ColsonsPropagation Model
HELSEEM w/Colsons prop
Laser
Target
Sensor
Clock
?
Input file initialization parameters
Script File initialization parameters
2
1
Legacy Prop Code
NewPropagator
NewPropagator w/ Legacy Prop Code
Output File Representation Of a propagated wave
Approach 2 Legacy Code rewritten as HELSEEM
entity
Approach 1 Legacy Code as External Entity
13
1st Approach Legacy Code as External Entity
  • Colsons code propagates wavefront by
    incrementally manipulating beams underlying data
    representation.
  • Each increment partially propagates the
    wavefront, and can be viewed as individual slices
    of the wavefront, or in aggregate as a 3D view of
    path from transmission source to target.
  • Treated legacy code as an external entity rather
    than rewriting the wavefront propagation source
    code to create a HELSEEM component.

14
1st Approach Leaves Legacy Code Intact
  • Create Microsoft Visual C program to house
    system calls to legacy code
    written in C under Unix
  • Make system call to legacy code in
    HELSEEM component
    (NewPropagator.cpp)
  • Read output of legacy program and process
    to a form understood by
    HELSEEM (Intensity Grid)
  • Place the grid in a HELSEEM message
  • Broadcast the message via JMPS
    message broker network

Sensor
Target
Laser
Script File
Clock
Legacy Code
Propagation Method
Display
Output (Intensity Grid)
15
Legacy Code via System Calls
  • HELSEEM represents a lasers wavefront as an
    intensity grid and a phase grid, with a
    one-to-one correlation between the output
    produced by the legacy code and the input
    required by HELSEEM framework for intensity.
  • Legacy code minor modification in order to
    produce output for phase angles of each complex
    entry in grid,
  • Required
    pre-processing

    to prepare grid for
    entry into
    JMPS
    message broker.

16
Advantages of Legacy Code as External Entity
  • Invoking the legacy code via system or remote
    calls allows
  • minimization of code transfer from the legacy
    code to the corresponding HELSEEM component, and
  • the ability to run a
    wavefronts prop
    code on
    disparate
    hardware.
  • The 2nd approach we
    took was to rewrite
    the
    legacy code to allow its
    inclusion as a
    self
    contained HELSEEM
    component.

17
2nd Approach Convert Legacy Code to HELSEEM
Component
  • Convert legacy codes C functions into C
    functions
  • Move the functions and variables into the
    NewPropagator class (Converted Legacy Code
    below) as private members
  • NewPropagator class
    designed to accept

    input from a script file
  • Write the script file
    section that
    inputs the
    initialization parameters

18
2nd Approach, Legacy as HELSEEM entity
  • Advantageous when the legacy code takes on more
    responsibility than just wavefront propagation.
  • In our case, we had code that generates an
    initial beam and also contains the model for
    propagating the beam.
  • Within HELSEEM, generating a wavefront should be
    the responsibility of a component within the
    framework since generation depends on the
    characteristics of the laser which should not be
    visible to the other components.
  • Disadvantages
  • Not all legacy code can be easily re-written.
  • Legacy code may run faster on dissimilar
    architecture

19
Advantages provided by the HELSEEM Framework
  • HELSEEMs advantages center around the ability to
    communicate with any component by broadcasting a
    message via the broker.
  • Framework supports the
    ability to write additional

    components that transform one
    messages contents to a different
    format which
    tends to mitigate data model disparity issues.
  • Took this route with our 2nd approach in order to
    compute phase angles that HELSEEMs display
    components could recognize.
  • Suggests that a message arbitrator would be
    useful to
  • determine which messages a component may, or
    should, respond to,
  • especially where more than one component can be
    expected to act on the same message.

20
Advantages provided by the HELSEEM Framework
  • Other advantages provided by HELSEEMs approach
    include support from the framework for the user
    to tailor the output.
  • For example, the legacy codes
    propagation can be viewed as a series
    of two dimensional slices
    of the lasers wavefront.
  • Users can add their own user-defined display
    components to the framework.
  • These components could display a 3D view of
    the beam during propagation, or present tables
    numerically depicting the computed intensity of
    the beam at any or all points along propagation
    path.
  • This extensibility makes HELSEEM particularly
    valuable for end-to-end simulations.

21
Areas of Improvement
  • The ease with which legacy propagation codes can
    be made to interact with the HELSEEM framework.
  • If HELSEEM were modified to support generalized
    wrapper classes designed for integration with
    laser propagation codes, much of the effort
    needed to integrate legacy code would be
    diminished.
  • Such wrapper classes would need an interface that
    HELSEEM could expect to dynamically invoke.
  • The legacy code would then need to be tied in
    only with the wrapper class, leaving little
    knowledge required on the part of the user
    regarding the inner workings of the HELSEEM
    framework.
  • This requires the identification of a super-set
    of methods and data used in end-to-end high
    energy laser simulations

22
Areas of Improvement
  • We found that while the hierarchy of components
    capable of responding to user-defined JMPS
    messages is readily expandable, the underlying
    data model is somewhat limited with regard to
    what data can be placed in a message.
  • We cannot, for example, send a message directly
    to a display component that contains information
    that describes how the propagating wavefront
    looks on a target, but must instead follow the
    HELSEEM message passing protocols though which
    the data is manipulated according to the
    component(s) receiving and acting upon the
    message.
  • A standardized but expandable
    data model would prove
    beneficial for
    end-to-end
    simulations.

23
Conclusions
  • Simulation environments that support integration
    and substitution of laser modeling codes of
    varying fidelity are required for high energy
    laser end-to-end simulations.
  • Northrop Grummans HELSEEM framework supports
    tracing a lasers energy from initial conversion
    through to target illumination.
  • Such simulations benefit from a modularized
    architecture in which components can be modified
    or replaced without significantly impacting the
    rest of the simulation framework. 
  • We incorporated an existing laser propagation
    model into the HELSEEM framework, and considered
    the frameworks underlying component model from
    the perspective of such legacy code integration.

24
Future Work
  • Consider the runtime impact of the various laser
    models communicating via the HELSEEM message
    broker.
  • There is a wide range of models with different
    degrees of fidelity (mathematical accuracy).
  • High fidelity models typically take significantly
    longer to compute a result than a lower fidelity
    model.
  • An end-to-end laser propagation simulation can
    expect to integrate models of differing fidelity,
    and it would be useful to understand the impact
    on message passing via the broker in terms of
    timing issues between models.
  • For example, if one model produces a high
    fidelity, but short-lived, result for consumption
    by other components via the broker, then the time
    spent conducting message brokering must be
    evaluated to ensure timely use of that messages
    data within the simulation.
About PowerShow.com