VisIt avt Integration

From ParaQ Wiki
Jump to navigationJump to search

TODO


Introduction

This document describes the Visit Database Bridge ParaView plugin. The motivation for our plugin is to allow ParaView to make use VisIt's IO components, and to explore the re-usable capabilities of VisIt and its underlying pipeline library avt. Like ParaView VisIt is a scientific data visualization application based on VTK and Qt. There are a number of subtle differences between the two application's implementation. However in general there are more similarities than differences between the two. Hence porting subsets of functionality form one to the other is very doable and potentially very beneficial as both applications have large, publicly available, thoroughly tested code bases.

In ParaView IO components are called "readers" while in VisIt they are called "databases". VisIt developers have provided a consistent interface both for database plugin authors, who are typically scientists, via the avtFileFormat interface and for VisIt developers via the avtGenericDatabase interface. We thus had two options. The file format interface provides low level access to the database plugins. This would be a minimalistic approach isolating the essential code needed to read data from disk. However, if we were to take the file format approach we'd have to forgo quite a lot of VisIt's implemented functionality and re-invent a large body of tested code. This is why we chose the second option, namely to use the avtGenericDatabase interface which turns out to be quite a bit more efficient from a coding point of view.

In our implementation we have a single VTK class called the vtkVisItDatabase that exposes all of VisIt's 84 database plugins in a general way. At run time a database name is passed into the vtkVisItDatabase via a vtkSetStringMacro. Internally the vtkVisItDtabase owns an avt DatabasePluginManager object which is used to load one of VisIt's available database plugins, returning an avtGenericDatabase object from which meta data can be extracted and an avtSource object can be created. The source object can then be used to construct a simple avt pipeline from which we can extract VTK datasets. The vtkVisItDatabase class is layered inside of a VTK algorithm implementation class named vtkVisItDatabaseBridge. To expose the bridge as a reader in ParaView we generate a server manager XML source proxy tag for each of VisIt's database plugins. The tags name the specific database plugin to use with the given list of file extensions. Due to VisIt's long list of external library dependencies, there can be quite a bit of variability in the available database plugins between builds. We handle this by probing the VisIt installation and generating XML for only those database plugins that are found as the bridge is compiled.

The database concept is very general, and as such very powerful. VisIt's database abstraction means that storage formats and file contents all appear the same to the application. A database represents some collection of data, providing a means to query and access what is available. There are few restrictions on what data can be provided. For example a database is not restricted to providing a single dataset at a single time step. Further the database concept implies nothing about how the provided data is organized. For that purpose VisIt uses the avtSILSet object. SIL stands for subset inclusion lattice, and was introduced to facilitate sub-setting operations. The avtSILSet can be thought of as a directed graph that describes a collection of VTK datasets. SIL set vertices are given SIL set IDs and and are hierarchically organized. This scheme allows for collections or groupings of data to be simply constructed. For example an mechanical assemblies can be handled by creating a SIL set with edges to a number of domains. Sub-setting operations can be performed by following the graphs edges. More imprtant than facilitating sub-setting, the avtSILSet provides a consistent and flexible presentation of arbitrary collections of VTK data.

SIL sets are used throughout VisIt's avt pipeline, most notably inside of avtDataRequest objects which are travel through the pipeline. Filters modified the data request and pass it on. At some point the request reaches the generic database object which processes it by manipulating the loaded database plugin. The requested data is read into memory and passed to the pipeline in an avtDataSet object which is very similar to a vtkCompositeDataSet. In the bridge we have exposed the avtDataRequest to the ParaView client directly via a custom Qt panel. Each of the generated ParaView readers (source proxies) are associated with this panel, thus all of the 84 available VisIt database plugins have the same user interface.

When a user attempts to open a file that can be read using one of the VisIt database plugins it will return a true value from it's CanReadFile method. When ParaView executes the request information phase of a pipeline update, the bridge by manipulating the database object queries database plugin. The newly discovered SIL set is displayed in the ParaView client. The user then interacts with the SIL set before initiating the request data pipeline update phase during which the user's selections are translated into an avtDataRequest and fed into an avt pipeline. At this point the avt pipeline is executed and the resulting avt data set is translated into a VTK data object where it is shallow copied into the vtkDataObject provided by ParaView. From that point on ParaView operates as usual. Because we are building an avt pipeline we have the option of doing things in the native avt way which lets us provide expected VisIt functionality such as expression evaluation, material interface reconstruction (MIR), and sub-setting operations.

Given our approach upgrading VisIt should be as simple as installing the new version and reconfiguring the bridge. Unfortunately a number aspects of VisIt's design complicate things. The first and largest complication is that VisIt has forked VTK at release 5.0 2006. In order to use VisIt from within ParaView we have to use the same version of VTK in both. Unfortunately, VTK has changed substantially in between version 5.0 and the current cvs trunk, and further the VisIt developers have modified their fork. Not all of VisIt's new or modified VTK code is compatible with the current revision of VTK. Some of the major incompatibilities include VisIt's rendering additions and or are a result of VTK's interfaces making use of vtkIdType. Further, VisIt was not designed as a library but rather as a stand alone application so are large unnamed interdependencies between compiled objects leading to a situation where dynamic loaders don't know how to resolve undefined symbols. To work around both of these issues we ended up patching VisIt's build system. Fortunately only the build system configuration files needed to be modified, no modifications to VisIt sources were required. In the next major release of VisIt, VisIt 2.0, these issues will likely be solved, as VisIt developers are actively cleaning up the code base with library use in mind and switching to CMake.


The structure of our bridge is as follows:

  • vtkVisItDatabase -- VTK object that encapsulates all avt code, providing clients with an API for manipulating database plugins, the meta-data produced from files they can load, configuration of data requests and conversion the data returned from actual read operations into VTK data objects. Contains a DatabasePluginManager.
  • vtkVisItDatabaseBridge -- A VTK algorithm that implements the VTK pipline required of a ParaView reader. Contains a vtkVisItDatabase.
  • pqVisItDatabaseBridgePanel -- A custom QT panel for ParaView that can read the directed graph describing the data available in any given file.

VisItSlideScreenShot.png

Which of VisIt's databases are available?

This depends largely on how VisIt is built because databases only are built if their dependencies are found. Our plugin handles this by scanning the VisIt build at compile time, and only generating server manager XML for those which are present. This list reflects what is available in a full VisIt 1.10.0 build. A number of these however are intentionally skipped since ParaView already has support for them. The databases are skipped based on the contents of a text file included in the plugin sources.

  • ANALYZE
  • ANSYS
  • AUXFile
  • AugDecomp
  • BOV
  • BOW
  • Boxlib2D
  • Boxlib3D
  • CEAucd
  • CGNS
  • CMAT
  • CTRL
  • Cale
  • Chombo
  • Claw
  • Cosmos
  • CosmosPP
  • Curve2D
  • DDCMD
  • Dune
  • Dyna3D
  • EnSight
  • Enzo
  • ExtrudedVol
  • FITS
  • FLASH
  • Fluent
  • GDAL
  • GGCM
  • GTC
  • H5Nimrod
  • H5Part
  • Hex
  • Image
  • KullLite
  • Lines
  • M3D
  • MFIX
  • MM5
  • Miranda
  • NASTRAN
  • NETCDF
  • Nek3D
  • OVERFLOW
  • OpenFOAM
  • PATRAN
  • PDB
  • PFLOTRAN
  • PLOT2D
  • PLOT3D
  • Pixie
  • PlainText
  • Point3D
  • ProteinDataBank
  • RAW
  • Rect
  • S3D
  • SAMI
  • SAMRAI
  • SAR
  • SAS
  • STL
  • Shapefile
  • Silo
  • SimV1
  • SimV1Writer
  • Spheral
  • StreamGhostTest
  • TFT
  • TSurf
  • Tecplot
  • Tetrad
  • UNIC
  • VASP
  • VLI
  • Vis5D
  • Vista
  • WavefrontOBJ
  • XDMF
  • XYZ
  • Xmdv
  • ZeusMP
  • ZipWrapper

Building the Plugin

The plugin build has two distinct parts, building our patched version of VisIt and building the plugin itself.Building VisIt is a complicated process due to a large number of external library dependencies. VisIt has handled the issue by providing a the "build_visit" bash script to automate the process for Linuxes and Mac. Unfortunately

Step 1: Build VisIt's dependencies

General Information and Notes

On Linux and Mac VisIt makes use of autotools, while on Windows VisIt makes use of Visual Studio solutions.

An additional complication when developing our bridge plugin was that VisIt builds only those plugins whose dependencies can be resolved at compile time so that a static build configuration was impractical. We have handled this by writing a bootsrap configuration utility that probes the named VisIt install loading database plugins one by one, extracting name, and file extensions as we go and generating the servermanager XML. The one complication of the bootstrap is that ParaView plugins which require a custom panel have to name that panel in the CMake file. We don't know which plugin's are going to be required until we are not able to modify the CMake files while CMake is running. To work around this we build the plugin in two steps, a bootstrap step and a build step.

This file is a site-config file that I used to build VisIt as a library for use with ParaView. To do so VisIt's makefiles had to be patched so that its GUI is excluded and ParaView's VTK can be used. The top section of the file is a set of notes as to how I configured VisIt's dependencies and VisIt itself. The bottom of this file is a bash script that VisIt uses to configure itself. You will have to modify the variables to reflect locations of the dependencies on your system. If you are only interested in a specific database plugin then you can skip many of the dependencies. You can't skip szip, silo, or hdf5. Be sure to point ParaView to the version of HDF5 you are using here when you build ParaView.

Notes:

VisIt suggests to use static libraries for its dependencies. This isn't always a good idea. HDF5 for instance should be shared when using with ParaView. Theses notes need to be updated to reflect this. TODO

Windows has a completely different build process because VisIt used visual studio. Mac is as of yet uncharted territory.

In theory one can build all of VisIt's dependencies using the "build_visit" script available from VisIt's web site. If you go that route, then you still should use this file to configure the patched VisIt with the ./configure line below.

You'll need to have Qt 3 development packge around somewhere because VisIt's ./configure script has a Qt 3 dependency.

It's best to try ot use the versions of the libraries I have used here, if not then second best is to use the ones recomended by VisIt. If you do niether you're on your own, but things will probably be OK as long as you stick to the recomended configuration.== General Information and Notes == On Linux and Mac VisIt makes use of autotools, while on Windows VisIt makes use of Visual Studio solutions.

An additional complication when developing our bridge plugin was that VisIt builds only those plugins whose dependencies can be resolved at compile time so that a static build configuration was impractical. We have handled this by writing a bootsrap configuration utility that probes the named VisIt install loading database plugins one by one, extracting name, and file extensions as we go and generating the servermanager XML. The one complication of the bootstrap is that ParaView plugins which require a custom panel have to name that panel in the CMake file. We don't know which plugin's are going to be required until we are not able to modify the CMake files while CMake is running. To work around this we build the plugin in two steps, a bootstrap step and a build step.

This file is a site-config file that I used to build VisIt as a library for use with ParaView. To do so VisIt's makefiles had to be patched so that its GUI is excluded and ParaView's VTK can be used. The top section of the file is a set of notes as to how I configured VisIt's dependencies and VisIt itself. The bottom of this file is a bash script that VisIt uses to configure itself. You will have to modify the variables to reflect locations of the dependencies on your system. If you are only interested in a specific database plugin then you can skip many of the dependencies. You can't skip szip, silo, or hdf5. Be sure to point ParaView to the version of HDF5 you are using here when you build ParaView.

Notes:

VisIt suggests to use static libraries for its dependencies. This isn't always a good idea. HDF5 for instance should be shared when using with ParaView. Theses notes need to be updated to reflect this. TODO

Windows has a completely different build process because VisIt used visual studio. Mac is as of yet uncharted territory.

In theory one can build all of VisIt's dependencies using the "build_visit" script available from VisIt's web site. If you go that route, then you still should use this file to configure the patched VisIt with the ./configure line below.

You'll need to have Qt 3 development packge around somewhere because VisIt's ./configure script has a Qt 3 dependency.

It's best to try ot use the versions of the libraries I have used here, if not then second best is to use the ones recomended by VisIt. If you do niether you're on your own, but things will probably be OK as long as you stick to the recomended configuration.

szip

LIBS=-lm CFLAGS=-fPIC CXXFLAGS=-fPIC ./configure --prefix=/opt/szip-2.1 --disable-shared
make -j 8
sudo make install

HDF4

LIBS=-lm CFLAGS=-fPIC CXXFLAGS=-fPIC ./configure --prefix=/opt/hdf4-4.2r3 --disable-fortran --with-szlib=/opt/szip-2.1/ 
make -j 8
sudo make install

HDF5

for gcc 4.3 you'll have to edit perform/zip_perf.c change line 549 to "output = open(filename, O_RDWR | O_CREAT, S_IRWXU);" 

CFLAGS=-fPIC CXXFLAGS=-fPIC ./configure --prefix=/opt/hdf5-1.6.8_ser --disable-shared --disable-fortran --disable-parallel --with-szlib=/opt/szip-2.1 
make -j 8
sudo make install
sudo ln -s /opt/szip-2.1/lib/libsz.a /opt/hdf5-1.6.8_ser/lib/libsz.a

BoxLib

For gcc-4.3 add #include <cstdlib> to ParallelDescriptor.cpp Usiing gfortran instead of g77 works well. 

cd into boxlib directory in the CCSEApps
edit GNUMakefile, set USE_MPI=false, COMP=g++
mv std std.old
chmod 644 *.H
CXXFLAGS=-fPIC CFLAGS=-fPIC FFLAGS=-fPIC make -j 8
sudo  mkdir -p /opt/boxlib/{include/2D,include/3D,lib}
sudo cp libbox3d.Linux.g++.f77.DEBUG.a /opt/boxlib/lib/libbox3D.a
sudo cp *.H /opt/boxlib/include/3D/
edit GNUMakefile,set DIM=2
CXXFLAGS=-fPIC CFLAGS=-fPIC FFLAGS=-fPIC make -j 8
sudo cp libbox2d.Linux.g++.f77.DEBUG.a /opt/boxlib/lib/libbox2D.a
sudo cp *.H /opt/boxlib/include/2D/

NetCDF

For gcc-4.3 add #include <cstring> to ./cxx/ncvalues.cpp 

CXXFLAGS=-fPIC CFLAGS=-fPIC ./configure --prefix=/opt/netcdf-3.6.0-p1
make -j 8
sudo mkdir /opt/netcdf-3.6.0-p1
sudo make install

Silo

4.6.2 doesn't work with VisIt and gcc 4.3 as of this writing(2009-02-25). Some sort of link issue, may be libtool.? 

./configure --prefix=/opt/silo-4.6.1 --without-readline --with-hdf5=/opt/hdf5-1.6.8_ser/include/,/opt/hdf5-1.6.8_ser/lib/ --without-exodus --with-szlib=/opt/szip-2.1 --disable-fortran --disable-browser --disable-shared --disable-silex
make -j 8
sudo make install
sudo ln -s /opt/silo-4.6.2/lib/libsiloh5.a /opt/silo-4.6.2/lib/libsilo.a

CGNS

Only use hdf5 if you need it.
CXXFLAGS=-fPIC CFLAGS=-fPIC ./configure --prefix=/opt/cgns-2.4 --with-szip=/opt/szip-2.1/lib/libsz.a --with-hdf5=/opt/hdf5-1.6.8_ser/
make -j 8
sudo mkdir -p /opt/cgns-2.4/{include,lib}
sudo make install

CFITSIO

./configure --prefix=/opt/cfitsio
make -j 8
sudo make install

H5Part

CFLAGS=-fPIC ./configure --prefix=/opt/h5part-1.3.3 --with-hdf5path=/opt/hdf5-1.6.8_ser/
make -j 8
sudo make install

CCMIO

Didn't work & looks like it uses qmake ?!?. If some one complains we'll get it working.

GDAL

For gcc-4.3 download gdal-1.6.0, the following config works with both version 

CFLAGS=-fPIC CXXFLAGS=-fPIC ./configure --prefix=/opt/gdal-1.6.0 --enable-static --disable-shared --with-libtiff=internal --with-gif=internal --with-png=internal --with-jpeg=internal --with-libz=internal --with-netcdf=no --without-jasper --without-python
make -j 8
sudo make install

Qt 3

We don't have to link against Qt but VisIt plugin system requires Qt to build. 

export QTDIR=`pwd`
export LD_LIBRARY_PATH=$QTDIR/lib
./configure --prefix=/opt/qt-3.3.8
make -j 8
sudo make install

Step 2: Build and install VisIt

Once some subset of VisIt's dependencies ahave been built on the target system it's time to build VisIt itself.


NOTE for now set VTK_USE_64BIT_IDS to OFF NOTE should we force the use of static libs when both shared and static are available? -Bstatic ??

patch -p6 < /home/burlen/ext/kitware_cvs/VisitPluginTool/VisItPV3Build.in.patch 

./configure --prefix=/opt/VisIt-1.10.0 --with-config=/home/burlen/ext/kitware_cvs/VisitPluginTool/building_visit/vtkVisitDatabaseBridge.conf --with-hdf5=/opt/hdf5-1.6.8_ser/include,/opt/hdf5-1.6.8_ser/lib --enable-parallel --disable-scripting --disable-visitmodule --disable-viewer-mesa-stub --disable-icet --disable-bilib --disable-glew --disable-bzip2 --with-dbs=all

Step 3: Build the ParaView plugin

Building the database plugin for ParaView is a two step process, namely: 

cd bin;
ccmake ../ ===> Set BOOTSTRAP to ON
make
ccmake ../ ===> Set BOOSTRAP to OFF
make

Step 1: 

  BootstrapConfigure.
     During this pass a local copy of the VisIt libraries and database
     plugins are made. On Windows a copy of the "third party dependencies"
     is also made. This is done to facilitate the crossplatform build
     and configuration which is necessary due the large differences between
     the VisIt build system accross platforms, and to mitigate differneces
     in how various platforms handle shared libraries at run time. The final
     step of this pass is to generate the CMake files, ServerManager and 
     Pq xml for the vtkVisItDatabaseBridge plugin upon the VisIt configuration
     found.

Step 2: 

  vtkVisItDatabaseBridge ParaView Plugin.
    During this pass the paraview plugin is built from the configuration
    generated during the first pass.

Windows

Configure PV for shared libs, using system HDF5. Point both ZLIB and HDF5 include and lib to HDF5 of VisIt/windowsbuild.

C:\VisitPluginTool\plugin\bin\Debug\MSVC8.Net\Debug

set PATH=%PATH%;C:\VisitPluginTool\plugin\bin\Debug;C:\VisitPluginTool\plugin\bin\Debug\MSVC8.Net\Debug;C:\VisitPluginTool\plugin\bin\Debug\MSVC8.Net\Debug\databases;C:\VisitPluginTool\plugin\bin\Debug\MSVC8.Net\ThirdParty


What's Not Done

  1. We need to map VisIt ghost cells to VTK ghost cells.
  2. Finish MIR. Part of the MIR code has been written (it's commented out). Basically we need to inquire with the VisIt devs about what is the right way to do this.
  3. Finish Experssions.Part of the expression code has been written (it's commented out). Expressions will be expected by VisIt users.They can be trivially added. See the avtExpresssionEvaluationFilter.
  4. Leaks! Run the plugin through valgrind and you'll find all kinds of leaks. These are certainly coming from within VisIt, however we have to

be certain it's not ourfault before asking them for help. I've been careful but now need to go over thoroughly.

Retrieved from "http://www.paraview.org/ParaView/index.php?title=VisIt_avt_Integration&oldid=6288"