• Lapack Library
• Lapack Library Path
• See More Results

Low-level LAPACK functions (. This module contains low-level functions from the LAPACK library. The.gegv family of routines have been removed from LAPACK 3.6.0 and have been deprecated in SciPy 0.17.0. They will be removed in a future release. New in version 0.12.0. The Accelerate framework provides the LAPACK library for numerical linear algebra. A basic technique of linear algebra is to solve systems of simultaneous equations. For example, the following shows three equations that contain the unknowns x, y, and z.

The Data Transfer Kit (DTK) is an open-source software librarydesigned to provide parallel services for solution transfer formultiphysics simulations. DTK uses a general operator design toprovide scalable parallel services for solution transfer betweenshared volumes and surfaces.

DTK was originally developed at the University of Wisconsin - Madison as partof the Computational Nuclear Engineering Group (CNERG) grouphttp://cnerg.github.iohttps://github.com/CNERG and is now activelydeveloped at the Oak Ridge National Laboratory as part of the ComputationalEngineering and Energy Sciences (CEES) group https://github.com/ORNL-CEES.

DTK is supported and used by the following Department of Energy multiphysicsmodeling and simulation programs:

• Consortium for Advanced Simulation of Light Water Reactors (CASL)http://www.casl.gov

• Nuclear Energy Advanced Modeling and Simulation (NEAMS)http://www.ne.anl.gov/NEAMS/

and the following Department of Transportation programs:

• National Highway Traffic Safety Administration (NHTSA)http://batterysim.org

DataTransferKit Development Team

DTK is developed and maintained by:

Lapack Library

• Stuart Slattery slatterysr@ornl.gov

• Damien Lebrun-Grandie lebrungrandt@ornl.gov

• Bruno Turcksin turcksinbr@ornl.gov

• Roger Pawlowski rppawlo@sandia.gov

• Alex McCaskey mccaskeyaj@ornl.gov

DataTransferKit Packages

DTK has the following packages:

Utils General utilities for software development including exception handling, MPI-based tools, and functional programming tools.

Interface Core DTK interface package. Interfaces are divided into two categories: Client and Operator. Client interfaces define a polymorphic API implemented by client applications providing access to mesh, geometry, parallel decomposition, shape functions, and parametric mappings. Operator interfaces define the general operator and vector objects for solution transfer and other concepts for constructing solution transfer operators from client code.

Operators DTK solution transfer operator implementation package. Operators contains parallel implementations of the following algorithms:

Adapters Client interface adapters for common mesh databases, discretization libraries, and geometric objects. Implementations include:

Notes on Classic DTK Adapters This can serve as a starting point for migrating from version 1.0 to 2.0 but note that the classic adapters only have version 1.0 functionality - no version 2.0 functionality is provided. To use these adapters, simply build them and your code should link. See the unit tests in the classic adapters directory for examples of these changes.

Questions, Bug Reporting, and Issue Tracking

Questions, bug reporting and issue tracking are provided byGitHub. Please report all bugs by creating a new issue. You can askquestions by emailing the developers or by creating a issue with thequestion tag.

Publications

Publications to date related to DataTransferKit:

• S. Slattery, “Mesh-Free Data Transfer Algorithms for PartitionedMultiphysics Problems: Conservation, Accuracy, and Parallelism”, Journal ofComputational Physics, vol. 307, pp. 164-188, 2016.

• S. Slattery, S. Hamilton, T. Evans, “A Modified Moving Least SquareAlgorithm for Solution Transfer on a Spacer Grid Surface”, ANS MC2015 -Joint International Conference on Mathematics and Computation (M&C),Supercomputing in Nuclear Applications (SNA) and the Monte Carlo (MC)Method, Nashville, Tennessee · April 19–23, 2015, on CD-ROM, AmericanNuclear Society, LaGrange Park, IL (2015).

• R. Schmidt, K. Belcourt, R. Hooper, R. Pawlowski, K. Clarno, S. Simunovic, S. Slattery, J. Turner, S. Palmtag,“An Approach for Coupled-Code Multiphysics Core Simulations from a CommonInput”, Annals of Nuclear Energy, Volume 84, pp. 140-152, 2014.

• S. Slattery, P.P.H. Wilson, R. Pawlowski, “The Data Transfer Kit: AGeometric Rendezvous-Based Tool for Multiphysics Data Transfer”,International Conference on Mathematics and Computational Methods Applied toNuclear Science & Engineering (M&C 2013), American Nuclear Society, SunValley, ID, May 5-9, 2013.

Dependencies

DataTransferKit is designed to build and run with a minimum number ofdependencies and is structured largely as a Trilinos package. Thedependenices and third-party libraries (TPLs) necessary to build DTKare all open-source and freely available. The Dependencies for DTK arelisted in the following table:

You can get the most recent Trilinos version athttp://trilinos.org/download/.

To use build some examples and tests you will need the DTKDatarepository which can be found athttps://github.com/ORNL-CEES/DTKData. Simply check out therepository into the top level DataTransferKit directory or provide asoft link of to the location of the repository.

Building DTK

The following steps can be followed to build DTK with MPI support aswell as tests and examples. First, checkout DataTransferKit (assumedto be in a directory named DataTransferKit for theseinstructions). Next create a soft link to the cloned copy of theDTKData repository::

After this, we need to create a soft link of DTK into the mainTrilinos directory. We do this because DTK is a TriBITS package andwill build as a part of the Trilinos build, effectively becoming alinkable package include among the larger group of Trilinospackages. We create this link as::

TriBITS is a CMake-based meta-build systemhttps://github.com/TriBITSPub/TriBITS used by Trilinos. Although freely available on GitHub, a version is also included as a snapshot inTrilinos and we use that version here. To setup the build we will maketwo directories; one for building and one for installing::

Next we can run a build shell script that executes CMake with a numberof options to configure both Trilinos and DataTransferKit::

Some details on the script:

Lapack Library Path

• Changing the variable CMAKE_BUILD_TYPE from DEBUG to RELEASEwill produce an optimized build instead of debug build.

• MPI_BASE_DIR:PATH=$PATH_TO_MPI_INSTALL tells CMake where the MPIinstallation you would like to use resides. If you only have one andit is set in your environment, simply settingTPL_ENABLE_MPI:BOOL=ON can be enough.

• TPL_BLAS_LIBRARIES and TPL_LAPACK_LIBRARIES point to the BLAS andLAPACK libraries installed on your system.

• Trilinos_EXTRA_REPOSITORIES='DataTransferKit' indicates to TriBITSthat we are adding DataTransferKit as an additional Trilinospackage.

• Trilinos_ENABLE_DataTransferKit:BOOL=ON instructs TriBITS to buildDataTransferKit

• DataTransferKit_ENABLE_DBC toggles the DataTransferKitDesign-by-Contract feature ON or OFF. This feature adds manylayers of checks into the code useful for debugging purposes at thatcost of significant additional runtime. Enabling the feature isrecommended for new users to verify inputs and implementations. Thisfeature should be disabled for production calculations once animplementation is tested.

• DataTransferKit_ENABLE_TESTS toggles if unit tests are ON orOFF

• DataTransferKit_ENABLE_EXAMPLES=ON toggles if examples are ON orOFF

See More Results

To build other packages of DTK, the syntax is similar. For example, toadd the Moab client interface implementations to the build add thefollowing::

Configuration, building, testing, installing (assumingDataTransferKit_ENABLE_TESTS is ON) then proceeds as followsassuming 8 threads are available for building and testing::

It is always recommended to build and run unit tests when installingDTK to ensure that the installation process was correct and that DTKhas no bugs dependent on your system. If your application code usingDTK is not working and unit tests are failing, this can help thedevelopers track down the problem.

Razvan Carbunescu

EECS Department
University of California, Berkeley
Technical Report No. UCB/EECS-2014-224
December 18, 2014

http://www2.eecs.berkeley.edu/Pubs/TechRpts/2014/EECS-2014-224.pdf

Many applications call linear algebra libraries as methods of achieving better performance and reliability. LAPACK (Linear Algebra Package) is a standard software library for numerical linear algebra that is widely used in the industrial and scientific community. LAPACK functions require the user to know the sparsity and other mathematical structure of their inputs to be able to take advantage of the fastest codes: General Matrix (GE), General Band (GB), Positive Definite (PO) etc. If a user is unsure of their matrix structure or cannot easily express it in the formats available (profile matrices, arrow matrices etc.) they are forced to use a more general structure, which includes their input, and so run less efficiently than possible. The goal of this thesis is to allow for automatic sparsity detection (ASD) within LAPACK that is completely hidden from the user and provides no slowdown for users running fully dense matrices. This work adds modular support for the detection of blocked sparsity within LAPACK LU and Cholesky functions. It also creates the infrastructure and the algorithms to potentially expand sparsity detection to other factorizations, more input matrix structures, or provide further timing and memory improvements via integration directly in the solver routines. Two general approaches are implemented named `Profile' (ASD1) and `Sparse block' (ASD2) with a third more complicated method named `Full sparsity' (ASD3) being described more abstractly, only at an algorithm level. With these algorithms we obtain benefits of up to an order of magnitude (35.10x faster over the same LAPACK function) for matrices displaying `blocked sparsity' patterns and large benefits over the best LAPACK algorithms for patterns that don't fit into LAPACK categories (4.85x faster over the best LAPACK function). For matrices exhibiting no sparsity these implementations incur either a negligible penalty (an overhead of 1%) or incur a small overhead (10-30%) that quickly decreases with the size of matrix n or band b (less than 5% for n,b > 500).

Advisor: James Demmel

BibTeX citation:

EndNote citation: