Community Admin's picture

Hi, John Readey here. I'm the chief architect of the Intel Array Visualizer. Till now I've been handling AV-related questions on the Visual Fortran forum.Now that AVisincluded with Intel C++ as well as Intel Visual Fortran, we thought it made senseto havea separate forum devoted to AV..

We arevery proud of this product andare looking for ways to improve it. I'm hoping we can get hearfrom AV users and potential users on how to make it even better.

This will also be the spot to exchange interesting graphs and data files, and to exchangeadvice and code on how to do interesting things in AV.

Please use this thread to introduce yourself to the community. If you can briefly describe how you use AV for your work, that would be great!


Message Edited by JohnReadey on 07-28-2005 10:14 AM

9 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

I'm Joan Buchanan, technical writer for the Intel Array Visualizer online help. I welcome your feedback andlook forward to hearing yoursuggestions on ways to enhance the documentation.

Wendy Doerner (Intel)'s picture


I am a technical consulting engineer for the Intel Fortran Compiler and the Intel Array Visualizer. In addition to being one of the engineers who answers your Intel Premier Support questions at, I also run our Compiler Beta Programs and deliver Intel Software College trainings.

I will be a backup host for this forum and look forward to reading and responding to topics on Intel Array Visualizer.

Hi, Beau Paisley here. I am with Harmonic Software, providers of O-Matrix,, an interactive language for analyzing engineering and scientific data.

We have used the Array Viewer to create and add-on for O-Matrix, rendering O-Matrix results within Array Viewer. We greatly welcome input on this tool and look forward to hear how other technical computing professionals are using Array Viewer.

Hello, I'm Chris Johnson, Senior Development Engineer at the Pacific Northwest National Laboratory (PNNL). I work in the environmental field on bioremediation and groundwater modelling. I am also a developer of the Reactive Transport in 3-Dimensions (RT3D) code. RT3D simulates the reactive transport of multiple chemical species in groundwater. RT3D is included in the major groundwater modelling packages (GMS, Visual Modflow, Groundwater Vistas, PMWIN), which provide graphical user interfaces (GUIs) for setting up a reactive flow and transport model. RT3D is also available as a standalone item at the RT3D website ( with executables, documentation, examples, and Fortran source code.

I got interested in the Array Visualizer when it came out with the Compaq Visual Fortran product. Being a developer of RT3D, I often bypass the tedious GUIs in favor of setting up input files via Excel and/or VBA scripts. But Excel isn't particularly good for visualization of the RT3D output of chemical concentrations over time. And another concern was that most of these groundwater modelling GUIs are very expensive and I wanted an inexpensive way for RT3D users to be able to examine their data. The CVF Array Visualizer came with an Active-X control that worked very well for displaying data from a single layer of a RT3D model grid in Excel and I could even put together an AVI animation via a third-party utility. So I was generally pleased.

