We are building a graphical interface for our astrophysical fluid dynamics simulations!

Team Members

The product will be used in two, and maybe three venues. The first venue is for graduate and advanced undergraduate education, as an aid in a class on astrophysical fluid dynamics. The second venue is in an "edutainment" context at museums and planetariums, to provide patrons with an interactive investigation of astrophysics. The third possible venue is real use in astrophysics research. For the second venue, adequate help and intuitive operation is an absolute necessity. In the other venues, such interactive aid and simplicity is "merely" a nicety, but extremely worthwhile.
 

It is worth pointing out that a component here is not solely a graphical interface unit.  Each component consists of both graphical user interface code and support code for obtaining, sending, and processing information before and after it is presented graphically to the user.  More formally, a component here is a collaboration of objects which conspire to accomplish a limited number of related tasks.

We intend the simulation system as a whole (the front end and the simulation code) to be distributed.  For those students and schools which don't have the computing power to run simulations on local PCs, we want the flexibility to run the front end locally, but run the simulations on powerful, but remote computers.  One could easily imagine letting the front end run inside of some web browser such as Netscape.  However, this means the front end will have to deal with connecting and disconnecting the simulation across the network, and cannot depend on the simulation itself always being available to respond to commands.   The front end will have to deal gracefully with network failures.  Also, the simulation cannot depend on the front end to be continuously connected and always running.  Users should be able to start and stop the interface without disturbing their (possibly) long running simulations on a remote computer.    This also leads to obvious, but complicated, issues of security, logins, and accounts.

One of the most important capabilities Java brings to the project is its object orientation.  The complexity of this project requires careful modular design.  Also, the magnitude of the investment this project represents encourages us to build the code with future enhancment in mind, so that the investment is long lived.  Object programming, when used wisely, can aid in acheiving these goals.    And an object oriented language can make this task much easier.

Sun's implementation of Java provides very convenient and powerful documentation capabilities.  It is a simple matter to include comments interspersed among the source code, which the document compiler can then pick out and turn into extensive hyperlinked documentation.  The programmer writes the programmatic documentation in only one place, leading to saved time and fewer errors.

Java has its problems as well.  It lacks a viable version of some standard debugging mechanisms (e.g. assertions),  and omits object oriented features found in other mature languages (e.g. templates, operator overloading).   We should be able to  work around these omissions in some effective way.

Java byte-code, because it is interpreted in many implementations, will raise some interesting performance issues.  As the project develops, we may find it necessary to rewrite time critical animation, or other behavior using a separate compiled language.  Java has a mechanism for encapsulating separately compiled code in a convenient way, which will make this task relatively painless.  Also, this mechanism makes it possible for us to link Java with the simulation code, which will have to be compiled for speed.
 
The  simulation programs are currently written in Fortran '77 and may be partially rewritten in Fortran '90 code.  In any event, these programs are currently command line and standard input driven.  They will need to be modified so that a GUI can drive them from a separate thread or process, possibly by wrapping Java classes around them.
 
 

 
 

Overview

1. The user picks a simulation scenario.  Some examples are supernovae (say a spherical blastwave propagating into a uniform environment), or hydrodynamic jet propagation (a confined inlet of supersonic gas into a uniform medium).
2. The user then decides on some initial conditions for each of the principal ``actors'' in the scenario.  For example they choose the composition, temperature, and other characteristics of the ambient medium, of the

blastwave source, or the jet.  This may include the choice of boundary conditions.
3. The user then starts the simulation running.  At this point, the user interactively views the simulation, and can stop it to try either a different scenario or different initial conditions.