Initial MIR component #1438

BradWhitlock · 2024-10-03T20:12:48Z

This PR is adds an initial MIR component to Axom. EquiZ MIR was implemented as the first algorithm because it was more familiar and my first goal was to shake out problems with infrastructure for writing algorithms against Blueprint data. The MIR algorithm takes Blueprint input and generates Blueprint output.

This PR does the following:

Supercedes previous MIR work (previous work was either adapted or moved to "reference" directory)
Implements EquiZ (without iteration for now) that runs on CPU/GPU and works on 2D/3D meshes with various topology and shape types.
Provides views to simplify writing algorithms that use Blueprint data.
Provides several utility classes that perform mesh operations (extract zones, merge meshes, etc.)
Adds documentation
Adds example programs
Adds a little core infrastructure

NOTE:

The Elvira algorithm will be added in a future PR.
The previous serial MIR implementation was moved to a "reference" directory that we can remove once EquiZAlgorithm has iteration support (future work).
The component requires Conduit, RAJA, Umpire - I'll probably have to iterate with the CI some to make that work everywhere.
There are some files that changed because of "make style"

BradWhitlock · 2024-11-09T01:00:30Z

I added a script that will make BASH scripts to run the mir_concentric_circles example program on various platforms and gather the caliper data results. I plotted the MIR runtime and some things look good, some very bad at the moment. I think SEQ mode could be optimized more to bring it down, likely bringing down time in the other modes too. OMP has inexplicably bad performance. I've seen some hints of this before during development but focused more on GPU so far. I'll need to profile OMP and see what's the matter.

rzansel42{whitlocb}144: env OMP_NUM_THREADS=44 ./examples/mir_concentric_circles --gridsize 1000 --numcircles 5 --policy omp | grep runMIR
runMIR                                 17.601138     17.601138     17.601138 88.542790 
rzansel42{whitlocb}145: env OMP_NUM_THREADS=88 ./examples/mir_concentric_circles --gridsize 1000 --numcircles 5 --policy omp | grep runMIR
runMIR                                 20.347344     20.347344     20.347344 89.191530 
rzansel42{whitlocb}146: env OMP_NUM_THREADS=32 ./examples/mir_concentric_circles --gridsize 1000 --numcircles 5 --policy omp | grep runMIR
runMIR                                 16.865811     16.865811     16.865811 88.723097 
rzansel42{whitlocb}147: env OMP_NUM_THREADS=22 ./examples/mir_concentric_circles --gridsize 1000 --numcircles 5 --policy omp | grep runMIR
runMIR                                 12.256273     12.256273     12.256273 85.147964 
rzansel42{whitlocb}148: env OMP_NUM_THREADS=2 ./examples/mir_concentric_circles --gridsize 1000 --numcircles 5 --policy omp | grep runMIR
runMIR                                  6.044385      6.044385      6.044385 73.873691 
rzansel42{whitlocb}149: env OMP_NUM_THREADS=1 ./examples/mir_concentric_circles --gridsize 1000 --numcircles 5 --policy omp | grep runMIR
runMIR                                  3.880441      3.880441      3.880441 64.487702 
rzansel42{whitlocb}150: ./examples/mir_concentric_circles --gridsize 1000 --numcircles 5 --policy omp | grep runMIR
runMIR                                 30.048744     30.048744     30.048744 90.253846

Arlie-Capps · 2024-11-15T20:28:02Z

src/axom/mir/tests/mir_equiz2d.cpp

+void conduit_debug_err_handler(const std::string &s1, const std::string &s2, int i1)
+{
+  std::cout << "s1=" << s1 << ", s2=" << s2 << ", i1=" << i1 << std::endl;
+  // This is on purpose.


Thank you: this is a necessary comment.

gunney1 · 2024-11-20T15:18:13Z

src/axom/core/memory_management.hpp

+inline int getAllocatorIDForAddress(void* ptr)
+{
+  umpire::ResourceManager& rm = umpire::ResourceManager::getInstance();
+  return rm.getAllocator(ptr).getId();


What if ptr was not Umpire-allocated? A check that the allocator could be found would be helpful to avoid crashing. Would it make sense to return INVALID_ALLOCATOR_ID in that case?

Good suggestion. I added a test that calls getAllocatorIDForAddress() with a pointer not allocated by Umpire, which made Umpire throw an exception. I added exception handling and return INVALID_ALLOCATOR_ID in that case.

src/axom/core/utilities/Sorting.hpp

…h a pointer not allocated by umpire. Added test.

…mall changes too.

Arlie-Capps · 2024-12-13T23:38:09Z

src/axom/mir/utilities/CoordsetBlender.hpp

+   *
+   * \note The coordset view must agree with the coordset in n_input. We pass both
+   *       a view and the coordset node since the view may not be able to contain
+   *       come coordset metadata and remain trivially copyable.


"come coordset metadata" Should this be "some coordset metadata"?

… put it in utilities/blueprint namespace.

gunney1 · 2025-01-15T02:58:11Z

I'm struggling to understand what "blending" is. Can't find it in the code or the docs. (Maybe it's in the referenced publications.) It seems like an important concept. Can you define it, at least in the documentation?

BradWhitlock · 2025-01-15T22:08:52Z

Blending takes tuples of ids and weights applies them to an input coordset or field to make a new coordset or field. The inputs are blended according to the weights to make the new item. https://github.com/LLNL/axom/pull/1438/files#diff-fb605bba545a37f0257de0b2acdc23ec71f15af3ab1cf907ba5a580e635cb754

kennyweiss

Thanks you @BradWhitlock for this comprehensive and well-documented new feature!
Sorry it took so long to review -- there is a lot here!

The new blueprint/view utilities are going to be extremely useful. As we discussed offline, we'll likely want to move them outside the MIR component in the future. Either as a new folder in sidre or as a separate component.

kennyweiss · 2024-11-06T18:53:23Z