GEMPACK Header Array Files

GEMPACK uses its own standard form for storing data, called Header Files

Global.har: all the SALTER notation parameters described above. Price94.har: price elasticities for private consumption

lnc94.har: income elasticities for private consumption Subst.har: elasticities of substitution.

The last three files will be detailed below, but the form in which they store data is identical to that for Global.har and any other header array file.

The format of header array files described here was found by extensive testing of

header array files using a hex Where necessary, some values are given in

hexadecimal notation, prefixed by the characters &h. So, for example, the number is equal to &hB. Header array files, like any computer file, are a long series of bytes (numbers in the range 0 - 255. or to &hFF), the interpretation of which differs

according to how they are used. some cases the bytes are interpreted directly as

numbers, in other cases, pairs of bytes are interpreted as integers (numbers in the range -32768 to +32767). A sequence of four bytes can be interpreted as a long

integer (numbers in the range to 2,147,483,647) or as single precision

real numbers (real numbers in the range to bytes can

be interpreted as ASCII codes representing characters.

A header array file consists of a number of header arrays, each of which contains a header containing information about the array, and the array itself, which can be either a series of text strings, or a series of bytes represenfing a table of single precision real numbers. The header arrays are stored one after another: no information at the start of the file describes how many header arrays are on the file - the last header is read when the end of the file is reached.

A header array is always preceded by the four bytes &hl3,&hOO,&hOO,&hOO (as a

long integer, this is interpreted as the number The short name of the header

hex editor used is Hex a It allows the viewing of computer tiles directly as a

follows, which is always four bytes (or letters) long. Then follows four bytes that identify the array as either a text array (the bytes &h20,&h73,&h01,&h00, which can be interpreted as the long integer 95008), or as a real array (if the bytes are

or 115488 as a long integer). These four bytes are

sometimes followed by a null byte but in some cases are not - this seems to

be in order to keep the following byte on an even-numbered position in the file, the reason for which is unclear. This is followed by 80 bytes giving an 80-character long name for the header array.

The naming information is followed by four bytes interpreted as a long integer giving

the number of dimensions that the array is defined followed by a long integer for

each dimension giving the size of that dimension. GEMPACK allows parameters to have up to seven dimensions, and although the largest array in the GTAP database has four dimensions (for DI02), the sizing information always gives real arrays that have

seven dimensions. An array defined over (size 37 &h25) and REG

(size 24 = therefore has the eight long numbers:

&h7.&h25,&hl8,&hl,&hl,&hl,&hl,&hl. Real arrays are then followed by 134 bytes, text arrays are followed by 22 bytes (in both cases, the meaning of these bytes is unidentified). The array follows after that. An example follows, taken from

Global.har for the header array Here all bytes are given in their hexadecimal

form, followed by a description. Note that text strings often contain the space character (=&h20) as padding.

Example Header Array

Long integer = 17 Short name =

Identifies real array (+ a null byte)

0202020202020202020202020202020202020202020202020202020202020202020202020202020 80 character long name RLFULL

07000000 integer = 7 (number of dimensions) 25000000 integer = 37 (size of first dimension) 25000000 integer = 37 (size of second dimension)

Long integer = 24 (size of third dimension) integer = 1 (size of fourth dimension) Long integer = 1 (size of fifth dimension) 10000000 Long integer = I (size of sixth dimension)

Long integer = (size of seventh dimension)

I ABO 135 unidentified bvtes.

Text in the GTAP database header array files include text for creation

information, and descriptions of the last changes made to files. As such, they are of no interest when compiling the database, except that the total length of the array needs to be calculated in order to find the starting point for the next header array in the file. The exact format of text arrays will not be examined here. Each character in a text

array is one byte long, so that an array defined as having two the first

dimension as 3, and the second dimension as 46, will be three strings of 46 characters. The size of the array is then 3 x 46 138 bytes.

Real arrays are complicated by the way that GEMPACK saves data. For arrays with more than two dimensions (i.e. arrays with more than two dimensions of size greater than one), each two-dimensional table is held on the file separately. for example, an is defined over i,r,s. then the array consists of 24 tables, each with 37x24

elements (first dimension size times second dimension size). For the these

tables are held on the file one after another, but approximately e\ery five to tables 84 bytes are inserted into the file, with no apparent use. Tests showed that the first four bytes of this spare block of bytes can always be interpreted as a real number