From: Patrick Moran <pmoran@nas.nasa.gov>

Date: Thu Sep 11, 2003 8:34:27 PM US/Pacific

To: John Shalf <jshalf@lbl.gov>, patrick.j.moran@nasa.gov

Cc: Lori Freitag Diachin <diachin2@llnl.gov>, kohlja@ornl.gov, diva@lbl.gov

Subject: Re: Analysis techniques examples with FM

Reply-To: patrick.j.moran@nasa.gov

Hi,

On Thursday 11 September 2003 03:01 pm, John Shalf wrote:

On Thursday, September 11, 2003, at 01:16 PM, Patrick Moran wrote:

Also, I have some basic vis techniques (isosurfaces,

contours, color-mapped surfaces) implemented in terms of

FM. I could post them to the sourceforge site if there's

enough interest.

Yes, that would be very informative.

-john

OK, so I've uploaded one more module into the Field Model repository:

the Analysis Techniques (AT) module. It's available as one of the

subdirectories in the new 2.01 release. See the "Latest File Releases"

section of the main project page:

http://sourceforge.net/projects/field-model/

A little bit about how the example techniques in the AT module work --

there are three example techniques to start with: Isosurface, Contour

and Surface. Each can be constructed with a field argument

(an FM object). The execution model is relatively simple: you call

the execute method on the instance, and the final argument to execute

is a Graphics_Device instance. The Graphics_Device interface is

essentially 5 basic calls, each with an obvious correspondence to

OpenGL: begin, end, vertex3fv, normal3fv, texCoord1f. The semantics

are bascially OpenGL semantics. There are several implementations

of the interface, the two most important are

GL_Graphics_Device and Buffer_Graphics_Device. As you can

guess, the GL_* version calls OpenGL immediately, the Buffer_*

version records, and then plays back the graphics calls. See the

code, it's pretty simple.

The execute methods also take other arguments, depending on the

analysis technique type. All three examples take an FM iterator

argument, which enables the controlling program to specify subsets

of cells to process (e.g., split out work in multi-threading scenarios).

Other arguments, for example, would include a threshold level argument

for the isosurface technique.

In case it's not obvious, the code is prototype, work in progress.

The design is not set in stone. But it's working code. As I mentioned

before, I have Python wrappers and a little app that supports run-time

composition and execution, with a simple gui and OpenGL viewer

widget. I can show that next week if there's interest.

Pat