Initial MIR component #1438
Initial MIR component #1438
Conversation
|
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 ?
There was a problem hiding this comment.
I added comments for all of the functions.
| 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 (?)
There was a problem hiding this comment.
I changed the code to use Sphere's computeSignedDistance().
| 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?
There was a problem hiding this comment.
I added comments. I also added functions to make other flavors of matset for testing.
| } | ||
|
|
||
| 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
There was a problem hiding this comment.
I added comments and an ASCII diagram of material.
| { } | ||
| } | ||
|
|
||
| void mixed3d(conduit::Node &mesh) |
There was a problem hiding this comment.
I documented all of the functions.
| // 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?
There was a problem hiding this comment.
That could work - future.
| 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
There was a problem hiding this comment.
I added guards for AXOM_USE_HDF5
src/axom/mir/EquiZAlgorithm.hpp
Outdated
| #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
There was a problem hiding this comment.
That would introduce new klee/quest dependencies into MIR. Is that worth it?
There was a problem hiding this comment.
I was thinking we could generate the data using the shaping app and then separately use it for mir. That seems better to me than supporting a second ad-hoc way of generating volume fractions, and also shows that MIR can support the data generated by the shaping app
There was a problem hiding this comment.
clearly, this would only be for the examples that create volume fraction data from geometry, as opposed to the ones that have explicit volume fractions
…ass that merges materials take an optional policy that tells it which materials it operates on. This can limit the amount of code generated to handle materials.
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: