Re: [Paraview] MILI reader still broken for me
Hi Rich, It looks like your VisItBridge submodule is not up to date, so could you run the following commands in the root of your source directory for me and return me the results? git fetch origin --prune git checkout master git pull --rebase git submodule update git status On Tue, Jul 5, 2011 at 9:17 PM, Cook, Rich wrote: > Hi, regarding bug 12292 http://paraview.org/Bug/view.php?id=12292 > > I tried building the latest from git and got an error. I included the > CMakeCache.txt file online. > > > == > The essential bits are: > > CMAKE_CXX_COMPILER:FILEPATH=/usr/local/bin/mpiCC > CMAKE_C_COMPILER:FILEPATH=/usr/local/bin/mpicc > CMAKE_INSTALL_PREFIX:PATH=/usr/global/tools/Kitware/Paraview/3.11/chaos_4_x86_64_ib > > PARAVIEW_USE_MPI:BOOL=ON > PARAVIEW_USE_BOOST:BOOL=ON > PARAVIEW_USE_VISITBRIDGE:BOOL=ON > VISIT_BUILD_READER_CGNS:BOOL=ON > VISIT_BUILD_READER_Mili:BOOL=ON > VISIT_BUILD_READER_Silo:BOOL=ON > > CGNS_INCLUDE_DIR:PATH=/usr/gapps/visit/cgns/3.0.8/linux-x86_64_gcc-4.1/include > CGNS_LIBRARY:FILEPATH=/usr/gapps/visit/cgns/3.0.8/linux-x86_64_gcc-4.1/lib/libcgns.a;/usr/gapps/visit/szip/2.1/linux-x86_64_gcc-4.1/lib/libsz.a;/usr/lib64/libz.so > > MILI_INCLUDE_DIR:PATH=/usr/gapps/visit/mili/1.10.0/linux-x86_64_gcc-4.1/include > MILI_LIBRARY:FILEPATH=/usr/gapps/visit/mili/1.10.0/linux-x86_64_gcc-4.1/lib/libmili.a;/usr/gapps/visit/szip/2.1/linux-x86_64_gcc-4.1/lib/libsz.a;/usr/lib64/libz.so > > SILO_INCLUDE_DIR:PATH=/usr/gapps/visit/silo/4.8/linux-x86_64_gcc-4.1/include;/usr/gapps/visit/mili/1.10.0/linux-x86_64_gcc-4.1/include > SILO_LIBRARY:FILEPATH=/usr/gapps/visit/silo/4.8/linux-x86_64_gcc-4.1/lib/libsiloh5.a;/usr/gapps/visit/szip/2.1/linux-x86_64_gcc-4.1/lib/libsz.a;/usr/lib64/libz.so > > Boost_INCLUDE_DIR:PATH=/nfs/tmp2/rcook/ParaView/3.11/build/boost_1_46_1 > Boost_LIBRARY_DIRS:FILEPATH=/nfs/tmp2/rcook/ParaView/3.11/build/boost_1_46_1/stage/lib > > CMAKE_VERBOSE_MAKEFILE:BOOL=TRUE > > CMAKE_CXX_FLAGS:STRING=' > -I/usr/global/tools/Kitware/Paraview/3.11/chaos_4_x86_64_ib/include > -I/usr/gapps/visit/mili/1.10.0/linux-x86_64_gcc-4.1/include ' > CMAKE_C_FLAGS:STRING=' > -I/usr/global/tools/Kitware/Paraview/3.11/chaos_4_x86_64_ib/include > -I/usr/gapps/visit/mili/1.10.0/linux-x86_64_gcc-4.1/include ' > > VTK_USE_SYSTEM_HDF5:BOOL=ON > HDF5_C_INCLUDE_DIR:PATH=/usr/gapps/visit/hdf5/1.8.4/linux-x86_64_gcc-4.1/include > HDF5_INCLUDE_DIR:PATH=/usr/gapps/visit/hdf5/1.8.4/linux-x86_64_gcc-4.1/include > HDF5_LIBRARY:FILEPATH=/usr/gapps/visit/hdf5/1.8.4/linux-x86_64_gcc-4.1/lib/libhdf5.a;/usr/gapps/visit/szip/2.1/linux-x86_64_gcc-4.1/lib/libsz.a;/usr/lib64/libz.so > HDF5_hdf5_LIBRARY:FILEPATH=/usr/gapps/visit/hdf5/1.8.4/linux-x86_64_gcc-4.1/lib/libhdf5.a;/usr/gapps/visit/szip/2.1/linux-x86_64_gcc-4.1/lib/libsz.a;/usr/lib64/libz.so > HDF5_hdf5_LIBRARY:FILEPATH=/usr/gapps/visit/hdf5/1.8.4/linux-x86_64_gcc-4.1/lib/libhdf5.a;/usr/gapps/visit/szip/2.1/linux-x86_64_gcc-4.1/lib/libsz.a;/usr/lib64/libz.so > HDF5_hdf5_LIBRARY_DEBUG:FILEPATH=/usr/gapps/visit/hdf5/1.8.4/linux-x86_64_gcc-4.1/lib/libhdf5.a;/usr/gapps/visit/szip/2.1/linux-x86_64_gcc-4.1/lib/libsz.a;/usr/lib64/libz.so > HDF5_hdf5_LIBRARY_RELEASE:FILEPATH=/usr/gapps/visit/hdf5/1.8.4/linux-x86_64_gcc-4.1/lib/libhdf5.a;/usr/gapps/visit/szip/2.1/linux-x86_64_gcc-4.1/lib/libsz.a;/usr/lib64/libz.so > HDF5_ENABLE_SZIP_SUPPORT:BOOL=ON > > > BUILD_SHARED_LIBS:BOOL=ON > CMAKE_INSTALL_RPATH_USE_LINK_PATH:BOOL=ON > > > == > RESULTING ERROR: > > [ 36%] Building CXX object [ 33%] Building CXX object > Utilities/VisItBridge/databases/CMakeFiles/vtkVisItDatabases.dir/Mili/avtMiliFileFormat.C.o > /nfs/tmp2/rcook/ParaView/3.11/build/ParaView-311-clone/ParaView/Utilities/VisItBridge/databases/Mili/avtMiliFileFormat.C: > In member function 'void avtMiliFileFormat::ReadMesh(int)': > /nfs/tmp2/rcook/ParaView/3.11/build/ParaView-311-clone/ParaView/Utilities/VisItBridge/databases/Mili/avtMiliFileFormat.C:1296: > error: no matching function for call to > 'avtMiliFileFormat::ConstructMaterials(std::vector std::allocator >, std::allocator std::allocator > > >&, std::vector std::allocator >, std::allocator > > > >&, int&)' > /nfs/tmp2/rcook/ParaView/3.11/build/ParaView-311-clone/ParaView/Utilities/VisItBridge/databases/Mili/avtMiliFileFormat.h:183: > note: candidates are: avtMaterial* > avtMiliFileFormat::ConstructMaterials(std::vector std::allocator >, std::allocator > > > >&, std::vector >, > std::allocator > > >&, int) > gmake[2]: *** > [Utilities/VisItBridge/databases/CMakeFiles/vtkVisItDatabases.dir/Mili/avtMiliFileFormat.C.o] > Error 1 > gmake[2]: Leaving directory > `/nfs/tmp2/rcook/ParaView/3.11/build/ParaView-311-clone/ParaView-3.11-build' > gmake[1]: *** > [Utilities/VisItBridge/databases/CMakeFiles/vtkVisItDatabases.dir/all] Error 2 > gmake[1]: Leaving directory > `/nfs/tmp2/rcook/ParaView/3.11/build/ParaView-311-clo
[Paraview] pqAutoApplyReaction
I have built a Toolbar plugin in paraview with a button that applies extractblock filter to a multiblock dataset so as to get all the blocks seperately in different objects in the pipeline browser. I achieve getting the number of blocks from the selected multiblock but I don't want to push apply button for each filter that has been created so got suggested about creating a pqAutoApplyReaction object and setting auto-apply to true, creating my filters and setting it back to false. pqAutoApplyReaction * autoapply=new pqAutoApplyReaction(); gives me an error: ASSERT: "parentObject != NULL" and: pqAutoApplyReaction * autoapply=new pqAutoApplyReaction(a); where "a" is a QAction* attribute of my GUI class gives me an error: libGUIMyToolBar.so: undefined symbol: _ZN19pqAutoApplyReaction12setAutoApplyEb do I have to put a specific object in pqAutoApplyReaction constructor? ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] pqAutoApplyReaction
Hi papa, The problem is that we forgot to implement the static method setAutoApply(bool)! If you could create a bug report I will fix this issue. For now you can call the static method: pqObjectInspectorWidget::setAutoAccept(bool); which does the same thing as the reaction but doesn't save the state in your settings file. 2011/7/7 papa ndéné NDIAYE : > I have built a Toolbar plugin in paraview with a button that applies > extractblock filter to a multiblock dataset > so as to get all the blocks seperately in different objects in the pipeline > browser. > > I achieve getting the number of blocks from the selected multiblock but I > don't > want to push apply button for each filter that has been created > > so got suggested about creating a pqAutoApplyReaction object and setting > auto-apply to true, creating my filters > and setting it back to false. > > pqAutoApplyReaction * autoapply=new pqAutoApplyReaction(); > gives me an error: > ASSERT: "parentObject != NULL" > > and: > pqAutoApplyReaction * autoapply=new pqAutoApplyReaction(a); > where "a" is a QAction* attribute of my GUI class > gives me an error: > libGUIMyToolBar.so: undefined symbol: > _ZN19pqAutoApplyReaction12setAutoApplyEb > > do I have to put a specific object in pqAutoApplyReaction constructor? > > > ___ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Please keep messages on-topic and check the ParaView Wiki at: > http://paraview.org/Wiki/ParaView > > Follow this link to subscribe/unsubscribe: > http://www.paraview.org/mailman/listinfo/paraview > > -- Robert Maynard ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] writing a bunch of polyhedrons
Hi Tomislav, Are you aware of vtk polyhedron support (http://www.vtk.org/Wiki/VTK/Polyhedron_Support)? Instead of manipulating the polydata structure yourself, you can insert the polyhedrons into an vtkUnstructuredGrid and then save the unstructured grid using vtkXMLUnstructuredGridWriter. There are some examples in Graphics/TestPolyhedron0(1).cxx. Thanks. Hua > -- Forwarded message -- > From: Tomislav Maric > Date: Wed, Jun 29, 2011 at 5:09 AM > Subject: [Paraview] writing a bunch of polyhedrons > To: paraview@paraview.org > > > Hi everyone, > > I have a list of polyhedrons which have arbitrary shape, and I would > like to write them all down > into a single .vtk file. I am using the POLYDATA data set. Right now, > my option is: > > init global points > init global faces > > for all polyhedra: > get local points > get local faces > add local points to global points > map+add local faces to global faces > > open the file for writing > write the .vtk header for POLYDATA > > for all points: > write the points > > for all faces: > write the polygons > > Is it possible to make this more effective? Right now I am duplicating > my information when copying/mapping > to global lists. If I want to write into this file without copying the > polyhedron data, I will still need > a memory buffer to store the file from the insertion point on, and it > would be needed twice for each > polyhedron: > > file::seek up > > write the points > > file::seek down > > write the faces > > and at the end, I would need to insert the > > POINTS nPoints dataType > > and > > POLYGONS n size > > at apropriate places. > > Any advice would be appreciated! :) > > Thanks! > ___ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Please keep messages on-topic and check the ParaView Wiki at: > http://paraview.org/Wiki/ParaView > > Follow this link to subscribe/unsubscribe: > http://www.paraview.org/mailman/listinfo/paraview > -- Hua Yang, Ph. D. R&D Engineer, Kitware, Inc. 1-919-969-6990 x 309 ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] pqAutoApplyReaction
great thanks Robert! it works all fine! I just don't know how to create a bug report 2011/7/7 Robert Maynard > Hi papa, > > The problem is that we forgot to implement the static method > setAutoApply(bool)! If you could create a bug report I will fix this > issue. For now you can call the static method: > > pqObjectInspectorWidget::setAutoAccept(bool); > > which does the same thing as the reaction but doesn't save the state > in your settings file. > > > 2011/7/7 papa ndéné NDIAYE : > > I have built a Toolbar plugin in paraview with a button that applies > > extractblock filter to a multiblock dataset > > so as to get all the blocks seperately in different objects in the > pipeline > > browser. > > > > I achieve getting the number of blocks from the selected multiblock but I > > don't > > want to push apply button for each filter that has been created > > > > so got suggested about creating a pqAutoApplyReaction object and setting > > auto-apply to true, creating my filters > > and setting it back to false. > > > > pqAutoApplyReaction * autoapply=new pqAutoApplyReaction(); > > gives me an error: > > ASSERT: "parentObject != NULL" > > > > and: > > pqAutoApplyReaction * autoapply=new pqAutoApplyReaction(a); > > where "a" is a QAction* attribute of my GUI class > > gives me an error: > > libGUIMyToolBar.so: undefined symbol: > > _ZN19pqAutoApplyReaction12setAutoApplyEb > > > > do I have to put a specific object in pqAutoApplyReaction constructor? > > > > > > ___ > > Powered by www.kitware.com > > > > Visit other Kitware open-source projects at > > http://www.kitware.com/opensource/opensource.html > > > > Please keep messages on-topic and check the ParaView Wiki at: > > http://paraview.org/Wiki/ParaView > > > > Follow this link to subscribe/unsubscribe: > > http://www.paraview.org/mailman/listinfo/paraview > > > > > > > > -- > Robert Maynard > ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] Ongoing Work to Release Unused Memory from Pipeline
Mike, There are currently no such plans in the near future, at the least. But that's definitely something we should start thinking about more seriously as we start dealing with larger and larger datasets. Utkarsh On Wed, Jul 6, 2011 at 10:12 PM, Michael Jackson wrote: > Is there any ongoing or upcoming work in ParaView to have some sort of option > to dispose of unused memory from filters that are higher up in the pipeline? > We are thinking of basing our Materials Science based software package on VTK > and then make the filters available in ParaView but our data sets are already > pushing the memory limits of "PCs". Having multiple copies of the data in > memory would just make a bad situation worse for us. I know if I write my own > pipeline in VTK I can manually dispose of memory from each pipeline step. > Just wandering if this type of capability is going to be exposed in someway > in an upcoming version of ParaView. > > Thanks > ___ > Mike Jackson www.bluequartz.net > Principal Software Engineer mike.jack...@bluequartz.net > BlueQuartz Software Dayton, Ohio > > ___ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Please keep messages on-topic and check the ParaView Wiki at: > http://paraview.org/Wiki/ParaView > > Follow this link to subscribe/unsubscribe: > http://www.paraview.org/mailman/listinfo/paraview > ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
[Paraview] Interesting bug when using windbladereader and multiple time steps
Hi, I've noticed a bug when using the windbladereader; the portion of the code that reads the blade file is one timestep behind the code that reads the field. For instance, if one is at timestep i, the field data will correspond with timestep "i" but the blade data will correspond with the last timestep chosen. When a data set is opened initially both the blade and field items are set to the initial timestep. After one starts changing the timestep, the bug makes an appearance. In the code, the blade and field specify their timesteps (individually) based on the bladeInfo and fieldInfo objects, respectively. These info objects are related to the outputVector of requestInformation -- I wonder if this is some kind of pipeline issue? Thanks, Sohail ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] Interesting bug when using windbladereader and multiple time steps
I'll take a look at it. I may need a time dependent data set if I can't figure it out though. Andy On Thu, Jul 7, 2011 at 9:13 PM, Sohail Shafii wrote: > Hi, > > I've noticed a bug when using the windbladereader; the portion of the code > that reads the blade file is one timestep behind the code that reads the > field. For instance, if one is at timestep i, the field data will > correspond with timestep "i" but the blade data will correspond with the > last timestep chosen. When a data set is opened initially both the blade > and field items are set to the initial timestep. After one starts changing > the timestep, the bug makes an appearance. > > In the code, the blade and field specify their timesteps (individually) > based on the bladeInfo and fieldInfo objects, respectively. These info > objects are related to the outputVector of requestInformation -- I wonder if > this is some kind of pipeline issue? > > Thanks, > Sohail > > ___ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Please keep messages on-topic and check the ParaView Wiki at: > http://paraview.org/Wiki/ParaView > > Follow this link to subscribe/unsubscribe: > http://www.paraview.org/mailman/listinfo/paraview > > ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] Ongoing Work to Release Unused Memory from Pipeline
If this is something that you are interested in exploring, we can help to some extent. On Thu, Jul 7, 2011 at 3:22 PM, Utkarsh Ayachit wrote: > Mike, > > There are currently no such plans in the near future, at the least. > But that's definitely something we should start thinking about more > seriously as we start dealing with larger and larger datasets. > > Utkarsh > > On Wed, Jul 6, 2011 at 10:12 PM, Michael Jackson > wrote: >> Is there any ongoing or upcoming work in ParaView to have some sort of >> option to dispose of unused memory from filters that are higher up in the >> pipeline? We are thinking of basing our Materials Science based software >> package on VTK and then make the filters available in ParaView but our data >> sets are already pushing the memory limits of "PCs". Having multiple copies >> of the data in memory would just make a bad situation worse for us. I know >> if I write my own pipeline in VTK I can manually dispose of memory from each >> pipeline step. Just wandering if this type of capability is going to be >> exposed in someway in an upcoming version of ParaView. >> >> Thanks >> ___ >> Mike Jackson www.bluequartz.net >> Principal Software Engineer mike.jack...@bluequartz.net >> BlueQuartz Software Dayton, Ohio >> >> ___ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Please keep messages on-topic and check the ParaView Wiki at: >> http://paraview.org/Wiki/ParaView >> >> Follow this link to subscribe/unsubscribe: >> http://www.paraview.org/mailman/listinfo/paraview >> > ___ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Please keep messages on-topic and check the ParaView Wiki at: > http://paraview.org/Wiki/ParaView > > Follow this link to subscribe/unsubscribe: > http://www.paraview.org/mailman/listinfo/paraview > ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] Interesting bug when using windbladereader and multiple time steps
I believe that data set went you (related to the updates I made for the wind blade reader)...the one with ten timesteps, should do the trick. Do you still have it? Sohail --- On Thu, 7/7/11, Andy Bauer wrote: From: Andy Bauer Subject: Re: [Paraview] Interesting bug when using windbladereader and multiple time steps To: "Sohail Shafii" Cc: paraview@paraview.org Date: Thursday, July 7, 2011, 7:09 PM I'll take a look at it. I may need a time dependent data set if I can't figure it out though. Andy On Thu, Jul 7, 2011 at 9:13 PM, Sohail Shafii wrote: Hi, I've noticed a bug when using the windbladereader; the portion of the code that reads the blade file is one timestep behind the code that reads the field. For instance, if one is at timestep i, the field data will correspond with timestep "i" but the blade data will correspond with the last timestep chosen. When a data set is opened initially both the blade and field items are set to the initial timestep. After one starts changing the timestep, the bug makes an appearance. In the code, the blade and field specify their timesteps (individually) based on the bladeInfo and fieldInfo objects, respectively. These info objects are related to the outputVector of requestInformation -- I wonder if this is some kind of pipeline issue? Thanks, Sohail ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
