f90gl

[markgeo]

Hello,

I've developed a research Finite Element Code written in Fortran 90/95. I've connected my software with an existing visual package but for the visual representation of some additional features I've developed an incore graphical environment based on f90gl 32bit.

Recently I've moved to a 64bit platform (Win7) and managed to built the glut.lib and glut.dll files so as for the f90gl libraries to compile and successfully work in a 64bit platform. The f90gl libraries were built in 2006 since I was unable to built them my self. I was informed that Steve Lionel was the one that compiled these libraries thus if so, I was wondering if Steve or anyone else can guide me through the process of building the corresponding libraries.

The new glut.lib and glut.dll files (for 64bit system) along with the old f90gl files can be found at the following link:
http://users.ntua.gr/markgeo/index_files/Download.htm

If you Steve or anyone else can provide any help, I would be oblidged. Ofcourse after building the files and testing them I will post them on my web so as fmaking them available to everybody.

[Steven_L_Intel1]

I'll take a look at this when I can. May be a few days.

[markgeo]

OK. I'll be waiting for your reply.

[Steven_L_Intel1]

Here you go - 32-bit and 64-bit, compiled with Intel Visual Fortran Composer XE 2011.

[jimdempseyatthecove]

Steve,

Thanks for posting the IVF compiled versions of f90gl.

I have been a long time user of ArrayVisualizer and ArrayViewer. I am debating to try f90gl and/or HDF5. HDF5 will be quite similar to what I am currently doing with the ArrayVisualizer and ArrayViewer, so I may go that way (AV uses HDF5 format, or an early rendition of that format). I have been very happy with AV to date. A few quirks and work-arounds are required for this no longer supported product :(...

Recently I have been experiencing some problems where some of the avWatch'darraysare not watched. These get missed on the avUpdate that is supposed to snapshot new copies of the data. I am assuming there is an internal program error in this unsupported graphics library.

One of the attractive features of AV was the ArrayViewer ran as a seperate process from my application which populates a shared database. On a 32-bit platform - this provided double the virtual address space to work with. On a 64-bit platform this isn't an issue. However, for both platforms, it adds an additional means for parallization. The rasterization of the 3D graphs are performed by a different thread or threads than those within my application. Although there is some communication overhead, it isn't very large. (either block moves or remapped virtual memory).

Now to the point of my question:

I've used GLUT before in C++ applications and am fairly satisfied for its use in those programs. One of my concerns though, my FORTRAN simulation usage currently has significantly complex 3D renditions. And I may need to increase the complexity 1,000x to 100,000x what I currently am doing.

This will require (necessitate)making the rendering (or portions thereof) both parallel and separate from the data generation. i.e. I am willing to drop a rendered frame at the benefit of solution integration. I am not producing a video, rather I am observing the progress of an engineering model during simulation. Using GLUT I would run n integration intervals (in parallel), call GLUT (serial), back to integration. Using AV, I have some preparation of the raw data, but then there is a relatively quick call to announce the data is ready for rendering. When rendering is occurring, I am advancing the state of the simulation.

Other than for AV, are you aware of someone seperating the renderitioning in GLUT or HDF5 from the applicaiton (producing the data)?

I do not have estimates for my computational requirements nor the RAM requirements. Currently I use a 1P 4 core Q6600 (under powered). I am waiting for Sandy Bridge to stabalize. Later a 4P or8P Ivy Bridge might be useful (whenever that is available).

Jim Dempsey

[Steven_L_Intel1]

Jim,

Sorry, I have no knowledge of such separation, but it isn't the sort of thing I would be aware of.

[jimdempseyatthecove]

Steve,

No problem. I was hoping you or one of the readers of this thread might know of such an implementation. I may try to duplicate this feature.

An interesting capability of this feature is I can launch multiple viewers at the same time. Each viewer can be seperately panned and zoomed (multiple perspectives of simulation at same time), or one viewer can display 3D image while other viewer is displaying numeric tables (e.g. looking at strain values of portion of simulation). Or, I can close a viewer to recover some processing time. Adds parallelization with no coding change. Very flexible.

Jim Dempsey

[markgeo]

Thank you Steve for your reply and the files!!! I've uploaded the package to my web site and I will take them for a ride asap.

Regards,

GM

[jimdempseyatthecove]

Steve,

I tried your f90gl file (f90gl-1.2.15-ifort.zip) on my Windows XP x64 using IVF 11.0.066 and was unable to produce asuccessful linkdue to missing __intel_sse2_... string function. Additional references to this problem did not produce a work around for me. This is likely a result of me using an older version of the compiler than the one use to build the 1.2.15 library you provided.

As a result, I fell back to using f90gl-1.2.12.zip from http://math.nist.gov/f90gl/ This seems to work fine on the Intel64 builds using IVF 11.0.066 on XP Pro x64. Is there a listing of these function prototypes and description of argument usage? If that were available then I could scab in a replacement routine.

I would use a newer version of IVF, but 11.0.066 is working well enough. Maybe Kathy can sendme a IPS XE with up-to-date IVF. This might help me with my forum replies.

I am in the process of converting from Array Visualizer to OpenGL. This is more work than anticipated and will result in a less comprehensive solution (without substantial extra coding effort). The OpenGL port might be lighter weight (memory footprint and processing overhead). AV is crappingout withlarger number of objects. After a few 100's of objects some of the avWatch arrays are no longer watched. This cause missing object (or lack of information updates to those objects).OpenGL has a different programming paradigm, I won't know if this is a good move or not, I suspect I won't have missing/bad artifacts with OpenGL, if I do, I can fix it. Some of my upcoming research may involve over 1 million objects in simulation runs. I may need to replace my Q6600 (4-core) with a Sandy Bridge, or Ivy Bridge MP if I can get some external funding support.

Jim Dempsey

[Steven_L_Intel1]

Jim,

There is no magic involved in building f90GL if you have a Fortran compiler (and a C compiler). You should be able to build the 1.2.15 sources with your 11.0. But yeah, we should see about getting you something newer...