visit-dav
Polyhedral volume calculation mismatch
See teams chat for more details.
https://teams.microsoft.com/l/message/19:[email protected]/1755548668973?tenantId=a722dec9-ae4e-4ae3-9d75-fd66e2680a63&groupId=70162982-9587-4bcc-ad53-20178c76fe11&parentMessageId=1755548668973&teamName=VisIt&channelName=General&createdTime=1755548668973
More generally, visit subdivides polyhedral meshes into tetrahedron. For a hexehedral mesh, written in polyhedral format, each zone becomes 24 zones to visit. On a polyhedral mesh with 1 zone, NumZones query returns 24. A mesh variable with a value of 1, the variable sum query returns 24. It would be nice if visit could hide the fact that it is subdividing polyhedral zones from the user.
More generally, visit subdivides polyhedral meshes into tetrahedron. For a hexehedral mesh, written in polyhedral format, each zone becomes 24 zones to visit. On a polyhedral mesh with 1 zone, NumZones query returns 24. A mesh variable with a value of 1, the variable sum query returns 24. It would be nice if visit could hide the fact that it is subdividing polyhedral zones from the user.
Just an FYI...that I think there are multiple routes for arbitrary polyhedra in VisIt and the do not all subdivide bona fid hexes into tets. For Silo arb. polyhedral meshes, the elements are traversed and examined and decomposed ONLY if they are not already a known zoo type (tet, pyramid, wedge or hex). If they are a known zoo type, they are converted to that type (e.g. a standard HEX). If they are truly arbitrary, they are converted to a combination of tets and pyramids by inserting a new point for the elements geometric center than fanning out over each face with pyramids and tets, depending on the number of edges in each face.
- Does the transform manager understand intensive vs extensive (volume dependence)?
- If we are given this information from Silo, then we can do this correctly. They give us volume as a variable on a field, so we should be able to scale things appropriately for subdivided elements.
- Does the transform manager understand intensive vs extensive (volume dependence)?
It does not. Worse, I suspect MOST data producers and most database formats do not support annotating a variable as to whether it is intensive or extensive. Silo supports this but I think few data producers actually use it. So, most Silo data files will not have the necessary information to know if a variable is intensive or extensive.
- Does the transform manager understand intensive vs extensive (volume dependence)?
It does not. Worse, I suspect MOST data producers and most database formats do not support annotating a variable as to whether it is intensive or extensive. Silo supports this but I think few data producers actually use it. So, most Silo data files will not have the necessary information to know if a variable is intensive or extensive.
The way forward under these conditions, IMHO, is to give the user the ability to explicitly manage whether a variable is treated as intensive or extensive through the GUI/CLI if the information is not already available for the variable from the data producer (and database format intermediary). This could lead to a design like so...
- Have global preference for "when variable is not annotated with extensive or intensive behavior, assume <pull-down menu selection of either intensive or extensive).
- Have expression that has the effect of annotating a variable as intensive or extensive. So, in the expression system, a user can specify
em=extensive(mass)and thenemgets treated how they want it. Likewise for anintensive()expression. - Upgrade Silo plugin and mesh transformation manager to deliver this information.