-
Notifications
You must be signed in to change notification settings - Fork 24
Arbitrary_Polygons_and_Polyhedra_in_Silo
- DBPutZonelist
- Obsoleted in favor of DBPutZonelist2
- DBPutZonelist2
- Added to deal with shapetype. With DBPutZonelist, we could not tell difference between a 4 noded quadrilateral (2D) and a 4 noded Tetrahedron (3D).
- DBPutFacelist
- Ordinarily used for the external faces of a mesh but sometimes also used to output 2D mesh zonelist information
- DBPutPHZonelist
- Designed to support arbitrary polyehdra in 3 dimensions but also supports them in 2D in a couple of diffferent ways.
There are simply way too many different options available in Silo for writers to output polygon and polyhedral information. There is no guidance in the Silo user’s manual on how to use it properly.
This is negative impact on VisIt’s Silo plugin as there is a bunch of code in their to deal with myriad of different ways a Silo writer may have written the data.
The writer is concerned with simplicity in writing the data out as well as storage efficiency in the representation.
How are mixtures of zoo-type and arbitrary-type elements, that is zonelists that contain both zoo-type and arbitrary elements, handled? Simplicity in the writer may favor treating all zones in one way, say as arbitrary, simply because its easier.
DBPutZonelist is deprecated. New writers should not be using it. There may be legacy data files that contain data written using it however.
In two dimensions1, we are dealing with polygons, not polyhedra. Its easier. Each polygon is identified by its list of nodes. But, there are many options presently available in Silo for how to handle this.
Three arguments are relevant
- nodelist array
- shapesize array
- shapecount array
The zonelist is broken into segments of similarly shaped polygons. The shapesize argument indicates, for a given segment the number of nodes in each of the polygons (2D) or polyhedra (3D) of that segment. The shapecount argument then indicates the number of polygons (2D) or polyhedra (3D) in that segment. However, there is a convention where a shapesize entry of zero is used to indicate that for all of the polygons (2D) or polyedra (3D) of that segment, the size (e.g. number of nodes in 2D or number of faces in 3D) is actually the first integer value in the nodelist before the list of nodes defining a polygon (2D) or face of a polyhedron (3D).
WARNING: Turns out the zero shapesize entry convention is apparently valid only for 2D polygonal zones. In 3D, the expectation is that the shapesize entry will be the number of slots the (collection of) arbitrary shapes takes up on the nodelist. This is totally whacky!
For arbitrary shapes in two dimensions, the cooresponding nodelist entries begins with a count of the number of nodes of the polygon followed by the list of nodes for the polygin. For arbitrary shapes in three dimensions, the cooresponding nodelist entries begin with a count of the number of faces of the polyhedron followed by the enumeration of each of those faces as an arbitrary polygon (e.g. node count followed by node ids) for that face. A problem with this approach is that the edges of arbitrary polygons as well as the faces of arbitrary polyhedra all wind up having to be enumerated in the nodelist twice, once for each zone that shares them.
So, there are a couple of ways to handle arbitrary polygons (2D) or polyhedra (3D) in this method. One is to specify a shapesize entry of zero and then encode any number of arbitrary polygons (2D) or polyhedra (3D) in the associated segment by including the size of each polygon in the nodelist just before all the nodes defining the polygon in the nodelist (2D) or the number of faces of the polyhedron followed by each polygonal face where the first entry for each face is the number of nodes for that face (3D). This frees the caller from having to either gather together polygons or polyhedra of similar size/shape into contiguous segments in the zonelist or from having to treat each as a very short segment of length one. Of course, as soon as one reaches this conclusion, it then becomse easier to simply encode all polygons or polyhedra, even the zoo-type shapes, in the same way resulting in a single segment with a shapesize of zero but where each and every polygon’s nodes in the nodelist is preceded by the shapeize (e.g. node count) of the number of nodes in that polygon (2D) or where every polyhedra’s faces in the nodelist are preceded by the number of faces and then followed by an enumeration of the polygon forming each face. In this case, the shapesize and shapecount arguments both become arrays of length only 1 and all node/face counts get embedded into the nodelist itself.
So, I think this means that for the old DBPutZonelist method, there are really only two modalities of use that are important to support. One is the appraoch where the caller does indeed try to gather together common shapes into larger coherent segments. We call this a segmented zonelist. In this approach, the shapesize for a segement should most likely always be non-zero (in other words, when a caller is segmenting the zonelist, there will never be a reason to create a special segment with a shapesize of zero. In the other approach, the caller cannot be bothered with trying to collect similarly sized shapes together and simply enumerates them in whatever order they exist. In this case, there will only be a single segment and its shapsize will be zero and its count will be equal to the total number of polygons or polyhedra. We call this a monolithic zonelist. The mixing of zoo-type with arbitrary-type shapes is likely to be encountered only in the former, segmented usage. In the latter usage, even if the caller does indeed have a zoo-type shape (e.g. triangle or quadrilateral), it will nonetheless be most likely to characterize it as an arbitrary shape.
Supporting modalities of use in VisIt’s Silo plugin other than these two common ones seems unproductive and overly complex.
Relevant Arguments
- nodelist array
- shapetype array
- shapesize array
- shapecnt array
In addition to all the same arguments as DBPutZonelist, the additional argument DBPutZonelist2 supports is shapetype plus the ability to specify hi and lo offsets for ghosting. Nonetheless, the other considerations are the same for DBPutZonelist2 as they were for DBPutZonelist with one key exception. The shapesize entry can never be zero. If a shapetype entry for a given segment of the zonelist is DB_ZONETYPE_POLYGON or DB_ZONETYPE_POLHEDRON, then the corresponding shapesize entry must be a count of the number of slots in the nodelist that the given entry spans.
So, as with DBPutZonelist, there are really only two modalities of use that are important to support. One is where the caller does gather together common shapes into larger coherent segments of either zoo-type shapes and/or segments of arbitrary shapes. In this case, the shapesize argument will always be non-zero. In the other approach, the caller treats all shapes as arbitrary type. In this case, there is only one, uber segment whose shapesize will be zero, shapecount will be equal to total number of zones in the mesh and shapetype will be DB_ZONETYPE_POLYGON.
By and large, the situation is identical to DBPutZonelist.
Only two modalities of usage need be supported; the segmented case and the monolithic case.
The relevant arguments are…
- nodecounts
- nodelist
- facecounts
- facelist
The polyhedral zonelist method was introduced primarily to support 3D meshes of arbitrary polyhedra. However, it can just as easily also support 2D meshes of arbitrary polygons.
In 2D, there are two distinct usage modalities to consider. One is where each zone in the mesh is treated as a single face in the PH zonelist and there is no explicit representation of the edges. In this case, each zone consists of only a single face. The nodecounts argument then enumerates the number of nodes in each zone (face). The facecounts and facelist arguments are both null. In the other case, we explicitly represent all the edges of the mesh. The nodelist is then just lists of pairs of nodes, each pair representing one of the edges. Unfortunately, we still wind up having to store a ‘2’ in the nodecounts argument for each edge. So, each edge winds up costing 3 integers to store; the ‘2’ for its size in the nodecounts array and then the two node ids for each edge in the nodelist array. On the other hand, each edge in the mesh appears only once in the edgelist. Then, each 2D polygonal zone is defined by listing the edges that comprise the zone (thats the 2D analog of what we do to define the faces of a 3D arbitrary polyhedron). I suppose, also, in theory, each edge of a given zone could involve more than just two nodes.
So, for 2D, there are two usage modalities for a PH zonelist. The first is where the facecounts and facelist arguments are null and the nodecounts indicates the number of nodes in each 2D zone and then the nodelist then lists the nodes for each 2D zone. The other is where each 2D zone is defined in terms of a list of its bounding elements (which are edges for 2D) and so the nodecounts array contains a slew of ’2’s in it and the nodelist array identifies pairs of nodes defining each edge. The facecounts array indicates the number of edges in each zone and then the facelist array identifies the edges for each zone.
For 3D, there is only one usage modality to consider and that is where each shape is characterized as an arbitrary polhedra.
1 Although both DBPutZonelist and DBPutZonelist2 functions include an ndims argument, it would appear that in the original specification of the Silo interface, that was treated as the number of spatial dimensions in the associated mesh. It might have been more useful to have this argument be called tdims and have it be the number of topological dimensions in the associated mesh as that would then help to determine if we are specifying logicaly planar things (e.g. polygonal faces) or logically voluminous things (e.g. polyhedral volumes). It would help to distinguish between a 4 noded quadrilateral and a 4 noded tetrahedron and it would help to distinguish between a polygon requiring only specification of its node count and then its nodes or a polyhedron requiring specification of its number of faces.