Initial MIR component #1438
Initial MIR component #1438
Conversation
| * | ||
| * \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. |
There was a problem hiding this comment.
"come coordset metadata" Should this be "some coordset metadata"?
… put it in utilities/blueprint namespace.
|
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? |
|
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 |
There was a problem hiding this comment.
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.
|
|
||
| void add_distance(conduit::Node &mesh, float dist = 6.5f) | ||
| { | ||
| // Make a new distance field. |
There was a problem hiding this comment.
Please enhance the comment -- I think it's the distance to a sphere of radius dist ?
| for(int index = 0; index < nnodes; index++) | ||
| { | ||
| const auto pt = coordsetView[index]; | ||
| float norm2 = 0.f; | ||
| for(int i = 0; i < pt.DIMENSION; i++) norm2 += pt[i] * pt[i]; | ||
| valuesPtr[index] = sqrt(norm2) - dist; | ||
| } |
There was a problem hiding this comment.
Minor: Would it be clearer to use a primal::Sphere and it's computeSignedDistance() member function?
Perhaps not, b/c the latter is templated on the dimension (?)
| add_distance(mesh); | ||
| } | ||
|
|
||
| void make_unibuffer(const std::vector<float> &vfA, |
There was a problem hiding this comment.
Please add a brief documentation here. Specifically, what is a unibuffer?
| } | ||
|
|
||
| template <typename Dimensions> | ||
| void make_matset(const std::string &type, |
There was a problem hiding this comment.
Please add a brief description of what this function does. It looks like it makes some (arbitrary) choices about the material distribution
| { } | ||
| } | ||
|
|
||
| void mixed3d(conduit::Node &mesh) |
| // Uncomment to generate baselines | ||
| //#define AXOM_TESTING_GENERATE_BASELINES | ||
|
|
||
| // Uncomment to save visualization files for debugging (when making baselines) | ||
| //#define AXOM_TESTING_SAVE_VISUALIZATION |
There was a problem hiding this comment.
Minor: Since this file takes CLI arguments, would it make sense for these to be command line arguments that are off by default rather than compiler guards?
| using MaterialID = int; | ||
| using MaterialIDArray = axom::Array<MaterialID>; | ||
| using MaterialIDView = axom::ArrayView<MaterialID>; | ||
| using MaterialVF = float; |
There was a problem hiding this comment.
Might be a good idea for a follow-up PR
| n_tmpInput[n_matset.path()].set_external(n_matset); | ||
| conduit::relay::io::blueprint::save_mesh(n_tmpInput, | ||
| "debug_equiz_input", | ||
| "hdf5"); |
There was a problem hiding this comment.
Note: "hdf5" is only available when AXOM_USE_HDF5 is defined
| #endif | ||
|
|
||
| /*! | ||
| * \brief Perform material interface reconstruction on a single domain. |
There was a problem hiding this comment.
[Possible copy/paste] Is this the right doxygen comment for this function?
| /*! | ||
| * \file MeshTester.hpp | ||
| * | ||
| * \brief Contains the specification for the MeshTester class. | ||
| * | ||
| */ |
There was a problem hiding this comment.
Can we create a ticket to reimplement some of these test cases using Klee in a follow-up PR?
The ones we can't reproduce w/ Klee, (e.g. b/c they give explicit values) should probably be moved to axom_data
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:
NOTE: