Open mlohry opened 3 months ago
Another example, this time using the two pyramid connectivity example from the blueprint docs
const std::string image_filename = "two_pyr_poly_mesh_render";
const std::string mesh_filename = "two_pyr_poly_mesh_extract";
std::vector<double> xvert = {0.5, 0.0, 1.0, 0.0, 1.0, 0.5};
std::vector<double> yvert = {1.0, 0.0, 0.0, 0.0, 0.0, -1.0};
std::vector<double> zvert = {0.5, 1.0, 1.0, 0.0, 0.0, 0.5};
conduit::Node mesh;
mesh["coordsets/coords/type"] = "explicit";
mesh["coordsets/coords/values/x"].set_external(xvert);
mesh["coordsets/coords/values/y"].set_external(yvert);
mesh["coordsets/coords/values/z"].set_external(zvert);
// connectivity from example https://llnl-conduit.readthedocs.io/en/latest/blueprint_mesh.html
std::vector<std::int32_t> poly_face_conn = {1, 2, 4, 3, 1, 2, 0, 2, 4, 0, 4, 3, 0, 3, 1, 0, 1, 2, 5, 2, 4, 5, 4, 3, 5, 3, 1, 5};
std::vector<std::int32_t> poly_face_sizes = {4, 3, 3, 3, 3, 3, 3, 3, 3};
std::vector<std::int32_t> poly_face_offsets = {0, 4, 7, 10, 13, 16, 19, 22, 25};
std::vector<std::int32_t> poly_cell_conn = {0, 1, 2, 3, 4, 0, 5, 6, 7, 8};
std::vector<std::int32_t> poly_cell_sizes = {5, 5};
std::vector<std::int32_t> poly_cell_offsets = {0, 5};
mesh["topologies/topo/type"] = "unstructured";
mesh["topologies/topo/elements/shape"] = "polyhedral";
mesh["topologies/topo/subelements/shape"] = "polygonal";
mesh["topologies/topo/coordset"] = "coords";
mesh["topologies/topo/elements/connectivity"].set_external(poly_cell_conn);
mesh["topologies/topo/elements/sizes"].set_external(poly_cell_sizes);
mesh["topologies/topo/elements/offsets"].set_external(poly_cell_offsets);
mesh["topologies/topo/subelements/connectivity"].set_external(poly_face_conn);
mesh["topologies/topo/subelements/sizes"].set_external(poly_face_sizes);
mesh["topologies/topo/subelements/offsets"].set_external(poly_face_offsets);
// dummy field needed to work around https://github.com/Alpine-DAV/ascent/issues/1260
std::vector<double> ones(xvert.size(), 1.0);
mesh["fields/dummy/association"] = "vertex";
mesh["fields/dummy/topology"] = "topo";
mesh["fields/dummy/values"].set_external(ones);
conduit::Node verify_info;
const bool verified = conduit::blueprint::mesh::verify(mesh, verify_info);
ASSERT_TRUE(verified) << verify_info.to_yaml() << std::endl;
ascent::Ascent ascent_viewer;
conduit::Node ascent_opts;
ascent_opts["mpi_comm"] = MPI_Comm_c2f(MPI_COMM_WORLD);
ascent_viewer.open(ascent_opts);
ascent_viewer.publish(mesh);
conduit::Node actions;
// declare an action to create a .png render
conduit::Node& add_actions = actions.append();
add_actions["action"] = "add_scenes";
conduit::Node& scenes = add_actions["scenes"];
scenes["s1/plots/p1/type"] = "mesh";
scenes["s1/image_prefix"] = image_filename;
// declare an action to create a mesh extraction to hdf5
conduit::Node& add_extracts = actions.append();
add_extracts["action"] = "add_extracts";
conduit::Node& extracts = add_extracts["extracts"];
extracts["e0/type"] = "relay";
extracts["e0/params/path"] = mesh_filename;
extracts["e0/params/protocol"] = "blueprint/mesh/hdf5";
std::cout << actions.to_yaml() << std::endl;
ascent_viewer.execute(actions);
// conduit::Node info;
// ascent_viewer.info(info);
// info.print();
ascent_viewer.close();
std::cout << "Image file should have been written to disk: " << image_filename << std::endl;
std::cout << "Mesh file should have been written to disk: " << mesh_filename << std::endl;
This also shows negative volumes, and oddly the mesh edge lines don't appear (or are white and opaque)
@mlohry Thank you for all of these examples.
We have some face ordering constraints in another set of codes that I think explain why we have negative volumes in VisIt. We will look at addressing those by making VisIt's volume expressions more robust.
For the internal mesh lines, this happens b/c we do subdivide the mesh to render using simpler primitives.
VisIt has logic to remove the mesh lines of automatically subdivided mesh (when it is presented directly with a polytopal mesh). Ascent doesn't have the same logic, but needs it.
Ascent subdividing is impacting the extract (you are exporting the subdivided result instead of the original published mesh)
Both versions are useful, so we will look at adding options that allow both flavors to be exported.
The following code for a single tetrahedron mesh generates a blueprint hdf5 mesh file and render,
The rendered image and the mesh viewed in visit are as expected,
Attempting to render the same thing, but using the general polyhedral format,
In the render it appears the tetrahedron has been subdivided,
and when loading the mesh into visit, what appears to be subdivided cells, which additionally have all negative volumes by visit's calculation.
The polygonal face ordering used here is (I believe) the same as that specified in the VTK source definition for a tetra 4.
Looking at the VTK-m source is a different winding equivalent to
again the render is split but this time some sub-cells are listed with negative volumes of -0.01389 and positive +0.01389.
If I use the SIDS tetra_4 ordering for faces equivalent to
again the cell is subdivided, this time with all negative -0.01389 volumes showing in visit:
Questions: