Tucson format

Tucson format or decadal format or rwl format is one of the most common formats for storing ring width data. It is the standard format for ITRDB. It is a text file format. Different extensions are used, such as .rwl, .crn, .tuc and .dec. (.crn is used for derivate chronologies). The name comes from the city of Tucson in Arizona.

A Tucson file consists of three lines of meta data followed by an undefined number of data lines (and cores). A data line consist of the core identity (max 8 alphanumeric characters, i.e. letters or digits), the year of the oldest measurement of the line (4 digits) ring width data, up to ten rings per line. Measurement data is either given with 3 or 4 digits according to resolution. Except for the first and last lines of each core there are measurements for one decade per line. After the youngest ring there is a "999" as a stop mark. Missing data mark is -999.

PMkr12b 1781   120    87    69   122   108    85   125   114    77
PMkr12b 1790   134   131   114    97   117    49    69   100   123    89
PMkr12b 1800   137    89  -999    79    44    38    62    99    68    26
PMkr12b 1810    27    43    51    57    36   999

An example of a three digit resolution sample which covers the timespan AD 1781-1814, with a missing ring for AD 1802 (-999). The width of AD 1781 (the first year) annual ring is 1.20 mm and for 1782 AD 0.87 mm.

Examples

These examples are taken from comments within the CDendro code. Best would be if we could have two sections with awkward data - one for each precision - that could be used for testing Tucson format reading capability of software.

'Examples of decadal file format:
	'The usual ending of a sample is like this:
	'6682    1980   143   231   154   145   150   201   130   156   245   137
	'6682    1990   141   202   120    96   999
	'NM002   1632    90    92    91   174    84    45   185   111
	'NM002   1640   116    72    91    49    85   146   125   126   136   131
	'Here is an example from brit9.rwl.
	'SH387C  1170    14    16    14    19    22    22    26    16    23    23
	'SH387C  1180    17    11    14    12   999     0     0     0     0     0
	'SH387D  1078    48    48
	'SH387D  1080    50    42    46    62    49    53    41    28    17    31
	'
	'Here is a snappet from brit045.rwl:
	'Q 9730   990    72    98   112   124   107   132   137   145   114    80
	'Looks very much normal, but ends with two Asciichar(13) characters which
	'will not be trimmed away by the VB Trim function.
	'The normal start of a sample is like this:
	'6682    1884   261   267   191   189   215   309
	'6682    1890   357   284   248   174   274   271   229   201   200   130
	'But here is a snappet from brit5.rwl:
	'WRU9    1190   190   192   218   213   204   259   206   150   178   149
	'WRU9    1200   198   232   151   199   175   196  9990  9990  9990  9990
	'WRU13   1075  9990  9990  9990  9990  9990   342   426   240   213   217
    'It both ends and start a sample with 9990 markers.
    '
    'From ca535.rwl:
    'MWK964  1970    16    11    22    25     9    13    26    24    23    16        
    'MWK964  1980   999                                                              
    'MWK965   509    62     0     0     0     0     0     0     0     0     0        
    'MWK965   510    47    45    25    19    33    24    32    51    24    22        
    'where zeroes are filled into positions which are not in use
    'and this with a -0 instead of 0 or -999
    'MWK401 -3550    26    21    19    20    28    21    13    11    -0    11  
    '
    'Format still not handled with example from fran009.rwl:
    '606 13  1570    24    31    30    25    26    24    27    27    33    30
    '606 13  1580    20   999
    '606 13  1586    20    19    19    18
    '606 13  1590    27    20    20    25    22    22    23    23    10    15
    'I.e. a gap of missing rings is handled as two series one after the other though with the same identity.	

CDendro interpretation

....
See also CDendro naming standard