-
Notifications
You must be signed in to change notification settings - Fork 63
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add option to also transform matset_values to silo #685
Conversation
I am testing this out in visit, I may add some more example fields to venn if it helps me verify all the moving pieces. |
…x bugs with relay mesh bp truncate write
@xjrc I think this is ready for further review, can you take a pass? Once this is ready, I plan todo a 0.7.0 release for use in VisIt. (I am still testing this in parallel in VisIt) |
also, this should resolve #676 (but we may need more docs) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, Cyrus. I'm requesting changes with my review because I believe that we need to update the docs and tests to indicate that material_map
can be included with any form of matset
entry now, but is optional for multi-buffer material sets. Thanks for the changes and let me know if you'd like any help with synthesizing or reviewing the docs!
while(mats_itr.has_next()) | ||
{ | ||
mats_itr.next(); | ||
idx_matset["materials"][mats_itr.name()]; | ||
idx_matset["material_map"][mats_itr.name()] = mat_id; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unless I'm missing something, this could be simplified by using mats_itr.index()
instead.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FYI: Good suggestion, I made this change.
} | ||
else if(matset.has_child("materials")) | ||
{ | ||
// NOTE: I believe path is deprecated ... |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is correct; we either have and use the material_map
provided, or we use a default ordering to create a temporary material_map
for processing. Thus, this branch can be safely removed.
CHECK_MESH(verify_matset_index,mindex,info,true); | ||
mindex["material_map/mat2"].set(2); | ||
CHECK_MESH(verify_matset_index,mindex,info,true); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great! However, for the sake of completeness, we also need this to be tested at the matset
level for multi-buffer matsets, and for the documentation to be updated.
temp.set_external(DataType::int64(1), &mat_index); | ||
temp.to_data_type(int_dtype.id(), matset_mat_map[mat_name]); | ||
temp.to_data_type(int_dtype.id(), matset_mat_map[curr_mat_name]); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this look could also be simplified with vf_itr.index()
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FYI: Good suggestion, I made this change.
Just saw this; yes, I agree with your assessment based on my read-through of the code. |
@xjrc thanks for the suggestions and for keeping me honest. I added more docs, strengthened the verify checks and tests. Let me know if think they are more ways to improve. |
@cyrush more docs, more tests (less problems :-) Is that like tastes great, less filling? |
@rhornung67 hmm, less problems is good thing - but I am not sure filling is a bad thing. Especially because #686 would be a good thing. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just have one more comment on the way matset::verify
currently works, but overall this looks great and could be merged as-is. Thanks for all of you hard work on these features, Cyrus!
// verifies that it's one level deep and that each child child houses | ||
// an integer-style array. | ||
vfs_res &= verify_object_field(protocol, matset, info, "material_map"); | ||
vfs_res &= verify_matset_material_map(protocol,matset,info); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I'd make this check separate, similar to what's done in the multi-buffer case; this way, the user can check for a valid material_set
entry (i.e. an object with all integer values) without depending on a valid volume_fractions
entry.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree, I shifted the logic to outside
const std::vector<std::string> &map_mats = matset["material_map"].child_names(); | ||
const std::set<std::string> vf_matset(vf_mats.begin(), vf_mats.end()); | ||
const std::set<std::string> map_matset(map_mats.begin(), map_mats.end()); | ||
if(vf_matset != map_matset) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this should probably check that vf_matset
is a subset of map_matset
instead of forcing them to be equal. It's a slim and out-there use case, but I could imagine a user having one material_map
spread across all matset
entries, and in that case it may have extra material values that aren't relevant to some particular entries.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done, also added a test case
@@ -1127,6 +1235,34 @@ TEST(conduit_blueprint_mesh_verify, matset_general) | |||
n["element_ids"].set(DataType::int32(5)); | |||
CHECK_MESH(verify_matset,n,info,true); | |||
CHECK_MATSET(n,is_uni_buffer,is_material_dominant); | |||
|
|||
//--------------------------------------// | |||
// check for optional use of material_map |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
check for non-optional use of material map
CHECK_MESH(verify_matset,n,info,false); | ||
|
||
|
||
n.remove("material_map"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for being so thorough with these tests, Cyrus!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great, @cyrush; thanks!
No description provided.