Support a different elastic material in each block #5737
Conversation
nilsvu
force-pushed
the
elasticity1
branch
15 times, most recently
from
1370a66
to
b322e11
Compare
|
|
||
| private: | ||
| size_t num_blocks_; | ||
| std::vector<std::string> block_names_; | ||
| std::unordered_map<std::string, std::unordered_set<std::string>> | ||
| block_groups_; | ||
| }; | ||
|
|
||
| template <typename T> |
There was a problem hiding this comment.
Could we move the definitions to a tpp and instantiate STL types maybe in ExpandOverBlocks.cpp? We can then also instantiate specific other types in other places as necessary. I'd us to continue to reduce code in header files. In this case I worry a bit that it'll be transitively included in a decent number of places.
| std::to_string(num_blocks_) + " blocks."}; | ||
| } | ||
| if constexpr (tt::is_a_v<std::unique_ptr, T>) { | ||
| std::vector<T> expanded{}; |
There was a problem hiding this comment.
Utilities/CloneUniquePtrs.hpp has code to do this. Can you just use that?
| // Expand group names | ||
| auto value_per_block = [&value]() { | ||
| if constexpr (tt::is_a_v<std::unique_ptr, T>) { | ||
| std::unordered_map<std::string, T> copy{}; |
There was a problem hiding this comment.
Again, can we use Utilities/CloneUniquePtrs.hpp?
| @@ -38,6 +38,7 @@ | |||
| #include "Utilities/ErrorHandling/Error.hpp" | |||
There was a problem hiding this comment.
I don't understand how this change allows observing anything per material layer. It just allows you to name ObserveNorms something else. Couldn't this be achieved with compute tags filtering on the layer?
This needs tests regardless, but I'm not sure this is the right solution to the problem. Maybe we can discuss in the tech call?
There was a problem hiding this comment.
As discussed in a meeting recently, yes, this only provides a name for the event in the input file. It's needed when you have multiple ObserveNorms events in the same executable (here you have one for norms over the full domain and one for norms over each material layer). I think passing along a label struct is consistent with other parts of the code where we do that, e.g. Options::Auto<T, Label>. I added some docs to explain.
src/Domain/Creators/BlockGroups.hpp
Outdated
| * \p all_block_names. If one of the input names was a group, then all block | ||
| * names from that group are included. Overlaps between groups are allowed. | ||
| */ | ||
| std::unordered_set<std::string> expand_block_groups( |
There was a problem hiding this comment.
maybe add _to_block_names? It isn't clear to me from the current name what it does, and while documented, the extra clarity seems worth it to me 🤷
| @@ -0,0 +1,201 @@ | |||
| // Distributed under the MIT License. | |||
|
I squashed in the split of ExpandOverBlocks into a tpp file, and added a test. |
Also support `std::unique_ptr`s. This helps specify an elastic material for each block of the domain in the input file.
Allows to use this to observe quantities per material layer.
Also modernize constructors a bit.
|
@geoffrey4444 do you want to take another look? |
Proposed changes
Getting code merged that's used in the thermal noise paper (https://arxiv.org/abs/2111.06893). This PR adds support for layered materials, but the DG scheme still needs an update to support this (next PR).
Upgrade instructions
Code review checklist
make docto generate the documentation locally intoBUILD_DIR/docs/html.Then open
index.html.code review guide.
bugfixornew featureif appropriate.Further comments