Code Monkey home page Code Monkey logo

llnl / umt Goto Github PK

View Code? Open in Web Editor NEW
8.0 62.0 8.0 2.71 MB

UMT (Unstructured Mesh Transport) is an LLNL ASC proxy application (mini-app) that solves a thermal radiative transport equation using discrete ordinates (Sn). It utilizes an upstream corner balance method to compute the solution to the Boltzmann transport equation on unstructured spatial grids.

License: Other

C 0.36% C++ 18.91% Fortran 75.21% CMake 2.40% Python 0.80% Cuda 2.12% Shell 0.21%
radiation-transport unstructured-meshes hpc scientific-computing proxy-application

umt's Introduction

UMT Introduction

Teton obscured by clouds

UMT (Unstructured Mesh Transport) is an LLNL ASC proxy application (mini-app) that solves a thermal radiative transport equation using discrete ordinates (Sn). It utilizes an upstream corner balance method to compute the solution to the Boltzmann transport equation on unstructured spatial grids.

This class of problems is characterized by tens of thousands of unknowns per zone and upwards of millions of zones, thus requiring large, scalable, parallel computing platforms with tens of processors per node.

To achieve scalability, the application exploits both spatial decomposition using message passing between nodes and a threading algorithm across angles and energy groups across processors within the node. More recent versions of UMT are also capable of utilizing both CPUs and GPUs on heterogeneous platforms.

The code is primarily written in Fortran 2003 with some C++ and Cuda.

Building

UMT uses the CMake build system. A MPI compiler is required.

More information on building UMT can be found in BUILDING.md

Third party libraries

UMT depends on several libraries, some of them optionally. See the DEPENDENCIES.md file for more information.

Test problems

UMT can run different test problems, depending on how it was configured and built.

Blueprint test problem

UMT can dynamically generate an unstructured 2D or 3D mesh when built against Conduit version 0.8.9 or later, or their develop branch as of 1/1/2024 or later. This mode is selected using the -B command line argument. Each MPI rank in UMT will construct a mesh domain by repeating a Blueprint tile topology into a larger, repeated pattern arranged as a square tiling of the tile topology. By default, UMT will use the tile pattern that is built into Conduit, although other tile patterns can be supplied.

Default tile

Useful command line arguments for this problem:

Argument Description
-B Selects Blueprint tiled mode. This argument is required to run this problem.
-d x,y,z Determines the number of tiles generated in X,Y,Z dimensions in each domain. The default is 10,10,10. In 2D, supply 0 for the z value. For 3D, supply a z value greater than 0. Generally, the number of zones in a domain will be equal to the product of these numbers (excluding 0's). Naturally, larger x,y,z values will result in more zones.
-M kdtree,none The tiled mesh will apply some mesh zone re-ordering rules by default to try and improve memory locality. Pass a value of none to disable this behavior.
-i filename This option can be used to supply a Conduit .yaml or .json file containing an alternate tile definition, represented as a Blueprint topology. See Conduit/Blueprint documentation for more information on creating a new tile definition.
-P number Set a new number of polar angles. The default is 2.
-A number Set a new number of azimuthal angles. The default is 2.
-G number Set a new number of groups. The default is 2.

Each MPI rank creates an identical mesh domain that makes up part of the whole problem. The overall problem domain is a unit cube that is divided spatially into nx,ny,nz bricks. The nx,ny,nz values are determined by an heuristic in UMT. Essentially, the number of MPI ranks is factored into prime factors and these factors are multiplied round-robin in reverse order by [nz,]ny,nz until all factors have been assigned to a dimension. The product of the numbers is the MPI size. For MPI ranks that are prime numbers, this results in strips of domains in Y for 2D and slabs of domains in Z for 3D. If the decomposition results in high aspect ratio domains, then adjust the number of tiles in x,y,z using the -d command line argument.

To run this problem:

  1. Build UMT (MFEM is not needed)
  2. Run the test driver in 3D. In the below example, the problem will run for 10 cycles. The -d 10,10,10 argument will create a mesh domain with 10x10x10 = 1000 tiles, resulting in ~24000 zones/domain. Overall, there would be 8 times that number of zones due to running on 8 MPI ranks. The domains will be arranged in 2x2x2 layout. Run 'test_driver -h' for more info on the arguments.
srun -n 8 /path/to/install/bin/test_driver -c 10 -B -d 10,10,10
  1. Run the test driver in 2D. In the below example, the problem will run for 10 cycles. The -d 10,10,0 argument will create a 2D mesh domain with 10x10 = 100 tiles, resulting in ~2400 zones/domain. The domains will be arranged in a 2x2 layout.
srun -n 4 /path/to/install/bin/test_driver -c 10 -B -d 10,10,0

MFEM test problem

UMT includes an unstructured mesh 3d test problem using a MFEM mesh This mesh can be refined using MFEM at run time to provide larger problems. This problem requires UMT to have been built with MFEM support.

To run this problem:

  1. Build UMT. This will produce a test_driver and makeUnstructuredBox executable.
  2. Run the makeUnstructuredBox to produce the 3d test mesh.
srun -n1 /path/to/install/bin/makeUnstructuredBox
  1. Run the test driver. In the below example the problem will run for 10 cycles and the mesh will be refined. Run 'test_driver -h' for more info on the arguments.
srun -n2 /path/to/install/bin/test_driver -i ./unstructBox3D.mesh -c 10 -r 1 -R 6

References

  • Nemanic, M K, and Nowak, P. "Radiation transport calculations on unstructured grids using a spatially decomposed and threaded algorithm". United States: N. p., 1999. https://www.osti.gov/servlets/purl/14136

  • Nowak, P. "Deterministic Methods for Radiation Transport: Lessons Learned and Future Directions." United States: N. p., 2004. https://www.osti.gov/servlets/purl/15014024

  • Howell, Louis H., Gunney, Brian T., and Bhatele, Abhinav. "Characterization of Proxy Application Performance on Advanced Architectures. UMT2013, MCB, AMG2013." United States: N. p., 2015. Web. doi:10.2172/1224409.

  • Maginot, P G, Nowak, P F, and Adams, M L. "A Review of the Upstream Corner Balance Spatial Discretization". United States: N. p., 2017, https://www.osti.gov/servlets/purl/1357379

  • Thomas A. Brunner, Terry S. Haut & Paul F. Nowak "Nonlinear Elimination Applied to Radiation Diffusion", Nuclear Science and Engineering, 2020, 194:11, 939-951, DOI: 10.1080/00295639.2020.1747262

  • P. Nowak, A. Black, S. Rennich, D. Appelhans, R. Chen, T. Haut, P. Maginot, T. Bailey, P. Brown, A. Kunen, J. Loffeld, B. Tagani, "Porting Teton, a Discrete-Ordinates Thermal Radiative Transfer Code, to Sierra", Proceedings, M&C 2019, Portland, OR, August 25-29, 2019, Pages 2128-2137

  • Steven J. Plimpton, Bruce Hendrickson, Shawn P. Burns, William McLendon III & Lawrence Rauchwerger (2005) "Parallel Sn Sweeps on Unstructured Grids: Algorithms for Prioritization, Grid Partitioning, and Cycle Detection", Nuclear Science and Engineering, 150:3, 267-283, DOI: 10.13182/NSE150-267

  • Nowak, P. "Unstructured-Mesh Deterministic Radiation Transport. Single Physics Package Code". Computer software. Vers. 01. USDOE. 1 May. 2013. LLNL-CODE-638452, https://github.com/LLNL/UMT

Release

LLNL-CODE-829542

umt's People

Contributors

aaroncblack avatar jdenny-ornl avatar pearce8 avatar rennich avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

umt's Issues

Error while building Teton with GCC and Mvapich2

Hello, I am building UMT via Spack, and have run into this following error message that calls to mismatch in Teton source for MPI. Should I change my MPI version? I am using Mvapich2 downloaded from spack
(building using Spack latest, and Mvapich2 MPI, GCC 11.3)

==> Installing umt-master-ah6pibyhzhavaitbn5e5pcfo3bqc7kzc ==> No binary for umt-master-ah6pibyhzhavaitbn5e5pcfo3bqc7kzc found: installing from source ==> No patches needed for umt ==> umt: Executing phase: 'initconfig' ==> umt: Executing phase: 'cmake' ==> umt: Executing phase: 'build' ==> Error: ProcessError: Command exited with status 2: `/home/13_spack_UMT/spack/opt/spack/linux-ubuntu20.04-cascadelake/gcc-11.3.0/gmake-4.4.1-jilr5zmh37kfd4rfidm6iyq6vdws5oii/bin/make' '-j32'

24 errors found in build log:
176
177 1048 | call MPI_Irecv(recvBuf, nrecv, MPI_REAL8, irecv, &
178 | 1
179 ......
180 1126 | call MPI_Irecv(recvBuf, nrecv, MPI_INTEGER, irecv, &
181 | 2
182 Error: Type mismatch between actual argument at (1) and actual argument at (2) (REAL(8)/INTEGER(4)).
183 /tmp/spack-stage/spack-stage-umt-master-ah6pibyhzhavaitbn5e5pcfo3bqc7kzc/spack-src/src/teton/misc/mpif90_mod.F90:1010:20:
184
185 1010 | call MPI_Irecv(recvBuf, nrecv, MPI_REAL8, irecv, &
186 | 1
187 ......
188 1126 | call MPI_Irecv(recvBuf, nrecv, MPI_INTEGER, irecv, &
189 | 2

All the 24 errors are along this same line in the same file

Error: Cannot fetch non-existent child "relativeTolerance" from Node (options/iteration)

I think there's an error here with the relativeTolerance option being set only if a benchmark problem is specified.

options["iteration/relativeTolerance"] = 1e-10;

If one doesn't run a benchmark problem, i.e. the program isn't run with -b [0,1,2], the relativeTolerance isn't set and then I see an error when trying to read this option

terminate called after throwing an instance of 'conduit::Error' what(): file: /tmp/cmakrides/spack-stage/spack-stage-conduit-0.8.8-d7d3sdhauopbnumlex4gwzgcs4d2pvah/spack-src/src/libs/conduit/conduit_node.cpp line: 14197 message: Cannot fetch non-existent child "relativeTolerance" from Node(options/iteration)

The read that causes an error later on is from

double relative_tol = options.fetch_existing("iteration/relativeTolerance").value();

There doesn't seem to be an option to the driver that allows the tolerance to be set, so in principle a default would have to be set before the test for the benchmark problem is made.

Question on Parallelization

Hello,

This message is more of a question, so my apologies in advance if this is not the best place for this.

We are trying to use UMT to help processor architectures with their next gen design, and they want to parallelize the hot loop of the code among certain number of microthreads. We performed a VTune analysis using the MFEM test case, and it seemed the hot loops are in SweepUCBxyz.F90 line 270 and 278. Now the architects are wondering if they can parallelize the two most outer loops, HyperPlaneLoop (line 103) and ZoneLoop (line 107). The question is that is there data dependency on either of these loops preventing parallelization? Is the value of c0 unique in each iteration (it seems like that based on the data from the test case, but we can't say that for sure)? We would truly appreciate any guidance on this, and more general, on OpenMP parallelization of the code. Thank you in advance for your time.

Spack package?

@aaroncblack , is there a Spack package for this? Conduit has its own spack package which builds HDF5 but not SILO, so I think I have to build, at minimum SILO, HYPRE, and MFEM, and hook them up. Is there a Spack package around or is what's in this repo the current state of the art? Thanks!

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.