1. 10 Aug, 2010 12 commits
  2. 09 Aug, 2010 3 commits
  3. 07 Aug, 2010 1 commit
  4. 06 Aug, 2010 2 commits
    • garth's avatar
      Merged integral curve changes from garth/streamlines branch: · 09f7c3ca
      garth authored
          Enabled AMR ghost zone information in avtIVPVTKField; integral curves  
          now correctly descend into finer levels as encountered (Eduard Deines).  
          Modified domain transition handling in avtIntegralCurve::Advance() to
          push across the boundary with smaller steps.
          Adapted the IC algorithms and the Poincare plot to the new terminology.  
          Cleanup of status and termination flags used between avtIVPSolver and  
          Introduced explicit DIRECTION flag for avtIntegralCurve to allow more robust  
          handling of integration direction; this was previously inferred from the  
          termination criterion, which is not compatible with pathlines.  
          Refactored termination handling out of the avtIVPSolver subclasses, it is now  
          the responsibility of avtIntegralCurve::AnalyzeStep().  
          avtIntegralCurve::Advance() now explicitly respects temporal bounds of  
          avtIVPField. (avtIntegralCurve::DoAdvance() was merged into  
          Reduce role of avtIVPStep: avtIVPField::ComputeScalarVariable() now uses an  
          index-based instead of variable name strings, the mapping is set through  
          Total rewrite of avtStateRecorderIntegralCurve to use a flat storage scheme  
          that reduces memory consumption tremendously. Adapted  
          avtStreamlinePolyDataFilter correspondingly.  
          avtStateRecorderIntegralCurve::Serialize() now also transmits the serialize  
          flags, ensuring that sender and receiver agree on what is transmitted; this  
          fixes current crashes in parallel IC algorithms.  
          New cell locator infrastructure based on avtCellLocator, for now local to the  
          IVP module. The previously used vtkVisItCellLocator was reimplemented as  
          avtCellLocatorClassic. Added cell locators for rectilinear  
          (avtCellLocatorRect) and unstructured meshes (avtCellLocatorBIH). The new  
          infrastructure is more robust, faster and consumes less memory for  
          (un)structured meshes; fast paths for specific mesh and cell types are  
          introduced that avoid calls to VTK methods which are not thread-safe and slow  
          (e.g. unstructured tet/hex). Locators are now stateless and can be safely  
          shared between multiple threads (in preparation for David Camp's hybrid  
          parallel work) and cached in the pipeline (future work).  
          Rewrote avtIVPVTKField to contain all cell/point location state.  
          avtParICAlgorithm now handles the case of no seedpoints without crashing.
      git-svn-id: http://visit.ilight.com/svn/visit/trunk/src@12139 18c085ea-50e0-402c-830e-de6fd14e8384
    • pugmire's avatar
      Fix compile error. · 48bb44a3
      pugmire authored
      git-svn-id: http://visit.ilight.com/svn/visit/trunk/src@12133 18c085ea-50e0-402c-830e-de6fd14e8384
  5. 05 Aug, 2010 3 commits
  6. 04 Aug, 2010 2 commits
  7. 03 Aug, 2010 9 commits
  8. 02 Aug, 2010 3 commits
  9. 31 Jul, 2010 1 commit
    • miller86's avatar
      Fixed problems with FindXdmf. It was only third party lib support function · ed4f3dc8
      miller86 authored
      using FIND_PACKAGE and was explicitly setting XDMF_DIR, both of which are
      intended to be handled by SET_UP_THIRD_PARTY.
      Added ${HDF5_XXX_DIR} refs to Xdmf.xml. Why? The Xdmf plugin doesn't use
      HDF5 does it? Yes, thats correct. It does not. However, either we are using
      Xdmf lib header files incorrectly or Xdmf lib is itself flawed in this
      regard but by virtue of include dependencies, our Xdmf plugin is indeed
      including hdf5.h as well as other HDF5 header files. So, the Xdmf plugin
      is presently DIRECTLY dependent on HDF5 and therefore needs HDF5 lib
      variables in its .xml file.
      Note, if the Xdmf plugin was not DIRECTLY dependent on HDF5, and only
      indirectly through Xdmf library's use of HDF5 itself, then
      VISIT_XDMF_LIBDEP would be the correct way to handle that.
      Found and fixed the opposite problem with H5Part. The H5Part plugin is
      DIRECTLY dependent on a number of libraries including HDF5, FASTBIT,
      SZIP. And, the .xml file for H5Part captures this dependency by
      including all the lib INCLUDE_DIR and LIB_DIR variables. However, we
      were also defining LIBDEP variable for it in CMakeLists.txt as well
      as many config-site files and that is not appropriate for H5Part.
      git-svn-id: http://visit.ilight.com/svn/visit/trunk/src@12076 18c085ea-50e0-402c-830e-de6fd14e8384
  10. 30 Jul, 2010 1 commit
  11. 29 Jul, 2010 3 commits