text:
# VTK File Formats

A lot of this material is taken from [The VTK User’s Guide](https://www.kitware.com/products/books/VTKUsersGuide.pdf).

The *Visualization Toolkit* provides a number of source and writer objects to read and write popular data file formats. The *Visualization Toolkit* also provides some of its own file formats. The main reason for creating yet another data file format is to offer a consistent data representation scheme for a variety of dataset types, and to provide a simple method to communicate data between software. Whenever possible, we recommend that you use formats that are more widely used. But if this is not possible, the *Visualization Toolkit* formats described here can be used instead. Note that these formats may not be supported by many other tools.

There are two different styles of file formats available in VTK. The simplest are the legacy, serial formats that are easy to read and write either by hand or programmatically. However, these formats are less flexible than the XML based file formats described later in this section. The XML formats support random access, parallel I/O, and portable data compression and are preferred to the serial VTK file formats whenever possible.

VTK 10.0 introduces the HDF file formats. The goal of this work is to
provide simulations with a way to save data in the HDF format that
could be easily loaded in VTK without the need for an external data
description (such as XDMF). Currently we provide readers for Image
Data and Unstructured Grid.

## Simple Legacy Formats

The legacy VTK file formats consist of five basic parts.

1. The first part is the file version and identifier. This part contains the single line: ```vtk DataFile Version x.x.``` This line must be exactly as shown with the exception of the version number x.x, which will vary with different releases of VTK. (Note: the current version number is 3.0. Version 1.0 and 2.0 files are compatible with version 3.0 files.)

2. The second part is the header. The header consists of a character string terminated by end-of-line character \n. The header is 256 characters maximum. The header can be used to describe the data and include any other pertinent information.

3. The next part is the file format. The file format describes the type of file, either ASCII or binary. On this line the single word ASCII or BINARY must appear.

4. The fourth part is the dataset structure. The geometry part describes the geometry and topology of the dataset. This part begins with a line containing the keyword _DATASET_ followed by a keyword describing the type of dataset.Then, depending upon the type of dataset, other keyword/data combinations define the actual data.

5. The final part describes the dataset attributes. This part begins with the keywords _POINT_DATA_ or _CELL_DATA_, followed by an integer number specifying the number of points or cells, respectively. (It doesn’t matter whether _POINT_DATA_ or _CELL_DATA_ comes first.) Other keyword/data combinations then define the actual dataset attribute values (i.e., scalars, vectors, tensors, normals, texture coordinates, or field data).

An overview of the file format is shown in [Figure 1](#Figure1):

# vtk DataFile Version 2.0	(1)

Really cool data	(2)

ASCII | BINARY	(3)

DATASET type
...	(4)

POINT_DATA type
...
CELL_DATA type
...	(5)

Key:

Part 1: Header	Part 4: Geometry/Topology. Type is one of

        STRUCTURED_POINTS

        STRUCTURED_GRID

        UNSTRUCTURED_GRID

        POLYDATA

        STRUCTURED_POINTS

        RECTILINEAR_GRID

        FIELD

Part 2:Title (256 characters

 maximum, terminated with

 newline \n character)	Part 5: Dataset attributes. The number of data

items n of each type must match the number

of points or cells in the dataset. (If type is

FIELD, point and cell data should be omitted.

Part 3:Data type, either
 ASCII or BINARY

**Figure 1:** **Overview of five parts of VTK data file format.**

 The first three parts are mandatory, but the other two are optional. Thus you have the flexibility of mixing and matching dataset attributes and geometry, either by operating system file
manipulation or using VTK filters to merge data. Keywords are case insensitive, and may be separated by whitespace. Before describing the data file formats please note the following.

* _dataType_ is one of the types _bit_, _unsigned_char_, _char_, _unsigned_short_, _short_, _unsigned_int_, _int_, _unsigned_long_, _long_, _float_, or _double_. These keywords are used to describe the form of the data, both for reading from file, as well as constructing the appropriate internal objects. Not all data types are supported for all classes.

* All keyword phrases are written in ASCII form whether the file is binary or ASCII. The binary section of the file (if in binary form) is the data proper; i.e., the numbers that define points coordinates, scalars, cell indices, and so forth.

* Indices are 0-offset. Thus the first point is point id 0.

* If both the data attribute and geometry/topology part are present in the file, then the number of data values defined in the data attribute part must exactly match the number of points or cells defined in the geometry/topology part.

* Cell types and indices are of type _int_.

* Binary data must be placed into the file immediately after the “newline” _(\n)_ character from the previous ASCII keyword and parameter sequence.

* The geometry/topology description must occur prior to the data attribute description.

### Binary Files.

Binary files in VTK are portable across different computer systems as long as you observe two conditions. First, make sure that the byte ordering of the data is correct, and second, make sure that the length of each data type is consistent.

Most of the time VTK manages the byte ordering of binary files for you. When you write a binary file on one computer and read it in from another computer, the bytes representing the data will be automatically swapped as necessary. For example, binary files written on a Sun are stored in big endian order, while those on a PC are stored in little endian order. As a result, files written on a Sun workstation require byte swapping when read on a PC. (See the class vtkByteSwap for implementation details.) The VTK data files described here are written in big endian form.

Some file formats, however, do not explicitly define a byte ordering form. You will find that data read or written by external programs, or the classes vtkVolume16Reader, vtkMCubesReader, and vtkMCubesWriter may have a different byte order depending on the system of origin. In such cases, VTK allows you to specify the byte order by using the methods

```
SetDataByteOrderToBigEndian()
SetDataByteOrderToLittleEndian()
```

Another problem with binary files is that systems may use a different number of bytes to represent an integer or other native type. For example, some 64-bit systems will represent an integer with 8-bytes, while others represent an integer with 4-bytes. Currently, the *Visualization Toolkit* cannot handle transporting binary files across systems with incompatible data length. In this case, use ASCII file formats instead.

### Dataset Format.
The *Visualization Toolkit* supports five different dataset formats: structured points, structured grid, rectilinear grid, unstructured grid, and polygonal data. Data with implicit topology (structured data such as vtkImageData and vtkStructuredGrid) are ordered with x increasing fastest, then y, then z. These formats are as follows.

* **Structured Points**. The file format supports 1D, 2D, and 3D structured point datasets. The dimensions nx, ny, nz must be greater than or equal to 1. The data spacing sx, sy, sz must be greater than 0. (Note: in the version 1.0 data file, spacing was referred to as “aspect ratio”. ASPECT_RATIO can still be used in version 2.0 data files, but is discouraged.)

DATASET STRUCTURED_POINTS

DIMENSIONS nx ny nz

ORIGIN x y z

SPACING sx sy yz

* **Structured Grid**. The file format supports 1D, 2D, and 3D structured grid datasets. The dimensions nx, ny, nz must be greater than or equal to 1. The point coordinates are defined by the data in the _POINTS_ section. This consists of x-y-z data values for each point.

DATASET STRUCTURED_GRID

DIMENSIONS nx ny nz

POINTS n dataType

p0x p0y p0z

p1x p1y p1z

...

p(n-1)x p(n-1)y p(n-1)z

* **Rectilinear Grid**. A rectilinear grid defines a dataset with regular topology, and semi-regular geometry aligned along the x-y-z coordinate axes. The geometry is defined by three lists of monotonically increasing coordinate values, one list for each of the x-y-z coordinate axes. The topology is defined by specifying the grid dimensions, which must be greater than or equal to 1.

DATASET RECTILINEAR_GRID

DIMENSIONS nx ny nz

X_COORDINATES nx dataType

x0 x1 ... x(nx-1)

Y_COORDINATES ny dataType

y0 y1 ... y(ny-1)

Z_COORDINATES nz dataType

z0 z1 ... z(nz-1)

* **Polygonal Data**. The polygonal dataset consists of arbitrary combinations of surface graphics primitives vertices (and polyvertices), lines (and polylines), polygons (of various types), and triangle strips. Polygonal data is defined by the _POINTS_, _VERTICES_, _LINES_, _POLYGONS_, or _TRIANGLE_STRIPS_ sections. The _POINTS_ definition is the same as we saw for structured grid datasets. The _VERTICES_, _LINES_, _POLYGONS_, or _TRIANGLE_STRIPS_ keywords define the polygonal dataset topology. Each of these keywords requires two parameters: the number of cells n and the size of the cell list size. The cell list size is the total number of integer values required to represent the list (i.e., sum of numPoints and connectivity indices over each cell). None of the keywords _VERTICES_, _LINES_, _POLYGONS_, or _TRIANGLE_STRIPS_ is required.

DATASET POLYDATA

POINTS n dataType

p0x p0y p0z

p1x p1y p1z

...

p(n-1)x p(n-1)y p(n-1)z

VERTICES n size

numPoints0, i0, j0, k0, ...

numPoints1, i1, j1, k1, ...

...

numPointsn-1, in-1, jn-1, kn-1, ...

LINES n size

numPoints0, i0, j0, k0, ...

numPoints1, i1, j1, k1, ...

...

numPointsn-1, in-1, jn-1, kn-1, ...

POLYGONS n size

numPoints0, i0, j0, k0, ...

numPoints1, i1, j1, k1, ...

...

numPointsn-1, in-1, jn-1, kn-1, ...

TRIANGLE_STRIPS n size

numPoints0, i0, j0, k0, ...

numPoints1, i1, j1, k1, ...

...

numPointsn-1, in-1, jn-1, kn-1, ...

* **Unstructured Grid**. The unstructured grid dataset consists of arbitrary combinations of any possible cell type. Unstructured grids are defined by points, cells, and cell types. The CELLS keyword requires two parameters: the number of cells n and the size of the cell list size. The cell list size is the total number of integer values required to represent the list (i.e., sum of numPoints and connectivity indices over each cell). The CELL_TYPES keyword requires a single parameter: the number of cells n. This value should match the value specified by the CELLS keyword. The cell types data is a single integer value per cell that specified cell type (see vtkCell.h or Figure 2).

DATASET UNSTRUCTURED_GRID

POINTS n dataType

p0x p0y p0z

p1x p1y p1z

...

p(n-1)x p(n-1)y p(n-1)z

CELLS n size

numPoints0, i0, j0, k0, ...

numPoints1, i1, j1, k1, ...

numPoints2, i2, j2, k2, ...

...

numPointsn-1, in-1, jn-1, kn-1, ...

CELL_TYPES n

type0

type1

type2

...

typen-1

* **Field**. Field data is a general format without topological and geometric structure, and without a particular dimensionality. Typically field data is associated with the points or cells of a dataset. However, if the FIELD type is specified as the dataset type (see [Figure 1](#Figure1)), then a general VTK data object is defined. Use the format described in the next section to define a field. Also see “Working With Field Data” on [page 249](https://www.kitware.com/products/books/VTKUsersGuide.pdf#page=263) and the fourth example in this chapter [Legacy File Examples](#legacy-file-examples).

### Dataset Attribute Format.

The *Visualization Toolkit* supports the following dataset attributes: scalars (one to four components), vectors, normals, texture coordinates (1D, 2D, and 3D), tensors, and field data. In addition, a lookup table using the RGBA color specification, associated with the scalar data, can be defined as well. Dataset attributes are supported for both points and cells.

Each type of attribute data has a dataName associated with it. This is a character string (without embedded whitespace) used to identify a particular data. The dataName is used by the VTK readers to extract data. As a result, more than one attribute data of the same type can be included in a file. For example, two different scalar fields defined on the dataset points, pressure and temperature, can be contained in the same file. (If the appropriate dataName is not specified in the VTK reader, then the first data of that type is extracted from the file.)

* **Scalars**. Scalar definition includes specification of a lookup table. The definition of a lookup table is optional. If not specified, the default VTK table will be used (and tableName should be “default”). Also note that the numComp variable is optional—by default the number of components is equal to one. (The parameter numComp must range between 1 and 4 inclusive; in versions of VTK prior to 2.3 this parameter was not supported.)

SCALARS dataName dataType numComp

LOOKUP_TABLE tableName

s0

s1

...

sn-1

The definition of color scalars (i.e., unsigned char values directly mapped to color) varies depending upon the number of values (nValues) per scalar. If the file format is ASCII, the color scalars are defined using nValues float values between (0,1). If the file format is BINARY, the stream of data consists of nValues unsigned char values per scalar value.

COLOR_SCALARS dataName nValues

c00 c01 ... c0(nValues-1)

c10 c11 ... c1(nValues-1)

...

c(n-1)0 c(n-1)1 ... c(n-1)(nValues-1)

* **Lookup Table**. The *tableName* field is a character string (without imbedded white space) used to identify the lookup table. This label is used by the VTK reader to extract a specific table.
Each entry in the lookup table is a rgba[4] (red-green-blue-alpha) array (alpha is opacity where alpha=0 is transparent). If the file format is ASCII, the lookup table values must be float values between (0,1). If the file format is BINARY, the stream of data must be four unsigned char values per table entry.

LOOKUP_TABLE tableName size

r0 g0 b0 a0

r1 g1 b1 a1

...

rsize-1 gsize-1 bsize-1 asize-1

* **Vectors**.

VECTORS dataName dataType

v0x v0y v0z

v1x v1y v1z

...

v(n-1)x v(n-1)y v(n-1)z

* **Normals**. Normals are assumed normalized |n| = 1.

NORMALS dataName dataType

n0x n0y n0z

n1x n1y n1z

...

n(n-1)x n(n-1)y n(n-1)z

* **Texture Coordinates**. Texture coordinates of 1, 2, and 3 dimensions are supported.

TEXTURE_COORDINATES dataName dim dataType

t00 t01 ... t0(dim-1)

t10 t11 ... t1(dim-1)

...

t(n-1)0 t(n-1)1 ... t(n-1)(dim-1)

* **Tensors**. Currently only real-valued, symmetric tensors are supported.

TENSORS dataName dataType

t000 t001 t002

t010 t011 t012

t020 t021 t022

t100 t101 t102

t110 t111 t112

t120 t121 t122

...

tn - 100 tn - 101 tn - 102

tn - 110 tn - 111 tn - 112

tn - 120 tn - 121 tn - 122

* **Field Data**. Field data is essentially an array of data arrays. Defining field data means giving a name to the field and specifying the number of arrays it contains. Then, for each array, the name of the array arrayName(i), the number of components of the array, numComponents, the number of tuples in the array, numTuples, and the data type, dataType, are defined.

FIELD dataName numArrays

arrayName0 numComponents numTuples dataType

f00 f01 ... f0(numComponents-1)

f10 f11 ... f1(numComponents-1)

...

f(numTuples-1)0 f(numTuples-1)1 ... f(numTuples-1)(numComponents-1)

arrayName1 numComponents numTuples dataType

f00 f01 ... f0(numComponents-1)

f10 f11 ... f1(numComponents-1)

...

f(numTuples-1)0 f(numTuples-1)1 ... f(numTuples-1)(numComponents-1)

...

arrayName(numArrays-1) numComponents numTuples dataType

f00 f01 ... f0(numComponents-1)

f10 f11 ... f1(numComponents-1)

...

f(numTuples-1)0 f(numTuples-1)1 ... f(numTuples-1)(numComponents-1)

### Legacy File Examples.
The first example is a cube represented by six polygonal faces. We define a single-component scalar, normals, and field data on the six faces. There are scalar data associated with the eight vertices. A lookup table of eight colors, associated with the point scalars, is also defined.

```
# vtk DataFile Version 2.0
Cube example
ASCII
DATASET POLYDATA
POINTS 8 float
0.0 0.0 0.0
1.0 0.0 0.0
1.0 1.0 0.0
0.0 1.0 0.0
0.0 0.0 1.0
1.0 0.0 1.0
1.0 1.0 1.0
0.0 1.0 1.0
POLYGONS 6 30
4 0 1 2 3
4 4 5 6 7
4 0 1 5 4
4 2 3 7 6
4 0 4 7 3
4 1 2 6 5
CELL_DATA 6
SCALARS cell_scalars int 1
LOOKUP_TABLE default
0
1
2
3
4
5
NORMALS cell_normals float
0 0 -1
0 0 1
0 -1 0
0 1 0
-1 0 0
1 0 0
FIELD FieldData 2
cellIds 1 6 int
0 1 2 3 4 5
faceAttributes 2 6 float
0.0 1.0 1.0 2.0 2.0 3.0 3.0 4.0 4.0 5.0 5.0 6.0
POINT_DATA 8
SCALARS sample_scalars float 1
LOOKUP_TABLE my_table
0.0
1.0
2.0
3.0
4.0
5.0
6.0
7.0
LOOKUP_TABLE my_table 8
0.0 0.0 0.0 1.0
1.0 0.0 0.0 1.0
0.0 1.0 0.0 1.0
1.0 1.0 0.0 1.0
0.0 0.0 1.0 1.0
1.0 0.0 1.0 1.0
0.0 1.0 1.0 1.0
1.0 1.0 1.0 1.0
```

The next example is a volume of dimension 3 by 4 by 6. Since no lookup table is defined, either the user must create one in VTK, or the default lookup table will be used.

```
# vtk DataFile Version 2.0
Volume example
ASCII
DATASET STRUCTURED_POINTS
DIMENSIONS 3 4 6
ASPECT_RATIO 1 1 1
ORIGIN 0 0 0
POINT_DATA 72
SCALARS volume_scalars char 1
LOOKUP_TABLE default
0 0 0 0 0 0 0 0 0 0 0 0
0 5 10 15 20 25 25 20 15 10 5 0
0 10 20 30 40 50 50 40 30 20 10 0
0 10 20 30 40 50 50 40 30 20 10 0
0 5 10 15 20 25 25 20 15 10 5 0
0 0 0 0 0 0 0 0 0 0 0 0
```

The third example is an unstructured grid containing twelve of the nineteen VTK cell types (see Figure 2 and Figure 3).
Figure 2 shows all 16 of the linear cell types and was generated with the [LinearCellDemo](../Cxx/GeometricObjects/LinearCellDemo).

Figure 2. - Linear cell types found in VTK. Use the include file ?vtkCellType?.h to manipulate cell types..

Figure 3 shows 16 of the non-linear cells and was generated with the [IsoparametricCellsDemo](../Cxx/GeometricObjects/IsoparametricCellsDemo).

Figure 3. - Non-linear cell types found in VTK.

The file contains scalar and vector data.
Figure 4 shows a presentation of this file generated by [ReadLegacyUnstructuredGrid](../Cxx/IO/ReadLegacyUnstructuredGrid).

Figure 4. - UnstructuredGrid example.

```
# vtk DataFile Version 2.0
Unstructured Grid Example
ASCII
DATASET UNSTRUCTURED_GRID

POINTS 27 float
0 0 0  1 0 0  2 0 0  0 1 0  1 1 0  2 1 0
0 0 1  1 0 1  2 0 1  0 1 1  1 1 1  2 1 1
0 1 2  1 1 2  2 1 2  0 1 3  1 1 3  2 1 3
0 1 4  1 1 4  2 1 4  0 1 5  1 1 5  2 1 5
0 1 6  1 1 6  2 1 6

CELLS 11 60
8 0 1 4 3 6 7 10 9
8 1 2 4 5 7 8 10 11
4 6 10 9 12
4 11 14 10 13
6 15 16 17 14 13 12
6 18 15 19 16 20 17
4 22 23 20 19
3 21 22 18
3 22 19 18
2 26 25
1 24

CELL_TYPES 11
12
11
10
8
7
6
9
5
4
3
1

POINT_DATA 27
SCALARS scalars float 1
LOOKUP_TABLE default
0.0 1.0 2.0 3.0 4.0 5.0
6.0 7.0 8.0 9.0 10.0 11.0
12.0 13.0 14.0 15.0 16.0 17.0
18.0 19.0 20.0 21.0 22.0 23.0
24.0 25.0 26.0

VECTORS vectors float
1 0 0  1 1 0  0 2 0  1 0 0  1 1 0  0 2 0
1 0 0  1 1 0  0 2 0  1 0 0  1 1 0  0 2 0
0 0 1  0 0 1  0 0 1  0 0 1  0 0 1  0 0 1
0 0 1  0 0 1  0 0 1  0 0 1  0 0 1  0 0 1
0 0 1  0 0 1  0 0 1

CELL_DATA 11
SCALARS scalars float 1
LOOKUP_TABLE CellColors
0.0 1.0 2.0 3.0 4.0 5.0
6.0 7.0 8.0 9.0 10.0

LOOKUP_TABLE CellColors 11
.4 .4 1 1
.4 1 .4 1
.4 1 1 1
1 .4 .4 1
1 .4 1 1
1 1 .4 1
1 1 1 1
1 .5 .5 1
.5 1 .5 1
.5 .5 .5 1
1 .5 .4 1

```

The fourth and final example is data represented as a field. You may also wish to see “Working With Field Data” on [page 249](https://www.kitware.com/products/books/VTKUsersGuide.pdf#page=263) to see how to manipulate this data. The data file shown below can be found in its entirety [here](https://raw.githubusercontent.com/Kitware/vtk-examples/gh-pages/src/Testing/Data/financial.vtk).
The example [FinanceFieldData](../Cxx/Modelling/FinanceFieldData) generated Figure 5.

Figure 5. - Visualizing financial field data.

```
# vtk DataFile Version 2.0
Financial data in vtk field format
ASCII
FIELD financialData 6
TIME_LATE 1 3188 float
29.14 0.00 0.00 11.71 0.00 0.00 0.00 0.00
...(more stuff — 3188 total values)...
MONTHLY_PAYMENT 1 3188 float
7.26 5.27 8.01 16.84 8.21 15.75 10.62 15.47
...(more stuff)...
UNPAID_PRINCIPLE 1 3188 float
430.70 380.88 516.22 1351.23 629.66 1181.97 888.91 1437.83
...(more stuff)...
LOAN_AMOUNT 1 3188 float
441.50 391.00 530.00 1400.00 650.00 1224.00 920.00 1496.00
...(more stuff)...
INTEREST_RATE 1 3188 float
13.875 13.875 13.750 11.250 11.875 12.875 10.625 10.500
...(more stuff)...
MONTHLY_INCOME 1 3188 unsigned_short
39 51 51 38 35 49 45 56
...(more stuff)...
```

In this example, a field is represented using six arrays. Each array has a single component and 3,188 tuples. Five of the six arrays are of type float, while the last array is of type unsigned_short. Additional examples are available in the data directory.

## XML File Formats

VTK provides another set of data formats using XML syntax. While these formats are much more complicated than the original VTK format described previously (see [Simple Legacy Formats](#simple-legacy-formats)), they support many more features. The major motivation for their development was to facilitate data streaming and parallel I/O. Some features of the format include support for compression, portable binary encoding, random access, big endian and little endian byte order, multiple file representation of piece data, and new file extensions for different VTK dataset types. XML provides many features as well, especially the ability to extend a file format with application specific tags.

There are two types of VTK XML data files: parallel and serial as described in the following.

* **Serial**. File types designed for reading and writing by applications of only a single process. All of the data are contained
within a single file.

* **Parallel**. File types designed for reading and writing by applications with multiple processes executing in parallel. The dataset is broken into pieces. Each process is assigned a piece or set of pieces to read or write. An individual piece is stored in a corresponding serial file type. The parallel file type does not actually contain any data, but instead describes structural information and then references other serial files containing the data for each piece.

In the XML format, VTK datasets are classified into one of two categories.

* **Structured**. The dataset is a topologically regular array of cells such as pixels and voxels (e.g., image data) or quadrilaterals and hexahedra (e.g., structured grid). Rectangular subsets of the data are described through extents. The structured dataset types are vtkImageData, vtkRectilinearGrid, and vtkStructuredGrid.

* **Unstructured**. The dataset forms a topologically irregular set of points and cells. Subsets of the data are describedusing pieces. The unstructured dataset types are vtkPolyData and vtkUnstructuredGrid.

By convention, each data type and file type is paired with a particular file extension. The types and corresponding extensions are

* ImageData (_.vti_) — Serial vtkImageData (structured).
* PolyData (_.vtp_) — Serial vtkPolyData (unstructured).
* RectilinearGrid (_.vtr_) — Serial vtkRectilinearGrid (structured).
* StructuredGrid (_.vts_) — Serial vtkStructuredGrid (structured).
* UnstructuredGrid (_.vtu_) — Serial vtkUnstructuredGrid (unstructured).
* PImageData (_.pvti_) — Parallel vtkImageData (structured).
* PPolyData (_.pvtp_) — Parallel vtkPolyData (unstructured).
* PRectilinearGrid (_.pvtr_) — Parallel vtkRectilinearGrid (structured).
* PStructuredGrid (_.pvts_) — Parallel vtkStructuredGrid (structured).
* PUnstructuredGrid (_.pvtu_) — Parallel vtkUnstructuredGrid (unstructured).

All of the VTK XML file types are valid XML documents.

**Note:**

There is one case in which the file is not a valid XML document. When the AppendedData section is not encoded as base64, raw binary data is present that may violate the XML specification. This is not default behavior, and must be explicitly enabled by the user.

The document-level element is _VTKFile_:

```xml
<VTKFile type=”ImageData” version=”0.1” byte_order=”LittleEndian”>
...
</VTKFile>
```

The attributes of the element are:

       _type_ — The type of the file (the bulleted items in the previous list)..

       _version_ — File version number in “major.minor” format.

      _byte_order_ — Machine byte order in which data are stored. This is either “BigEndian” or “LittleEndian”.

      _compressor_ — Some data in the file may be compressed. This specifies the subclass of vtkDataCompressor that was used to compress the data.

Nested inside the _VTKFile_ element is an element whose name corresponds to the type of the data format (i.e., the _type_ attribute). This element describes the topology the dataset, and is different for the serial and parallel formats, which are described as follows.

### **Serial XML File Formats.**
The _VTKFile_ element contains one element whose name corresponds to the type of dataset the file describes. We refer to this as the dataset element, which is one of _ImageData_, _RectilinearGrid_, _StructuredGrid_, _PolyData_, or _UnstructuredGrid_. The dataset element contains one or more _Piece_ elements, each describing a portion of the dataset. Together, the dataset element and _Piece_ elements specify the entire dataset.

Each piece of a dataset must specify the geometry (points and cells) of that piece along with the data associated with each point or cell. Geometry is specified differently for each dataset type, but every piece of every dataset contains
_PointData_ and _CellData_ elements specifying the data for each point and cell in the piece.

The general structure for each serial dataset format is as follows:

#### **ImageData**
Each ImageData piece specifies its extent within the dataset’s whole extent. The points and cells are described implicitly by the extent, origin, and spacing. Note that the origin and spacing are constant across all pieces, so they are specified as attributes of the _ImageData_ XML element as follows.

```xml
<VTKFile type=”ImageData” ...>
  <ImageData WholeExtent=”x1 x2 y1 y2 z1 z2”
   Origin=”x0 y0 z0” Spacing=”dx dy dz”>
   <Piece Extent=”x1 x2 y1 y2 z1 z2”>
      <PointData>...</PointData>
      <CellData>...</CellData>
   </Piece>
   </ImageData>
</VTKFile>
```

#### **RectilinearGrid**
Each RectilinearGrid piece specifies its extent within the dataset’s whole extent. The points are described by the _Coordinates_ element. The cells are described implicitly by the extent.

```xml
<VTKFile type=”RectilinearGrid” ...>
  <RectilinearGrid WholeExtent=”x1 x2 y1 y2 z1 z2”>
    <Piece Extent=”x1 x2 y1 y2 z1 z2”>
    <PointData>...</PointData>
    <CellData>...</CellData>
    <Coordinates>...</Coordinates>
    </Piece>
  </RectilinearGrid>
</VTKFile>
```

#### **StructuredGrid**
Each StructuredGrid piece specifies its extent within the dataset’s whole extent. The points are described explicitly by the Points element. The cells are described implicitly by the extent.

```xml
<VTKFile type=”StructuredGrid” ...>
  <StructuredGrid WholeExtent=”x1 x2 y1 y2 z1 z2”>
    <Piece Extent=”x1 x2 y1 y2 z1 z2”>
    <PointData>...</PointData>
    <CellData>...</CellData>
    <Points>...</Points>
    </Piece>
  </StructuredGrid>
</VTKFile>
```

#### **PolyData**
Each PolyData piece specifies a set of points and cells independently from the other pieces. The points are described explicitly by the Points element. The cells are described explicitly by the Verts, Lines, Strips, and Polys elements.

```xml
<VTKFile type=”PolyData” ...>
  <PolyData>
    <Piece NumberOfPoints=”#” NumberOfVerts=”#” NumberOfLines=”#”
      NumberOfStrips=”#” NumberOfPolys=”#”>
    <PointData>...</PointData>
    <CellData>...</CellData>
    <Points>...</Points>
    <Verts>...</Verts>
    <Lines>...</Lines>
    <Strips>...</Strips>
    <Polys>...</Polys>
   </Piece>
  </PolyData>
</VTKFile>
```

#### **UnstructuredGrid**
Each UnstructuredGrid piece specifies a set of points and cells independently from the other pieces. The points are described explicitly by the Points element. The cells are described explicitly by the Cells element.

```xml
<VTKFile type=”UnstructuredGrid” ...>
  <UnstructuredGrid>
    <Piece NumberOfPoints=”#” NumberOfCells=”#”>
    <PointData>...</PointData>
    <CellData>...</CellData>
    <Points>...</Points>
    <Cells>...</Cells>
    </Piece>
  </UnstructuredGrid>
</VTKFile>
```

Every dataset describes the data associated with its points and cells with PointData and CellData XML elements as follows:
```xml
  <PointData Scalars=”Temperature” Vectors=”Velocity”>
    <DataArray Name=”Velocity” .../>
    <DataArray Name=”Temperature” .../>
    <DataArray Name=”Pressure” .../>
  </PointData>
```

VTK allows an arbitrary number of data arrays to be associated with the points and cells of a dataset. Each data array is described by a DataArray element which, among other things, gives each array a name. The following attributes of PointData and CellData are used to specify the active arrays by name:

      _Scalars_ — The name of the active scalars array, if any.

      _Vectors_ — The name of the active vectors array, if any.

      _Normals_ — The name of the active normals array, if any.

      _Tensors_ — The name of the active tensors array, if any.

      _TCoords_ — The name of the active texture coordinates array, if any.

Some datasets describe their points and cells using different combinations of the following common elements:

* **Points** — The _Points_ element explicitly defines coordinates for each point individually. It contains one _DataArray_ element describing an array with three components per value, each specifying the coordinates of one point.

```xml
    <Points>
      <DataArray NumberOfComponents=”3” .../>
    </Points>
```

* **Coordinates** — The _Coordinates_ element defines point coordinates for an extent by specifying the ordinate along each axis for each integer value in the extent’s range. It contains three _DataArray_ elements describing the ordinates along the x-y-z axes, respectively.

```xml
    <Coordinates>
      <DataArray .../>
      <DataArray .../>
      <DataArray .../>
    </Coordinates>
```

* **Verts**, **Lines**, **Strips**, and **Polys** — The _Verts_, _Lines_, _Strips_, and _Polys_ elements define cells explicitly by specifying point connectivity. Cell types are implicitly known by the type of element in which they are specified. Each element contains two _DataArray_ elements. The first array specifies the point connectivity. All the cells’ point lists are concatenated together. The second array specifies the offset into the connectivity array for the end of each cell.

```xml
    <Verts>
      <DataArray type=”Int32” Name=”connectivity” .../>
      <DataArray type=”Int32” Name=”offsets” .../>
    </Verts>
```

* **Cells** — The _Cells_ element defines cells explicitly by specifying point connectivity and cell types. It contains three _DataArray_ elements. The first array specifies the point connectivity. All the cells’ point lists are concatenated together. The second array specifies the offset into the connectivity array for the end of each cell. The third array specifies the type of each cell. (Note: the cell types are defined in Figure 2 and Figure 3.)

```xml
    <Cells>
      <DataArray type=”Int32” Name=”connectivity” .../>
      <DataArray type=”Int32” Name=”offsets” .../>
      <DataArray type=”UInt8” Name=”types” .../>
    </Cells>
```

All of the data and geometry specifications use _DataArray_ elements to describe their actual content as follows:

* **DataArray** — The _DataArray_ element stores a sequence of values of one type. There may be one or more components per value.

```xml
    <DataArray type=”Float32” Name=”vectors” NumberOfComponents=”3”
               format=”appended” offset=”0”/>
    <DataArray type=”Float32” Name=”scalars” format=”binary”>
               bAAAAAAAAAAAAIA/AAAAQAAAQEAAAIBA... </DataArray>
    <DataArray type=”Int32” Name=”offsets” format=”ascii”>
               10 20 30 ... </DataArray>
```

The attributes of the _DataArray_ elements are described as follows:
       type — The data type of a single component of the array. This is one of Int8, UInt8, Int16, UInt16, Int32, UInt32, Int64, UInt64, Float32, Float64. Note: the 64-bit integer types are only supported if VTK_USE_64BIT_IDS is on (a CMake variable—see “CMake” on [page 10](https://www.kitware.com/products/books/VTKUsersGuide.pdf#page=24)) or the platform is 64-bit.

      Name — The name of the array. This is usually a brief description of the data stored in the array.

      NumberOfComponents — The number of components per value in the array.

      format — The means by which the data values themselves are stored in the file. This is “ascii”, “binary”, or “appended”.

      offset — If the format attribute is “appended”, this specifies the offset from the beginning of the appended data section to the beginning of this array’s data.

The _format_ attribute chooses among the three ways in which data values can be stored:

      _format=”ascii”_ — The data are listed in ASCII directly inside the _DataArray_ element. Whitespace is used for separation.

      _format=”binary”_ — The data are encoded in base64 and listed contiguously inside the _DataArray_ element. Data may also be compressed before encoding in base64. The byte-order of the data matches that specified by the byte_order attribute of the _VTKFile_ element.

      format=”appended” — The data are stored in the appended data section. Since many _DataArray_ elements may store their data in this section, the offset attribute is used to specify where each DataArray’s data begins. This format is the default used by VTK’s writers.

The appended data section is stored in an _AppendedData_ element that is nested inside _VTKFile_ after the dataset element:

```xml
  <VTKFile ...>
    ...
    <AppendedData encoding=”base64”>
                  _QMwEAAAAAAAAA...
    </AppendedData>
  </VTKFile>
```

The appended data section begins with the first character after the underscore inside the _AppendedData_ element. The underscore is not part of the data, but is always present. Data in this section is always in binary form, but can be compressed and/or base64 encoded. The byte-order of the data matches that specified by the byte_order attribute of the _VTKFile_ element. Each _DataArray_’s data are stored contiguously and appended immediately after the previous _DataArray_’s data without a seperator. The _DataArray_’s _offset_ attribute indicates the file position offset from the first character after the underscore to the beginning its data.

### **Parallel File Formats.**
The parallel file formats do not actually store any data in the file. Instead, the data are broken into pieces, each of which is stored in a serial file of the same dataset type.

The _VTKFile_ element contains one element whose name corresponds to the type of dataset the file describes, but with a “P” prefix. We refer to this as the parallel dataset element, which is one of _PImageData_, _PRectilinearGrid_, _PStructuredGrid_, _PPolyData_, or _PUnstructuredGrid_.

The parallel dataset element and those nested inside specify the types of the data arrays used to store points, pointn data, and cell data (the type of arrays used to store cells is fixed by VTK). The element does not actually contain any data, but instead includes a list of _Piece_ elements that specify the source from which to read each piece. Individual pieces are stored in the corresponding serial file format. The parallel file needs to specify the type and structural information so that readers can update pipeline information without actually reading the pieces’ files.

The general structure for each parallel dataset format is as follows:

#### **PImageData**
The _PImageData_ element specifies the whole extent of the dataset and the number of ghost-levels by which the extents in the individual pieces overlap. The Origin and Spacing attributes implicitly specify the point locations. Each _Piece_ element describes the extent of one piece and the file in which it is stored.

```xml
  <VTKFile type=”PImageData” ...>
    <PImageData WholeExtent=”x1 x2 y1 y2 z1 z2”
                GhostLevel=”#” Origin=”x0 y0 z0” Spacing=”dx dy dz”>
      <PPointData>...</PPointData>
      <PCellData>...</PCellData>
      <Piece Extent=”x1 x2 y1 y2 z1 z2” Source=”imageData0.vti”/>
      ...
   </PImageData>
  </VTKFile>
```

#### **PRectilinearGrid**
The _PRectilinearGrid_ element specifies the whole extent of the dataset and the number of ghost-levels by which the extents in the individual pieces overlap. The _PCoordinates_ element describes the type of arrays used to specify the point ordinates along each axis, but does not actually contain the data. Each _Piece_ element describes the extent of one piece and the file in which it is stored.

```xml
  <VTKFile type=”PRectilinearGrid” ...>
    <PRectilinearGrid WholeExtent=”x1 x2 y1 y2 z1 z2”
                      GhostLevel=”#”>
      <PPointData>...</PPointData>
      <PCellData>...</PCellData>
      <PCoordinates>...</PCoordinates>
      <Piece Extent=”x1 x2 y1 y2 z1 z2”
             Source=”rectilinearGrid0.vtr”/>
      ...
    </PRectilinearGrid>
  </VTKFile>
```

#### **PStructuredGrid**
The _PStructuredGrid_ element specifies the whole extent of the dataset and the number of ghost-levels by which the extents in the individual pieces overlap. The _PPoints_ element describes the type of array used to specify the point locations, but does not actually contain the data. Each _Piece_ element describes the extent of one piece and the file in which it is stored.

```xml
  <VTKFile type=”PStructuredGrid” ...>
    <PStructuredGrid WholeExtent=”x1 x2 y1 y2 z1 z2”
                     GhostLevel=”#”>
      <PPointData>...</PPointData>
      <PCellData>...</PCellData>
      <PPoints>...</PPoints>
      <Piece Extent=”x1 x2 y1 y2 z1 z2”
             Source=”structuredGrid0.vts”/>
      ...
    </PStructuredGrid>
  </VTKFile>
```

#### **PPolyData**
The _PPolyData_ element specifies the number of ghost-levels by which the individual pieces overlap. The _PPoints_ element describes the type of array used to specify the point locations, but does not actually contain the data. Each _Piece_ element specifies the file in which the piece is stored.

```xml
  <VTKFile type=”PPolyData” ...>
    <PPolyData GhostLevel=”#”>
      <PPointData>...</PPointData>
      <PCellData>...</PCellData>
      <PPoints>...</PPoints>
      <Piece Source=”polyData0.vtp”/>
      ...
    </PPolyData>
  </VTKFile>
```

#### **PUnstructuredGrid**
The _PUnstructuredGrid_ element specifies the number of ghost-levels by which the individual pieces overlap. The _PPoints_ element describes the type of array used to specify the point locations, but does not actually contain the data. Each _Piece_ element specifies the file in which the piece is stored.

```xml
  <VTKFile type=”PUnstructuredGrid” ...>
    <PUnstructuredGrid GhostLevel=”0”>
      <PPointData>...</PPointData>
      <PCellData>...</PCellData>
      <PPoints>...</PPoints>
      <Piece Source=”unstructuredGrid0.vtu”/>
      ...
    </PUnstructuredGrid>
  </VTKFile>
```

Every dataset uses _PPointData_ and _PCellData_ elements to describe the types of data arrays associated with its points and cells.

* **PPointData** and **PCellData** — These elements simply mirror the _PointData_ and _CellData_ elements from the serial file formats. They contain _PDataArray_ elements describing the data arrays, but without any actual data.

```xml
    <PPointData Scalars=”Temperature” Vectors=”Velocity”>
      <PDataArray Name=”Velocity” .../>
      <PDataArray Name=”Temperature” .../>
      <PDataArray Name=”Pressure” .../>
   </PPointData>
```

For datasets that need specification of points, the following elements mirror their counterparts from the serial file format:

* **PPoints** — The _PPoints_ element contains one _PDataArray_ element describing an array with three components. The data array does not actually contain any data.

```xml
    <PPoints>
      <PDataArray NumberOfComponents=”3” .../>
    </PPoints>
```

* **PCoordinates** — The _PCoordinates_ element contains three _PDataArray_ elements describing the arrays used to specify ordinates along each axis. The data arrays do not actually contain any data.

```xml
    <PCoordinates>
      <PDataArray .../>
      <PDataArray .../>
      <PDataArray .../>
   </PCoordinates>
```

All of the data and geometry specifications use _PDataArray_ elements to describe the data array types:

* **PDataArray** — The _PDataArray_ element specifies the type, Name, and optionally the NumberOfComponents attributes from the _DataArray_ element. It does not contain the actual data. This can be used by readers to create the data array in their output without needing to read any real data, which is necessary for efficient pipeline updates in some cases.

```xml
    <PDataArray type=”Float32” Name=”vectors” NumberOfComponents=”3”/>
```

### XML File Example.
The following is a complete example specifying a vtkPolyData representing a cube with some scalar data on its points and faces. [1](#VTKUsersGuide)

```xml
  <?xml version="1.0"?>
  <VTKFile type="PPolyData" version="0.1" byte_order="LittleEndian">
    <PPolyData GhostLevel="0">
      <PPointData Scalars="my_scalars">
        <PDataArray type="Float32" Name="my_scalars"/>
      </PPointData>
        <PCellData Scalars="cell_scalars" Normals="cell_normals">
          <PDataArray type="Int32" Name="cell_scalars"/>
           <PDataArray type="Float32" Name="cell_normals" NumberOfComponents="3"/>
        </PCellData>
        <PPoints>
          <PDataArray type="Float32" NumberOfComponents="3"/>
        </PPoints>
        <Piece Source="polyEx0.vtp"/>
    </PPolyData>
  </VTKFile>

  <?xml version="1.0"?>
    <VTKFile type="PolyData" version="0.1" byte_order="LittleEndian">
      <PolyData>
        <Piece NumberOfPoints="8" NumberOfVerts="0" NumberOfLines="0"
               NumberOfStrips="0" NumberOfPolys="6">
        <Points>
          <DataArray type="Float32" NumberOfComponents="3" format="ascii">
            0 0 0 1 0 0 1 1 0 0 1 0 0 0 1 1 0 1 1 1 1 0 1 1
          </DataArray>
        </Points>
        <PointData Scalars="my_scalars">
          <DataArray type="Float32" Name="my_scalars" format="ascii">
            0 1 2 3 4 5 6 7
         </DataArray>
        </PointData>
        <CellData Scalars="cell_scalars" Normals="cell_normals">
          <DataArray type="Int32" Name="cell_scalars" format="ascii">
           0 1 2 3 4 5
          </DataArray>
          <DataArray type="Float32" Name="cell_normals"
                     NumberOfComponents="3" format="ascii">
            0 0 -1 0 0 1 0 -1 0 0 1 0 -1 0 0 1 0 0
          </DataArray>
        </CellData>
        <Polys>
          <DataArray type="Int32" Name="connectivity" format="ascii">
             0 1 2 3 4 5 6 7 0 1 5 4 2 3 7 6 0 4 7 3 1 2 6 5
          </DataArray>
          <DataArray type="Int32" Name="offsets" format="ascii">
             4 8 12 16 20 24
          </DataArray>
        </Polys>
      </Piece>
    </PolyData>
   </VTKFile>
```

## HDF File Formats
We use the same extension for serial and parallel formats and for all
types of datasets. We use HDF standard file extensions such as hdf,
hdf5, h5 or he5.

VTK HDF files start with a group called `VTKHDF` with two attributes:
`Version`, an array of two integers and `Type`, a string showing the
VTK dataset type stored in the file. Additional attributes can follow
depending on the dataset type. Currently, `Version`
is the array [1, 0] and `Type` can be `ImageData`, `UnstructuredGrid`
or `OverlappingAMR`.

The data type for each HDF dataset is part of the dataset and it is
determined at write time. The reader matches the type of the dataset
with a `H5T_NATIVE_` type and creates the VTK array of that
type. Consequently, the type at writing might be different than the
type at reading even on the same machine because for instance `long`
can be the same type as `long long` or `int` can be the same as `long`
on certain platforms. Also, `vtkIdType` is read as the C++ type it
represents (`long` or `long long`). Endianness conversions are done
automatically.

In the following diagrams showing the HDF file structure for VTK
datasets, the rounded blue rectangles are HDF groups and the gray
rectangles are HDF datasets. Each rectangle shows the name of the
group or dataset in bold font and the attributes underneath with
regular font.

### Image data
The format for image data is detailed in the Figure 6 where the `Type`
attribute of the `VTKHDF` group is `ImageData`.  An
ImageData (regular grid) is not split into partitions for parallel
processing. We rely on the writer to chunk the data to optimize
reading for a certain number of MPI ranks. Attribute data is stored in
a PointData or CellData array using hyper slabs. `WholeExtent`,
`Origin`, `Spacing` and `Direction` attributes have the same meaning
as the corresponding attributes for the vtkImageData dataset. `Scalars`,
`Vectors`, ... string attributes for the `PointData` and `CellData`
groups specify the active attributes in the dataset.

Figure 6. - Image data VTKHDF File Format

### Unstructured grid
The format for unstructured grid is shown in Figure 7. In this case
the `Type` attribute of the `VTKHDF` group is `UnstructuredGrid`.
The unstructured grid is split into partitions, with a partition for
each MPI rank. This is reflected in the HDF5 file structure. Each HDF
dataset is obtained by concatenating the data for each partition. The
offset O(i) where we store the data for partition i is computed using:

O(i) = S(0) + ... + S(i-1), i > 1 with O(0) = 0.

where S(i) is the size of partition i.

We describe the split into partitions using HDF5 datasets
`NumberOfConnectivityIds`, `NumberOfPoints` and `NumberOfCells`. Let n
be the number of partitions which usually correspond to the number of
the MPI ranks. `NumberOfConnectivityIds` has size n where
NumberOfConnectivityIds[i] represents the size of the `Connectivity`
array for partition i. `NumberOfPoints` and `NumberOfCells` are arrays
of size n, where NumberOfPoints[i] and NumberOfCells[i] are the number
of points and number of cells for partition i. The `Points` array
contains the points of the VTK dataset. `Offsets` is an array of size
∑ S(i), where S(i) is the size of partition i, indicating the index in
the `Connectivity` array where each cell's points start.
`Connectivity` stores the lists of point ids for each cell, and
`Types` contain the cell information stored as described in
vtkCellArray documentation. Data for each partition is appended in a
HDF dataset for `Points`, `Connectivity`, `Offsets`, `Types`,
`PointData` and `CellData`. We can compute the size of partition i
using the following formulas:

|   | Size of partition i |
|:--|:--|
| Points  | NumberOfPoints[i] * 3 * sizeof(Points[0][0])  |
| Connectivity  | NumberOfConnectivityIds[i] * sizeof(Connectivity[0]) |
| Offsets  | (NumberOfCells[i] + 1) * sizeof(Offsets[0]) |
| Types  | NumberOfCells[i] * sizeof(Types[i]) |
| PointData  | NumberOfPoints[i] * sizeof(point_array_k[0]) |
| CellData | NumberOfCells[i] * sizeof(cell_array_k[0]) |

Figure 7. - Unstructured grid VTKHDF File Format

To read the data for its rank a node reads the information about all
partitions, compute the correct offset and then read data from that
offset.

### Overlapping AMR
The format for Overlapping AMR is shown in Figure 8. In this case
the `Type` attribute of the `VTKHDF` group is `OverlappingAMR`.
The mandatory `Origin` parameter is a double triplet that defines
the global origin of the AMR data set.
Each level in an overlapping AMR file format (and data structure)
consists of a list of uniform grids with the same spacing from the
Spacing attribute. The Spacing attribute is a list a three doubles
describing the spacing in each x/y/z direction.
The AMRBox dataset contains the bounding box
for each of these grids. Each line in this dataset is expected to contain
6 integers describing the the indexed bounds in i, j, k space
(imin/imax/jmin/jmax/kmin/kmax).
The points and cell arrays for these grids are
stored serialized in one dimension and stored in a dataset in the
PointData or CellData group.

Figure 8. - Overlapping AMR VTKHDF File Format

### Limitations

This specification and the reader available in VTK currently only
supports ImageData, UnstructuredGrid and Overlapping AMR. Other dataset
types may be added later depending on interest and funding.

### Examples

We present three examples of VTK HDF files, shown using h5dump -A one
image file, one unstructured grid and one overlapping AMR.
These files can be examined in the VTK source code, by building VTK
and enabling testing (`VTK_BUILD_TESTING`). The two files are in the build directory
ExternalData at `Testing/Data/mandelbrot-vti.hdf` for the ImageData
and at `Testing/Data/can-pvtu.hdf` for the partitioned UnstructuredGrid
and `Testing/Data/amr_gaussian_pulse.hdf` for the overlapping AMR.

#### ImageData

The image data file is a wavelet source produced in ParaView. Note
that we don't partition image data, so the same format is used for
serial and parallel processing.

```
HDF5 "./ExternalData/Testing/Data/mandelbrot-vti.hdf" {
GROUP "/" {
   GROUP "VTKHDF" {
      ATTRIBUTE "Direction" {
         DATATYPE  H5T_IEEE_F64LE
         DATASPACE  SIMPLE { ( 9 ) / ( 9 ) }
         DATA {
         (0): 1, 0, 0, 0, 1, 0, 0, 0, 1
         }
      }
      ATTRIBUTE "Origin" {
         DATATYPE  H5T_IEEE_F64LE
         DATASPACE  SIMPLE { ( 3 ) / ( 3 ) }
         DATA {
         (0): -1.75, -1.25, 0
         }
      }
      ATTRIBUTE "Spacing" {
         DATATYPE  H5T_IEEE_F64LE
         DATASPACE  SIMPLE { ( 3 ) / ( 3 ) }
         DATA {
         (0): 0.131579, 0.125, 0.0952381
         }
      }
      ATTRIBUTE "Type" {
         DATATYPE  H5T_STRING {
            STRSIZE 9;
            STRPAD H5T_STR_NULLPAD;
            CSET H5T_CSET_ASCII;
            CTYPE H5T_C_S1;
         }
         DATASPACE  SCALAR
         DATA {
         (0): "ImageData"
         }
      }
      ATTRIBUTE "Version" {
         DATATYPE  H5T_STD_I64LE
         DATASPACE  SIMPLE { ( 2 ) / ( 2 ) }
         DATA {
         (0): 1, 0
         }
      }
      ATTRIBUTE "WholeExtent" {
         DATATYPE  H5T_STD_I64LE
         DATASPACE  SIMPLE { ( 6 ) / ( 6 ) }
         DATA {
         (0): 0, 19, 0, 20, 0, 21
         }
      }
      GROUP "PointData" {
         ATTRIBUTE "Scalars" {
            DATATYPE  H5T_STRING {
               STRSIZE 18;
               STRPAD H5T_STR_NULLPAD;
               CSET H5T_CSET_ASCII;
               CTYPE H5T_C_S1;
            }
            DATASPACE  SCALAR
            DATA {
            (0): "IterationsGradient"
            }
         }
         DATASET "Iterations" {
            DATATYPE  H5T_IEEE_F32LE
            DATASPACE  SIMPLE { ( 22, 21, 20 ) / ( 22, 21, 20 ) }
         }
         DATASET "IterationsGradient" {
            DATATYPE  H5T_IEEE_F64LE
            DATASPACE  SIMPLE { ( 22, 21, 20, 3 ) / ( 22, 21, 20, 3 ) }
         }
         DATASET "Iterations_double" {
            DATATYPE  H5T_IEEE_F64LE
            DATASPACE  SIMPLE { ( 22, 21, 20 ) / ( 22, 21, 20 ) }
         }
         DATASET "point_index_llong" {
            DATATYPE  H5T_STD_I64LE
            DATASPACE  SIMPLE { ( 22, 21, 20 ) / ( 22, 21, 20 ) }
         }
         DATASET "xextent_int" {
            DATATYPE  H5T_STD_I32LE
            DATASPACE  SIMPLE { ( 22, 21, 20 ) / ( 22, 21, 20 ) }
         }
         DATASET "xextent_long" {
            DATATYPE  H5T_STD_I64LE
            DATASPACE  SIMPLE { ( 22, 21, 20 ) / ( 22, 21, 20 ) }
         }
         DATASET "xextent_uint" {
            DATATYPE  H5T_STD_U32LE
            DATASPACE  SIMPLE { ( 22, 21, 20 ) / ( 22, 21, 20 ) }
         }
         DATASET "xextent_ulong" {
            DATATYPE  H5T_STD_U64LE
            DATASPACE  SIMPLE { ( 22, 21, 20 ) / ( 22, 21, 20 ) }
         }
      }
   }
}
}
```

#### UnstructuredGrid

The unstructured grid is the can example (only the can, not the brick) from ParaView, partitioned in three:

```
HDF5 "./ExternalData/Testing/Data/can-pvtu.hdf" {
GROUP "/" {
   GROUP "VTKHDF" {
      ATTRIBUTE "Type" {
         DATATYPE  H5T_STRING {
            STRSIZE 16;
            STRPAD H5T_STR_NULLPAD;
            CSET H5T_CSET_ASCII;
            CTYPE H5T_C_S1;
         }
         DATASPACE  SCALAR
         DATA {
         (0): "UnstructuredGrid"
         }
      }
      ATTRIBUTE "Version" {
         DATATYPE  H5T_STD_I64LE
         DATASPACE  SIMPLE { ( 2 ) / ( 2 ) }
         DATA {
         (0): 1, 0
         }
      }
      GROUP "CellData" {
         DATASET "EQPS" {
            DATATYPE  H5T_IEEE_F64LE
            DATASPACE  SIMPLE { ( 5480 ) / ( H5S_UNLIMITED ) }
         }
         DATASET "vtkGhostType" {
            DATATYPE  H5T_STD_U8LE
            DATASPACE  SIMPLE { ( 5480 ) / ( H5S_UNLIMITED ) }
         }
         DATASET "vtkOriginalCellIds" {
            DATATYPE  H5T_STD_I64LE
            DATASPACE  SIMPLE { ( 5480 ) / ( H5S_UNLIMITED ) }
         }
      }
      DATASET "Connectivity" {
         DATATYPE  H5T_STD_I64LE
         DATASPACE  SIMPLE { ( 43840 ) / ( H5S_UNLIMITED ) }
      }
      GROUP "FieldData" {
         DATASET "ElementBlockIds" {
            DATATYPE  H5T_STD_I32LE
            DATASPACE  SIMPLE { ( 1 ) / ( 1 ) }
         }
         DATASET "Info_Records" {
            DATATYPE  H5T_STD_I8LE
            DATASPACE  SIMPLE { ( 4, 81 ) / ( 4, 81 ) }
         }
         DATASET "KE" {
            DATATYPE  H5T_IEEE_F64LE
            DATASPACE  SIMPLE { ( 44 ) / ( 44 ) }
         }
         DATASET "NSTEPS" {
            DATATYPE  H5T_IEEE_F64LE
            DATASPACE  SIMPLE { ( 44 ) / ( 44 ) }
         }
         DATASET "QA_Records" {
            DATATYPE  H5T_STD_I8LE
            DATASPACE  SIMPLE { ( 24, 33 ) / ( 24, 33 ) }
         }
         DATASET "TMSTEP" {
            DATATYPE  H5T_IEEE_F64LE
            DATASPACE  SIMPLE { ( 44 ) / ( 44 ) }
         }
         DATASET "TimeValue" {
            DATATYPE  H5T_IEEE_F64LE
            DATASPACE  SIMPLE { ( 1 ) / ( 1 ) }
         }
         DATASET "Title" {
            DATATYPE  H5T_STRING {
               STRSIZE H5T_VARIABLE;
               STRPAD H5T_STR_NULLTERM;
               CSET H5T_CSET_ASCII;
               CTYPE H5T_C_S1;
            }
            DATASPACE  SIMPLE { ( 1 ) / ( 1 ) }
         }
         DATASET "XMOM" {
            DATATYPE  H5T_IEEE_F64LE
            DATASPACE  SIMPLE { ( 44 ) / ( 44 ) }
         }
         DATASET "YMOM" {
            DATATYPE  H5T_IEEE_F64LE
            DATASPACE  SIMPLE { ( 44 ) / ( 44 ) }
         }
         DATASET "ZMOM" {
            DATATYPE  H5T_IEEE_F64LE
            DATASPACE  SIMPLE { ( 44 ) / ( 44 ) }
         }
      }
      DATASET "NumberOfCells" {
         DATATYPE  H5T_STD_I64LE
         DATASPACE  SIMPLE { ( 3 ) / ( 3 ) }
      }
      DATASET "NumberOfConnectivityIds" {
         DATATYPE  H5T_STD_I64LE
         DATASPACE  SIMPLE { ( 3 ) / ( 3 ) }
      }
      DATASET "NumberOfPoints" {
         DATATYPE  H5T_STD_I64LE
         DATASPACE  SIMPLE { ( 3 ) / ( 3 ) }
      }
      DATASET "Offsets" {
         DATATYPE  H5T_STD_I64LE
         DATASPACE  SIMPLE { ( 5483 ) / ( H5S_UNLIMITED ) }
      }
      GROUP "PointData" {
         DATASET "ACCL" {
            DATATYPE  H5T_IEEE_F64LE
            DATASPACE  SIMPLE { ( 8076, 3 ) / ( H5S_UNLIMITED, 3 ) }
         }
         DATASET "DISPL" {
            DATATYPE  H5T_IEEE_F64LE
            DATASPACE  SIMPLE { ( 8076, 3 ) / ( H5S_UNLIMITED, 3 ) }
         }
         DATASET "GlobalNodeId" {
            DATATYPE  H5T_STD_I64LE
            DATASPACE  SIMPLE { ( 8076 ) / ( H5S_UNLIMITED ) }
         }
         DATASET "PedigreeNodeId" {
            DATATYPE  H5T_STD_I64LE
            DATASPACE  SIMPLE { ( 8076 ) / ( H5S_UNLIMITED ) }
         }
         DATASET "VEL" {
            DATATYPE  H5T_IEEE_F64LE
            DATASPACE  SIMPLE { ( 8076, 3 ) / ( H5S_UNLIMITED, 3 ) }
         }
         DATASET "vtkGhostType" {
            DATATYPE  H5T_STD_U8LE
            DATASPACE  SIMPLE { ( 8076 ) / ( H5S_UNLIMITED ) }
         }
      }
      DATASET "Points" {
         DATATYPE  H5T_IEEE_F64LE
         DATASPACE  SIMPLE { ( 8076, 3 ) / ( H5S_UNLIMITED, 3 ) }
      }
      DATASET "Types" {
         DATATYPE  H5T_STD_U8LE
         DATASPACE  SIMPLE { ( 5480 ) / ( H5S_UNLIMITED ) }
      }
   }
}
}
```

#### Overlapping AMR

The Overlapping AMR data file is an AMR Guaussian Pulse source with two levels
(0 and 1), describing one Point Data, several Cell Data and a Field Data. Actual
`Data` are not displayed for readibility.

```
GROUP "/" {
   GROUP "VTKHDF" {
      ATTRIBUTE "Origin" {
         DATATYPE  H5T_IEEE_F64LE
         DATASPACE  SIMPLE { ( 3 ) / ( 3 ) }
         DATA {
         (0): -2, -2, 0
         }
      }
      ATTRIBUTE "Type" {
         DATATYPE  H5T_STRING {
            STRSIZE 14;
            STRPAD H5T_STR_NULLPAD;
            CSET H5T_CSET_ASCII;
            CTYPE H5T_C_S1;
         }
         DATASPACE  SCALAR
         DATA {
         (0): "OverlappingAMR"
         }
      }
      ATTRIBUTE "Version" {
         DATATYPE  H5T_STD_I64LE
         DATASPACE  SIMPLE { ( 2 ) / ( 2 ) }
         DATA {
         (0): 1, 0
         }
      }
      GROUP "Level0" {
         ATTRIBUTE "Spacing" {
            DATATYPE  H5T_IEEE_F64LE
            DATASPACE  SIMPLE { ( 3 ) / ( 3 ) }
            DATA {
            (0): 0.5, 0.5, 0.5
            }
         }
         DATASET "AMRBox" {
            DATATYPE  H5T_STD_I32LE
            DATASPACE  SIMPLE { ( 1, 6 ) / ( 1, 6 ) }
            DATA {
            (0,0): 0, 4, 0, 4, 0, 4
            }
         }
         GROUP "CellData" {
            DATASET "Centroid" {
               DATATYPE  H5T_IEEE_F64LE
               DATASPACE  SIMPLE { ( 125, 3 ) / ( 125, 3 ) }
            }
            DATASET "Gaussian-Pulse" {
               DATATYPE  H5T_IEEE_F64LE
               DATASPACE  SIMPLE { ( 125 ) / ( 125 ) }
            }
            DATASET "vtkGhostType" {
               DATATYPE  H5T_STD_U8LE
               DATASPACE  SIMPLE { ( 125 ) / ( 125 ) }
            }
         }
         GROUP "FieldData" {
            DATASET "KE" {
               DATATYPE  H5T_IEEE_F64LE
               DATASPACE  SIMPLE { ( 44 ) / ( 44 ) }
            }
         }
         GROUP "PointData" {
            DATASET "Coord Result" {
               DATATYPE  H5T_IEEE_F64LE
               DATASPACE  SIMPLE { ( 216 ) / ( 216 ) }
            }
         }
      }
      GROUP "Level1" {
         ATTRIBUTE "Spacing" {
            DATATYPE  H5T_IEEE_F64LE
            DATASPACE  SIMPLE { ( 3 ) / ( 3 ) }
            DATA {
            (0): 0.25, 0.25, 0.25
            }
         }
         DATASET "AMRBox" {
            DATATYPE  H5T_STD_I32LE
            DATASPACE  SIMPLE { ( 2, 6 ) / ( 2, 6 ) }
            DATA {
            (0,0): 0, 3, 0, 5, 0, 9,
            (1,0): 6, 9, 4, 9, 0, 9
            }
         }
         GROUP "CellData" {
            DATASET "Centroid" {
               DATATYPE  H5T_IEEE_F64LE
               DATASPACE  SIMPLE { ( 480, 3 ) / ( 480, 3 ) }
            }
            DATASET "Gaussian-Pulse" {
               DATATYPE  H5T_IEEE_F64LE
               DATASPACE  SIMPLE { ( 480 ) / ( 480 ) }
            }
            DATASET "vtkGhostType" {
               DATATYPE  H5T_STD_U8LE
               DATASPACE  SIMPLE { ( 480 ) / ( 480 ) }
            }
         }
         GROUP "FieldData" {
            DATASET "KE" {
               DATATYPE  H5T_IEEE_F64LE
               DATASPACE  SIMPLE { ( 88 ) / ( 88 ) }
            }
         }
         GROUP "PointData" {
            DATASET "Coord Result" {
               DATATYPE  H5T_IEEE_F64LE
               DATASPACE  SIMPLE { ( 770 ) / ( 770 ) }
               }
            }
         }
      }
   }
}
```

repository: Kitware/vtk-examples

repo_name: Kitware/vtk-examples


text:
[![](http://jenkins.imagej.net/job/ImageJ-tutorials/lastBuild/badge/icon)](http://jenkins.imagej.net/job/ImageJ-tutorials/)

This project contains example code for working with [ImageJ2][1].

GETTING STARTED
---------------

You can import these projects into your favorite IDE:

  * Eclipse: File > Import > Existing Maven Projects
  * NetBeans: File > Open Project
  * IDEA: File > Open Project... (select pom.xml)

Or build and run from the command line:

    mvn
    cd load-and-display-dataset
    mvn exec:java -Dexec.mainClass=LoadAndDisplayDataset

LICENSING
---------

To the extent possible under law, the ImageJ developers have waived
all copyright and related or neighboring rights to this tutorial code.

See the [CC0 1.0 Universal license][2] for details.

SEE ALSO
--------

The [ImgLib2 Examples][3], an excellent image processing tutorial.

[1]: http://imagej.net/ImageJ2
[2]: http://creativecommons.org/publicdomain/zero/1.0/
[3]: http://imagej.net/ImgLib2_Examples

repository: gaohangdy/imagej-tutorials

branch_name: refs/heads/master

extension: md

license_type: permissive

repo_name: gaohangdy/imagej-tutorials


text:
[![Build Status](https://travis.ibm.com/bdu/companion-cube-ruby.svg?token=CCLjK5gsaLWyxhCwwcrs&branch=master)](https://travis.ibm.com/bdu/companion-cube-ruby)

# Companion Cube

Ruby client for [Companion Cube](https://github.ibm.com/bdu/companion-cube).

## Installation

Add this line to your application's `Gemfile`:

```ruby
gem "companion_cube"
```

And then execute:

```sh
bundle install
```

Or install it yourself as:

```sh
gem install companion_cube
```

## Usage

```ruby
# To start, create a client
cc = CompanionCube::Client.new(url: "https://cc.example.com")

# Retrieve all existing courses
courses = cc.courses

# Create a new course
params = {
  run:          "...",
  archive_file: File.new("...")
}
new_course = cc.create_course(params)

# Retrieve an existing course
course = cc.course(new_course["id"])

# Update a course
params = {
  archive_file: File.new("...")
}
updated_course = cc.update_course(course["id"], params)
```

## Development

To run the tests, run:

```sh
docker-compose run --rm cc rake spec
```

You can also run the following command for an interactive prompt that will
allow you to experiment.

```sh
docker-compose run --rm cc bin/console
```

For added flexibility, you can use Bash.

```sh
docker-compose run --rm cc bash
```

## Build

Add the gem repo to your configuration:

```sh
# replace @ with %40 in your username
gem source -a \
<EMAIL_ADDRESS>
# keep @ AS IS
curl -u<USERNAME>:<PASSWORD> \
  https://na.artifactory.swg-devops.com/artifactory/api/gems/apset-ruby/api/v1/api_key.yaml \
  > ~/.gem/credentials
```

Build the gem:

```sh
gem build companion_cube.gemspec
```

Install the gem locally: (optional)

```sh
gem install companion_cube-*.gem
```

Push the gem:

```sh
gem push companion_cube-*.gem --host https://rubygems.org
rm companion_cube-*.gem
```

The credentials for the team account are in the box folder and in 1Password.

## License

Please refer to [LICENSE](LICENSE).

## Authors

*   Partner Ecosystem Team, IBM Digital Business Group<EMAIL_ADDRESS>

license: MIT


text:
![cover](./cover.png)

# Day 46 - Implement a double ended queue (deque)

Write a program to implement deque (Double Ended Queue)

### Double Ended Queue

Deque or Double Ended Queue is a generalized version of Queue data structure that allows insert and delete at both ends.

### Operations on Deque

Mainly the following four basic operations are performed on queue:

- insertFront(): Adds an item at the front of Deque.
- insertLast(): Adds an item at the rear of Deque.
- deleteFront(): Deletes an item from front of Deque.
- deleteLast(): Deletes an item from rear of Deque.

In addition to above operations, following operations are also supported

- getFront(): Gets the front item from queue.
- getRear(): Gets the last item from queue.
- isEmpty(): Checks whether Deque is empty or not.
- isFull(): Checks whether Deque is full or not.

[Read More (Geeks4Geeks)](https://www.geeksforgeeks.org/deque-set-1-introduction-applications/)

[ques](./ques.png)

## Solution

## JavaScript Implementation

### [Solution](./JavaScript/deque.js)

```js
// To Be Added
```

repository: CodeToExpress/dailycodebase

gha_language: Java

gha_license_id: MIT

repo_name: CodeToExpress/dailycodebase


text:
# Preussiella indica (Chattop. & C. Das Gupta) Lodha, 1978 SPECIES

#### Status
ACCEPTED

#### According to
The Catalogue of Life, 3rd January 2011

#### Published in
in Subramanian, Taxonomy of Fungi (Proc. Int. Symp. Madras, 1973) 1: 251 (1978)

#### Original name
Thielavia indica Chattop. & C. Das Gupta, 1957

### Remarks
null

repository: mdoering/backbone

repo_name: mdoering/backbone


text:
# ThinkpadBattery
Open source Thinkpad T420 battery design

http://beta.aceparent.me/#/battery

## What is this?

This is a fully open source T420 laptop battery design. The design uses an attiny85, which can reply to the T420 motherboard's SMBUS requests.

## Setup

### Configurable Constants

- BATTERY_CAPACITY | Your battery capacity in mAH
- V_HIGH | The highest output voltage of your battery, normally 12.6v
- V_LOW | The cutoff for when the battery will stop working, normally around 10.8v

### Creating your own

Parts Needed
- Arduino Uno (for programming the attiny85)
- 12v Lithium-Ion battery pack
- 3S Lithium-Ion BMS
- Components from schematic
- PCB from schematic

Once you have all these parts, assemble the pcb and attach a BMS to your battery pack. Solder the 12v battery output/input to the large pads on the pcb, then program the attiny85 with the included ino file. The output pins at the bottom of the PCB are a 1-1 mapping of the motherboard pin input.

### Debugging

- The laptop won't supply power to the board unless it detects there's a battery attached, meaning if you plug the board in to the battery without having an external battery to power it, it won't work.

### Libraries

Use the ATTinyCore for compiling. Without it, Wire.h won't work.

## Limitations

### Voltage Reading / Remaining battery

Currently remaining battery %'s aren't exact because I'm assuming there is a linear coorelation between voltage and capacity (Which is wrong). This is probably fixable using a battery gas gauge, I'll have to investiage more.

### MCU Power Consumption

By design, the MCU will always be on as long as a battery is connected to it. This can cause the battery to slowly run out of power if it isn't connected to a laptop. A potential fix could be to implement a low power mode for the attiny, or have a seperate disconnect switch for the battery power on the battery pack itself.

## Future Plans

### 3D Printable Case

When my current battery becomes unusable, I'm going to create a 3d printable model to house nine 21700 cells that can be attached to the laptop.

repository: digmorepaka/ThinkpadBattery

repo_name: digmorepaka/ThinkpadBattery


text:
# PermissionHandler

Simplifying check permissions in android

# Gradle usage

``` java
 compile 'com.huanjulu.android:permissionhandler:1.0.2'
```

# What can this library do?

 - With this library, you can easily check for a series of related permissions on a project.
 - Using this library, you can easily apply the permissions you need, such as Camera permission, Storage Permisson... And so on.
 - You can easily check the user for the "Never ask Again" option. And you can customize your future operations.

----

 - 利用这个library , 你可以很方便的在项目中检查是否拥有一系列的相关权限
 - 利用这个library , 你可以很方便的去申请你所需要的权限，比如Camera permission, Storage Permisson ...等等.
 - 你可以很方便的检查用户是够勾选了 “Never ask Again”选项。并且你可以自定义你以后的操作.

[![N|Solid](https://cldup.com/dTxpPi9lDf.thumb.png)](https://nodesource.com/products/nsolid)

# New Features!

  - Import a HTML file and watch it magically convert to Markdown

# How to Use

-  ##### First
You nees decelar the permission what you need in your "AndroidManifest.xml" file. like
``` java
    <uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE" />
    <uses-permission android:name="android.permission.CAMERA" />
```

-  ##### Request the permissions which you need
-  ##### 申请你所需要的权限
``` java
         //ask camera permission
        PermissionHandler.requestPermission(this, AppPermission.CAMERA.INSTANCE);
```
``` java
        //ask storage permission
        PermissionHandler.requestPermission(this, AppPermission.READ_EXTERNAL_STORAGE.INSTANCE);
```
-  ##### In the permissions dialog of the system,listen the click event of user
-  ##### 在系统的权限申请弹窗中，监听用户的点击事件

if you do this, the first thing what you need to do is that overrive the onRequestPermissionsResult funtion ,like this
``` java
    @Override
    public void onRequestPermissionsResult(int requestCode, @NonNull String[] permissions, @NonNull int[] grantResults) {

        PermissionHandler.onRequestPermissionsResultReceived(requestCode, permissions, grantResults, appPermissionGranted -> {

            Toast.makeText(this, " Permission Granted", Toast.LENGTH_SHORT).show();
            // you select granted
            return null;

        }, appPermissionDenied -> {

            Toast.makeText(this, " Permission Defined", Toast.LENGTH_SHORT).show();
            // you select  defined
            return null;
        });

    }
```

-  ##### Check to see if you have the permissions what you need
-  ##### 检查是否拥有你所需要的权限

here is some code what check camera permsiion, storage permission..so on
``` java
   private void checkCameraPermission() {

        PermissionHandler.checkPermission(this, AppPermission.CAMERA.INSTANCE,

                //this permission was granted already
                granted -> {
                    Toast.makeText(this, "Camera Permission Granted", Toast.LENGTH_SHORT).show();
                    return null;
                },
                //this permission was denied already
                denied -> {
                    Toast.makeText(this, "Camera Permission Denied", Toast.LENGTH_SHORT).show();
                    return null;
                },

                //user select dot not ask again already
                rationale -> {
                    Toast.makeText(this, "Camera Permission Not Ask Again", Toast.LENGTH_SHORT).show();
                    return null;
                });
    }
```
``` java

    private void checkStoragePermission() {
        PermissionHandler.checkPermission(this, AppPermission.READ_EXTERNAL_STORAGE.INSTANCE,

                //this permission was granted already
                granted -> {
                    Toast.makeText(this, "Storage Permission Granted", Toast.LENGTH_SHORT).show();
                    return null;
                },
                //this permission was denied already
                denied -> {
                    Toast.makeText(this, "Storage PermissionDenied", Toast.LENGTH_SHORT).show();
                    return null;
                },

                //user select dot not ask again already
                rationale -> {
                    Toast.makeText(this, "Storage Permission Not Ask Again", Toast.LENGTH_SHORT).show();
                    return null;
                });
    }
```
-  ##### Finally,enjoy use it !!

# License
``` java
  Copyright 2015 Anthony Restaino
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

    http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
```

repository: huanjulu/PermissionHandler

gha_language: Kotlin

repo_name: huanjulu/PermissionHandler


text:
# Training ERF-PSPNet or ERF-APSPNet in Pytorch

PyTorch code for training ERF-PSPNet or ERF-APSPNet models. The code was based initially on the code from [bodokaiser/piwise](https://github.com/bodokaiser/piwise), adapted with several custom added modifications and tweaks. Some of them are:
- Load dataset (Cityscapes, Mapillary Vistas or other datasets)
- ERF-PSPNet and ERF-APSPNet models definition
- Show IoU and ACC on each epoch during training (adapted using cityscapes scripts)
- Three different loss functions including cross-entropy, focal-loss and lovasz-loss
- Save snapshots and best model during training
- Save additional output files useful for checking results (see below "Output files...")
- Resume training from checkpoint (use "--resume" flag in the command)

## Options
For all options and defaults please see the bottom of the "main.py" file. Required ones are --savedir (name for creating a new folder with all the outputs of the training) and --datadir (path to cityscapes directory).

## Example commands

Train ERF-PSPNet decoder using encoder's pretrained weights with ImageNet:
```
python3.6 main.py --savedir erfnet_pspnet_training1 --datadir /home/kailun/Downloads/PASS-master/dataset/ --num-epochs 60 --batch-size 6 --decoder --pretrainedEncoder "../trained_models/erfnet_encoder_pretrained.pth.tar"
```

Train ERF-APSPNet decoder using encoder's pretrained weights with ImageNet:
```
python3.6 main.py --savedir erfnet_apspnet_training1 --datadir /home/kailun/Downloads/PASS-master/dataset/ --num-epochs 60 --batch-size 6 --decoder --pretrainedEncoder "../trained_models/erfnet_encoder_pretrained.pth.tar" --model erfnet_apspnet
```

Train encoder with 60 epochs and batch=6 and then train decoder (decoder training starts after encoder training):
```
python3.6 main.py --savedir erfnet_pspnet_traning1 --datadir /home/kailun/Downloads/PASS-master/dataset/ --num-epochs 60 --batch-size 6
```

## Output files generated for each training:
Each training will create a new folder in the "../save/" directory named with the parameter --savedir and the following files:
* **automated_log.txt**: Plain text file that contains in columns the following info of each epoch {Epoch, Train-loss,Test-loss,Train-IoU,Test-IoU, learningRate}. Can be used to plot using Gnuplot or Excel.
* **best.txt**: Plain text file containing a line with the best IoU achieved during training and its epoch.
* **checkpoint.pth**: bundle file that contains the checkpoint of the last trained epoch.
* **{model}.py**: copy of the model file used (default erfnet_pspnet.py).
* **model.txt**: Plain text that displays the model's layers
* **model_superbest.pth**: saved weights of the epoch that achieved best val accuracy.
* **opts.txt**: Plain text file containing the options used for this training

NOTE: Encoder trainings have an added "_encoder" tag to each file's name.

By default, only Validation IoU is calculated for faster training (can be changed in options)

## Visualization
If you want to visualize the outputs during training add the "--visualize" flag and open an extra tab with:
```
python3.6 -m visdom.server -port 8097
```
The plots will be available using the browser in http://localhost.com:8097

## Multi-GPU
If you wish to specify which GPUs to use, use the CUDA_VISIBLE_DEVICES command:
```
CUDA_VISIBLE_DEVICES=0 python3.6 main.py ...
CUDA_VISIBLE_DEVICES=0,1 python3.6 main.py ...
```


text:
# __An Analysis of Postman__

## __Document History__

| Date | Description |
| ------------- | -------------- |
| 3/11/2021 | Initial Creation of Document |

## __Document Author__

* Brandin Goldsberry -<EMAIL_ADDRESS>/<EMAIL_ADDRESS>
## __What is Postman?__

Postman is a testing suite for API frameworks. It is a robust application for requesting all HTTP requests. This industry standard is one of the most widely used applications for ensuring that your API is functioning, or just learning how an API works before using it in production.

## __Technical Specifications__

Postman supports Mac, Windows, and Linux operating systems, and has 32-bit and 64-bit releases for both Windows and Linux. It can run virtually in any setup and smoothly integrates into any development workflow.

## __Samples__

This industry standard application has a number of examples on their website and of course on sites like Stack Exchange. The exmaple this test was run on is simple:

1) Grab a list of movies with the query "Fear and Loathing."
2) Grab the Second result.
3) Get the lead actor of the cast.
4) Get a list of all movies the actor was present for.
5) Visualize the results in percentage of genre for all films.

## __Conventions__

The first thing to set up is a collection in order to have common variables between tests and to have tests run in a series with the press of a button.

Each test in said collection is then given a URL to receive data from. There is also a pre-request script that could be run before a request to set some variables beforehand if needed. After the request is run the Test section is run, which is a JavaScript script that runs like normal. The tests are run after the script is finished.

One of the best things about Postman is the built-in assertions, where the user can assert tests and have multiple pass/fail responses per request. These are inegral parts of the tests and you can have multiple assertions per test and multiple tests per request.

A small request test script:

```JavaScript
pm.test('Success', () => {
    pm.response.to.have.status(200);
    pm.response.to.be.ok;
})

pm.test('Set First Movie Variable', () => {
    pm.variables.set("first_movie", pm.response.json().results[1].id);
    pm.expect(pm.variables.get("first_movie")).to.equal(1878);
})
```

This uses the strange "English-like" syntax of chaining together multiple property accessors, but then also uses functions for certain assertions. It can be a bit clunky at times, but not needing external libraries is nice.

The other great part of Postman is having visualizations for data, where it can render HTML using the HandlebarJS library for templating.

```JavaScript
var template = `
<canvas id="myChart" width="auto" height="100%"></canvas>
<script<EMAIL_ADDRESS><script>
var ctx = document.getElementById('myChart').getContext('2d');
var myChart = new Chart(ctx, {
    type: 'doughnut',
    data: {
        labels: [
            {{#each labels}}
                "{{this}}",
            {{/each}}
        ],
        datasets:[{
            data: [{{data}}],
            backgroundColor: [
                {{#each bgColors}}
                    "{{this}}",
                {{/each}}
            ]
        }]
    }
});
</script>
`
//Code cut here for brevity

pm.visualizer.set(template, {
    data,
    labels,
    bgColors
})
```

This particular example here uses ChartJS to show a donut chart for the percentage of the movies. The website has this an example but does not tell you much on how to actually set it up. Just like a regular HTML page you need to import the required scripts, but since we can't make external JS files ourselves we have to write our script in a `<script>` tag.

One of the issues with the visualizations is that it does not render in the collection runner, only in the standard single request runner.

## __Conclusions__

Postman is a standard for a **good** reason. It can create several workspaces, environments, and collections of requests, with each group being able to have common scripts and requests but different in each execution. You could feasibly have multiple projects, with multiple APIs each, with hundreds of collections, each sorted and runnable in chunks. There are things that are difficult to use about it, but once you learn them you have a powerhouse of an API development tool.

|  | Ease of Use | Tools | Features | Site Variety | Framework Support | Documentation |
| - | - | - | - | - | - | - |
| Rating | 3 | 5 | 4 | 5 | 5 | 4 |

> ### **Final Rating** 4.2/5

\* Site variety indicates how many sites are testable
\*\* Framework Support indicates the intricacies in which frameworks are testable

branch_name: refs/heads/main


text:
# Script Linker

Script Linker is a helper program for [Superfighters Deluxe] (SFD) to help ease the process of scripting.

Currently, to script in SFD, you have to code in a built-in text editor that is basically a text area with a compile button which make scripting so much of a pain that only masochists will use said editor.

If you want to write anything more than a couple of classes, you should use Visual Studio/Vscode instead as it supports syntax highlighting, autocomplete, shortcuts like jump into file, see references...

Script Linker tries to smooth the process of using both tools: An IDE (for coding) and the SFD text editor (for compiling). Remove the unnecessary metal load to help scripters write more quality scripts

https://user-images.githubusercontent.com/23303775/162793252-f7ba9685-7830-4404-a812-8bfb4b2699c0.mp4

## Features

* Manage your scripts: Add, edit, search and remove script info (`sfde` files are not supported).
* Populate new script with game script template (template can be changed in `ScriptTemplate.txt`)
* Organize your code in multiple files and folders
* Automate the compiling task via a global hotkey
* Generate output file to SFD script folder.

## Usage

- Create a new project in Visual Studio.

- Rename the default `Class1.cs` file to `Main.cs` (or something more meaningful).

- Open ScriptLinker. Select `Script` > `New`.

- Fill in the script detail:
    - **Name**: *(Required)* Your script name. This field must be unique between scripts.
    - **Entry Point**: *(Required)* The main file where you have the `GameScript` lifecycles like `OnStartup` or `OnUpdate`.
    - **Project Directory**: *(Required)* The directory containing the `*.csproj` file.
    - **Author**: Self-explanatory
    - **Description**: Self-explanatory
    - **Map Modes**: versus, custom, survival or campaign. This is my bad, I should have made a combobox.
    - **Init game script template**: Initialize the Entry Point file with a starting template. The template can be modified in `ScriptTemplate.txt`

- In your IDE, the `Main.cs` file now should look like this:

- To fix the error, add the `SFD.GameScriptInterface` assembly. Right click `Dependencies` > `Add Project Preference...` > `Browse`

- Find and select the `SFD.GameScriptInterface.dll` file. It's in where the game is installed > Click `OK` to confirm.

- Go to the Map Editor and make sure the Script tab is opened so the code can be pasted from the IDE.

You're pretty much done here. Now you can develop your script in Visual Studio and enjoy all of the IDE features like syntax highlighting, intellisense, codelen... You can also create multiple files and directories to orgnaize your code however you want, Note that cross project import is not supported.

Once you edit your code, hit **F8** to compile. This shortcut can be changed in the settings (`Tools` > `Option`). You can see a short demo [here](https://youtu.be/q3M2rQQSNU4).

*Tip*: When you reference the `IGame` instance outside of the `GameScriptInterface` subclass, the IDE will complain that the `Game` property does not exist. To work around it, create a helper class with the same property name and type:

```c#
using SFDGameScriptInterface;

namespace YourProjectName
{
    public static class GameScriptUtil
    {
        public static readonly IGame Game;
    }
}
```

Then import the class in your file to make the member `Game` available in the scope:

```c#
using static YourProjectName.GameScriptUtil;

namespace YourProjectName.MyLib
{
    public static class Library
    {
        public static IEnumerable<IPlayer> GetAlivePlayers()
        {
            // Game is available here
            return Game.GetPlayers().Where(p => !p.IsDead);
        }
    }
}
```

## Download

Download [here](https://github.com/NearHuscarl/ScriptLinker/releases) (ScriptLinker.zip)

## Sample projects

* [BotExtended]

## Development

For anyone wondering why I dont have any Notification calls inside the properties from the ViewModel like this:

```C#
private string copyToClipboardHotkeyName;
public string CopyToClipboardHotkeyName
{
    get { return copyToClipboardHotkeyName; }
    set { SetPropertyAndNotify(ref copyToClipboardHotkeyName, value); }
}
```

but just the shorthand auto property

```C#
public string CopyToClipboardHotkeyName { get; set; }
```

That's because I'm using this awesome Fody plugin [PropertyChanged] which help you cut down the verbose part when declaring binding property in WPF

## Guides

* [Set up Visual Studio]

[Superfighters Deluxe]: https://mythologicinteractive.com/SuperfightersDeluxe
[BotExtended]: https://github.com/NearHuscarl/BotExtended
[PropertyChanged]: https://github.com/Fody/PropertyChanged
[Set up Visual Studio]: https://www.mythologicinteractiveforums.com/viewtopic.php?f=15&t=1588

repository: NearHuscarl/ScriptLinker

gha_language: C#

repo_name: NearHuscarl/ScriptLinker


text:
---
title: TDD in Android with Robolectric Part.2
date: '2014-03-12 20:04:52'
tags:
- cap-sandeep
- android
- onemdm
- technology
wp:post_id: '4592'
link: http://www.multunus.com/blog/2014/03/tdd-android-robolectric-part-2/
---

In Part 1 of this three-part series [
[Part 1](http://www.multunus.com/blog/2014/02/tdd-using-roboelectric/),
[Part 3](http://www.multunus.com/blog/2014/03/tdd-android-using-robolectric-part-3/) ], I had talked about problems involved in doing TDD when developing Android applications, and how
[Robolectric](http://robolectric.org/) helps you overcome those problems. In this post, I will go into the details of Robolectric framework along with an example.

**Installation & setup**

Robolectric setup requires the
[robolectric (with its dependencies](http://search.maven.org/#search%7Cga%7C1%7Cg%3A%22org.robolectric%22)) JAR and the
[JUnit 4](http://sourceforge.net/projects/junit/files/junit/) JAR in the classpath. You also need to add the
android.jar from your Android SDK installation directory to the classpath of the test project. You will find a very detailed description of Robolectric setup here:
[Robolectric Installation for Unit Testing](https://github.com/thecodepath/android_guides/wiki/Robolectric-Installation-for-Unit-Testing)

**Writing Tests**
****

Once Robolectric setup is done, you can start writing your tests. Let's take a look at a Robolectric test sample:@RunWith(RobolectricTestRunner.class)
public class MyActivityTest {
  @Test
  public void shouldShowLogoWhenButtonIsPressed() throws Exception {
      Activity activity = new MyActivity();
      activity.onCreate(null);
      ImageView logo = (ImageView) activity.findViewById(R.id.logo);
      Button button = (Button) activity.findViewById(R.id.button);
      assertThat(logo.getVisibility(), equalTo(View.GONE));
      button.performClick();
      assertThat(logo.getVisibility(), equalTo(View.VISIBLE));
  }
}

In line 1, the test class MyActivityTest is annotated with a JUnit annotation called
[@RunWith](http://junit.sourceforge.net/javadoc_40/org/junit/runner/RunWith.html), it invokes the class it references to run the tests in that class instead of the runner built into JUnit. Since Android code is used in the test, we need to use Robolectric as the test runner which is achieved using the above annotation. This is the starting point of a Robolectric test.

Setup

Next, let's go through the each of the lines in the test . The test code starts at line 5, and here the MyActivity class is instantiated which is an Android activity, so the test would have thrown an exception right here if Robolectric was not used. Just a reminder!

In line 6, one of the life cycle methods of any Android activity "onCreate" is called and this will set the user interface layout for this Activity. So, if our layout had a logo or a button on it we could use
findViewById method and get references to these objects, which is done in lines 7 and 8. In line 9, it is asserted that the logo is not there in the layout, this is just to ensure that the test is in correct state before and with this setup for the test is completed.

Action & Assertion

In line 10, a click action is performed on the button using Android's
performClick method, this will cause the click listeners registered on the button to fire and that will cause the application code to run. Lastly, the visibility of the logo is asserted to be true in line 11.

Next Steps

The above example will get you started on doing Unit Testing with Robolectric, but Robolectric framework has many other features which help you to test most of the use cases you come across in unit testing Android applications. For example, we can use
Shadow objects in our tests. Shadows are like mocks or stubs, but not quite the same.

Shadows exist to add additional methods that can be used in tests to inspect the state of the underlying Android object. For example, many Android objects have setters for certain values, but no getters. We can add getters to the shadows and use them in test to assert on the underlying object.

I will share some examples on using Shadows in tests in my next post.

repository: multunus/multunus-website

extension: markdown

repo_name: multunus/multunus-website


text:
---
layout: post
title: Project 2
---

# What would I do differently

Honestly, for this project, I would not do things differently because I felt like for this project, it was straightforward.

# What was the most difficult part for you

There was nothing really difficult about this project.

# What are my big take-aways from this project

The big takeaway from this project is automation for the analysis report. I can’t imagine having to write a report for each day because that would be very time consuming.

To view my project, check out [https://gbridges34.github.io/Project2Bridges-Lee/](https://gbridges34.github.io/Project2Bridges-Lee/) and [https://github.com/gbridges34/Project2Bridges-Lee](https://github.com/gbridges34/Project2Bridges-Lee)


text:
# Discord.Net v0.8.1-Beta2
An unofficial .Net API Wrapper for the Discord client (http://discordapp.com).

Check out the [documentation](https://discordnet.readthedocs.org/en/latest/) or join the [Discord API Chat](https://discord.gg/0SBTUU1wZTVjAMPx).

### Current Features
- Using Discord API v3
- Supports .Net 4.5 and DNX 4.5.1
- Server Management (Servers, Channels, Messages, Invites, Roles, Users)
- Send/Receieve Messages (Including mentions and formatting)
- Basic Voice Support (Outgoing only)
- Command extension library (Supports permission levels)

### Installation
You can download Discord.Net from NuGet:
- [Discord.Net](https://www.nuget.org/packages/Discord.Net/)
- [Discord.Net.Commands](https://www.nuget.org/packages/Discord.Net.Commands/)

### Known Issues
- DNX Core 5.0 is experiencing several network-related issues and support has been temporarily dropped.


text:
# About CQ-Actions

## Purpose

CQ Actions is a mechanism serving as the underlying transport layer, which ensures that data is properly and safely transported from publishers instances to author instance and is processed on the second one.

## Prerequisites

## Installation

### CQ 5.6:

Download latest stable version: https://github.com/Cognifide/CQ-Actions/archive/cq-actions-1.2.0.zip

Compile and install to your local repository:

    mvn clean install

Add dependency to your project:

    <dependency>
        <groupId>com.cognifide.cq.actions</groupId>
        <artifactId>cq-actions</artifactId>
        <version>1.2.0</version>
    </dependency>

Or just install it using your Felix console.

### AEM 6.0:

Download latest stable version: https://github.com/Cognifide/CQ-Actions/archive/cq-actions-2.0.0-incubator.zip

Compile and install to your local repository:

    mvn clean install

Add dependency to your project:

    <dependency>
        <groupId>com.cognifide.cq.actions</groupId>
        <artifactId>cq-actions</artifactId>
        <version>2.0.0-incubator</version>
    </dependency>

Or just install it using your Felix console.

## Usage

Implement data processing using `com.cognifide.actions.api.Action` interface. Remember to create OSGi descriptors for the class:

    @Service
    @Component
    public class MyAction implements Action {

        private final static Logger LOGGER = LoggerFactory.getLogger(MyAction.class);

        @Override
        public void perform(Page page) throws Exception {
            LOGGER.info("performing action");
        }

        public String getType() {
            return "my-action";
        }

    }

On publish instance, whenever you would like to invoke any action on author instance just invoke following snippet:

    @Reference
    ActionRegistry actionRegistryService;

    ...

    Node node = actionRegistryService.createActionNode(session, relPath, "my-action");
    node.setProperty(name, value);
    session.save();

Once, the `session.save()` is invoked, the node would be replicated to author instance and one of the `EventHandler`s (`ActionHandleEventListener`) will intercept the node creation event and fire proper action.

You might want to change the path on which the `ActionHandleEventListener` is listening using OSGi Configuration as well as the root path for creating action nodes in `ActionRegistryService` configuration.

### Setup Jobs Queue for CQ-Actions
Setup jobs queue adds ability to to adjust jobs queue type (eg Ordered), number of job retries if action job fails etc.

To do so:

1. On Author instance goto to Adobe CQ5 Web Console Configuration | Felix Console (http://localhost:4502/system/console/configMgr)
2. Find "Apache Sling Job Queue Configuration" and add new entry.
3. Set "Topics" field to "com/cognifide/actions/defaultActionsTopic".
4. Setup other fields according to your the needs and save

* Please note that if jobs queue wont be setup (or will be setup incorectly) CQ-Actions will use default main jobs-queue witch is parallel (this in certain circumstances it may be unwanted).

#### CQ-Action jobs queue tests

For testing purpose  check two files from /src/test/java folder :

* SimpleActionExample.java
* CreateActionNodes.groovy

SimpleActionExample mus be running on Author instance. (you can simply move it to src/java, build and install created JAR as bundle).
CreateActionNodes is Groovy script witch creates special nodes under /content/usergenerated/action/ path in JCR (same as ActionRegistryService.createActionNode method).
Adjust parameters in script, run it and check the CQ logs.

# Commercial Support

Technical support can be made available if needed. Please [contact us](https://www.cognifide.com/get-in-touch/) for more details.

We can:

* prioritize your feature request,
* tailor the product to your needs,
* provide a training for your engineers,
* support your development teams.

More documentation
------------------
* [Cognifide.com](http://cognifide.com)

repository: cmscreativeguy/CQ-Actions

repo_name: cmscreativeguy/CQ-Actions


text:
---
layout: post
title: Why software is so hard?
date: 2020-09-20
categories: software software-engeneering programming
author: Georg
---

Software project are late, expensive and hard to estimate. This is no secret.
But why is this industry so successful compared to other engineering
disciplines. So why is software entering every aspect of life?

**Moving important decisions** to the end of the development life cycle is one
of the key points of success. Electronic gives some freedom in the design of
control loops. With software it is possible to move it further to the right and
nowadays even customers can change the drive characteristics of modern cars.

So one common success story of electrical and software engineering is to move
the decision what to do further to the right of the development cycle. This is
in my opinion a crucial success factor, which also allowed to build general
purpose hardware.

## The **what**

Now everyone is building general purpose hardware and the software is going to
fix it. No problem at all, at least in theory. However the questions "What to
do?" is not answered in many product development projects. Agile processes try
to solve this by shortening the feedback loop.

Every major company adapts agile methods, so it should improve in the next years
or? In theory yes but the agile process gets tailored to the company and now
they have an agile waterfall ;-). Not a single responsibility or decision get's
transferred to the team and the feedback loop is removed entirely from the
process. The only difference is a stand-up in the morning and a two week
planning cycle. So there will be major delays in software projects. This will
take the industry a while to figure out.

*Disclaimer:* I only have insight in two companies, so far and in one of them
there was a pretty good understanding of customer needs and an agile mindset,
however agility wasn't a thing at all. So this posts reflects my personal
opinion and is not based on broad experience or research.


text:
---
name: Bug report
about: Create a report to help us improve

---

### Description

[Description of the bug]

### Steps to Reproduce

1. [First Step]
2. [Second Step]
3. [and so on...]

**Expected behavior:** [What you expected to happen]

**Actual behavior:** [What actually happened]

### Minimal reproduction

<!-- A link to a minimal reproduction of the issue -->

### React Native Environment

<!-- Share if the project is initiated with Expo (Go, Prebuilt or Custom Dev Client) or Bare. -->

### Versions

You can get this information from executing `npm version`.