Appeal for a sticky thread to start a sign list to re-introduce the Array Visualizer in IVF

Appeal for a sticky thread to start a sign list to re-introduce the Array Visualizer in IVF

Hello Steve,

is it possible to start a sticky thread as a list for people to sign a appeal for re-introduce Array Visualizer in IVF?

This might be a way to show decision makers from intel the wish from the users.

Thanks in advance

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

Here you are. Have at it. And yes, I will make sure that the "decision makers" see this.

Retired 12/31/2016

Add me to the list

The Array Visualizer was one of the least understood products of Intel Software and thus was not fully exploited the Intel Software marketing. It was a sad day for me when Array Visualizer was dropped.

Marketing may have assumed AV was only used in support of debugging and integration into development platforms was an incessant problem. Marketing didn't use or understand the product. The Array Visualizer was the only reason why I chose Intel Visual Fortran in 2005. A compiler that was marginally faster (in those days) was not the selling point. The visualization library that came with it was the selling point. Let's put Visualization back into Intel Visual Fortran. (Or is thisIntel Visual Fortran)

My use of AV was in driving 3D charts from within my simulation program during simulation runs. AV, though difficult to program, provided features and flexibility not found by any other means. With AV you can easily get many views of your data as well as multiple instances of different views of your data. If you failed to program a chart, you could add one ad-hoc while your simulation run was running. There are too many good parts about AV to mention here.

Using OpenGL with GLUT (F90GL), though easier to program, is feature poor as compared to Array Visualizer. Although Array Visualizer may be built on top of OpenGL and serves the functionality of GLUT, the integration into IVF was different and these differences have distinct advantages. The traditional programming model of GLUT has the application subservient to the display driver. Whereas for simulation, you want the display driver to be subservient to the application. You cannot have a computationaly intensive simulation running in a display driver idel loop. (I've written solutions around this, but this is not a traditional programming for GLUT).

Jim Dempsey

Yes please!!


I want AV too.

I am using AV for debugging and in my applications to display 3D data (surfaces).


Add me to the listNobat

If, when replying, you can write how you used AV, it would help.

Retired 12/31/2016

I am working in the
atmospheric science community (air pollution, climate models). In the
part I am working, Fortran is our major language to design methods
and models. If you are working with a 3D atmosphere, changing over
time a visualisation tool is a huge advantage.

I started my
scientific life with free Fortran tools like GFortran. A couple of
years ago I came across Compaq Visual Fortran. I was able to get
money for it because I could show the advantage of the Array Viewer.
Until 2010 we were able to use the unsupported Array Viewer with Win
XP 32bit on Intel Fortran. We have changed to Win 7 64bit. The Array
viewer is not working any more.

My money department is now saying, do
we really have to pay money for the yearly update any more? Our
administration is already thinking about cutting down this money.

Please think about your
decision to take the Array viewer out of Intel Fortran. We are
needing it for our work.


Two screenshots.
One using Array Visualizer / Array Viewer, the other using F90GL
The two were of the same model (both viewers open concurrently during the same simulation run at T=0
I am inexperienced at using F90GL (GLUT over OpenGL) so my skill is low at this point.

Below is a screenshot of Array Viewer.
The good part is the visual appearance of the lines. These are relatively smooth.
The bad part, is on the right side some of the wire frame cubic objects were dropped from the image.
The AV source code is not available so I cannot fix this.


Next is the image from F90GL
The good part is, all the objects are drawn
The bad part, the lines are quite jagged as compared to the AV screenshot. I have enabled GL_LINE_SMOOTH
Without line smoothing the lines are more jagged. Line thickness is greater in F90GL.
I haven't looked around to see if I can reduce this and get better looking lines.


If someone has a suggestion for improving the appearance I will appreciate it.

The 3D graphing is an important aspect to visual computing.
Note, I am not running a video game with approximations of physics.
I am running a engineering simulation program, where the graphics run in the background during the simulation.

One of the striking advantages of Array Visualizer / Array Viewer is the ability to Browse the database during run time.
Below is the browse of theTether that stretches from center of thering of cubes to the cube nearest (bottom).
Those are theposition verticies (other data off right of scrolling window)

Of particular interest to me, is I can horizontal scroll (or enlarge the window) and follow strain values in spreadsheet form
or view the 3D chart (image) with colored chart lines following the tether plot line. These "spreadsheets" present live data
during the execution of the simulation.

I shudder at trying to re-implement this functionality using F90GL

Jim Dempsey

Dear Intel Fortran Decision Makers

One line summary: At the least, Please^infinity get rid of the integration issue on 64bit.

4 years ago, I spent hours trying to figure out why AV does not work on Win64 when it used (and still) works without any problems on Win32....and then after it was made clear that there is an issue with the integration, a few more hours to write my own visualizer and also finding ways to make the AV-libray calls work on Win64.

I feel that AV is a tool whose value is simply not well-understood or perhaps it hasn't been presented well. There are other tools/softwares that do the job but having it all well-integrated just like MKL would be a HUGE benefit. Although at present the libray calls can be made to work ( on 64-bit, getting rid of the integration issue and enabling it through "View Array" should be given high enough priority. Come on, it is there...please let us use it.

Please consider doing the following (arranged in order of complexity as per my understanding):

(1) Fix the integration issue so that AV can be used in debug mode

(2) Fix the library call issue

(3) Consider supporting some basic things such as adding proper modules and libraries for a given platform at the install time of IVF (same as done for MKL)

(4) Consider full-support / development for AV.



I am interested in AV being integrated with future versions of IVF.
I mainly use AV for debugging.


Count me in , I do large FEM model development and it has always helped.


I need that too, that is pretty usefull for debugging codes where you have fields so you can see where your solution is getting diverged?

Another vote from me.

I previously used AV for data visualisation (to look at the surface generated by water enthalpy calculation routines). I currently use it to display 3D terrain data.

I am still
running CVF 6.6 on Win7-32. An upgrade to a compiler without 3D AV both at debug
time and as redistributable executables would not be an option for me.


Because of AV, I still use CVF in my computer. After I am sure there is no error any more, I compile my program in 64bit server using IVF. So my code has some subroutines especially written for CVF and IVF.
Without AV,it is difficult to check some errorhappened inan array.

In our research group "Theory of Quantum and Complex Systems" I volunteered to test the option for replacing CVF by IVF for all members of the group. My advice will clearly be NOT to invest in that replacement because of the lack of an Array Visualizer. I shall also distribute this (negative) advice among the scientists and research groups with whom we have a collaboration. An Array Visualizer comparable in quality with the one in CVF is absolutely required.


To add weight to your position statement, how many IVF licenses might you impact with your negative endorsement?

Jim Dempsey


Thanks for your comments. It would be helpful if you could tell me which Fortran compiler, including such a feature, you would recommend as an alternative.

Retired 12/31/2016

Hello Steve,

i am not the one you have ask, but i would like to to add an answer. (being the one having started the thread)

Currently i am using 3 compiler for my work (and i do hate it)

1) CVF 6.6 (for debug, based on WinXP Mode)
2) IVF11.1.070 (for developing win32 applications based on XEffort)
3) (for 'fast' numeric runs)

That means i usually start must of my projects with CVF (to have the dsw and dsp files) than doing the update to IVF. Every time i run into debug problems i start the WinXP mode --> start CVF --> there i can use the AV to find the problem inside GBytes of arrays.

If i find a new compiler doing the AV and win32 stuff, we will change


If someone has a suggestion for improving the appearance I will appreciate it

Although this was an old post and not germane to the thread, I point out that you need glEnable(GL_BLEND) and glBlendFunc(GL_SRC_ALPHA,GL_ONE_MINUS_SRC_ALPHA) to fix the jaggies in OpenGL, not just glEnable(GL_LINE_SMOOTH) and glHint(GL_LINE_SMOOTH_HINT,GL_NICEST).

Maybe readers of the Visual Fortran forum is not the right audience, but I was wondering if there is anyone looking for AV support for C++/Windows and/or Linux (C or Fortran). It may be easier to get support for AV if there is a broader platform base.John

Hello John,

for us the combination of Fortran and Windows is essential.


Hello Steve,We essentially work like in topic #20 by tropfen.We use Compaq Visual Fortran CVF6.6 (in Windows XP) for debugging, merely because of the good and intuitive array visualizer. It shows a graph of 1 and 2 dimensional arrays by a simple mouse click, similar as IVF gives a list of numbers. No need for calling extra routines in the program like with the old (and now unsupported) Intel Array Visualizer, as far as I can manage the later one.Because of its excellent performance, some of us then use IVF 2011.8.278 for production runs.Roughly speaking, 95% of the human development time is spent with CVF6.6, and 95% of the CPU time is spent in execution time after IVF compilation.Of course, with 64 bit upcoming, and CVF not being supported anymore, we would very much like to step over to IVF, and we shall do so without any doubt as soon as a good Array Visualizer becomes available.

I wrote here 2 years ago that a compiler without AV is not an option for me. But now I had to, I was forced to, finally upgrade from CVF to IVF 2013, and here I am: no way to integrate IAV 3.3 to VS2012 to be able to view the arrays in debug time, despite using all tutorials found on the Internet about this, or uninstall and reinstall the VS integration. There is a button for AV on the toolbar, but deactivated.

Just saw this thread...

I totally miss the Array Visualizer!

I never integrated it in my programs for displaying results, but for debugging reasons. It was very very easy to see numerical problems in arrays because of the coloured display of the values. When one term "faded" away you saw it at once. In a vast list of an array in a debugger it was almost impossible to spot these elements.

Steve, what did the decision makers decide after all?


It's still in limbo, but I have managed to get the marketing people express interest in having it return. Not a simple thing, though. I continue to work at it.

Retired 12/31/2016

Maybe if some of your marketing people visit their customers that are using Array Visualizer. Not just for debugging but also with application driven graphics. Perhaps then will they grasp the idea that they have this gem laying on the wayside for the prince of Serendip to come along to find it. Alas, marketing people tend not to be users. What is needed then is to demonstrate a demand.

The code you have is perhaps 90% done. Integration into VS for use in debugging is but one aspect of AV and ammounts to most of the missing 10%. Integration into application is already done, I can use it on Windows 7 x64. The documentation on how to install/fix it needs to be provided (or proper installation program updated).

I would like to propose that at some upcoming conference, IDF 2013, that you (Intel) bring together the necessary participants for a productive session:

Marketing people from Intel (decision makers)
Software support engineers from Intel (C++, IFV, others)
Proficient users of AV to demonstrate how they are using AV
Open the session to all those interested in integrating graphics into their applications (as well as disgruntled AV users wishing for reintroduction)

The marketing people need to be sold on the product offering. The purpose of the sesson is to provide marketing with the information they need to make the decision for reintroduction of AV.

I would be willing to prepare a demonstration for a portion of the session. It would be beneficial to find other volunteers proficient in AV to provide additional demonstrations. I also would be willing to work with the other contributors to collate the demonstrations into a complete presentation. April IDF 2013 Beijing, would likely be too soon to do a proper presentation, September IDF 2013 in San Francisco could work out.

For those users of AV (past and present) interested in providing demonstration material, please speak up.

Jim Dempsey


Thanks, Jim. Our marketing folks are in favor of it, but they don't make the decision. Still, it is an important step for them to have included AV in the list of desired features for future versions.

Retired 12/31/2016

Thanks Steve,

Let me propose an expanding circular argument:

T = Pentium 4
Intel needs compiler to demonstrate superiority of its implementation (to push HW sales)
Intel acquires compiler vendor SW development teams and/or improves compilers it has
SW now fully supports instruction set
Sales increase
Next generation HW (T = T+1)

The above was the original model management use to justify acquiring a SW department.

Now, there are additional SW vendors supplying compilers that are good at vectorization (not necessarily as good as Intel's nor as soon as Intel's). While I do not have the figures, I imagine a goodly portion of the SW market is using non-Intel compilers. I would like to argue that by increasing the Intel portion of the SW market, you attain a larger market share having compilers that fully supports most recent generation of hardware. This has an influencing effect to accelerate HW purchases.

By this reasoning, by increasing compiler market share, you accelerate and expand HW purchases. There are many factors that influence choice of compilers, outside of reliability, two of which are performance and programmer productivity features. The performance advantage is waining for those users willing to accepting time lag for their (open source) compiler to catch up. Adding programmer productivity features is an area that is more difficult for others to enter. Therefor:

more features == more SW users
more SW users == more/earlier HW purchases

Those are my arguing points.

Jim Dempsey


it would be perfect. Any working Array Viewer is better then having none. We can talk about inprovements later on.


Please add me to the list. However I need the CVF version of Array Visualizer and not the IAV for developing applications that show the array grid and the 3D plot with visible axis labels (IAV does not) . So those Active X controls for data grid and 3D plot will help me make more polished applications. Right now I have bypassed it by doing the same thing in Opengl but it is not the same quality



Hello Steve,

is there any change or movement in the Intel strategy about the arry viewer currently?


No, sorry. It continues to be mentioned but I have not seen any change in direction.

Retired 12/31/2016

Leave a Comment

Please sign in to add a comment. Not a member? Join today