Difference between revisions of "Visualization of simulation results"

From Einstein Toolkit Documentation
Jump to: navigation, search
(Add GT's current.)
Line 5: Line 5:
 
;Frank Löffler: rsync (smaller) files by hand, use gnuplot/ygraph/VisIt to look at current results often using e.g. scripts for plotting multiple things with gnuplot
 
;Frank Löffler: rsync (smaller) files by hand, use gnuplot/ygraph/VisIt to look at current results often using e.g. scripts for plotting multiple things with gnuplot
 
:              I would like to see support to obtain relevant files easily (simfactory comes to mind), and to have some kind of tool generating a short overview of the state of the simulation. An HTML page would probably not be a bad idea, and ideally this should also be able to run on (most) production machines, so that copying the actual data files would not be necessary.
 
:              I would like to see support to obtain relevant files easily (simfactory comes to mind), and to have some kind of tool generating a short overview of the state of the simulation. An HTML page would probably not be a bad idea, and ideally this should also be able to run on (most) production machines, so that copying the actual data files would not be necessary.
 +
;Tanja Bode
 +
:''Current'': Collection of bash/python/gnuplot/ygraph/VisIt scripts automatically generate a variety of interesting plots and generate an internal webpage summarizing the most interesting.  Our script for VisIt animations has been generalized to take a command-line description of the quantity to be plotted so its flexibility is maximized.
 +
:''Interests'': I would like to see support for dynamically set HTML summaries of a run and its status.  Perhaps by specifying certain basic system properties (0-2 BHs, with/without hydro, presence of non-BH compact object) to select from subsets of standard plots and a few animations.  Having more flexibility in the animation choices on top of this as we have locally would be useful. Having these function on a cluster would be a plus, but not necessary.

Revision as of 18:04, 31 January 2011

The current state of people producing quick-and-dirty, overview-like visualizations from their running and run simulations seems to be that everyone has their own scripts/tools, usually just barely doing the specific task they are designed to do. It would be beneficial to have a set of common tools helping with at least some parts of this process of a) retrieving parts of the files, and b) producing some overview of the state of a simulation. The task in question is not to create high-quality plots for e.g. publications, but more a monitoring/debugging kind of overview.

To get this started, everyone interested is asked to shortly describe below what they currently do in that respect.

Frank Löffler
rsync (smaller) files by hand, use gnuplot/ygraph/VisIt to look at current results often using e.g. scripts for plotting multiple things with gnuplot
I would like to see support to obtain relevant files easily (simfactory comes to mind), and to have some kind of tool generating a short overview of the state of the simulation. An HTML page would probably not be a bad idea, and ideally this should also be able to run on (most) production machines, so that copying the actual data files would not be necessary.
Tanja Bode
Current: Collection of bash/python/gnuplot/ygraph/VisIt scripts automatically generate a variety of interesting plots and generate an internal webpage summarizing the most interesting. Our script for VisIt animations has been generalized to take a command-line description of the quantity to be plotted so its flexibility is maximized.
Interests: I would like to see support for dynamically set HTML summaries of a run and its status. Perhaps by specifying certain basic system properties (0-2 BHs, with/without hydro, presence of non-BH compact object) to select from subsets of standard plots and a few animations. Having more flexibility in the animation choices on top of this as we have locally would be useful. Having these function on a cluster would be a plus, but not necessary.