Tiles are rectangular.
Blocks can be rectangular or triangular.
Bands are stepped: each row after the first row of a band
starts one column to the right of the previous row
of that band.
If tiles are used, then blocks and bands cannot be used.
If blocks and/or bands are used,
then tiles cannot be used.
If tiles, blocks and bands are not used,
then the entire grid is stored intact
(not partitioned or broken up).
Tiles cannot overlap. If tiling is used,
tiles are adjacent and provide full grid coverage
(every possible grid node will be in a tile)
without duplication (each node will be in only one tile).
If blocks and/or bands are used intstead of tiles,
duplication of nodes is allowed, and
full coverage of nodes is not required:
grid nodes that are not in a block or band
are not stored and are considered to be zero.
Tiles and blocks do not extend past the edges of the grid.
Bands can extend past the left and right
edges of the grid,
in which case the nonexistent nodes are not saved.
If tiles are used,
all tiles are the same number of nodes
wide and high,
except the right tiles are truncated (made less wide) if
the grid width is not an integral multiple of the tile width,
and the bottom tiles are truncated (have less rows)
if the grid height is not an integral multiple of the tile height.
|
|
Each floating point number (or integer) is stored intact
with most significant byte first.
The next number is the next matrix entry,
in raster order (row-major storage).
If there is more than one matrix,
each matrix is a
channel:
the nodes for the first matrix are stored,
followed by the nodes of the next matrix, etc.
If the file is tiled (or has blocks or bands),
each tile (or block or band) stores nodes for that tile
from the first matrix (channel), followed with nodes for that tile
from the second channel, etc.
|
|
Raster order is left to right, top to bottom
|
|
If tiling is used,
each tile consists of scan lines
(rows of numbers) in raster order,
beginning with the tile's top row of numbers.
Scan lines are stored sequentially,
one after the other, without interleaving.
There are no pad bytes between
scan lines: the first byte of a scan line
immediately follows the last byte of
the previous scan line.
Tiles are stored one after the other, in raster order.
The tiles are stored as rows of tiles, beginning with the top row of tiles.
Each row of tiles begins with its left-most tile.
|
|
If blocks are used (instead of tiles),
nonoverlapping blocks can be used to define linear algebra
block matrices
(see Strang,
Intro. To Linear Algebra
3/e, p. 60,
and Kwak & Hong,
Linear Algebra
2/e, p. 19).
In this file format, the term
block
is used more generally than that term is used in linear algebra.
In this format, a block can be any rectangular region within the main grid,
and those blocks can overlap.
In linear algebra, blocks do not overlap.
In linear algebra, overlapping and non-matrix-block rectangular regions
would be called something else (not “blocks”).
For example,
H.M. Antia
(Numerical Methods for Scientists and Engineers
2/e, p. 610)
calls such regions “boxes.”
For the storage purposes of this file format,
those boxes are blocks.
In this file format,
you can use blocks and diagonal bands in the same grid,
and the blocks and bands can overlap.
Tiles do not overlap and cannot be used
with blocks or bands.
Blocks and diagonal bands with some overlapping can be used
for storing sparse matrices, if you do not develop your
own custom file formats for sparse matrices.
For example, some environmental modelling uses
large matrices that have non-zero entries only along the
right and bottom edges and clusters along the main diagonal
(see P4.3.11
in Golub and Van Loan,
Matrix Computations,
p. 159,
and
Aziz-2006-10-16.pdf,
p. 22-23).
To store a matrix like that
in the FIN file format
use blocks and diagonals,
with nodes overlapping (duplicate entries)
where the last rows and columns meet
(lower right corner of the matrix).
|
|
Compression is ON or OFF for the entire FIN file.
If compression is ON, some tiles may be compressed
and other tiles may be uncompressed.
For example, you can decide to only compress
tiles that reduce the file size.
It is possible that no tiles are compressed
even if compression is ON for the file.
Each tile (or block or band) channel specifies which type
(or types) of compression are used for that tile channel.
If more than one compression type is specified,
the different types of compression are performed
one after the other (in stages).
Up to 4 compression stages can be specified.
If all of the compression stages are set to
No Compression, the tile channel is not compressed.
To uncompress a tile that has been compressed
with multiple stages,
process the stages in reverse order:
decode the last stage of
compression first, then the next-to-last stage, etc.
For example, if the first stage of compression was
DIFF_ENC, the second stage was PRE_STRIP and the
third stage was ZLIB, then to uncompress that tile
first use ZLIB decoding, then PRE_STRIP decoding,
then DIFF_ENC decoding. This is like the
sock theorem
in mathematical analysis (function composition:
you take off shoes and socks in the reverse
order than they were put on).
|
|
|
Unless otherwise specified, in this document the term
tile
also refers to
block
or
band.
For example, when stating above that
“some tiles may be compressed
and other tiles may be uncompressed”
that also means “some blocks
(or bands)
may be compressed and other
blocks (or bands)
may be uncompressed.”
|
|
|
If a tile does not exist, each number that is supposed to be
in that tile is assumed to be zero.
That helps reduce file size for sparse matrices.
When writing a tile to disk, if all the floating point numbers
(or integers) in the tile are zero, then do not save the tile,
and set its tile address to zero.
This also holds for blocks and bands.
For example, if the address of a block is zero,
that means the block was not saved and all of the
nodes in that block are zero.
|