With the re-written Intel Array Visualizer, I have found some nice improvements, some things that I miss, and some features that I would like to see implemented. I rather miss the property pages that the CVF AV Active-X control had. They had plentiful options/details that let me do what I wanted to the control. The latest version of the Intel Array Visualizer (IVF 9), has a number of nifty features, including the 2D vector plot, the Quad Mesh plot, and the scripting capabilities for such plots as the 3D view in astrojet.h5 (although I'm personally not fond of the Array Viewer being in a "web browser" container).

Here are some additional features that I would like to see in AV, keeping in mind that I'm coming from the perspective of groundwater modelling and looking at transient movement of contaminant plumes. Groundwater modelling involves spatially distributed data (versus a generic array of numbers), so some of these features pertain to helping view the data in a spatial context.

1. Variable grid spacing in X, Y, and Z. I believe that AV has this capability ("Scale Source"), but I have not been able to put together a working example yet.

2. Deformed top layer. It is often nice to be able to show the variation in elevation of land surface for the topmost layer of a 3D grid while showing other data in the grid. For example, I may want to look at a 3D view of a grid with values for hydraulic conductivity (a spatial property of the soil) as a color fill of the grid cells and also the land surface elevation of the top layer that would indicate locations of hills/rivers/lakes/etc.

3. Image map and/or DXF draping or over/underlay. Another spatial feature - it would be nice to be able to import a jpeg/tiff/DXF/DWG file and show it above/on/below the array grid. That would provide perspective and help with interpretation of the data. Draping the figure over the top of the grid would be useful, particularly in conjunction with a deformed
top layer. Transparency of images would be useful too. Drop lines would add additional perspective/spatial relationship.

4. 3D vectors. 2D vectors are good, but I'd like to be able to see 3D vectors. In our case the data would represent groundwater velocity in the 3D grid. Ability to change the color and/or length of the vectors based on the magnitude is useful (and I think exists currently for 2D vectors).

5. Isosurfaces (3D contours). Isosurfaces are very useful for seeing where a contaminant plume travels. Slices through the grid would help see the interior of a set of isosurfaces (for multiple contour levels). The astrojet.h5 example shows the slice capability, but I'm thinking along the lines of where you remove/hide say a quarter of the 3D grid (or perhaps an eighth) in one corner to reveal the contours on the inside of the grid. This would involve a method for hiding/showing layers, rows, columns, or blocks of grid cells (perhaps that can be done via sections). And if you do isosurfaces, might as well add a method to retrieve the volume and surface area of the isosurface (and the area encompassed by a 2D contour).

6. Change of data with time is another thing we look at. As I mentioned, I implemented a method to do that with the Compaq AV. I believe that scripting would work for the Intel AV. But the ability to generate an AVI animation file would be very useful. Also, the ability to copy a graph view as an image (jpeg/tiff) would be useful (for putting into documents or presentations) and may feed right into generating an AVI movie.

I think that most of these features are generic enough that a fairly wide audience would be interested. I'll be interested to see what other users have to say.


Community Admin's picture

Welcome to the forum Beau and Chris!

Beau, feel free to direct your customers to this forum if they have questions about using AV.

Chris, thanks for providing such a detailed description of the features you'd like to see in AV. I can't promise we'll have all of these implemented for the next release, but I'm hoping to get some of these done at least.

One thing that should work right now is variable grid spacing for image and height plots. Take a look at the attached file, plots: "VGrid Image" and "VGrid Height Plot". These plots have the Scale Source set to the arrays "xscale" and "yscale" to setup a non-uniform grid. Is that what you were looking for?

We didn't implementProperty Pages in the AV controls primarily because it would duplicate the work that was done for the property pages in the Array Viewer. But it should be fairly convenient to use the Viewer to examine/modify properties even if your primary focus is the AV controls. Take a look at the VB sample: AV/Samles/VB6/XYZPlot. If you run the sample you'll notice there is a checkbox labeled "Array Viewer". When you check it, the Array Viewer comes up and you should be able to examine the same graph as is displayed in the VB app. By right-clicking on the graph in the tree pane, you'll get the property page for the graph. When you modify these properties, the changes will be reflected in the AV control hosted by the VB app. Let me know what you think of this approach!

Jennifer J. (Intel)'s picture

I'm a technical consulting engineer for the Intel C++ Compiler and will be a backup host for the Arrary Visualizer for questions related to AV & C++ compiler. I'm also one of the many hosts for the Intel C++ Forum.

Feel free to send us your thoughts, ideas and suggestions or questions, we'll be happy to help you.


My name is Jim Dempsey. My introduction to the Array Visualizer was entirely by accident. I required a decent FORTRAN 90 compiler on a Windows platform. And by chance I chose the Intel compiler over trying to hack in a "free" open source compiler. Mainly I wanted the 1-year support contract to help with the growing pains. I haven't programmed in FORTRAN in over 30 years. The project I wanted to convert was a program written as an evolutionary process and is now produced on a Mac in F77. I wanted F90 on Windows.

In addition to sprucing it up to F90 with major rewrite of data layouts (fixed size COMMON blocks to allocated memory) I also wanted to add some graphics capabilities. The old code pumped output into a database and then you had to write a post processor to construct a visualization of the run. This may have been OK for the designer of the original program but it was not suitable for my needs.

My requirements were to see a visualization of the simulation as the simulation was churning out the data. This would permit me to observe what is happening during the run and to formulate corrective action during the run rather than as a post mortem dump-like process.

Originally I had intended to try to integrate Blender into the F90 program. But the Blender documentation (in regards to program interface) was (is?) in worse shape than the AV FORTRAN documentation (which sad to say is not very well written). At first I was hesitant at integrating AV into the application. It seemed too restrictive (at least what was available from the documentation). Virtually all the documentation, including examples, showed static graphs. What I needed was dynamic graphs (animated graphs). Last year none of the examples illustrated an animated graph. This year there is an example but it is not written in F90.

Almost by accident I came across avUpdate the documentation only indicates you can use this call to inform AV that a change occurred in data tables that AV should know about. I put 2 + 2 together and concluded that AV could be used to animate graphs.

Getting the graphs to animate was a steep learning curve. Due to the lack of adequate documentation.

After much work and effort I am extremely pleased with the capabilities of AV. The application now presents graphs, some of which contain upwards of 59 plots, all but one of which are dynamic plots.

Now for a bit of constructive criticism.

As a (formerly) new user to Array Visualizer from the FORTRAN user's view point I can only say that the documentation sucks almost to complete vacuum.

The problems lie in much of the FORTRAN interface is not in the Index. You can find most of the subroutine names with a search. But then you need to know or guess at the name. Then when you get to the topic, few are written well enough to explain the use of the function. Most are documented not better than the INTERFACE sections in the header files.

The biggest obstacle is, all the interface calls document a principal argument, object, as the opaque object. i.e. there is no description as to what the object is or how you extract the object handle from the database maintained by AV.

In order to derive this information I typically had to search the sample programs for use. Often a Java script file had a reference to the function of interest. In some cases the FORTRAN call could be figured out by one
line of the .js file. But in other cases a little bit of reverse engineering was require to go back up the object tree in .js and then came the job of bringing this back down to a conversion back into FORTRAN.


subroutine avSetViewpoint(object, coord, val, status)

integer(int_ptr_kind()), intent(IN) :: object

integer, intent(IN) :: coord

real(8), intent(IN) :: val

integer, intent(OUT) :: status

end subroutine avSetViewpoint

What is object. I know it is the camera but (for FORTRAN) just how do I go about getting the object handle for the camera.

So... I look in the index under camera. I find: center of interest, orientation, view angel, viewpoint. I also find Camera property and CameraUpdate event. None of the topic titles indicate something that would extract the camera handle from the AV database. Hmm... not in the index.

Well... I know most, if not all AV function/subroutine names are prefixed by Av So... I enter in AvCamera. I find AvCamera object. Which tells me the properties and methods of how to use a camera but it does not tell be how to obtain the camera object handle.

So... I put in a search for "camera" and I find 15 topics that require the camera object handle but none that tell how to obtain the camera object handle. Hmm... not in search...

So... I use Visual Studion IDE editor to search for "camera" in all the files starting at "C:Program FilesIntel" and try to pick out sample uses and then try to reverse engineer the syntax from an example, most of which are not in FORTRAN.

I discover that the proper FORTRAN subroutine is avCamera. What??? I looked for avCamera in the index and found it. But the call the the FORTRAN function was not there. There was the description of the camera object (properties and methods) not much help there.

So... back to Search "avCamera" and find the topic "Camera Property" which lists the FORTRAN call for avCamera. Technicaly speaking avCamera is not a property of a Camera object so what is this call doing under "Camera Property", never mind I got the call now....

Almost there. Dang!!! another reference to the opaque and ubiquitous "object"

Ding!.... round two.

Oops! Now I discover the documented call to avSetViewpoint doesn't match the interface statement in the library... So... I must figure out the call.

And so it goes. Over and over and over.

I almost gave up on AV after several rounds of this type of rope-a-dope activity.

From a new users point of view this was a horror show.

Now for the constructive part.

I strongly suggest that you place into the documentation an outline of the calls to the helper functions that obtain the object handles regardless of how redundant it may look in the documentation.

subroutine avSetViewpoint(object, vector, status)

integer(int_ptr_kind()), intent(IN) :: object

real(8), intent(IN) :: vector

integer, intent(OUT) :: status

end subroutine avSetViewpoint

Sample use:

Real(8) :: CameraXYZ(3)


hRoot = avGetObject("/")


call avCreateGraph3DObj(avGraphs(hRoot), "graph", hGraph)


call avSetViewpoint(avCamera(hGraph), CameraXYZ, iStat)

A few extracts of code would have cleared things up immensely.

From this example I can clearly see tha
t "object" is a camera object obtained from a call to avCamera with a graph object which in turn was obtained when creating the graph. And the creation of the graph required a Graphs handle obtained from the graphs section of the root handle and the root handle which was obtained from a call to avGetObject.

Enough for the gripes.

I have found the AV library a powerful feature that could attract customers... But only if you can develop a user base. The biggest obstacle to developing a user base is poor documentation. Please put more effort into your documentation.

Jim Dempsey


System and Method for Space Elevator

Community Admin's picture

Hi Jim,

Welcome to the forum! I appreciate your lengthly critique. I can see that documentation is really critical in getting people to try and stay with AV. I'm going to start a new thread to discuss what can be done to improve the documentation. See: Hopefully this will generate some interesting discussion on how the documentation can be made more useful.

Login to leave a comment.