Skip to content
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

Merged
merged 6 commits into from
Feb 4, 2021

Conversation

cyrush
Copy link
Member

@cyrush cyrush commented Jan 26, 2021

No description provided.

@cyrush cyrush added this to the 0.7.0 milestone Jan 26, 2021
@cyrush cyrush requested a review from xjrc January 26, 2021 17:39
@cyrush
Copy link
Member Author

cyrush commented Jan 26, 2021

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.

@coveralls
Copy link

coveralls commented Jan 26, 2021

Coverage Status

Coverage increased (+0.09%) to 86.317% when pulling 46223f8 on task/2021_01_matset_vals_to_silo into b3d1ba0 on develop.

@cyrush
Copy link
Member Author

cyrush commented Jan 29, 2021

@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)

@cyrush
Copy link
Member Author

cyrush commented Jan 29, 2021

also, this should resolve #676 (but we may need more docs)

Copy link
Member

@xjrc xjrc left a 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;
Copy link
Member

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.

Copy link
Member Author

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 ...
Copy link
Member

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);
}
Copy link
Member

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]);
Copy link
Member

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().

Copy link
Member Author

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.

@xjrc
Copy link
Member

xjrc commented Jan 29, 2021

also, this should resolve #676 (but we may need more docs)

Just saw this; yes, I agree with your assessment based on my read-through of the code.

@cyrush
Copy link
Member Author

cyrush commented Jan 29, 2021

@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.

@rhornung67
Copy link
Member

@cyrush more docs, more tests (less problems :-) Is that like tastes great, less filling?

@cyrush
Copy link
Member Author

cyrush commented Jan 30, 2021

@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.

Copy link
Member

@xjrc xjrc left a 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);
Copy link
Member

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.

Copy link
Member Author

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)
Copy link
Member

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.

Copy link
Member Author

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
Copy link
Member

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");
Copy link
Member

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!

Copy link
Member

@xjrc xjrc left a 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!

@cyrush cyrush merged commit 57c39c9 into develop Feb 4, 2021
@cyrush cyrush deleted the task/2021_01_matset_vals_to_silo branch February 4, 2021 23:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants