VisIt avt Integration: Difference between revisions

From ParaQ Wiki
Jump to navigationJump to search
Line 3: Line 3:


== Introduction ==
== Introduction ==
This document describes the Visit Database Bridge ParaView plugin. The motivation for our plugin is simple: to allow ParaView to make use of some subset of VisIt's IO components. In ParaView IO components are called "readers" but in VisIt they are called "databases". Besides the nomenclature, there are a number of subtle differences between the two application's implementation of IO components. First VisIt provides a consistent interface both for database implementors and for programmers constructing pipelines using avt. Avt is what VisIt's internal visualization pipeline library is called. VisIt database plugin authors implement one of 4 interfaces derived from avtFileFormat. We thus had the option of tying into the VisIt code base here. The file format interface provides a consistent albeit low level interface to any given database. We could simply rip out the various database source code and manipulate them directly using this interface. In this approach we'd likely end up writing a VTK pipeline for each VisIt database implementation. Under the covers we'd make a new instance of some dtabase and then make calls on it via the file format interface. This alone is a daunting amount of work since there are 84 database plugins currently available in VisIt. It very quickly became apparent that if we were to do this we'd reinvent a large amount of code that was already available in VisIt.Fortunately there was a second option, namely to manipulate the database plugins at the plugin level. This usage pattern is what VisIt itself does. Specifically the DatabasePluginManager is used to load plugins returning an avtDatabase object which is the from which meta data can be extracted and a an avtSource object can be created. The source object can be used to construct a simple avt pipeline from which we can extract VTK objects. This turns out to be quite a bit more efficient than tying into the file format interface. For one thing we have only a hand full of avt classes we need to deal with, as opposed to the 84 that would be necessary if we were to use the file format interface. In our implementation we have a single VTK class that exposes all 84 database plugins in a general way. We have additionally used a directed graph for storing data meta data and for describing relationships amongst data elements that are stored in a file to provid a general unified presentation of all 84 database plugins. Further because we are building an avt pipeline we have the option of adding avt filters and doing things in the native avt way letting us provide those familliar with VisIt expected functionality such as expression evaluation, material interface reconstruction (MIR), and sub-setting operations. The structure of our plugins is as follows:
This document describes the Visit Database Bridge ParaView plugin. The motivation for our plugin is simple: to allow ParaView to make use of some subset of VisIt's IO components. In ParaView IO components are called "readers" but in VisIt they are called "databases". Besides the nomenclature, there are a number of subtle differences between the two application's implementation of IO components. VisIt architects have provided a consistent interface both for database authors via file format interface and for programmers constructing pipelines via a database plugin interface. VisIt database plugin authors implement one of 4 interfaces derived from avtFileFormat. We thus had the option of tying into the VisIt code base here. The file format interface provides a consistent, albeit low level interface, to any given database. We could simply rip out the various database source code and manipulate them directly using this interface. In this approach we'd likely end up writing a VTK pipeline for each VisIt database implementation. Under the covers we'd make a new instance of some database class and then make calls on it via the file format interface. This alone is a daunting amount of work since there are 84 database plugins currently available in VisIt.  
 
It very quickly became apparent that if we were to do this we'd reinvent a large amount of code that was already available in VisIt.Fortunately there was a second option, namely to manipulate the database plugins at the database plugin level. Specifically the DatabasePluginManager is used to load plugins returning an avtDatabase object which is the from which meta data can be extracted and a an avtSource object can be created. The source object can be used to construct a simple avt pipeline from which we can extract VTK objects. This turns out to be quite a bit more efficient than tying into the file format interface. For one thing we have only a hand full of avt classes we need to deal with, as opposed to the 84 that would be necessary if we were to use the file format interface. In our implementation we have a single VTK class called the vtkVisItDatabase that exposes all 84 database plugins in a general way. We have additionally used a directed graph for storing data meta data and for describing relationships amongst data elements that are stored in a file to provide a general unified presentation of all 84 database plugins. Further because we are building an avt pipeline we have the option of adding avt filters and doing things in the native avt way letting us provide those familliar with VisIt expected functionality such as expression evaluation, material interface reconstruction (MIR), and sub-setting operations. The structure of our plugins 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, configration of data requests and the VTK data returned from actual read operations. Contains a DatabasePluginManager.
* 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, configration of data requests and the VTK data returned from actual read operations. Contains a DatabasePluginManager.
* vtkVisItDatabaseBridge -- A VTK algorithm that implements the VTK pipline required of a ParaView reader. Contains a vtkVisItDatabase.  
* vtkVisItDatabaseBridge -- A VTK algorithm that implements the VTK pipline required of a ParaView reader. Contains a vtkVisItDatabase.  
* pqVisItDatabaseBridgePanel -- A QT  
* pqVisItDatabaseBridgePanel -- A custom QT panel for ParaView that can read the directed graph describing the data available in any given file.


In this approach the database plugins are used with out alteration, in essence using VisIt avt classes as a shared library to programatically manipulate the plugins in a general way. This approach should have additional benefit of making the process of upgrading VisIt as simple as installing the new version and reconfiguring the bridge. Unfortunately a number aspects of VisIt's design complicate this approach. The first and largest complication is that VisIt has forked VTK at release 5.0 circa 2006. was not designed as a library but rather ahas not (to our knowledge)
In this approach the database plugins are used with out alteration, in essence using VisIt avt classes as a shared library to programatically manipulate the plugins in a general way. This approach should have additional benefit of making the process of upgrading VisIt as simple as installing the new version and reconfiguring the bridge. Unfortunately a number aspects of VisIt's design complicate this approach. The first and largest complication is that VisIt has forked VTK at release 5.0 2006. Clearly to use VisIt from within ParaView we have to use the same version of VTK and it's not an option to use VisIt's thus we need to have the capability of compiling VisIt against our version of VTK. Unfortunately, VisIt was not designed as a library but rather as a stand alone application.  so that there are large unnamed interdependencies between compiled objects leading to a situation where dyna,ic loaders won't know how to resolve undefined symbols. To work around


== General Information and Notes ==
== General Information and Notes ==

Revision as of 14:22, 10 April 2009

TODO


Introduction

This document describes the Visit Database Bridge ParaView plugin. The motivation for our plugin is simple: to allow ParaView to make use of some subset of VisIt's IO components. In ParaView IO components are called "readers" but in VisIt they are called "databases". Besides the nomenclature, there are a number of subtle differences between the two application's implementation of IO components. VisIt architects have provided a consistent interface both for database authors via file format interface and for programmers constructing pipelines via a database plugin interface. VisIt database plugin authors implement one of 4 interfaces derived from avtFileFormat. We thus had the option of tying into the VisIt code base here. The file format interface provides a consistent, albeit low level interface, to any given database. We could simply rip out the various database source code and manipulate them directly using this interface. In this approach we'd likely end up writing a VTK pipeline for each VisIt database implementation. Under the covers we'd make a new instance of some database class and then make calls on it via the file format interface. This alone is a daunting amount of work since there are 84 database plugins currently available in VisIt.

It very quickly became apparent that if we were to do this we'd reinvent a large amount of code that was already available in VisIt.Fortunately there was a second option, namely to manipulate the database plugins at the database plugin level. Specifically the DatabasePluginManager is used to load plugins returning an avtDatabase object which is the from which meta data can be extracted and a an avtSource object can be created. The source object can be used to construct a simple avt pipeline from which we can extract VTK objects. This turns out to be quite a bit more efficient than tying into the file format interface. For one thing we have only a hand full of avt classes we need to deal with, as opposed to the 84 that would be necessary if we were to use the file format interface. In our implementation we have a single VTK class called the vtkVisItDatabase that exposes all 84 database plugins in a general way. We have additionally used a directed graph for storing data meta data and for describing relationships amongst data elements that are stored in a file to provide a general unified presentation of all 84 database plugins. Further because we are building an avt pipeline we have the option of adding avt filters and doing things in the native avt way letting us provide those familliar with VisIt expected functionality such as expression evaluation, material interface reconstruction (MIR), and sub-setting operations. The structure of our plugins 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, configration of data requests and the VTK data returned from actual read operations. 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.

In this approach the database plugins are used with out alteration, in essence using VisIt avt classes as a shared library to programatically manipulate the plugins in a general way. This approach should have additional benefit of making the process of upgrading VisIt as simple as installing the new version and reconfiguring the bridge. Unfortunately a number aspects of VisIt's design complicate this approach. The first and largest complication is that VisIt has forked VTK at release 5.0 2006. Clearly to use VisIt from within ParaView we have to use the same version of VTK and it's not an option to use VisIt's thus we need to have the capability of compiling VisIt against our version of VTK. Unfortunately, VisIt was not designed as a library but rather as a stand alone application. so that there are large unnamed interdependencies between compiled objects leading to a situation where dyna,ic loaders won't know how to resolve undefined symbols. To work around

General Information and Notes

VisItSlideScreenShot.png

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.

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

Step 1: Build VisIt's dependencies

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.