Hi, I have attached a closeup picture of some of the older data from the GTC code (actually GTC_S, but the only difference is the shape; one is circular, the other has this funny shape).
You can see the mesh structure per plane, and by looking at this, you can understand some of Matt’s comments better. More comments in what you wrote with »>
Scott
—–Original Message—– From: hecura-bounces@mail.cs.unm.edu [mailto:hecura-bounces@mail.cs.unm.edu] On Behalf Of Matthew Wolf Sent: Saturday, October 27, 2007 1:48 PM To: hecura@mail.cs.unm.edu Subject: [Hecura] GTC annotation pipeline example
Hello, all.
I had a chance to sit down with Scott Klasky and get more detail on some
of the post-processing and visualization that they do with the GTC code. This is my best shot at explaining the technical bits without some amount of drawing on a whiteboard. This is the process used to generate the visualizations that we use on the “bad data” slides, if you
remember – the circular cross-sections with red streamers breaking out radially, with a background that goes from white to yellow.
You can see the beginning of the breaking of the streamers/eddies in
the slide I attached
If you think of the simulated plasma as being a donut, we will be looking at a cross-section slice made by cutting radially out from the center of the donut. We will also be looking at the grid data, not the particles... so we need to be sure that the output3d functions are pushing out the correct data. I’ll tell you where to pull the relevant stuff out of the traditional hdf5 files; Jay will have to speak up as to
how to get at them with adios.
This should be there in ADIOS. Chen placed them in a while ago. I
forgot the name of the file that gets converted over to the RUNcoord.h5? Chen can answer this to me, and I will send back the answer.
Note that I will try to clean this up a little when I find a copy of RUNcoord.h5 that I can snoop in – I couldn’t find one where I thought it would be on ewok. Any of you who will be directly working with the data, please ping me and/or Scott and we’ll try to clarify.
First, we need to extract the grid that describes the poloidal plane. It isn’t a structured grid, but the grid points are organized in RUNcoord.h5 based on a binning in the radial direction. ie [rmin, rmin+dr), [rmin+dr,rmin+2*dr), ... [rmin+(nflux_surf-1)*dr, rmax), where
dr = (rmax - rmin)/nflux_surf. In the file, the number of those bins is
called number_of_flux_surfaces, and the data in the poloidal grid is just the number of points in that bin. So the total number of points in
the grid slice is just the sum of the integer values in the poloidal grid array.
The actual x,y,z coordinates for each of the points are stored in the RUNcoord file under the (highly suspicious) names X, Y, and Z.
Good guess
Next in processing, you need to create a graphical mesh from the raw x,y,z locations. As always, you need to be sure to respect the ordering
of your loops when making the mesh. Scott makes a quadrangular mesh, with the occasional triangle (in order to turn round the circle) as a degenerate quadrangle. You could use one of the standard triangulation packages, but Scott also sent me the core from his AVS routines that does this.... I’ll pass that along separately. Basic idea, though, is that you start on the outside ring and move around in a consistent direction, finding the nearest point on the inner ring to that point, and then building the quadrangle using the nearest neighbor paths.
I used my routines, because I mainly worked on a 3d version of this,
which is a bit more complex for 3rd party packages.
Now that the mesh is created, you need to read out the scalar potential information (represents the electrostatic potential on the grid points). This is written out in the PHI_*.h5 files – it is a multidimensional array of size [number of poloidal slices, number of points in a poloidal slice]. For our purposes, we can just pull the 0th
slice, and read in the values of the potential onto the grid.
In order to establish the color map, you need to determine some sort of global min & max values for the potential for the entire length of the run. This means we more or less need to run the code once with whatever set of parameters, and then use that to set reasonable values for the rest of the demo. Min & Max are generally symmetrical or very close to it, so that values are generally in a range [-big,big]. Using that “big” value to scale everything, Scott’s favorite color map assigns
black to 0, with positive values getting increasingly warm colors (red-orange-yellow-white) and negative values going increasingly cool (blue, purple, magenta, cyan).
My guess is that you can use about -1e-6 to 1e-6 for the colormap.
In the beginning you will see nothing, but later you will see lots.
Once you have a mesh with colors assigned on all of the vertices, it’s pretty straight-forward to load into whatever your favorite visualization package is. Dropping it into a java3d module would probably work best, given that we want this to run in eclipse eventually. But having a native opengl rendering would be great too, or
using opendx, or raytracing, or...
for 2D, you can probably use Java2D. Why do you need java3d for 2d
images?
I think this makes a nice iograph/metabot example. You could data hit the disk immediately, or go through some of the mesh embedding operations, or all the way to a rendered image. Going forward, it should also be a nice motivator for some of the custom data selection work in the datatap implementation.
I will also get an example in the near future which will do binning
of particle data. You can then generate a plot of this, and even change some of the parameters for real-time changes in this. Perhaps this is too ambitious for SC, but you will probably want it later.
Hope this still makes sense...
too me, yesThanks Matt
Matt
