diff --git a/.github/ci/configure_python3.cmake b/.github/ci/configure_python3.cmake index 1001946ba..f94391ec1 100644 --- a/.github/ci/configure_python3.cmake +++ b/.github/ci/configure_python3.cmake @@ -1,13 +1,13 @@ execute_process( - COMMAND "which" "python3" - OUTPUT_VARIABLE pyexec + COMMAND "python3-config" "--prefix" + OUTPUT_VARIABLE PY_ROOT OUTPUT_STRIP_TRAILING_WHITESPACE) -set(Python3_EXECUTABLE "${pyexec}" CACHE PATH "") -set(Python3_EXECUTABLE "${pyexec}" CACHE PATH "") -get_filename_component(pypath "${pyexec}" DIRECTORY) -get_filename_component(pypath "${pypath}" DIRECTORY) -set(Python3_ROOT_DIR "${pypath}" CACHE PATH "") +set(Python3_ROOT_DIR "${PY_ROOT}" CACHE PATH "") +set(Python3_EXECUTABLE "${PY_ROOT}/bin/python3" CACHE PATH "") + +set(Python3_FIND_STRATEGY "LOCATION" CACHE STRING "") +set(Python3_FIND_FRAMEWORK "FIRST" CACHE STRING "") set(ENABLE_PYTHON ON CACHE BOOL "") set(SENSEI_PYTHON_VERSION 3 CACHE STRING "") diff --git a/.github/workflows/base-library.yml b/.github/workflows/base-library.yml index ad88c150f..703c24822 100644 --- a/.github/workflows/base-library.yml +++ b/.github/workflows/base-library.yml @@ -3,7 +3,7 @@ name: base-library on: pull_request: branches: - - main + - master - develop jobs: @@ -19,7 +19,7 @@ jobs: export DEBIAN_FRONTEND="noninteractive" export TZ="America/Los_Angeles" sudo apt-get update -qq - sudo apt-get install -qq -y git-core gcc g++ gfortran cmake ninja-build subversion automake m4 wget swig python3-dev mpich python3-numpy python3-mpi4py + sudo apt-get install -qq -y git-core gcc g++ gfortran cmake ninja-build subversion automake m4 wget swig python3-dev openmpi-bin libopenmpi-dev python3-numpy python3-mpi4py - name: Setup CCache uses: hendrikmuhs/ccache-action@v1.2 with: diff --git a/.github/workflows/ecp-data-vis-sdk.yml b/.github/workflows/ecp-data-vis-sdk.yml index 4ffcc4f22..3fe6789ca 100644 --- a/.github/workflows/ecp-data-vis-sdk.yml +++ b/.github/workflows/ecp-data-vis-sdk.yml @@ -3,7 +3,7 @@ name: ecp-sdk-integration on: pull_request: branches: - - main + - master - develop jobs: diff --git a/CMake/SENSEIConfig.cmake.in b/CMake/SENSEIConfig.cmake.in index 02063b9ab..963b71bc3 100644 --- a/CMake/SENSEIConfig.cmake.in +++ b/CMake/SENSEIConfig.cmake.in @@ -13,7 +13,7 @@ endif () list(APPEND CMAKE_MODULE_PATH "${SENSEI_DIR}") -list(APPEND CMAKE_MODULE_PATH "${CMAKE_CURRENT_LIST_DIR}/svtk-9.0") +list(APPEND CMAKE_PREFIX_PATH "${CMAKE_CURRENT_LIST_DIR}/svtk-9.0") find_package(svtk REQUIRED) set(SENSEI_LIB_TYPE STATIC) @@ -60,18 +60,25 @@ elseif (ENABLE_VTK_CORE) if (NOT VTK_DIR) set(VTK_DIR "@VTK_DIR@") endif() - find_dependency(vtk) + find_dependency(VTK) endif() +if (ENABLE_VTK_CORE) + include(sVTK) +endif () + if (ENABLE_VTKM) include(sVTKm) endif() + if (ENABLE_LIBSIM) include(sLibsim) endif() + if (ENABLE_ADIOS1) include(sADIOS1) endif() + if (ENABLE_ADIOS2) if(NOT ADIOS2_DIR) set(ADIOS2_DIR "@ADIOS2_DIR@") @@ -79,9 +86,11 @@ if (ENABLE_ADIOS2) find_dependency(ADIOS2) include(sADIOS2) endif() + if (ENABLE_HDF5) include(sHDF5) endif() + if (ENABLE_CONDUIT) if(NOT CONDUIT_DIR) set(CONDUIT_DIR "@CONDUIT_DIR@") @@ -89,6 +98,7 @@ if (ENABLE_CONDUIT) find_dependency(Conduit NO_DEFAULT_PATH PATHS ${CONDUIT_DIR}) include(sConduit) endif() + if(ENABLE_ASCENT) if(NOT ASCENT_DIR) set(ASCENT_DIR "@ASCENT_DIR@") @@ -100,7 +110,7 @@ endif() include(senseiCore) if (ENABLE_PYTHON) - set(SENSEI_PYTHON_DIR "${CMAKE_CURRENT_LIST_DIR}/../../@SENSEI_PYTHON_DIR@") + set(SENSEI_PYTHON_DIR "${CMAKE_CURRENT_LIST_DIR}/../../../@SENSEI_PYTHON_DIR@") include(sPython) diff --git a/CMake/adios.cmake b/CMake/adios.cmake index 8204be344..2b43510a6 100644 --- a/CMake/adios.cmake +++ b/CMake/adios.cmake @@ -8,6 +8,6 @@ if(ENABLE_ADIOS1) target_compile_definitions(sADIOS1 INTERFACE ${ADIOS1_DEFINITIONS}) endif() install(TARGETS sADIOS1 EXPORT sADIOS1) - install(EXPORT sADIOS1 DESTINATION ${CMAKE_INSTALL_LIBDIR}/cmake + install(EXPORT sADIOS1 DESTINATION ${sensei_CMAKE_INSTALL_CMAKEDIR} EXPORT_LINK_INTERFACE_LIBRARIES) endif() diff --git a/CMake/adios2.cmake b/CMake/adios2.cmake index a0aff1080..eff277bcd 100644 --- a/CMake/adios2.cmake +++ b/CMake/adios2.cmake @@ -5,6 +5,6 @@ if(ENABLE_ADIOS2) add_library(sADIOS2 INTERFACE) target_link_libraries(sADIOS2 INTERFACE adios2::adios2) install(TARGETS sADIOS2 EXPORT sADIOS2) - install(EXPORT sADIOS2 DESTINATION ${CMAKE_INSTALL_LIBDIR}/cmake + install(EXPORT sADIOS2 DESTINATION ${sensei_CMAKE_INSTALL_CMAKEDIR} EXPORT_LINK_INTERFACE_LIBRARIES) endif() diff --git a/CMake/ascent.cmake b/CMake/ascent.cmake index 2d68adcbe..2dd47401d 100644 --- a/CMake/ascent.cmake +++ b/CMake/ascent.cmake @@ -15,6 +15,6 @@ if(ENABLE_ASCENT) target_include_directories(sAscent SYSTEM INTERFACE ${ASCENT_INCLUDE_DIRS}) install(TARGETS sAscent EXPORT sAscent) - install(EXPORT sAscent DESTINATION ${CMAKE_INSTALL_LIBDIR}/cmake + install(EXPORT sAscent DESTINATION ${sensei_CMAKE_INSTALL_CMAKEDIR} EXPORT_LINK_INTERFACE_LIBRARIES) endif() diff --git a/CMake/build.cmake b/CMake/build.cmake index ccdf6def3..b653e4b5d 100644 --- a/CMake/build.cmake +++ b/CMake/build.cmake @@ -41,6 +41,7 @@ include(GNUInstallDirs) set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY "${CMAKE_BINARY_DIR}/${CMAKE_INSTALL_LIBDIR}") set(CMAKE_LIBRARY_OUTPUT_DIRECTORY "${CMAKE_BINARY_DIR}/${CMAKE_INSTALL_LIBDIR}") set(CMAKE_RUNTIME_OUTPUT_DIRECTORY "${CMAKE_BINARY_DIR}/${CMAKE_INSTALL_BINDIR}") +set(sensei_CMAKE_INSTALL_CMAKEDIR ${CMAKE_INSTALL_LIBDIR}/cmake/sensei) message(STATUS "CMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE}") message(STATUS "CMAKE_CXX_FLAGS=${CMAKE_CXX_FLAGS}") diff --git a/CMake/catalyst.cmake b/CMake/catalyst.cmake index c4d6f1236..6a459859a 100644 --- a/CMake/catalyst.cmake +++ b/CMake/catalyst.cmake @@ -29,7 +29,7 @@ if (ENABLE_CATALYST) add_library(sVTK INTERFACE) target_link_libraries(sVTK INTERFACE ${ParaView_LIBRARIES} ${VTK_LIBRARIES}) install(TARGETS sVTK EXPORT sVTK) - install(EXPORT sVTK DESTINATION ${CMAKE_INSTALL_LIBDIR}/cmake + install(EXPORT sVTK DESTINATION ${sensei_CMAKE_INSTALL_CMAKEDIR} EXPORT_LINK_INTERFACE_LIBRARIES) endif() diff --git a/CMake/conduit.cmake b/CMake/conduit.cmake index a884e1152..1be51b751 100644 --- a/CMake/conduit.cmake +++ b/CMake/conduit.cmake @@ -7,6 +7,6 @@ if(ENABLE_CONDUIT) target_include_directories(sConduit SYSTEM INTERFACE ${CONDUIT_INCLUDE_DIRS}) install(TARGETS sConduit EXPORT sConduit) - install(EXPORT sConduit DESTINATION ${CMAKE_INSTALL_LIBDIR}/cmake + install(EXPORT sConduit DESTINATION ${sensei_CMAKE_INSTALL_CMAKEDIR} EXPORT_LINK_INTERFACE_LIBRARIES) endif() diff --git a/CMake/config.cmake b/CMake/config.cmake index 83bcb9838..9be9ca7c2 100644 --- a/CMake/config.cmake +++ b/CMake/config.cmake @@ -5,11 +5,11 @@ install(FILES ${CMAKE_BINARY_DIR}/senseiConfig.h DESTINATION include) set(SENSEI_BUILD OFF) configure_file(CMake/SENSEIConfig.cmake.in - ${CMAKE_INSTALL_LIBDIR}/cmake/SENSEIConfig.cmake @ONLY) + ${sensei_CMAKE_INSTALL_CMAKEDIR}/SENSEIConfig.cmake @ONLY) configure_file(CMake/SENSEIConfigVersion.cmake.in - ${CMAKE_INSTALL_LIBDIR}/cmake/SENSEIConfigVersion.cmake @ONLY) + ${sensei_CMAKE_INSTALL_CMAKEDIR}/SENSEIConfigVersion.cmake @ONLY) -install(FILES ${CMAKE_BINARY_DIR}/${CMAKE_INSTALL_LIBDIR}/cmake/SENSEIConfig.cmake - ${CMAKE_BINARY_DIR}/${CMAKE_INSTALL_LIBDIR}/cmake/SENSEIConfigVersion.cmake - DESTINATION ${CMAKE_INSTALL_LIBDIR}/cmake) +install(FILES ${CMAKE_BINARY_DIR}/${sensei_CMAKE_INSTALL_CMAKEDIR}/SENSEIConfig.cmake + ${CMAKE_BINARY_DIR}/${sensei_CMAKE_INSTALL_CMAKEDIR}/SENSEIConfigVersion.cmake + DESTINATION ${sensei_CMAKE_INSTALL_CMAKEDIR}) diff --git a/CMake/hdf5.cmake b/CMake/hdf5.cmake index 8f3e363ef..1b97508c3 100644 --- a/CMake/hdf5.cmake +++ b/CMake/hdf5.cmake @@ -10,6 +10,6 @@ if (ENABLE_HDF5) target_include_directories(sHDF5 SYSTEM INTERFACE ${HDF5_INCLUDE_DIRS}) install(TARGETS sHDF5 EXPORT sHDF5) - install(EXPORT sHDF5 DESTINATION ${CMAKE_INSTALL_LIBDIR}/cmake + install(EXPORT sHDF5 DESTINATION ${sensei_CMAKE_INSTALL_CMAKEDIR} EXPORT_LINK_INTERFACE_LIBRARIES) endif() diff --git a/CMake/libsim.cmake b/CMake/libsim.cmake index 94ac82551..ed02d1331 100644 --- a/CMake/libsim.cmake +++ b/CMake/libsim.cmake @@ -4,6 +4,6 @@ if(ENABLE_LIBSIM) target_link_libraries(sLibsim INTERFACE ${LIBSIM_LIBRARIES}) target_include_directories(sLibsim SYSTEM INTERFACE ${LIBSIM_INCLUDE_DIRS}) install(TARGETS sLibsim EXPORT sLibsim) - install(EXPORT sLibsim DESTINATION ${CMAKE_INSTALL_LIBDIR}/cmake + install(EXPORT sLibsim DESTINATION ${sensei_CMAKE_INSTALL_CMAKEDIR} EXPORT_LINK_INTERFACE_LIBRARIES) endif() diff --git a/CMake/mpi.cmake b/CMake/mpi.cmake index 853a355e3..57be9ce17 100644 --- a/CMake/mpi.cmake +++ b/CMake/mpi.cmake @@ -16,7 +16,7 @@ elseif (ENABLE_CORI_GPU OR (NOT DEFINED ENABLE_CORI_GPU AND NOT ("$ENV{OPENMPI_D set(MPIEXEC srun CACHE STRING "Platform MPI run equivalent") set(MPI_C_FOUND CACHE BOOL ON "status of MPI config") else() - find_package(MPI COMPONENTS C) + find_package(MPI COMPONENTS C CXX) endif() if (NOT MPI_C_FOUND) @@ -35,5 +35,5 @@ target_include_directories(sMPI SYSTEM INTERFACE target_link_libraries(sMPI INTERFACE ${MPI_C_LIBRARIES}) install(TARGETS sMPI EXPORT sMPI) -install(EXPORT sMPI DESTINATION ${CMAKE_INSTALL_LIBDIR}/cmake +install(EXPORT sMPI DESTINATION ${sensei_CMAKE_INSTALL_CMAKEDIR} EXPORT_LINK_INTERFACE_LIBRARIES) diff --git a/CMake/opts.cmake b/CMake/opts.cmake index 6974ecd23..6f6730e0f 100644 --- a/CMake/opts.cmake +++ b/CMake/opts.cmake @@ -6,7 +6,7 @@ if(ENABLE_OPTS) $) install(TARGETS sOPTS EXPORT sOPTS) - install(EXPORT sOPTS DESTINATION ${CMAKE_INSTALL_LIBDIR}/cmake) + install(EXPORT sOPTS DESTINATION ${sensei_CMAKE_INSTALL_CMAKEDIR}) install(DIRECTORY "${CMAKE_CURRENT_SOURCE_DIR}/utils/opts/include" DESTINATION include) endif() diff --git a/CMake/python.cmake b/CMake/python.cmake index c206866c5..77ec51127 100644 --- a/CMake/python.cmake +++ b/CMake/python.cmake @@ -21,10 +21,6 @@ if (ENABLE_PYTHON) find_package(PythonInterp ${SENSEI_PYTHON_VERSION} REQUIRED) find_package(PythonLibs ${SENSEI_PYTHON_VERSION} REQUIRED) find_package(NUMPY REQUIRED) - find_program(swig_cmd NAMES swig swig3.0 swig4.0) - if (swig_cmd-NOTFOUND) - message(SEND_ERROR "Failed to locate swig") - endif() # find MPI find_package(MPI4PY REQUIRED) @@ -34,18 +30,18 @@ if (ENABLE_PYTHON) target_include_directories(sPython INTERFACE ${PYTHON_INCLUDE_PATH} ${MPI4PY_INCLUDE_DIR}) target_link_libraries(sPython INTERFACE ${PYTHON_LIBRARIES}) install(TARGETS sPython EXPORT sPython) - install(EXPORT sPython DESTINATION ${CMAKE_INSTALL_LIBDIR}/cmake + install(EXPORT sPython DESTINATION ${sensei_CMAKE_INSTALL_CMAKEDIR} EXPORT_LINK_INTERFACE_LIBRARIES) # find SWIG cmake_policy(SET CMP0078 NEW) cmake_policy(SET CMP0086 NEW) - find_package(SWIG COMPONENTS python) + find_package(SWIG REQUIRED COMPONENTS python) include(UseSWIG) # the destination of all SENSEI Python codes set(SENSEI_PYTHON_SITE - "${CMAKE_INSTALL_LIBDIR}/python-${PYTHON_VERSION_MAJOR}.${PYTHON_VERSION_MINOR}/site-packages/" + "${CMAKE_INSTALL_LIBDIR}/python${PYTHON_VERSION_MAJOR}.${PYTHON_VERSION_MINOR}/site-packages/" CACHE STRING "Where Python modules are compiled and installed.") set(SENSEI_PYTHON_DIR "${SENSEI_PYTHON_SITE}/sensei/" diff --git a/CMake/svtk.cmake b/CMake/svtk.cmake index 373eb904e..47ca5d139 100644 --- a/CMake/svtk.cmake +++ b/CMake/svtk.cmake @@ -5,5 +5,5 @@ add_library(sSVTK INTERFACE) target_link_libraries(sSVTK INTERFACE ${SVTK_LIBRARIES}) install(TARGETS sSVTK EXPORT sSVTK) -install(EXPORT sSVTK DESTINATION ${CMAKE_INSTALL_LIBDIR}/cmake +install(EXPORT sSVTK DESTINATION ${sensei_CMAKE_INSTALL_CMAKEDIR} EXPORT_LINK_INTERFACE_LIBRARIES) diff --git a/CMake/threads.cmake b/CMake/threads.cmake index b8086eeaf..aa430b8f1 100644 --- a/CMake/threads.cmake +++ b/CMake/threads.cmake @@ -4,5 +4,5 @@ set_property(TARGET Threads::Threads PROPERTY IMPORTED_GLOBAL TRUE) add_library(thread INTERFACE) target_link_libraries(thread INTERFACE ${CMAKE_THREAD_LIBS_INIT}) install(TARGETS thread EXPORT thread) -install(EXPORT thread DESTINATION ${CMAKE_INSTALL_LIBDIR}/cmake +install(EXPORT thread DESTINATION ${sensei_CMAKE_INSTALL_CMAKEDIR} EXPORT_LINK_INTERFACE_LIBRARIES) diff --git a/CMake/version.cmake b/CMake/version.cmake index ea171adeb..46d79642a 100644 --- a/CMake/version.cmake +++ b/CMake/version.cmake @@ -1,14 +1,27 @@ -set(tmp) -find_package(Git QUIET) -if(GIT_FOUND) - execute_process(COMMAND ${GIT_EXECUTABLE} - --git-dir=${CMAKE_SOURCE_DIR}/.git describe --tags - OUTPUT_VARIABLE tmp OUTPUT_STRIP_TRAILING_WHITESPACE) -endif() -if(NOT tmp) - set(tmp "v0.0.0") +set(SENSEI_VERSION "" CACHE STRING "SENSEI version") + +# Default detection of version +if (SENSEI_VERSION STREQUAL "") + # The default version is the current major release + # This is required for computing version in released + # source tarballs. + set(tmp "v4.0.0") + + # If inside a git repo, attempt to inspect the tag instead + # of using the hardcoded value + if (EXISTS ${CMAKE_SOURCE_DIR}/.git) + find_package(Git QUIET) + if(GIT_FOUND) + execute_process(COMMAND ${GIT_EXECUTABLE} + --git-dir=${CMAKE_SOURCE_DIR}/.git describe --tags + OUTPUT_VARIABLE tmp OUTPUT_STRIP_TRAILING_WHITESPACE) + endif() + endif () + + # Override the CACHE variable for configure with the computed + # version + set(SENSEI_VERSION ${tmp}) endif() -set(SENSEI_VERSION ${tmp} CACHE STRING "SENSEI version" FORCE) string(REGEX REPLACE "^v([0-9]+)\\.([0-9]+)\\.([0-9]+)(.*$)" "\\1" SENSEI_VERSION_MAJOR ${SENSEI_VERSION}) diff --git a/CMake/vtk.cmake b/CMake/vtk.cmake index 5311864bc..018814290 100644 --- a/CMake/vtk.cmake +++ b/CMake/vtk.cmake @@ -7,7 +7,7 @@ if (ENABLE_VTK_MPI OR ENABLE_VTK_IO OR ENABLE_VTK_MPI OR # lets build the list of modules for VTK pre-8.90 and post 8.90 set(sensei_vtk_components_legacy) - set(sensei_vtk_components_modern) + set(sensei_vtk_components_modern CommonDataModel) if (ENABLE_VTK_MPI) list(APPEND sensei_vtk_components_legacy vtkParallelMPI) @@ -75,7 +75,7 @@ if (ENABLE_VTK_MPI OR ENABLE_VTK_IO OR ENABLE_VTK_MPI OR endif() install(TARGETS sVTK EXPORT sVTK) - install(EXPORT sVTK DESTINATION ${CMAKE_INSTALL_LIBDIR}/cmake + install(EXPORT sVTK DESTINATION ${sensei_CMAKE_INSTALL_CMAKEDIR} EXPORT_LINK_INTERFACE_LIBRARIES) endif() endif() diff --git a/CMake/vtkm.cmake b/CMake/vtkm.cmake index d5dff6283..13551cf9b 100644 --- a/CMake/vtkm.cmake +++ b/CMake/vtkm.cmake @@ -13,6 +13,6 @@ if (ENABLE_VTKM) #target_include_directories(sVTKm SYSTEM INTERFACE ${VTKm_INCLUDE_DIRS}) #target_compile_definitions(sVTKm INTERFACE ${VTKm_COMPILE_OPTIONS}) install(TARGETS sVTKm EXPORT sVTKm) - install(EXPORT sVTKm DESTINATION ${CMAKE_INSTALL_LIBDIR}/cmake + install(EXPORT sVTKm DESTINATION ${sensei_CMAKE_INSTALL_CMAKEDIR} EXPORT_LINK_INTERFACE_LIBRARIES) endif() diff --git a/rtd-docs/conf.py b/rtd-docs/conf.py index eac292ab7..75bb9b5e5 100644 --- a/rtd-docs/conf.py +++ b/rtd-docs/conf.py @@ -66,6 +66,7 @@ # source_suffix = ['.rst', '.md'] source_suffix = '.rst' + # The master toctree document. master_doc = 'index' @@ -82,8 +83,9 @@ # add any included files to this list to silence warnings about # duplicate references exclude_patterns = [u'_build', 'Thumbs.db', '.DS_Store', \ - 'reaction_rate_demo', 'adaptor_apisi.rst', 'data_addaptor_apis.rst', \ - 'analysis_adaptor_apis.rst'] + 'data_adaptor_api.rst', 'analysis_adaptor_api.rst', 'ascent_back_end.rst', \ + 'catalyst_back_end.rst', 'histogram_back_end.rst', 'autocorrelation_back_end.rst', \ + 'reaction_rate_demo.rst', 'pipeline_demo.rst'] # The name of the Pygments (syntax highlighting) style to use. pygments_style = 'friendly' @@ -107,6 +109,12 @@ # so a file named "default.css" will overwrite the builtin "default.css". html_static_path = ['_static'] +# These paths are either relative to html_static_path +# or fully qualified paths (eg. https://...) +html_css_files = [ + 'theme_overrides.css', +] + # Custom sidebar templates, must be a dictionary that maps document names # to template names. # diff --git a/rtd-docs/data_adaptor_api.rst b/rtd-docs/data_adaptor_api.rst index 6250b5777..c47d90bcb 100644 --- a/rtd-docs/data_adaptor_api.rst +++ b/rtd-docs/data_adaptor_api.rst @@ -15,8 +15,8 @@ Finally the data adaptor is a key piece of SENSEI's in transit system. The analysis back end can be run in a different parallel job and be given an in transit data adaptor in place of the simulation's data adaptor. In this scenario the in transit data adaptor helps move data needed by the analysis back end. -The data adaptor API enables this scenario to apear the same to the simulation -and the analysis back end. Neither simulaiton nor analysis need be modified for +The data adaptor API enables this scenario to appear the same to the simulation +and the analysis back end. Neither simulation nor analysis need be modified for in transit processing. diff --git a/rtd-docs/data_model.rst b/rtd-docs/data_model.rst index b69d2d6e8..39d4bf003 100644 --- a/rtd-docs/data_model.rst +++ b/rtd-docs/data_model.rst @@ -1,4 +1,5 @@ .. _data_model: + Data model ========== The data model is a key piece of the system. It allows data to be packaged and diff --git a/rtd-docs/examples.rst b/rtd-docs/examples.rst index 99abf9086..218f53b74 100644 --- a/rtd-docs/examples.rst +++ b/rtd-docs/examples.rst @@ -1,9 +1,8 @@ .. _examples: + ********* Examples ********* .. include:: reaction_rate_demo.rst .. include:: pipeline_demo.rst - - diff --git a/rtd-docs/examples_amrex_tutorials.rst b/rtd-docs/examples_amrex_tutorials.rst new file mode 100644 index 000000000..280b7cc8c --- /dev/null +++ b/rtd-docs/examples_amrex_tutorials.rst @@ -0,0 +1,129 @@ +.. _amrextutorials: + +*********************************************** +SENSEI + AMReX +*********************************************** + +======== +Synopsis +======== + +AMReX is a freely available simulation software framework designed to enable massively parallel block-structured adaptive mesh refinement (AMR) applications. + +The `AMReX Tutorials repository `_ houses several tutorial examples demonstrating the use of SENSEI in AMReX based simulation codes. The full list of tutorials are documented `here `_. + +-------- +Overview +-------- + +Two distinct tutorial examples are available with multiple configurations: + ++--------------------+---------------------------------------------------------------------------+ +| Name | Description | ++====================+===========================================================================+ +| Advection_AmrCore | This tutorial illustrates an explicit SENSEI instrumentation of a code | +| | that makes use of `amrex::AmrMesh`. | ++--------------------+---------------------------------------------------------------------------+ +| Advection_AmrLevel | This tutorial illustrates 3 scenarios with a code that makes use of | +| | `amrex::Amr`. The first, `ImplcitAmr`, illustrates using SENSEI with the | +| | built-in instrumentation in `amrex::Amr`. The second, `ExplcitAmr`, | +| | illustrates using SENSEI with an explicit instrumentation. The third, | +| | `ExplicitParticlesAndAmr`, illustrates using SENSEI from a simulation | +| | that generates both particle and meshed based data. | ++--------------------+---------------------------------------------------------------------------+ + +Note that the `Advection_AmrLevel` contains code for 3 different scenarios. +Which of these is active/available depends on how AMReX is compiled. See below +for the details on configuring the build. + + +========== +Setting Up +========== + +Compiling the AMReX SENSEI tutorials requires that SENSEI is previously +installed. The options that SENSEI was built with determine the specific in +situ capabilities available. Additional CMake options must also be passed +when compiling AMReX to activate the SENSEI bridge and adaptors bundled +with AMReX. The AMReX library is available on `GitHub `_. + +------------- +Build options +------------- + +The options that AMReX is compiled with determine which SENSEI tutorials are +available. The following table summarizes the various combinations and results. + ++---------------------------------+--------------------------------------------------------------+ +| CMake Options | What gets built | ++=================================+==============================================================+ +| -DAMReX_SENSEI=ON | Enables SENSEI features in AMReX. Required to compile SENSEI | +| -DAMReX_FORTRAN=ON | tutorials. Enables the AmrCore tutorial and AmrLevel | +| -DSENSEI_DIR= | implicit tutorial. | ++---------------------------------+--------------------------------------------------------------+ +| -DAMReX_SENSEI=ON | Enables the AmrCore tutorial, AmrLevel explicit tutorial, | +| -DAMReX_PARTICLES=ON | and particle based tutorials to be compiled. | +| -DAMReX_NO_SENSEI_AMR_INST=TRUE | | +| -DAMReX_FORTRAN=ON | | +| -DSENSEI_DIR= | | ++---------------------------------+--------------------------------------------------------------+ +| -DAMReX_SENSEI=ON | Enables the AmrCore tutorial, AmrLevel explicit tutorial. | +| -DAMReX_NO_SENSEI_AMR_INST=TRUE | | +| -DAMReX_FORTRAN=ON | | +| -DSENSEI_DIR= | | ++---------------------------------+--------------------------------------------------------------+ + +=================== +Running the Example +=================== + +Once the tutorials are compiled they can be run from their corresponding +directory. The executable is passed an AMReX parm-parse `inputs` file +configuring the run. Options inside the `inputs` file configure the SENSEI +instrumentation inside AMReX. Additionally SENSEI needs to configure the +back-end that will process the data generated. This is done with a SENSEI XML +file. Within each tutorial the `sensei` directory contains a number of SENSEI +XML configuration files. The `inputs` file must be modified to point to one of +these. Which one depends on how SENSEI was compiled. For instance the following +snippet from an `inputs` file would configure SENSEI to send data to ParaView +Catalyst, + +.. highlight:: shell + +:: + + sensei.enabled = 1 # turn SENSEI in situ on/off + sensei.config = sensei/render_iso_catalyst_3d.xml # render simulation data with ParaView Catalyst + sensei.frequency = 1 # number of level 0 steps between in situ processing + +while the following snippet would configure SENSEI to send data to VisIt Libsim, + +.. highlight:: shell + +:: + + sensei.enabled = 1 # turn SENSEI in situ on/off + sensei.config = sensei/render_iso_libsim_3d.xml # render simulation data with ParaView Catalyst + sensei.frequency = 1 # number of level 0 steps between in situ processing + +There are a number of XML files providing the configuration for a number of the +available back-ends. A given SENSEI XML configuration is only valid when the +SENSEI install has been compiled with the requisite back-end enabled. + +Note that the `Advection_AmrLevel_ExplicitParticlesAndAmr` uses the file +`inputs.tracers` while the others use the file `inputs`. + +The tutorials are run by switching into the tutorial's build directory and +issuing the launching command. For instance the +`Advection_AmrLevel_ImplicitAmr` tutorial is launched by a command similar to: + +.. highlight:: shell + +:: + + mpiexec -np 4 ./Advection_AmrLevel_ImplicitAmr inputs + +======= +Results +======= + diff --git a/rtd-docs/examples_catalyst_bidirectional.rst b/rtd-docs/examples_catalyst_bidirectional.rst new file mode 100644 index 000000000..722b10ff3 --- /dev/null +++ b/rtd-docs/examples_catalyst_bidirectional.rst @@ -0,0 +1,83 @@ +.. _catalystbidirectional: + +*********************************************** +Computational Steering with Catalyst and SENSEI +*********************************************** + +======== +Synopsis +======== + +In this example, we demonstrate using SENSEI with a bidirectional Catalyst 1.0 +Analysis Adaptor to perform computational steering. Here, we employ the +oscillator miniapp. The list of oscillator objects are exposed to Catalyst +where each oscillator can be manipulated. Position of oscillators as well as +oscillator properties can be modified on the fly, changing the behavior of the +simulated domain. + +========== +Setting Up +========== + +You will need ParaView 5.10 installed, and SENSEI compiled with the options +`ENABLE_CATALYST` and `ENABLE_CATALYST_PYTHON` turned on. + +Note, only Catalyst 1.0 scripts are compatible with computational steering in +SENSEI. Unfortunately, those scripts cannot be generated automatically in the +most recent editions of ParaView. The provided example script can be modified +manually for your own purposes. + +=================== +Running the Example +=================== + +Open the ParaView application and navigate to `Tools`->`Manage Plugins`. Press +the `Load New...` button, and navigate the file browser to the location of the +`oscillator_catalyst_steering_proxies.xml` file, and select that file. + +Next, navigate to `Catalyst`->`Connect` and accept incoming connections on port +22222. This will tell ParaView to begin listening for Catalyst connections on +that port. If a different port number is desired, you will need to edit the +port number in the Catalyst python script `oscillator_catalyst_steering.py` to +the desired port, and then start Catalyst in ParaView with the same desired +port number. + +In a terminal, navigate to your desired run directory (this testing directory +is fine to run from), and start the oscillator miniapp with the SENSEI config +xml `oscillator_catalyst_steering.xml`. Oscillator miniapp options can be set +as desired, but a good starting point is: + +.. code-block:: bash + + $ mpirun -np 1 /path/to/oscillator -g 1 -t 0.01 -f oscillator_catalyst_steering.xml simple.osc + +With the Oscillator miniapp running, ParaView should automatically detect a new Catalyst connection and add several items to the catalsyt server list in the `Pipeline Browser`. Clicking the icon next to `mesh` and `oscillator` will display the data to the 3D viewport, updating as the miniapp progresses. + +Click on the `Steering Parameters` item in the `Pipeline Browser`. The `Properties` panel will display several controls over each oscillator which can be modified, manipulating the oscillator parameters as the miniapp executes. + +.. figure:: images/pv_catalyst_steering_gui.png + :width: 30 % + :align: center + + The Properties panel provides parameters to add or delete oscillators in the domain, and change the parameters of the oscillators independently. + + +.. figure:: images/pv_catalyst_steering_window.png + :width: 80 % + :align: center + + ParaView's GUI contains the Properties panel, where oscillator parameters can be edited, a center 3D Viewport where the oscillators are rendered using ray-traced volume rendering, and a second 3D Viewport where the 5 existing oscillators' locations are visualized with respect to one another. + + +======= +Results +======= + +The key takeaway from this example is that Catalyst and SENSEI can be used to +perform computational steering tasks with in situ visualization. The +oscillators, whose properties and locations can be modified in situ, respond to +the user's modifications. Setting up such a computational steering workflow in +your own simulation code requires exposing desired parameters to SENSEI, and +writing XML instructions for ParaView to generate the GUI for modifying the +parameters. + diff --git a/rtd-docs/examples_example_rst.rst b/rtd-docs/examples_example_rst.rst new file mode 100644 index 000000000..43bd1be61 --- /dev/null +++ b/rtd-docs/examples_example_rst.rst @@ -0,0 +1,55 @@ +.. _example_example: + +Example Template +========================== + +Come up with a decent title and underline it with your favorite non-alphanumeric character (# is a good choice). + +Synopsis +######## + +Write a quick synopsis of your example. Detail briefly how it uses SENSEI and what code you are connecting to. `Hyperlinks `_ to the science code/repository are appropriated here. + +Setting Up +########## + +Here, we provide instructions on how to setup the build environment. Briefly describe which options you want for this example in SENSEI, but don't worry about going into detail about building dependencies that SENSEI needs as that is documented elsewhere (I hope...). Detail whatever unique build options and weird steps are required to build the science code with SENSEI enabled, but do not go into depth on how to build that science code in general, simply link to their build instructions (which are hopefully well documented). + +If there are multiple ways of setting up the science code, or there are multiple ways to build SENSEI which provide different functionality, detail those variations here as well. + +Running the Example +################### + +Next, we detail the procedures to run the example. You will want to include your SENSEI config xml(s) here like this: + +.. _python_insitu_xml: +.. code-block:: xml + + + + + threshold=1.0 + mesh='mesh' + array='data' + cen=1 + out_file='random_2d_64_python.png' + + + + +Subsections would be worthwhile if there are multiple ways to run the example. + +You can write terminal commands here like this: + +.. code-block:: shell + +mpirun -np 1 /path/to/oscillator -g 1 -t 0.01 -f oscillator_catalyst_steering.xml simple.osc + +If you have simple supplementary scripts (like Catalyst Python scripts, or bash scripts), you may want to write them in here as well, though sometimes these get quite long, and a hyperlink to the source code will suffice. + +For interactive examples (i.e. steering), provide instructions for interacting with the example. + +Results +####### + +Finally, briefly showcase what successfully running the example will yield. Provide pictures of output, or sample data output etc. diff --git a/rtd-docs/examples_intransit.rst b/rtd-docs/examples_intransit.rst new file mode 100644 index 000000000..dc3efb800 --- /dev/null +++ b/rtd-docs/examples_intransit.rst @@ -0,0 +1,52 @@ +.. _example_intransit: + +In Transit MxN communication with LAMMPS, SENSEI, and Paraview/Catalyst +======================================================================= + +Synopsis +######## + +In this example we instrument the molecular dynamics simulation code LAMMPS with SENSEI and demonstrate in transit capabilities. Our example showcases M to N ranks redistribution and the Catalyst analysis adaptor to generate a Cinema database. + +Setting Up +########## + +This example uses Docker containers. There are two containers: (1) Producer, which uses the LAMMPS molecular dynamics simulator instrumented with SENSEI; and (2) Consumer, which uses the SENSEI endpoint and the Paraview/Catalyst analysis adaptor. + +A Zenodo artifact is available at https://zenodo.org/record/6336286 , containing Dockerfile recipes to build the Producer and Consumer. Please refer to file "containers.zip" + +You should be able to build your own images with the Dockerfiles provided. If you would like to use prebuilt docker containers you can get them from the Docker hub: + +.. highlight:: shell + +:: + + docker pull srizzi/woiv22producer_runtime + docker pull srizzi/woiv22consumer_runtime + +If your site uses Singularity you can build Singularity images pulling from the Docker hub + +Running the Example +################### + +From the same Zenodo artifact, you can download "in_transit_demo_files.zip" , containing SENSEI xml configuration files and scripts to run the demo. + +The LAMMPS producer is configured to run a simple simulation configured in file in_lj + +With the parameters in in_lj the simulation evolves about 16 million hydrogen atoms. If you would like to change the size of the simulation, edit the multipliers for xx, yy, and zz in file in_lj. The multipliers are 16 in the file provided, which results in 67108864 atoms simulated. + +The producer is launched with producer.sh . Notice that settings in this script are specific for ThetaGPU, but you should not find any major difficulties if you wish to adapt it for your system. The script also relies on a local build of mpich. + +Notice that SENSEI uses the file adios_write_sst.xml to configure its backend. You will likely need to change the NetworkInterface in this xml file with an appropiate value for your own system. + +The consumer side contains SENSEI with ParaView/Catalyst. For simplicity, in this demo we use the PosthocIO backend, which saves the received data in VTK format. + +The consumer is launched with script consumer.sh and there are two xml configuration files required for SENSEI. The first defines the network transport and its called adios_transport_sst.xml . Once again, you may need to change the NetworkInterface parameter in this file according to your system. +The second xml file, vtk_io.xml in this case, activates the PosthocIO analysis adaptor in SENSEI and specifies a directory to save the data. + +These are intended to run on different machines and different ranks on producer (M) and consumer (N). The scripts provided will launch 16 MPI ranks on the producer and 4 MPI ranks on the consumer. + +Results +####### + +The simulation is configure to run five timesteps. The SENSEI endpoint should receive data for each timestep and save it as VTK files. diff --git a/rtd-docs/examples_openfoam.rst b/rtd-docs/examples_openfoam.rst new file mode 100644 index 000000000..99812abc3 --- /dev/null +++ b/rtd-docs/examples_openfoam.rst @@ -0,0 +1,119 @@ +SENSEI OpenFOAM Interface +========================= + +Synopsis +######## + +The SENSEI OpenFOAM Interface integrates SENSEI into OpenFOAM. The interface +is implemented as an OpenFOAM function object which subclasses the SENSEI +VTKDataAdaptor. The interface was developed using Version 7 of OpenFOAM at +`openfoam.org `_ and SENSEI 3.2.1. This interface may +work with other OpenFOAM and SENSEI versions, but this has not been tested. + +Setting Up +########## + +These instructions assume that SENSEI and OpenFOAM have already been built and +installed. + +To build the OpenFOAM function object that implements the SENSEI interface, +edit the file functionObjects/sensei/Allwmake and specify paths to SENSEI and +to VTK by setting the following variables: + +.. code-block:: shell + + SENSEI_DIR="SENSEI installation path" + VTK_INC="path to VTK include files" + VTK_LIB="path to VTK libraries" + +Note that you must point the the same VTK version used by SENSEI. + +These paths will be used to set the compile and link flags used by the build +as follows. These typically will not need to be modified: + +.. code-block:: shell + + export SENSEI_CXXFLAGS="-O2 -I$SENSEI_DIR/include -I$VTK_INC" + export SENSEI_CXXLIBS="-L$SENSEI_DIR/lib -lsensei -lsenseiCore -lpugixml" + export SENSEI_CXXLIBS="$SENSEI_CXXLIBS -Wl,-rpath=$VTK_LIB" + +To build the interface, you set up your OpenFOAM environment and execute the +Allwmake script: + +.. code-block:: shell + + cd functionObjects/sensei + source "OpenFOAM installation path"/etc/bashrc + ./Allwmake + +Running Allwmake builds the interface and installs it into the users OpenFOAM +library directory. + +Running the Example +################### + +Copy the pipeCyclic tutorial from the OpenFOAM distribution to use as an +example. You can find it here: + +.. code-block:: shell + + "OpenFOAM installation path"/tutorials/incompressible/simpleFoam/pipeCyclic + +Edit the system/controlDict file in the tutorial and add a +senseiFunctionObject block into the functions section. This will load the +interface during the solver run and export the requested fields. For example: + +.. code-block:: javascript + + functions + { + senseiFunctionObject + { + type senseiFunctionObject; + libs ("libSenseiAdaptor.so"); + + enabled true; + + name simpleFoam; + desc "simpleFoam pipeCyclic tutorial SENSEI export"; + fields ( U p k epsilon ); + } + } + +Next, create a file called constants/sensei_config.xml to control what SENSEI +will export. Here is an example sensei_config.xml file that outputs PNG +images of a slice using Libsim" + +.. code-block:: xml + + + + + +Then run the tutorial using the Allrun script: + +.. code-block:: shell + + ./Allrun + +Results +####### + +Here are two of the images produced running the tutorial with the above +sensei_config.xml file: + +.. figure:: images/openfoam_slice_00001.png + + Z = 0.25 slice at time step 1 + +.. figure:: images/openfoam_slice_00010.png + + Z = 0.25 slice at time step 10 diff --git a/rtd-docs/images/Bloodflow_Murphy.png b/rtd-docs/images/Bloodflow_Murphy.png new file mode 100644 index 000000000..30b3eae17 Binary files /dev/null and b/rtd-docs/images/Bloodflow_Murphy.png differ diff --git a/rtd-docs/images/Harvey_Ames.png b/rtd-docs/images/Harvey_Ames.png new file mode 100644 index 000000000..8d1467d12 Binary files /dev/null and b/rtd-docs/images/Harvey_Ames.png differ diff --git a/rtd-docs/images/Nek5000_Bernardoni.png b/rtd-docs/images/Nek5000_Bernardoni.png new file mode 100644 index 000000000..df9aafb16 Binary files /dev/null and b/rtd-docs/images/Nek5000_Bernardoni.png differ diff --git a/rtd-docs/images/Nek5000_Shudler.png b/rtd-docs/images/Nek5000_Shudler.png new file mode 100644 index 000000000..a7e16fcaf Binary files /dev/null and b/rtd-docs/images/Nek5000_Shudler.png differ diff --git a/rtd-docs/images/SENSEI-design.png b/rtd-docs/images/SENSEI-design.png new file mode 100644 index 000000000..2655f6967 Binary files /dev/null and b/rtd-docs/images/SENSEI-design.png differ diff --git a/rtd-docs/images/SENSEI-design_preview.png b/rtd-docs/images/SENSEI-design_preview.png new file mode 100644 index 000000000..641abf0e7 Binary files /dev/null and b/rtd-docs/images/SENSEI-design_preview.png differ diff --git a/rtd-docs/images/Spack_Shudler.png b/rtd-docs/images/Spack_Shudler.png new file mode 100644 index 000000000..2a8124700 Binary files /dev/null and b/rtd-docs/images/Spack_Shudler.png differ diff --git a/rtd-docs/images/amrex_tutorial_preview.png b/rtd-docs/images/amrex_tutorial_preview.png new file mode 100644 index 000000000..0e01db916 Binary files /dev/null and b/rtd-docs/images/amrex_tutorial_preview.png differ diff --git a/rtd-docs/images/engwcmp_preview.png b/rtd-docs/images/engwcmp_preview.png new file mode 100644 index 000000000..912687b24 Binary files /dev/null and b/rtd-docs/images/engwcmp_preview.png differ diff --git a/rtd-docs/images/iamr_iso_knl_420_128spp_sm_FIN.png b/rtd-docs/images/iamr_iso_knl_420_128spp_sm_FIN.png new file mode 100644 index 000000000..067a49e6a Binary files /dev/null and b/rtd-docs/images/iamr_iso_knl_420_128spp_sm_FIN.png differ diff --git a/rtd-docs/images/iamr_iso_knl_420_boxes_not_used_128spp_sm.png b/rtd-docs/images/iamr_iso_knl_420_boxes_not_used_128spp_sm.png new file mode 100644 index 000000000..4a777d3dd Binary files /dev/null and b/rtd-docs/images/iamr_iso_knl_420_boxes_not_used_128spp_sm.png differ diff --git a/rtd-docs/images/iamr_iso_knl_420_boxes_used_128spp_sm.png b/rtd-docs/images/iamr_iso_knl_420_boxes_used_128spp_sm.png new file mode 100644 index 000000000..a8eed97ae Binary files /dev/null and b/rtd-docs/images/iamr_iso_knl_420_boxes_used_128spp_sm.png differ diff --git a/rtd-docs/images/intransit.png b/rtd-docs/images/intransit.png new file mode 100644 index 000000000..c87fc3c40 Binary files /dev/null and b/rtd-docs/images/intransit.png differ diff --git a/rtd-docs/images/libis.png b/rtd-docs/images/libis.png new file mode 100644 index 000000000..3935d85ce Binary files /dev/null and b/rtd-docs/images/libis.png differ diff --git a/rtd-docs/images/openfoam_slice_00001.png b/rtd-docs/images/openfoam_slice_00001.png new file mode 100644 index 000000000..793446edd Binary files /dev/null and b/rtd-docs/images/openfoam_slice_00001.png differ diff --git a/rtd-docs/images/openfoam_slice_00010.png b/rtd-docs/images/openfoam_slice_00010.png new file mode 100644 index 000000000..d3ff74ebc Binary files /dev/null and b/rtd-docs/images/openfoam_slice_00010.png differ diff --git a/rtd-docs/images/placeholder.png b/rtd-docs/images/placeholder.png new file mode 100644 index 000000000..5f56a56ef Binary files /dev/null and b/rtd-docs/images/placeholder.png differ diff --git a/rtd-docs/images/pv-harr.png b/rtd-docs/images/pv-harr.png new file mode 100644 index 000000000..3385d431a Binary files /dev/null and b/rtd-docs/images/pv-harr.png differ diff --git a/rtd-docs/images/pv_catalyst_steering_gui.png b/rtd-docs/images/pv_catalyst_steering_gui.png new file mode 100644 index 000000000..6194cb301 Binary files /dev/null and b/rtd-docs/images/pv_catalyst_steering_gui.png differ diff --git a/rtd-docs/images/pv_catalyst_steering_preview.png b/rtd-docs/images/pv_catalyst_steering_preview.png new file mode 100644 index 000000000..525c6db81 Binary files /dev/null and b/rtd-docs/images/pv_catalyst_steering_preview.png differ diff --git a/rtd-docs/images/pv_catalyst_steering_window.png b/rtd-docs/images/pv_catalyst_steering_window.png new file mode 100644 index 000000000..3e065d633 Binary files /dev/null and b/rtd-docs/images/pv_catalyst_steering_window.png differ diff --git a/rtd-docs/images/pv_phasta_million_rank.png b/rtd-docs/images/pv_phasta_million_rank.png new file mode 100644 index 000000000..0f3f6b22c Binary files /dev/null and b/rtd-docs/images/pv_phasta_million_rank.png differ diff --git a/rtd-docs/images/pv_vtk-m.png b/rtd-docs/images/pv_vtk-m.png new file mode 100644 index 000000000..833473672 Binary files /dev/null and b/rtd-docs/images/pv_vtk-m.png differ diff --git a/rtd-docs/images/pv_vtk-m_isocontours.png b/rtd-docs/images/pv_vtk-m_isocontours.png new file mode 100644 index 000000000..1439dd2c9 Binary files /dev/null and b/rtd-docs/images/pv_vtk-m_isocontours.png differ diff --git a/rtd-docs/images/pv_vtk-m_isocontours_preview.png b/rtd-docs/images/pv_vtk-m_isocontours_preview.png new file mode 100644 index 000000000..48783b87c Binary files /dev/null and b/rtd-docs/images/pv_vtk-m_isocontours_preview.png differ diff --git a/rtd-docs/images/pv_vtk-m_rendering_pipeline.png b/rtd-docs/images/pv_vtk-m_rendering_pipeline.png new file mode 100644 index 000000000..03efd9b5a Binary files /dev/null and b/rtd-docs/images/pv_vtk-m_rendering_pipeline.png differ diff --git a/rtd-docs/images/sensei_yt.png b/rtd-docs/images/sensei_yt.png new file mode 100644 index 000000000..d4137efb2 Binary files /dev/null and b/rtd-docs/images/sensei_yt.png differ diff --git a/rtd-docs/images/v_nyx_evolution.png b/rtd-docs/images/v_nyx_evolution.png new file mode 100644 index 000000000..1a3ec1f26 Binary files /dev/null and b/rtd-docs/images/v_nyx_evolution.png differ diff --git a/rtd-docs/images/v_vortex_breakdown.png b/rtd-docs/images/v_vortex_breakdown.png new file mode 100644 index 000000000..52df0bc58 Binary files /dev/null and b/rtd-docs/images/v_vortex_breakdown.png differ diff --git a/rtd-docs/images/v_vortex_breakdown_preview.png b/rtd-docs/images/v_vortex_breakdown_preview.png new file mode 100644 index 000000000..223764c33 Binary files /dev/null and b/rtd-docs/images/v_vortex_breakdown_preview.png differ diff --git a/rtd-docs/index.rst b/rtd-docs/index.rst index e7f34e94c..66729326f 100644 --- a/rtd-docs/index.rst +++ b/rtd-docs/index.rst @@ -68,5 +68,6 @@ Table of Contents system_components mini-apps examples + vignettes developer_guide glossary diff --git a/rtd-docs/new_example.rst b/rtd-docs/new_example.rst new file mode 100644 index 000000000..a23e4c11d --- /dev/null +++ b/rtd-docs/new_example.rst @@ -0,0 +1,4 @@ +this new example +---------------- + +now we have a title diff --git a/rtd-docs/paper-ames-ldav19.rst b/rtd-docs/paper-ames-ldav19.rst new file mode 100644 index 000000000..03b9ab1e8 --- /dev/null +++ b/rtd-docs/paper-ames-ldav19.rst @@ -0,0 +1,20 @@ +.. _AmesLdav19: + +**************************************************** +Low-overhead in situ visualization using halo replay +**************************************************** + +Jeff Ames, Silvio Rizzi, Joseph Insley, Saumil Patel, Benjamín Hernández, Erik W Draeger, Amanda Randles + +============ +Full Text +============ + +Link to the full text `PDF `_. + +======== +Abstract +======== + +In situ visualization and analysis is of increasing importance as the compute and I/O gap further widens with the advance to exascale capable computing. Yet, currently in situ methods impose resource constraints leading to the difficult task of balancing simulation code performance and the quality of analysis. Applications with tightly-coupled in situ visualization often achieve performance through spatial and temporal downsampling, a tradeoff which risks not capturing transient phenomena at sufficient fidelity. Determining a priori visualization parameters such as sampling rate is difficult without time and resource intensive experimentation. We present a method for reducing resource contention between in situ visualization and stencil codes on heterogeneous systems. This method permits full-resolution replay through recording halos and the communication-free reconstruction of interior values uncoupled from the main simulation. We apply this method in the computational fluid dynamics (CFD) code HARVEY on the Summit supercomputer. We demonstrate minimal overhead, in situ visualization relative to simulation alone, and compare the Halo Replay performance to tightly-coupled in situ approaches. + diff --git a/rtd-docs/paper-ayachit-isav16.rst b/rtd-docs/paper-ayachit-isav16.rst new file mode 100644 index 000000000..4f02a136f --- /dev/null +++ b/rtd-docs/paper-ayachit-isav16.rst @@ -0,0 +1,76 @@ +.. _Ayachit_ISAV16: + +*********************************************** +The SENSEI Generic In Situ Interface +*********************************************** + +Utkarsh Ayachit, Brad Whitlock, Matthew Wolf, Burlen Loring, +Berk Geveci, David Lonie, and E. Wes Bethel + +============ +Full Text +============ + +Link to the full text PDF. + +Abstract +======== +The SENSEI generic in situ interface is an API that promotes code +portability and reusability. From the simulation view, a developer +can instrument their code with the SENSEI API and then make make use +of any number of in situ infrastructures. From the method view, a +developer can write an in situ method using the SENSEI API, then +expect it to run in any number of in situ infrastructures, or be +invoked directly from a simulation code, with little or no +modification. This paper presents the design principles underlying +the SENSEI generic interface, along with some simplified coding +examples. + +Interface Design +================= + +Data Model: A key part of the design of the common interface was a +decision on a common data description model. Our choice was to extend +a variant on the VTK data model. There were several reasons for this +choice. The VTK data model is already widely used in applications like +VisIt and ParaView, which are important codes for the post-hoc +development of the sorts of analysis and visualization that are +required in situ. The VTK data model has native support for a plethora +of common scientific data structures, including regular grids, +curvilinear grids, unstructured grids, graphs, tables, and AMR. There +is also already a dedicated community looking to carry forward VTK to +exascale computing, so our efforts can cross-leverage those. + +Despite its many strengths, there were some key additions we wanted +for the SENSEI model. To minimize effort and memory overhead when +mapping memory layouts for data arrays from applications to VTK, we +extended the VTK data model to support arbitrary layouts for +multicomponent arrays through a new API called generic arrays. Through +this work, this capability has been back-ported to the core VTK data +model. VTK now natively supports the commonly encountered +structure-of-arrays and array-of-structures layouts utilizing +zero-copy memory techniques. + +Interface: The SENSEI interface comprises of three components: data +adaptor that helps map sim data to VTK data model, analysis adaptor +that maps VTK data model for analysis methods, and in situ bridge that +links together the data adaptor and the analysis adaptor, and provides +the API that the simulation uses to trigger the in situ analysis. + +The data adaptor defines an API to access the simulation data as VTK +data objects. The analysis adaptor uses this API to access the data to +pass to the analysis method. To instrument a simulation code for +SENSEI, one has to provide a concrete implementation for this data +adaptor API. The API treats connectivity and attribute array +information separately, providing specific API calls for requesting +each. This helps to avoid compute cycles needed to map the +connectivity and/or data attributes to the VTK data model unless +needed by active analysis methods. + +The analysis adaptor’s role is to take the data adaptor and pass the +data to the analysis method, doing any transformations as necessary. +For a specific analysis method, the analysis adaptor is provided the +data adaptor in its Execute method. Using the sensei::DataAdaptor API, +the analysis adaptor can obtain the mesh (geometry, and connectivity) +and attribute or field arrays necessary for the analysis method. + diff --git a/rtd-docs/paper-ayachit-sc16.rst b/rtd-docs/paper-ayachit-sc16.rst new file mode 100644 index 000000000..93aa8e322 --- /dev/null +++ b/rtd-docs/paper-ayachit-sc16.rst @@ -0,0 +1,127 @@ +.. _ayachitsc16: + +****************************************************************************************************** +Performance Analysis, Design Considerations, and Applications of Extreme-scale In Situ Infrastructures +****************************************************************************************************** + +Utkarsh Ayachit, Andrew Bauer, Earl P. N. Duque, Greg Eisenhauer, +Nicola Ferrier, Junmin Gu, Kenneth E. Jansen, Burlen Loring, +Zarija Lukic , Suresh Menon, Dmitriy Morozov, Patrick O’Leary, +Reetesh Ranjan, Michel Rasquin, Christopher P. Stone, +Venkat Vishwanath, Gunther H. Weber, Brad Whitlock, Matthew Wolf, +K. John Wu, and E. Wes Bethel + +============ +Full Text +============ + +Link to the full text PDF. + +======== +Abstract +======== + +A key trend facing extreme-scale computational science is the widening +gap between computational and I/O rates, and the challenge that +follows is how to best gain insight from simulation data when it is +increasingly impractical to save it to persistent storage for +subsequent visual exploration and analysis. One approach to this +challenge is centered around the idea of in situ processing, where +visualization and analysis processing is performed while data is still +resident in memory. This paper examines several key design and +performance issues related to the idea of in situ processing at +extreme scale on modern platforms: scalability, overhead, performance +measurement and analysis, comparison and contrast with a traditional +post hoc approach, and interfacing with simulation codes. We +illustrate these principles in practice with studies, conducted on +large-scale HPC platforms, that include a miniapplication and multiple +science application codes, one of which demonstrates in situ methods +in use at greater than 1M-way concurrency. + +================= +Mini-Application +================= + +As a prototypical data source, we implemented a miniapplication, an +MPI code in C++, that simulates a collection of periodic, damped, or +decaying oscillators. Placed on a grid, each oscillator is convolved +with a Gaussian of a prescribed width. The oscillator parameters are +specified as the input, which is read and broadcast from the root +process. The user also specifies the time resolution, duration of the +simulation, and the dimensions of the grid, partitioned between the +processes using regular decomposition. The code iteratively fills the +grid cells with the sum of the convolved oscillator values; the +computation on each rank takes O(mN3) per time step, where m is the +number of oscillators and N3 is the size of the subgrid on the rank. +The computation is embarrassingly parallel; optionally, the ranks may +synchronize after every time step, but this synchronization is off in +the experiments below. + +========= +Pipelines +========= + +The miniapplication test configurations, listed below, show the +various combinations of the oscillator miniapplication, in situ the +ParaView/Catalyst, VisIt/Libsim, and ADIOS infrastructures, different +in situ analysis methods, and with/without use of the SENSEI data +interface. + ++-----------------+------------------------------------------------------------------------------+ +| Pipeline | Description | ++=================+==============================================================================+ +| Original | miniapplication with no SENSEI interface and no I/O. In some test | +| | configurations, we do perform in situ analysis, but that coupling is done | +| | directly via subroutine call and does not use any in situ interface. The | +| | distinction of with vs. without analysis will be called out when needed in | +| | the subsections that follow. | ++-----------------+------------------------------------------------------------------------------+ +| Baseline | miniapplication with SENSEI interface enabled, but no in situ analysis or | +| | I/O. This configuration is useful in measuring the overhead of the SENSEI | +| | data interface in isolation from other processing. | ++-----------------+------------------------------------------------------------------------------+ +| Histogram | miniapplication with the SENSEI interface enabled, and connected directly to | +| | an in situ histogram calculation, but without any of the in situ | +| | infrastructures. | ++-----------------+------------------------------------------------------------------------------+ +| Autocorrelation | miniapplication with the SENSEI interface enabled, and connected directly | +| | to an in situ autocorrelation calculation, but without any of the in situ | +| | infrastructures. | ++-----------------+------------------------------------------------------------------------------+ +| Catalyst-slice | miniapplication with SENSEI interface enabled, and connected to Catalyst, | +| | which performs in situ rendering of a 2D slice from a 3D volume, then writes | +| | the image to disk. | ++-----------------+------------------------------------------------------------------------------+ +| Libsim-slice | miniapplication with SENSEI interface enabled, and connected to Libsim, which| +| | performs in situ rendering of a 2D slice from a 3D volume, then writes the | +| | image to disk. | ++-----------------+------------------------------------------------------------------------------+ +| ADIOS-FlexPath | miniapplication with SENSEI interface en- abled, and connected to the ADIOS | +| | FlexPath in situ infrastructure. Within this miniapplication/in situ | +| | infrastructure combination, we further refine the configuration in §§4.1.4 to| +| | include in situ workloads for histogram, autocorrelation, and Catalyst-slice.| ++-----------------+------------------------------------------------------------------------------+ + +============================ +Science Application Examples +============================ + +.. figure:: images/v_vortex_breakdown.png + :width: 100 % + :align: center + + Computational Fluid Dynamics - The Evolution of Temporal Mixing Layer from Initial to Vortex Breakdown using AVF-LESLIE. + +.. figure:: images/v_nyx_evolution.png + :width: 30 % + :align: center + + Computational Cosmology - Time steps 200 and 300 of the 10243 Nyx Lyman α forest simulation. Simulations often only save every 100th time step. The difference between these time steps is considerable, hampering feature tracking. + +.. figure:: images/pv_phasta_million_rank.png + :width: 30 % + :align: center + + Computational Fluid Dynamics - 6.33 Billion element grid with 1,048,576 MPI ranks on 32,768 nodes (32 MPI ranks per node) with output size of 2900x725 and 30 time steps. + + diff --git a/rtd-docs/paper-loring-egpgv20.rst b/rtd-docs/paper-loring-egpgv20.rst new file mode 100644 index 000000000..7907103e5 --- /dev/null +++ b/rtd-docs/paper-loring-egpgv20.rst @@ -0,0 +1,35 @@ + +.. _loringEgpgv20: + +************************************************************************************************************ +Improving Performance of M-to-N Processing and Data Redistribution in In Transit Analysis and Visualization +************************************************************************************************************ + +B. Loring 1, M. Wolf, J. Kress 2, S. Shudler, J. Gu , S. Rizzi, J. Logan, N. Ferrier, and E. W. Bethel + +============ +Full Text +============ + +Link to the full text `PDF `_ . + +============ +Abstract +============ + +In an in transit setting, a parallel data producer, such as a numerical +simulation, runs on one set of ranks M, while a data consumer, such as a +parallel visualization application, runs on a different set of ranks N. One of +the central challenges in this in transit setting is to determine the mapping +of data from the set of M producer ranks to the set of N consumer ranks. This +is a challenging problem for several reasons, such as the producer and consumer +codes potentially having different scaling characteristics and different data +models. The resulting mapping from M to N ranks can have a significant impact +on aggregate application performance. In this work, we present an approach for +performing this M-to-N mapping in a way that has broad applicability across a +diversity of data producer and consumer applications. We evaluate its design +and performance with a study that runs at high concurrency on a modern HPC +platform. By leveraging design characteristics, which facilitate an +“intelligent” mapping from M-to-N, we observe significant performance gains are +possible in terms of several different metrics, including time-to-solution and +amount of data moved. diff --git a/rtd-docs/paper-loring-isav18.rst b/rtd-docs/paper-loring-isav18.rst new file mode 100644 index 000000000..52bbd2747 --- /dev/null +++ b/rtd-docs/paper-loring-isav18.rst @@ -0,0 +1,33 @@ +.. _LoringIsav18: + +************************************************ +Python-based In Situ Analysis and Visualization +************************************************ + +Burlen Loring, Andrew Myers, David Camp, E. Wes Bethel + +============ +Full Text +============ + +Link to the full text `PDF `_. + + +======== +Abstract +======== + +This work focuses on enabling the use of Python-based methods for the purpose +of performing in situ analysis and visualization. This approach facilitates +access to and use of a rapidly growing collection of Python-based, third-party +libraries for analysis and visualization, as well as lowering the barrier to +entry for userwritten Python analysis codes. Beginning with a simulation code +that is instrumented to use the SENSEI in situ interface, we present how to +couple it with a Python-based data consumer, which may be run in situ, and in +parallel at the same concurrency as the simulation. We present two examples +that demonstrate the new capability. One is an analysis of the reaction rate in +a proxy simulation of a chemical reaction on a 2D substrate, while the other is +a coupling of an AMR simulation to Yt, a parallel visualization and analysis +library written in Python. In the examples, both the simulation and Python in +situ method run in parallel on a large-scale HPC platform. + diff --git a/rtd-docs/paper-newberry-ewc22.rst b/rtd-docs/paper-newberry-ewc22.rst new file mode 100644 index 000000000..88bce0048 --- /dev/null +++ b/rtd-docs/paper-newberry-ewc22.rst @@ -0,0 +1,39 @@ + +.. _NewberryEWC22: + +*********************************************** +Software Tools to Enable Immersive Simulation +*********************************************** +Felix Newberry, Corey Wetterer-Nelson, John A Evans, Alireza Doostan, Kenneth E Jansen + +============ +Full Text +============ + +Link to the full text PDF. + +======== +Abstract +======== + +There are two main avenues to design space exploration. In the first approach, +a simulation is run, analyzed, the problem modified, and the simulation run +again. In the second approach, an ensemble simulation is performed and the +battery of results is leveraged to construct a surrogate model for a given +quantity of interest (QoI). The first approach allows a practitioner to +methodically move through the design space and analyze a solution field. A +disadvantage of this technique is that each new simulation requires time +consuming setup. The second approach provides the practitioner with a global +view of the problem, but requires a priori design space limits and the QoI +specification. In this work we introduce an immersive simulation software +frame- work that enables practitioners to maintain the flexibility of the first +approach, while eliminating the burden of setting up new simulations. Immersive +simulation can also be used to inform the second approach, establishing limits +and clarify- ing QoI selection prior to the launch of an ensemble simulation. +We demonstrate live, reconfigurable visualization of on-going simulations +coupled with live, reconfigurable problem definition that guides users in +determining problem parameters. Ultimately, an immersive simulation framework +enables more efficient design space exploration that reduces the gap between +simulations, data analysis and insight ex- traction. + + diff --git a/rtd-docs/paper-shudler-egpgv19.rst b/rtd-docs/paper-shudler-egpgv19.rst new file mode 100644 index 000000000..830ccca02 --- /dev/null +++ b/rtd-docs/paper-shudler-egpgv19.rst @@ -0,0 +1,20 @@ +.. _ShudlerEgpgv19: + +***************************************************************************** +Fast Mesh Validation in Combustion Simulations through In-Situ Visualization. +***************************************************************************** + +Sergei Shudler, Nicola J Ferrier, Joseph A Insley, Michael E Papka, Saumil Patel, Silvio Rizzi + +============ +Full Text +============ + +Link to the full text `PDF `_. + + +======== +Abstract +======== + +In situ visualization and analysis is a powerful concept that aims to give users the ability to process data while it is still resident in memory, thereby vastly reducing the amount of data left for posthoc analysis. The problem of having too much data for posthoc analysis is exacerbated in large-scale high-performance computing applications such as Nek5000, a massively-parallel CFD (Computational Fluid Dynamics) code used primarily for thermal hydraulics problems. Specifically, one problem users of Nek5000 often face is validating the mesh, that is identifying the exact location of problematic mesh elements within the whole mesh. Employing the standard posthoc approach to address this problem is both time consuming and requires vast storage space. In this paper, we demonstrate how in situ visualization, produced with SENSEI, a generic in situ platform, helps users quickly validate the mesh. We also provide a bridge between Nek5000 and SENSEI that enables users to use any existing and future analysis routines in SENSEI. The approach is evaluated on a number of realistic datasets diff --git a/rtd-docs/paper-shudler-isav19.rst b/rtd-docs/paper-shudler-isav19.rst new file mode 100644 index 000000000..35e36554b --- /dev/null +++ b/rtd-docs/paper-shudler-isav19.rst @@ -0,0 +1,20 @@ +.. _ShudlerIsav19: + +*************************************************************************** +Spack meets singularity: creating movable in-situ analysis stacks with ease +*************************************************************************** + +Sergei Shudler, Nicola Ferrier, Joseph Insley, Michael E Papka, Silvio Rizzi + +============ +Full Text +============ + +Link to the full text `PDF `_. + + +======== +Abstract +======== + +In situ data analysis and visualization is a promising technique to handle the enormous amount of data an extreme-scale application produces. One challenge users often face in adopting in situ techniques is setting the right environment on a target machine. Platforms such as SENSEI require complex software stacks that consist of various analysis packages and visualization applications. The user has to make sure all these prerequisites exist on the target machine, which often involves compiling and setting them up from scratch. In this paper, we leverage the containers technology (eg, light-weight virtualization images) and provide users with Singularity containers that encapsulate ready-to-use, movable in situ software stacks. Moreover, we make use of Spack to ease the process of creating these containers. Finally, we evaluate this solution by running in situ analysis from within a container on an HPC system. diff --git a/rtd-docs/paper-thompson-isav17.rst b/rtd-docs/paper-thompson-isav17.rst new file mode 100644 index 000000000..0a7bf4143 --- /dev/null +++ b/rtd-docs/paper-thompson-isav17.rst @@ -0,0 +1,52 @@ + +.. _ThompsonISAV17: + +*********************************************** +In Situ Summarization with VTK-m +*********************************************** + +David Thompson, Sebastien Jourdain, Andrew Bauer, Berk Geveci, +Robert Maynard, Ranga Raju Vatsavai, and Patrick O’Leary + +============ +Full Text +============ + +Link to the full text PDF. + +Abstract +======== +Summarization and compression at current and future scales requires a +framework for developing and benchmarking algorithms. We present a +framework created by integrating existing, production- ready projects +and provide timings of two particular algorithms that serve as +exemplars for summarization: a wavelet-based data reduction filter and +a generator for creating image-like databases of extracted features +(isocontours in this case). Both support browser-based, post-hoc, +interactive visualization of the summary for decision- making. A study +of their weak-scaling on a distributed multi-GPU system is included. + +.. figure:: images/pv_vtk-m.png + :width: 80% + :align: center + + VTKm’s architecture lazily transfers arrays to streaming processors for analysis. + +Summarization Examples +============================ + +.. figure:: images/pv-harr.png + :align: center + + Data Reduction - (a) By running a Haar wavelet filter multiple times, we can reduce the volume to a fixed size that is appropri- ate for rendering in a browser via ArcticViewer (depicted in Figure 5b). (b) Our wavelet-based reduction pipeline uses VTKm to compute multiple passes of the DHW transform. Circular dots indicate a zero-copy handoff of data. The tri- angle and diamond indicate where VTKm and VTK transfer data to/from the GPU, respectively. + +.. figure:: images/pv_vtk-m_isocontours.png + :align: center + + Isocontours - Complex periodic system composed of a grid of nine big oscillators and four interleaved smaller ones with various frequencies. Visualizations via (a) translucent contours and (b) in-browser volume rendering. + +.. figure:: images/pv_vtk-m_rendering_pipeline.png + :align: center + + Isocontours - Our visual summary rendering pipeline uses VTKm to compute renderings of isocontours. Circular dots indicate a zero-copy handoff of data. The triangle and dia- mond indicate where VTKm and VTK transfer data to/from the GPU, respectively. + diff --git a/rtd-docs/paper-usher-isav18.rst b/rtd-docs/paper-usher-isav18.rst new file mode 100644 index 000000000..b5a43dab5 --- /dev/null +++ b/rtd-docs/paper-usher-isav18.rst @@ -0,0 +1,20 @@ +.. _UsherIsav18: + +****************************************************************** +libIS: a lightweight library for flexible in transit visualization +****************************************************************** + +Will Usher, Silvio Rizzi, Ingo Wald, Jefferson Amstutz, Joseph Insley, Venkatram Vishwanath, Nicola Ferrier, Michael E Papka, Valerio Pascucci + +============ +Full Text +============ + +Link to the full text `PDF `_. + + +======== +Abstract +======== + +As simulations grow in scale, the need for in situ analysis methods to handle the large data produced grows correspondingly. One desirable approach to in situ visualization is in transit visualization. By decoupling the simulation and visualization code, in transit approaches alleviate common difficulties with regard to the scalability of the analysis, ease of integration, usability, and impact on the simulation. We present libIS, a lightweight, flexible library which lowers the bar for using in transit visualization. Our library works on the concept of abstract regions of space containing data, which are transferred from the simulation to the visualization clients upon request, using a client-server model. We also provide a SENSEI analysis adaptor, which allows for transparent deployment of in transit visualization. We demonstrate the flexibility of our approach on batch analysis and interactive visualization use cases on different HPC resources. diff --git a/rtd-docs/poster-bernardoni-ldav18.rst b/rtd-docs/poster-bernardoni-ldav18.rst new file mode 100644 index 000000000..6c9a637bd --- /dev/null +++ b/rtd-docs/poster-bernardoni-ldav18.rst @@ -0,0 +1,21 @@ +.. _BernardoniLdav18: + +**************************************************************************************************** +In situ visualization and analysis to design large scale experiments in computational fluid dynamics +**************************************************************************************************** + +Bennett Bernardoni, Nicola Ferrier, Joseph Insley, Michael E Papka, Saumil Patel, Silvio Rizzi + +============ +Full Text +============ + +Link to the full text `PDF `_. + + +======== +Abstract +======== + +Nek5000 is a massively-parallel computational fluid dynamics code, which is widely used and researched, including as part of a co-design center of the Exascale Computing Project (ECP). As computation capacity reaches exascale, storage bandwidth remains stable leading to a larger percentage of time spent performing I/O. In situ analysis overcomes this issue by processing the data before it is written to disk. One method for accomplishing in situ analysis is through SENSEI, a generic in situ interface that enables the use of many existing in situ infrastructures with little modification to the simulation. In this work, we present the instrumentation of Nek5000 with SENSEI and evaluate its ability to accelerate the development of large scale simulation campaigns. + diff --git a/rtd-docs/poster-murphy-ldav20.rst b/rtd-docs/poster-murphy-ldav20.rst new file mode 100644 index 000000000..736a33b05 --- /dev/null +++ b/rtd-docs/poster-murphy-ldav20.rst @@ -0,0 +1,19 @@ +.. _MurphyLdav20: + +********************************************************************************************* +Instrumenting multiphysics blood flow simulation codes for in situ visualization and analysis +********************************************************************************************* + +Anthony Bucaro, Connor Murphy, Nicola Ferrier, Joseph Insley, Victor Mateevitsi, Michael E Papka, Silvio Rizzi, Jifu Tan + +============ +Full Text +============ + +Link to the full text `PDF `_. + +======== +Abstract +======== + +Blood flow simulations have important applications in engineering and medicine, requiring visualization and analysis for both fluid (blood plasma) and solid (cells). Recent advances in blood flow simulations highlight the need of a more efficient analysis of large data sets. Traditionally, analysis is performed after a simulation is completed, and any changes of simulation settings require running the simulation again. With bi-directional in situ analysis we aim to solve this problem by allowing manipulation of simulation parameters in run time. In this project, we describe our early steps toward this goal and present the in situ instrumentation of two coupled codes for blood flow simulation using the SENSEI in situ framework. diff --git a/rtd-docs/vignette-example.rst b/rtd-docs/vignette-example.rst new file mode 100644 index 000000000..466a80781 --- /dev/null +++ b/rtd-docs/vignette-example.rst @@ -0,0 +1,18 @@ +.. _vignette-example: + +======================================== +A great example of a Scientific Vignette +======================================== + +Here is an example of a vignette. Start it off with a huge screen-width image exemplifying the work + + +Scientific Achievement +====================== + +Significance and Impact +======================= + + +Research Details +================= diff --git a/rtd-docs/vignettes.rst b/rtd-docs/vignettes.rst new file mode 100644 index 000000000..9332c9917 --- /dev/null +++ b/rtd-docs/vignettes.rst @@ -0,0 +1,145 @@ +.. _vignettes: + +********************************** +Analysis & Visualization Vignettes +********************************** + +====== +Papers +====== + +.. + add an image with a tag like the below references to add more vignettes. add + the image to the grid below. you can link to you page using the :target: + keyword make sure your preview image for this page is 600x600px. Deviating + from those dimensions will cause issues when rendering the page. + +.. |ISAV17| image:: images/pv_vtk-m_isocontours_preview.png + :width: 600px + :target: paper-thompson-isav17.html + +.. |SC016| image:: images/v_vortex_breakdown_preview.png + :width: 600px + :target: paper-ayachit-sc16.html + +.. |ISAV16| image:: images/SENSEI-design_preview.png + :width: 600px + :target: paper-ayachit-isav16.html + +.. |EWC22| image:: images/engwcmp_preview.png + :width: 600px + :target: paper-newberry-ewc22.html + +.. |blEGPGV20iso| image:: images/iamr_iso_knl_420_128spp_sm_FIN.png + :width: 600px + :target: paper-loring-egpgv20.html + +.. |blEGPGV20bu| image:: images/iamr_iso_knl_420_boxes_used_128spp_sm.png + :width: 600px + :target: paper-loring-egpgv20.html + +.. |blEGPGV20bn| image:: images/iamr_iso_knl_420_boxes_not_used_128spp_sm.png + :width: 600px + :target: paper-loring-egpgv20.html + +.. |blISAV18| image:: images/sensei_yt.png + :width: 600px + :target: paper-loring-isav18.html + +.. |bbLDAV18| image:: images/Nek5000_Bernardoni.png + :width: 600px + :target: poster-bernardoni-ldav18.html + +.. |wuISAV18| image:: images/libis.png + :width: 600px + :target: paper-usher-isav18.html + +.. |ssEGPGV19| image:: images/Nek5000_Shudler.png + :width: 600px + :target: paper-shudler-egpgv19.html + +.. |jaLDAV19| image:: images/Harvey_Ames.png + :width: 600px + :target: paper-ames-ldav19.html + +.. |ssISAV19| image:: images/Spack_Shudler.png + :width: 600px + :target: paper-shudler-isav19.html + +.. |cmLDAV20| image:: images/Bloodflow_Murphy.png + :width: 600px + :target: poster-murphy-ldav20.html + + ++------------------+-----------------+ +| |EWC22| | |blEGPGV20iso| | +| | |blEGPGV20bu| | +| | |blEGPGV20bn| | ++------------------+-----------------+ +| |cmLDAV20| | |ssISAV19| | ++------------------+-----------------+ +| |ssEGPGV19| | |jaLDAV19| | ++------------------+-----------------+ +| |blISAV18| | |bbLDAV18| | ++------------------+-----------------+ +| |wuISAV18| | |ISAV17| | ++------------------+-----------------+ +| |SC016| | |ISAV16| | ++------------------+-----------------+ + +.. toctree:: + :maxdepth: 1 + :name: vignettes_papers + :numbered: + + paper-newberry-ewc22 + paper-loring-egpgv20 + poster-murphy-ldav20 + paper-shudler-isav19 + paper-shudler-egpgv19 + paper-ames-ldav19 + paper-loring-isav18 + poster-bernardoni-ldav18 + paper-usher-isav18 + paper-thompson-isav17 + paper-ayachit-sc16 + paper-ayachit-isav16 + +====================== +Tutorials and Examples +====================== + +.. |amrex-ex| image:: images/amrex_tutorial_preview.png + :width: 100% + :target: examples_amrex_tutorials.html + +.. |catalyst-ex| image:: images/pv_catalyst_steering_preview.png + :width: 100% + :target: examples_catalyst_bidirectional.html + +.. |intransit-ex| image:: images/intransit.png + :width: 100% + :target: examples_intransit.html + +.. |openfoam-ex| image:: images/openfoam_slice_00001.png + :width: 100% + :target: examples_openfoam.html + +.. |example-ex| image:: images/placeholder.png + :width: 100% + :target: examples_example_html.html + ++--------------+-------------+ +||amrex-ex| ||catalyst-ex|| ++--------------+-------------+ +||intransit-ex|||openfoam-ex|| ++--------------+-------------+ + +.. toctree:: + :maxdepth: 1 + + examples_amrex_tutorials + examples_catalyst_bidirectional + examples_intransit + examples_openfoam + diff --git a/sensei/CMakeLists.txt b/sensei/CMakeLists.txt index c0afdbede..be33c227e 100644 --- a/sensei/CMakeLists.txt +++ b/sensei/CMakeLists.txt @@ -102,7 +102,7 @@ if (ENABLE_ADIOS2) INCLUDES DESTINATION include ARCHIVE DESTINATION ${CMAKE_INSTALL_LIBDIR} LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR}) - install(EXPORT senseiCore DESTINATION ${CMAKE_INSTALL_LIBDIR}/cmake + install(EXPORT senseiCore DESTINATION ${sensei_CMAKE_INSTALL_CMAKEDIR} EXPORT_LINK_INTERFACE_LIBRARIES) set(sensei_sources ConfigurableAnalysis.cxx) @@ -187,7 +187,7 @@ if (ENABLE_ADIOS2) INCLUDES DESTINATION include ARCHIVE DESTINATION ${CMAKE_INSTALL_LIBDIR} LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR}) - install(EXPORT sensei DESTINATION ${CMAKE_INSTALL_LIBDIR}/cmake + install(EXPORT sensei DESTINATION ${sensei_CMAKE_INSTALL_CMAKEDIR} EXPORT_LINK_INTERFACE_LIBRARIES) add_subdirectory(testing) diff --git a/sensei/CatalystAnalysisAdaptor.cxx b/sensei/CatalystAnalysisAdaptor.cxx index 52392f2ec..4fc006741 100644 --- a/sensei/CatalystAnalysisAdaptor.cxx +++ b/sensei/CatalystAnalysisAdaptor.cxx @@ -246,15 +246,15 @@ class CatalystScriptPipeline : public vtkCPPythonScriptPipeline this->ResultData = nullptr; if (this->SteerableSourceType != nullptr) - { + { this->InitializeSteerableSource(dataDescription); - } + } const auto status = this->Superclass::CoProcess(dataDescription); if (!status) - { + { return status; - } + } // find `ResultProducer` proxy and update it and get its data. @@ -385,13 +385,38 @@ void CatalystAnalysisAdaptor::AddPythonScriptPipeline( const std::string& resultMesh) { #ifdef ENABLE_CATALYST_PYTHON - vtkNew pythonPipeline; - pythonPipeline->SetResultProducer(!resultProducer.empty() ? resultProducer.c_str() : nullptr); - pythonPipeline->SetResultMesh(!resultMesh.empty() ? resultMesh.c_str() : nullptr); - pythonPipeline->SetSteerableSourceType( +#if PARAVIEW_VERSION_MAJOR > 5 || (PARAVIEW_VERSION_MAJOR == 5 && PARAVIEW_VERSION_MINOR >= 9) + // detect if we are given a Catalyst 1 or 2 script + vtkSmartPointer pythonPipeline = + vtkCPPythonPipeline::CreateAndInitializePipeline(fileName.c_str()); + + // if we have a catalyst 1 script, we can create a pipeline with steering options + if(auto catalyst1Pipeline = vtkCPPythonScriptPipeline::SafeDownCast(pythonPipeline)) + { + vtkNew steerablePipeline; + steerablePipeline->SetResultProducer(!resultProducer.empty() ? resultProducer.c_str() : nullptr); + steerablePipeline->SetResultMesh(!resultMesh.empty() ? resultMesh.c_str() : nullptr); + steerablePipeline->SetSteerableSourceType( + !steerableSourceType.empty() ? steerableSourceType.c_str() : nullptr); + steerablePipeline->Initialize(fileName.c_str()); + this->AddPipeline(steerablePipeline.GetPointer()); + } + else if(pythonPipeline) + { + // we currently do not support steering with this code path for Catalyst 2 + this->AddPipeline(pythonPipeline.GetPointer()); + } +#else + // we only have access to Catalyst 1, so we can use the steerable pipeline + vtkNew steerablePipeline; + steerablePipeline->SetResultProducer(!resultProducer.empty() ? resultProducer.c_str() : nullptr); + steerablePipeline->SetResultMesh(!resultMesh.empty() ? resultMesh.c_str() : nullptr); + steerablePipeline->SetSteerableSourceType( !steerableSourceType.empty() ? steerableSourceType.c_str() : nullptr); - pythonPipeline->Initialize(fileName.c_str()); - this->AddPipeline(pythonPipeline.GetPointer()); + steerablePipeline->Initialize(fileName.c_str()); + this->AddPipeline(steerablePipeline.GetPointer()); +#endif + #else (void)fileName; (void)resultProducer; @@ -632,7 +657,7 @@ bool CatalystAnalysisAdaptor::Execute(DataAdaptor* dataIn, DataAdaptor** dataOut // Query Catalyst for what data is required, fetch from the sim if (this->SelectData(dataIn, metadata, dataDesc.GetPointer())) { - SENSEI_ERROR("Failed to selct data") + SENSEI_ERROR("Failed to select data") return false; } diff --git a/sensei/DataAdaptor.i b/sensei/DataAdaptor.i index dd218bdeb..b6a0a26e1 100644 --- a/sensei/DataAdaptor.i +++ b/sensei/DataAdaptor.i @@ -317,7 +317,7 @@ SENSEI_WRAP_DATA_ADAPTOR(DataAdaptor) return out; } } -%ingnore sensei::##cname##::GetPartition; +%ignore sensei::##cname##::GetPartition; %enddef PARTITIONER_API(Partitioner) diff --git a/sensei/LibsimImageProperties.h b/sensei/LibsimImageProperties.h index 6a635806c..c317fd7fd 100644 --- a/sensei/LibsimImageProperties.h +++ b/sensei/LibsimImageProperties.h @@ -1,12 +1,14 @@ #ifndef sensei_LibsimImageProperties_h #define sensei_LibsimImageProperties_h +#include "senseiConfig.h" + #include namespace sensei { -class LibsimImageProperties +class SENSEI_EXPORT LibsimImageProperties { public: LibsimImageProperties(); diff --git a/utils/CMakeLists.txt b/utils/CMakeLists.txt index 993919d00..4f79fecd6 100644 --- a/utils/CMakeLists.txt +++ b/utils/CMakeLists.txt @@ -3,7 +3,7 @@ target_include_directories(sDIY SYSTEM INTERFACE $ $) install(TARGETS sDIY EXPORT sDIY) -install(EXPORT sDIY DESTINATION ${CMAKE_INSTALL_LIBDIR}/cmake) +install(EXPORT sDIY DESTINATION ${sensei_CMAKE_INSTALL_CMAKEDIR}) install(DIRECTORY "${CMAKE_CURRENT_SOURCE_DIR}/sdiy" DESTINATION include) diff --git a/utils/SVTK/CMakeLists.txt b/utils/SVTK/CMakeLists.txt index 29bd3f6e3..aa8bb20ef 100644 --- a/utils/SVTK/CMakeLists.txt +++ b/utils/SVTK/CMakeLists.txt @@ -309,12 +309,12 @@ endif () set(svtk_install_export SVTK) if (NOT DEFINED svtk_cmake_destination) set(svtk_cmake_destination - "${CMAKE_INSTALL_LIBDIR}/cmake/svtk${svtk_version_suffix}") + "${sensei_CMAKE_INSTALL_CMAKEDIR}/svtk${svtk_version_suffix}") set(svtk_target_package) if (SVTK_BUILD_COMPILE_TOOLS_ONLY) set(svtk_install_export SVTKCompileTools) set(svtk_cmake_destination - "${CMAKE_INSTALL_LIBDIR}/cmake/svtkcompiletools${svtk_version_suffix}") + "${sensei_CMAKE_INSTALL_CMAKEDIR}/svtkcompiletools${svtk_version_suffix}") set(svtk_target_package PACKAGE "${svtk_install_export}") endif () endif () diff --git a/utils/SVTK/Common/DataModel/svtkHyperTreeGrid.cxx b/utils/SVTK/Common/DataModel/svtkHyperTreeGrid.cxx index d6f04e8b0..5576a5327 100644 --- a/utils/SVTK/Common/DataModel/svtkHyperTreeGrid.cxx +++ b/utils/SVTK/Common/DataModel/svtkHyperTreeGrid.cxx @@ -1,3 +1,6 @@ +#pragma GCC diagnostic push +#pragma GCC diagnostic ignored "-Warray-bounds" +#pragma GCC diagnostic ignored "-Wstringop-overread" /*========================================================================= Program: Visualization Toolkit @@ -1711,3 +1714,4 @@ bool svtkHyperTreeGrid::HasAnyGhostCells() const { return this->PointData->GetArray(svtkDataSetAttributes::GhostArrayName()) != nullptr; } +#pragma GCC diagnostic pop diff --git a/utils/SVTK/Common/DataModel/svtkPolyhedron.cxx b/utils/SVTK/Common/DataModel/svtkPolyhedron.cxx index 40b77af12..d6c48d898 100644 --- a/utils/SVTK/Common/DataModel/svtkPolyhedron.cxx +++ b/utils/SVTK/Common/DataModel/svtkPolyhedron.cxx @@ -1393,7 +1393,7 @@ void FindLowestNeighbor(svtkIdType n, svtkIdType* arr, int idx, bool& mustRevers // therefore the same polygonized border. void TriangulateQuad(svtkCell* quad, FaceVector& faces) { - vector consistentTri1(3), consistentTri2(2); + vector consistentTri1(3), consistentTri2(3); int l = FindLowestIndex(4, quad->GetPointIds()->GetPointer(0)); bool mustReverse(false); FindLowestNeighbor(4, quad->GetPointIds()->GetPointer(0), l, mustReverse); diff --git a/utils/pugixml/CMakeLists.txt b/utils/pugixml/CMakeLists.txt index 09896fb1a..9d2d1400f 100644 --- a/utils/pugixml/CMakeLists.txt +++ b/utils/pugixml/CMakeLists.txt @@ -2,12 +2,12 @@ if (SENSEI_USE_EXTERNAL_pugixml) find_package(pugixml REQUIRED COMPONENTS pugixml) configure_file("${CMAKE_SOURCE_DIR}/CMake/external.pugixml.cmake.in" - "${CMAKE_BINARY_DIR}/${CMAKE_INSTALL_LIBDIR}/cmake/pugixml.cmake" + "${CMAKE_BINARY_DIR}/${sensei_CMAKE_INSTALL_CMAKEDIR}/pugixml.cmake" @ONLY) install( - FILES "${CMAKE_BINARY_DIR}/lib/cmake/pugixml.cmake" - DESTINATION "${CMAKE_INSTALL_LIBDIR}/cmake") + FILES "${CMAKE_BINARY_DIR}/${sensei_CMAKE_INSTALL_CMAKEDIR}/pugixml.cmake" + DESTINATION "${sensei_CMAKE_INSTALL_CMAKEDIR}") else () add_library(pugixml STATIC src/pugixml.cpp) @@ -24,6 +24,6 @@ else () INCLUDES DESTINATION include/pugixml ARCHIVE DESTINATION ${CMAKE_INSTALL_LIBDIR} LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR}) - install(EXPORT pugixml DESTINATION ${CMAKE_INSTALL_LIBDIR}/cmake + install(EXPORT pugixml DESTINATION ${sensei_CMAKE_INSTALL_CMAKEDIR} EXPORT_LINK_INTERFACE_LIBRARIES) endif () diff --git a/utils/pysvtk/CMakeLists.txt b/utils/pysvtk/CMakeLists.txt index 8ac26113b..3d94882bd 100644 --- a/utils/pysvtk/CMakeLists.txt +++ b/utils/pysvtk/CMakeLists.txt @@ -7,7 +7,7 @@ if (ENABLE_PYTHON) #set_property(SOURCE svtk.i PROPERTY COMPILE_OPTIONS -Wextra) set(SVTK_PYTHON_DIR - "${CMAKE_INSTALL_LIBDIR}/python-${PYTHON_VERSION_MAJOR}.${PYTHON_VERSION_MINOR}/site-packages/svtk/" + "${CMAKE_INSTALL_LIBDIR}/python${PYTHON_VERSION_MAJOR}.${PYTHON_VERSION_MINOR}/site-packages/svtk/" CACHE STRING "Where SVTK Python bindings are compiled and installed") message(STATUS "SVTK Python modules will be installed at \"${SVTK_PYTHON_DIR}\"") @@ -54,7 +54,7 @@ if (ENABLE_PYTHON) install(FILES ${CMAKE_BINARY_DIR}/${SVTK_PYTHON_DIR}/pysvtk.py DESTINATION ${SVTK_PYTHON_DIR}) - #install(EXPORT pysvtk DESTINATION ${CMAKE_INSTALL_LIBDIR}/cmake + #install(EXPORT pysvtk DESTINATION ${sensei_CMAKE_INSTALL_CMAKEDIR} # EXPORT_LINK_INTERFACE_LIBRARIES) # install additional pythons sources diff --git a/utils/pysvtk/numpy_support.py b/utils/pysvtk/numpy_support.py index 8ba3f18f9..dc897518a 100644 --- a/utils/pysvtk/numpy_support.py +++ b/utils/pysvtk/numpy_support.py @@ -75,7 +75,7 @@ def get_svtk_array_type(numpy_array_type): def get_svtk_to_numpy_typemap(): """Returns the SVTK array type to numpy array type mapping.""" - _svtk_np = {svtkConstants.SVTK_BIT:numpy.bool, + _svtk_np = {svtkConstants.SVTK_BIT:numpy.int8, svtkConstants.SVTK_CHAR:numpy.int8, svtkConstants.SVTK_SIGNED_CHAR:numpy.int8, svtkConstants.SVTK_UNSIGNED_CHAR:numpy.uint8,