POL/PSMSL Tidal Analysis Software Kit 2000
(TASK-2000)

C.Bell, J.M.Vassie and P.L.Woodworth

Permanent Service for Mean Sea Level,
CCMS Proudman Oceanographic Laboratory,
Bidston Observatory, Birkenhead,
Merseyside CH43 7RA, U.K.

POL/PSMSL Tidal Analysis Software Kit 2000
(TASK-2000)

The files on this disk (or supplied via ftp or other means) have been provided by the Proudman Oceanographic Laboratory (POL) and the Permanent Service for Mean Sea Level (PSMSL) for use by educational and research establishments in the course of sea level research.  They are supplied freely and in good faith with no known errors.  However, POL and PSMSL are required to disclaim any legal responsibility for their use.
Before using the files, a user should:
•	Make a back-up copy of this disk (or ftp files) together with a note of when it was obtained from POL/PSMSL.
•	Read fully the information supplied in this document and contact the PSMSL if anything is not clear.
•	Register with the PSMSL so that any future updates may easily be communicated. The registration information should include name and address, telephone and fax numbers, and email address together with the version number of this disk and date of receipt.
It would also be useful to include some details of the sort of tidal data being analysed (e.g. 6 minute data from an acoustic tide gauge, or hourly data from digitisations of tide gauge charts, or 15 minute current meter data).  That information may help us in developing any future versions of the package.
The PSMSL's address is:
          Permanent Service for Mean Sea Level
          CCMS Proudman Oceanographic Laboratory
          Bidston Observatory
          Birkenhead, Merseyside CH43 7RA
          United Kingdom

          Tel: +44 - 151 - 653 - 8633
          Fax: +44 - 151 - 653 - 6269
          Email: psmsl@pol.ac.uk

The files are not supplied freely to commercial organisations. Customers interested in using the software should register for a license with PSMSL/POL at the above address.

The files are derived from the TIRA tidal analysis programs (Murray, M.T. 1964. A general method for the analysis of hourly heights of the tide. International Hydrographic Review, 41(2), 91-101) used at POL for many years and developed most recently by Ian Vassie. They have been supplemented by DOS-compatible plotting software supplied by the POL Applications Group.
The package has been assembled by Colin Bell, Ian Vassie and Philip Woodworth from POL/PSMSL who would be delighted to hear about users' applications of the software. Any problems with its use should be addressed to the authors via the PSMSL address.
Computer Requirements
The programs should run on most DOS computers with at least 640K memory.  Clearly, they will run faster given a more modern PC. As an example, the test data file from Signy included with this disk takes about 20 seconds to analyse with tira.exe using a 75 MHz 486 PC.
Any .exe files (aside from those supplied with the TASK plotting module) will have been compiled with Microsoft FORTRAN with the emulation option for arithmetic. This allows the software to run without the need for a maths co-processor.
The TASK plotting module requires a VGA graphics card and, if the zoom facility is to be used, a mouse.
Files on this Disk
First, note that our convention for program and file names in this document is to refer to programs generally as TIRA, for example, whereas the actual names of the files are given in lower case bold characters, such as tira.for. The following files should be included on this disk:
task2k.rtf	this file which is in Rich Text Format
order.exe	DOS-executable code for reordering input data
tira.exe		DOS-executable code for tidal analysis
filter.exe	DOS-executable code for filtering input data to daily mean values
marie.exe	DOS-executable code for making tidal predictions
The disk may include the FORTRAN source files for ORDER, TIRA, FILTER and MARIE instead of, or as well as, the .exe files. These will have file names such as tira.for or tira.f. (The use of different extensions arises from our having a mixed Unix and PC environment. There is no difference in meaning between the two.) In each case, compile all the FORTRAN files for your computer if the corresponding .exe files are not present.
	The disk should also contain a number of files required by the TASK plotting module including:
taskplot.exe		DOS-executable code for plotting input data to TIRA, or the residuals of a TIRA tidal analysis, or tidal predictions from MARIE, or daily or monthly mean values from FILTER
	rtm.exe		a run-time memory manager program used by TASKPLOT
There will also be a number of other files which are needed for the TASKPLOT VGA graphics.
The disk should also contain a set of examples of the tira.ctl files which control the TIRA program:
tira1m.ctl		an example of a tira.ctl file which would be used for the analysis of 1 month of sea level data
tira6m.ctl		an example suitable for analysis of a 6 month dataset
tira1y.ctl		an example suitable for analysis of a 1 year dataset. This contains 58 constituents including seasonal dependence for M2 but no long period tides.
tira1yx.ctl		as previous example but with 63 constituents, the extra 5 being the larger long period tides (SA, SSA, MM, MSF, MF)
One of this set of .ctl files should be used to create the file tira.ctl which is the file which controls the TIRA program (see below). The exact choice of tidal harmonics to include in tira.ctl requires a certain amount of knowledge of tidal analysis techniques.
The disk should also contain a file of example input data (dataeg), the tira.ctl used to analyse the example input data, the printout file from the example TIRA analysis, and the file of resulting daily mean values (dayeg.out):
dataeg			example of input data in TASK-2000 format (see below). This example contains hourly pressure tide gauge data from Signy Island in the South Atlantic for one year 1989-90 with the pressures in channel 6 in mbar. The file has 20 header records followed by 7849 data records. Times are in GMT. There are no bad or missing data records.
tiraeg.ctl		the version of tira.ctl which was used to analyse dataeg and produce the output print file tira.pri.
tiraeg.pri		copy of tira.pri for this run.
dayeg.out		output for this example of daily mean values produced by running FILTER on channel 6 of dataeg.
Do not edit any of the example files as you may want to consult them in future; always edit copies of the examples.
In addition, the disk should contain:
marieeg.ctl	an example of the marie.ctl file used to control a run of the MARIE tidal prediction program.
Other FORTRAN files will also be contained on the disk including timesh.for, daydif.for, adjust.for and adjustd.for. See below for explanations of these programs. 

TASK-2000 Data Format
The tidal analysis program TIRA expects input data to be in "TASK-2000 Format" which is a slight modification of the “ACCLAIM Format” used in the original version of the package. (ACCLAIM is POL's tide gauge programme in the South Atlantic Ocean.) A user will, therefore, have first to write a FORTRAN, BASIC or other program to manipulate his data into TASK-2000 format.  That should be straightforward for someone familiar with programming, but in the event of difficulty the PSMSL may be able to advise.
A TASK-2000 file is a formatted ASCII file in two parts. The first part consists of 20 lines of text which the user can use to record details of the data. In FORTRAN these lines can be read or written as simple character strings.
The second part consists of the data records themselves in format
I6,1X,I1,1X,I4,1X,I3,F7.3,5F8.2
It can be seen that there are 10 columns or 'channels' in these records which are filled as follows:
Channel 1			a counter 1 to Number-of-Records-in-Data-Set. This counter need not exist in the user's first version of a TASK-2000 format data file as it will be defined when the file is tested by ORDER. This sequential counter is used in TIRA to define the start and end of the data period required for tidal analysis.
The TASK-2000 data file MUST be continuous (i.e. no gaps), no matter what the temporal sampling (e.g. 6 minute or hourly or whatever). Continuity is checked by ORDER.
Channel 2		bad or missing data flag. If the flag is 0, then the data in channels 6-10 are defined to be good. If the flag is 1, the record will be treated as bad or missing data.
Channel 3		four digit year (e.g. 1998).
Channel 4		day in year (i.e. 1 - 365 or 366).
Channel 5		hours in day. This should ideally be in GMT (UT) although it is not essential. The user should know what time zone is being used and should be aware that the phase lags of tidal constants obtained by TIRA will be different if different time zones are used for the input data.
Channels 6-10			data. These will usually be sea level values from a tide gauge. However, they could just as easily be air pressures or temperatures or perhaps current meter values. For new users of this software with only one data field to be analysed (e.g. tide gauge values), we suggest that these values go in channel 6, and that channels 7-10 are filled with zero (not blanks).
Conversion from ACCLAIM to TASK-2000 Format
Any data files in the earlier ACCLAIM format may be converted to TASK-2000 format using the simple code in t2kadd.for.
Typical Tidal Analysis Procedure
First, it must be stressed that there is no substitute for having good data to work with if any tidal analysis is to be meaningful. The IOC Manuals and Guides No.14 provide an overview of tide gauge operations which, if followed, should provide good sea level data sets. 
Once the tide gauge data are in computer-readable form, the series of tasks to be performed in a tidal analysis would typically go something like as follows:
1.	The user would translate his data into TASK-2000 format, probably with his data values in channel 6 as described above. The TASK-2000 file can be of any length but it must be continuous.
2.	The data would be inspected with TASKPLOT or with another plotting package at the user's disposal. (There are many commercial packages available e.g. Matlab or PV-WAVE). Obvious bad data (e.g. data spikes) would be identified, and any bad or missing data records would be flagged with a 1 in channel 2. See below for details on how to run TASKPLOT.
3.	ORDER would be run to check that the data are continuous and to set the channel 1 counters. The program prompts for input and output file names.
ORDER checks for continuity by noting the time interval between the first two data records. An error warning is made if any subsequent time interval differs by more than 1 percent from the first one.
4.	A suitable tira.ctl file would be constructed. The main criterion here is the length of the record to be analysed - a short record cannot provide a meaningful set of a large number of constants. The different examples of .ctl files included on this disk should give a guide to tira.ctl construction. However, some existing knowledge of tides and tidal analysis is essential.
The tira.ctl file contains the name of the TIRA input and output data files together control parameters for the program (see below).
5.	TIRA would be run under DOS. If successful, the results of the analysis will appear in the file tira.pri, while the output data file may contain tidal predictions and/or residuals depending on the choice of parameters made within tira.ctl (see below).
6.	If residuals have been requested to be stored in channel 10 of the output data file (for example), then they should be inspected with TASKPLOT for further, smaller errors (spikes, datum shifts etc.) which may not have been apparent from inspection of the raw data in step 2.  If further errors are apparent, then they should be edited and step 5 repeated.
The residuals may show up a number of features (e.g. residual tidal signals) which need some experience in interpreting. Clock timing errors, for example, are famous for generating quasi-tidal residuals.  The IOC Manuals on sea level data measurements and interpretation (IOC Manuals and Guides No.14) will be useful to people unfamiliar with tidal analysis. Several text books on tides (e.g. Tides, surges and mean sea-level, by D.T.Pugh, Wiley, 1987) should be read for background.
7.	Now that the data file has been quality controlled by editing of spikes etc. by means of the channel 2 flags, then FILTER would be run on its channel 6 (in this example) to provide daily mean values. FILTER will not use data from records flagged as bad or missing in channel 2.  Consequently, even if there is only one bad raw data record, there will be at least 2 missing daily means owing to the width of the filters employed.
In conventional sea level research, a ‘daily mean’ is defined to be data low pass filtered to give values corresponding to each day centred on 1200 hours GMT (and not 1200 hours local time).  Consequently, FILTER has to prompt for the time zone of the data in the input data file. This is a positive number of hours for stations east of Greenwich and negative for stations west of Greenwich e.g.
•	if data are recorded in local Indian time then you may have to enter 5.5 to FILTER as Indian time is often 5 hours 30 minutes ahead of GMT.
•	if data are recorded in US east coast time then you may have to enter -6.0 to FILTER if the US east coast time is 6 hours behind GMT.
The resulting 'days' of the daily means will then be 'Greenwich days'.
If you would rather have the time zone of your data set to GMT prior to running TIRA and FILTER, then make use of the program timesh.for described below.
The present version of FILTER can handle 6, 7.5, 15 and 60 minute data and prompts for the names of input and output data files. If any user employs a sampling period different to those included in the present version of the program, then special versions should be constructable.  Data with frequency higher than hourly are first filtered to hourlies. Then the hourlies are filtered to daily means using a Doodson X0 filter. (The IOC Manuals and David Pugh's book describe filters in some detail).
The daily information is written to the output file in format
I6,3I4,F10.3
being year (e.g. 1995), day in year, month, day in month, and filtered daily mean value.
Two work files (fil3temp and fil4temp) are created by the program which may be deleted once the analysis is completed; they are over-written each time FILTER is run. (See a note at the end of this report concerning the record lengths of these files.)
At the end of the program, FILTER will list calendar monthly mean values determined by means of simple arithmetic averaging of the daily values. These mean values are written to another file in the format
	I6,I4,F10.3,I4
being year (e.g. 1995), month, monthly mean value and number of daily means used to compute the monthly mean.
8.	TASKPLOT would be used to display the daily mean values.
9.	MARIE would be used to provide predictions of sea level based on the tidal constants determined by TIRA. These predictions will be made in the time zone for which the original input data, and the tidal constants, have been defined.
MARIE produces an output data file which is also in TASK-2000 format with the predictions in channel 9.
10.	TASKPLOT would be used to display the predictions included in the MARIE output file.
Further Details of TIRA, TIRA.CTL and TIRA.PRI
First, take a look at one of the example tira.ctl files included with this disk. There are ‘comment lines’ in the files which easily guide you where to insert the relevant parameters.
Edit the second line so that it contains the name of the input data file in TASK-2000 format as described above.
Edit the fourth line so that it contains the name of the file that you want to be the TIRA output data file.
Then edit the numbers underneath each of the following parameter names:
NREL = Number of related tidal constituents.
A related constituent is one which is not computed independently from the data but which is computed in relation to another one with a larger amplitude. Related constituents are usually a feature of the analysis of short records.
NSIG = Number of major (independent) harmonic constituents.
LREC = 1st data record to be used in the analysis.
LREC will usually be 1 but it need not be - the analysis can be performed over any subset of the input data file. It is often useful to perform several analyses over different subsets of data in order to search for timing errors.
NREC = Last data record to be used in the analysis.
NREC will usually be the number of records in the data file but it need not be - it could be less than the maximum if required.  (Clearly LREC < NREC).
CHOBS = Number of the column (or ‘channel’) of the input data file containing the observations to be analysed.
This will be 6 in the example described above. It can be any number in the range 6-10. The contents of channel CHOBS of the input data file will also appear in channel CHOBS of the output data file, unless overwritten by predictions (see below).
CHPRE = Column number of the output data file into which tidal predictions will be put.
If this is zero, then no tidal predictions will be put in the output file.
CHRES = Column number of the output data file into which non-tidal residuals will be put.
If this is zero, then non-tidal residuals are not generated.
If CHPRE = CHOBS then the input data will be reproduced in the output file except for those records flagged as bad or missing in channel 2 for which channel CHOBS will contain predictions.  This is most useful if predictions are required to interpolate short data gaps. In this case the channel 2 flag on the output file can be interpreted as flagging interpolated data rather than bad or missing data. (See the report ‘Data Holdings of the PSMSL’ and the IOC Manuals for advice on when or not to fill short data gaps by means of tidal analysis interpolation for mean sea level study purposes. In general, short gaps of about a day or so might be filled this way. Longer gaps should left as ‘missing data’).
These parameters are then followed in tira.ctl by a list of related (if required) and major constituents (see examples). The related constituent lines look like:
   PI1    K1  14.9178647  15.0410686    0.019      0.0
which means that the PI1 term is forced to that of K1 with amplitude ratio 0.019 and relative phase lag zero (other than the phases implied by the equilibrium tide for each constituent). Columns 3 and 4 are the frequencies for each term (degrees/hour).
The major constituent lines contain the name of each term and its frequency in integer form (degrees/hour * 10000000).
Finally, there are four text records which are used for keeping track of things e.g. the location of the station, units and time zone of the data. TIRA can analyse any sort of data (e.g. data in units of centimetres, mbars, cm/sec). For most POL/PSMSL use of TIRA for tide gauge data, the data in channels 6-10 have units of centimetres (for conventional gauges) or mbars (for pressure gauges). Beware possible lack of precision in the F8.2 format if you choose to express data in metres or feet.
Note that no time sampling or time zone information need be entered to TIRA. The program determines time sampling from the data itself.
The printout which appears on the computer screen will also be copied to the print file called tira.pri. In addition, tira.pri will contain a list of computed amplitudes and phase lags for each constituent. The amplitudes will have the same units as the input data, while the phase lags will be relevant to whatever time zone the input data are in. Each line will be in the form:
  32    M2       28.9841042     47.0060    263.742
where the first column is just a counter from 1 to the number of terms in the analysis (note: NOT the index number of the constituent in the TIRA internal arrays listed just below), the second and third are the constituent name and frequency, and the fourth and fifth are amplitude and phase lag. 
TIRA may well crash or hang up if there is something wrong with the input data (e.g. it is not consecutive and has not been checked with ORDER) or if there are errors in the tira.ctl parameters.
The code inside TIRA is set up to handle the nodal variations of up to 120 constituents plus the mean level. The names and frequencies of the 115 which are made use of typically at POL are listed below.  However, only the first 104 are programmed into the version of TIRA on this disk. If any other frequencies are entered, the program will not recognise them, and will assume that such unusual frequencies have no nodal dependence. It will attempt to fit them, although of course it is up to the user to decide what the results may mean.

	Name	Speed	(deg/hr)
	1	Sa	0.0410686
	2	Ssa	0.0821373
	3	Mm	0.5443747
	4	Msf	1.0158958
	5	Mf	1.0980331
	6	2Q1	12.8542862
	7	SIGMA1	12.9271398
	8	Q1	13.3986609
	9	RHO1	13.4715145
	10	O1	13.9430356
	11	MP1	14.0251729
	12	M1	14.4920521
	13	CHI1	14.5695476
	14	PI1	14.9178647
	15	P1	14.9589314
	16	S1	15.0000000
	17	K1	15.0410686
	18	PSI1	15.0821353
	19	PHI1	15.1232059
	20	THETA1	15.5125897
	21	J1	15.5854433
	22	SO1	16.0569644
	23	OO1	16.1391017
	24	OQ2	27.3416965
	25	MNS2	27.4238337
	26	2N2	27.8953548
	27	MU2	27.9682084
	28	N2	28.4397295
	29	NU2	28.5125831
	30	OP2	28.9019669
	31	M2	28.9841042
	32	MKS2	29.0662415
	33	LAMDA2	29.4556253
	34	L2	29.5284789
	35	T2	29.9589333
	36	S2	30.0000000
	37	R2	30.0410667
	38	K2	30.0821373
	39	MSN2	30.5443747
	40	KJ2	30.6265120
	41	2SM2	31.0158958
	42	MO3	42.9271398
	43	M3	43.4761563
	44	SO3	43.9430356
	45	MK3	44.0251729
	46	SK3	45.0410686
	47	MN4	57.4238337
	48	M4	57.9682084
	49	SN4	58.4397295
	50	MS4	58.9841042
	51	MK4	59.0662415
	52	S4	60.0000000
	53	SK4	60.0821373
	54	2MN6	86.4079380
	55	M6	86.9523127
	56	MSN6	87.4238337
	57	2MS6	87.9682084
	
	58	2MK6	88.0503457
	59	2SM6	88.9841042
	60	MSK6	89.0662415
	61	2MN2S2	26.4079379
	62	3M(SK)2	26.8701754
	63	3M2S2	26.9523127
	64	MNK2S2	27.5059710
	65	SNK2	28.3575922
	66	2SK2	29.9178627
	67	2MS2N2	31.0887494
	68	MQ3	42.3827651
	69	2MP3	43.0092770
	70	2MQ3	44.5695475
	71	3MK4	56.8701754
	72	3MS4	56.9523127
	73	2MSK4	57.8860711
	74	3MK5	71.9112441
	75	M5	72.4602605
	76	3MO5	73.0092771
	77	2(MN)S6	84.8476674
	78	3MNS6	85.3920422
	79	4MK6	85.8542795
	80	4MS6	85.9364168
	81	2MSNK6	86.3258006
	82	2MV6	86.4807915
	83	3MSK6	86.8701754
	84	4MN6	87.4966873
	85	3MSN6	88.5125832
	86	MKL6	88.5947204
	87	2(MN)8	114.8476674
	88	3MN8	115.3920422
	89	M8	115.9364168
	90	2MSN8	116.4079379
	91	3MS8	116.9523127
	92	3MK8	117.0344500
	93	MSNK8	117.5059710
	94	2(MS)8	117.9682084
	95	2MSK8	118.0503457
	96	4MS10	145.9364168
	97	3M2S10	146.9523127
	98	4MSN12	174.3761463
	99	5MS12	174.9205210
	100	4M2S12	175.9364168
	101	MVS2	27.4966873
	102	2MK2	27.8860711
	103	MA2	28.9430356
	104	MB2	29.0251728
	105	MSV2	30.4715211
	106	SKM2	31.0980331
	107	2MNS4	56.4079379
	108	MV4	57.4966873
	109	3MN4	58.5125830
	110	2MSN4	59.5284789
	111	NA2	28.3986609
	112	NB2	28.4807981
	113	MSO5	72.9271398
	114	MSK5	74.0251728
	115	2MN2	29.5284789

Expert tidal analysts may be interested that the version of TIRA in this package is suitable for analysis of data sets typically a few years or less, but not for data sets of 18.6 years, for example. This is owing to the way the present TIRA uses nodal factors throughout its code based on the date of the first record, rather than recomputing factors for each record throughout the data set. This is a reasonable approximation for relatively short data sets. Other versions of TIRA are available for particular applications should they be required.
Further Details of MARIE and MARIE.CTL
The harmonic constants obtained from TIRA can be used to produce tidal predictions with the MARIE program. This program is driven by the file marie.ctl.
To set up a marie.ctl for use, copy and edit an existing version e.g. marieeg.ctl supplied with this disk.
Edit the second line of the file to be the name of the output file for the tidal predictions. This file will be in TASK-2000 format and the predictions will be placed in channel 9. All other channels 6-10 will contain zeros.
Edit line 4 to be a scale factor to multiply the predictions by e.g.  if the amplitudes of the tidal constants inserted in this marie.ctl file are in centimetres, then a ‘conf’ value of 10.0 will produce predictions in channel 9 of the output file in millimetres. ‘conf’ will typically be 1.0.
On line 6 (format A18,4X,2I4,F8.0):
Under ‘portname’put the name of the station,
Under ‘ndc’ put the number of tidal constants included below,
Under ‘nth’ put the number of ‘non-standard Doodson constants’ (we recommend this be 0 for most purposes),
Under ‘z0’ put a mean level which you may want added to the predictions (e.g. a datum height for a particular port).
(The previous version of MARIE also had a parameter ‘no’ on this line, which occupied the 4X position in the above format. This parameter is not needed in the present version. Even earlier versions of MARIE also had parameters 'iy' and 'id' on this line, which were the year and day which are 'typical' of the prediction period, so as to compute nodal factors. In the version of MARIE on this disk 'iy' and 'id' are set equal to 'iys' and 'ids' from line 8).
On line 8 (format 3I8,2F8.0,2I8):
Under ‘iys’, ‘ids’, ‘ihs’ and ‘rms’ put the time in year, day in year, hour and minutes in that day from which the predictions should start. ‘iys’ should be a 4 digit year,
Under ‘delt’ put the time interval in minutes for predictions to be made,
Under ‘iye’ and ‘ide’ put the year and day in year at which predictions should end (the program may go one day further). ‘iye’ should also be a 4 digit year.
On line 9 and onwards should be inserted tidal constants obtained from TIRA but NOT including the Z0 constant; only oscillating terms should be included here while any mean level or datum can be inserted in the ‘z0’ column on line 6. You may choose to use an editor to copy lines from tira.pri into this file. However, note that MARIE takes no notice of the counters and constituent names from the tira.pri lines but recognises only the frequencies and the associated amplitudes and phases. If it finds a frequency it does not recognise, the job will stop with an error warning.
If a final check of consistency is required, then a TIRA analysis can be made of the channel 9 predictions. Obviously, the same amplitudes and phases should be obtained within computer precision.

High and Low Water Predictions
The program mariehl.for can be used to produce a list of heights and times of high and low waters based on predictions provided by MARIE. First, MARIE should be run for the required period (e.g. a year) with a time interval (delt) of one minute. MARIEHL will then search within a moving time window (set in the present code to 3 hours moving 1.5 hours each iteration) for when the tide ‘turns over’ either upwards or downwards. This is a less sophisticated, but adequate for most purposes, method than the cubic spline interpolations or analytic methods usually used for turning points, and does not require a mathematical subroutine library.

POLTIPS
The MARIE program is provided so as to enable files of predictions to be made by users of the TASK package. However, if ‘operational’ tide prediction tables are required, for use by the public or for port operations, then a more ‘professional product’ may be required. Users may be interested in the POLTIPS package, which runs under both DOS and Windows, and which provides a more polished presentation of printouts of high and low waters and a PC display of predicted tidal cycles.
POLTIPS was designed by POL in order to provide UK customers with an easy-to-use tidal predictions facility and its default data set contains an encrypted short-set of tidal constants (typically the largest 20 constituents) for many UK ports. The data set is encrypted for UK copyright reasons.  However, the POLTIPS encrypted data set can be extended using constants determined by TIRA or other packages for any other location in the world.
Anyone interested in obtaining a copy of POLTIPS for UK ports, and in extending its application to other locations, should contact Colin Bell of the POL Applications Group at the above address.

The TASK Plotting Module
The Task Plotting Module provides a fairly basic plotting capability for users of TASK-2000 and runs under DOS only. Consequently, users of Unix or other operating systems will instead have to acquire their own plotting software. There are many such packages which could be used (e.g. Matlab).
Requirements
The TASK Plotting Module requires a minimum of a 286 PC with a VGA graphics card and a mouse (if you wish to use the zoom facility). For the program to run, 2 executable files are required: taskplot.exe is the main plotting routine and rtm.exe is a run-time memory manager. These files must be in the same directory.  The recommended minimum memory is 2MB.
Before You Can Plot
TASK includes a simple to use plotting program for graphically displaying input data, residuals computed by TIRA or the daily or monthly mean values computed by FILTER. This program is called TASKPLOT.
However, before using TASKPLOT you must use PREPLOT. The FORTRAN program preplot.for  is a means of setting up the internal files used for plotting either a TASK-2000 data file or a file of daily or monthly mean values using TASKPLOT. In each case, the program reads the input data to determine its start time and recording interval, and will prompt for other information required. This information includes the title for the plot; the text for labelling the y-axis; whether points or lines are required for the plot; the interval for y-axis labelling; and the fraction of the screen area used for horizontal scrolling (see below).
The user is then invited to run TASKPLOT. 
Running TASKPLOT
Make sure you are in the directory containing the executable file, taskplot.exe, and all the relevant data files, including the files made by PREPLOT.
Then at a DOS prompt, type:
	TASKPLOT
The program will read in the data file and produce the plot. If you get an error message as soon as you try to run the program, refer to the section on Limits of the Program later in this document.
Using TASKPLOT
With the plot displayed on screen, you can carry out certain tasks to view the data.
Zooming In And Out
The plot initially displays all the data in the data file. Often, this will be a whole year and is too much data for the display to be of much use. You can zoom in to a smaller section of time by pressing Z.
Move the mouse to the left edge of your required zoom region and click the left button (don't hold it down). Then move the mouse to the right edge of the required zoom region and click the left button again. The program will redraw the screen with only the specified region displayed.
To zoom back out so the complete plot is displayed, press X at any time.
Scrolling Through The Data
When zoomed into a smaller region of the plot, the < and > keys can be used to scroll through the data. The screen will redraw with the plot shifted either left or right by the amount specified in PREPLOT.
This is useful for checking for discontinuity in a data set (such as might be caused by a change of datum), oscillation in residuals (due to a time shift error) or flats in the data set (due to equipment faults like the tide gauge float sticking, or siltation).
Handling Bad or Missing Data (TASK-2000 format files) 
TASKPLOT inspects the flag in channel 2 of each record of a TASK-2000 file to decide whether the data in that record is valid or not (i.e. bad or missing). By default, TASKPLOT will not plot bad data, hence you will get gaps in the plot wherever data is flagged as bad. You can override this by pressing the b key when the plot is displayed. This will include bad data, but will display it in red rather than light blue so it can still be distinguished. Remember that TASK-2000 files must be complete (with, if necessary, the channel 2 flags set if data are bad or missing) and have been checked to have no gaps by running the ORDER program. If the file is not complete, it may appear to be plotted satisfactorily by TASKPLOT, but TASKPLOT will in fact just squeeze up the time series to fill in the gaps making the overall record length appear shorter than it really is. Therefore, always check TASK-2000 files by running them through ORDER first.
Handling Bad or Missing Data (Daily and Monthly Files)
PREPLOT  and TASKPLOT can also be used to plot daily and monthly format files. These files need not be continuous (i.e. they can contain missing days or months). In these cases, missing days or months will be treated as described above for bad or missing data, with the b key used to show the missing daily or monthly means in red with a nominal value which is the average of all the values present in the file.

Exiting The Program
To exit from the program, press q at any time.
Printing A Plot
If you require hardcopy (printouts) of the plot, you must run the DOS GRAPHICS command before running the TASKPLOT program. This command requires you to specify which type of printer you are using. Refer to your DOS user guide for a list of possible printers.
When the plot you require is displayed on screen, press the 'Print Screen' key on your keyboard. If you are running in a DOS session under Microsoft Windows, hold down Shift when you press the Print Screen key.
Alternatively, use one of the many public domain screen grabbing / graphics utilities for capturing the screen as an image.
Limits Of The Program
The main limits of the program are dependent on the memory in your PC.  If you only have 1MB of memory you may run into problems if you make the value on line one of the configuration file too large.

Plotting with Excel
As an alternative to PREPLOT/TASKPLOT, many users will have access to Excel as most PC’s now come with Microsoft products. The fortran jobs excel.for, exceld.for and excelm.for will copy TASK-2000 format files and TASK daily and monthly files respectively into a form that can be easily read and plotted with Excel (i.e. two columns containing year and sea level values). Each of these fortran jobs can easily be adapted for a user’s own requirements. Each one prints a few notes on how to proceed in Excel. However, it will clearly be necessary for a user to become expert with that package. Note the versatility of Excel of being able to change the formatting of axes, zero suppression etc. by clicking on the axes of the plots made by the Chart Wizard. However, note the Chart Wizard restriction to plotting 4000 points which means that only part of a year of hourly values can be plotted at one time. 

Further Data Management And Quality Control Issues
These comments apply primarily to tide gauge data analysts. It is the responsibility of each user to maintain secure copies of original data sets together with full documentation of each step of analysis.
We suggest that a directory is devoted to holding original data, together with relevant documentation concerning the operation of the tide gauge at the time. This computerised information should be cross-referenced to documentation held in paper form in the user's institute.
A second directory could be devoted to holding copies of original data sets translated into the TASK-2000 format required for TIRA, while a third could contain edited versions of the second after quality control checking. Files of daily and monthly mean values would constitute fourth and fifth directories.
The point to always consider is that, if one returns to the study of data some years after it was first acquired, then full documentation and preservation of data sets from each step of analysis is essential.  Users might consider keeping secure copies of all data sets and records in another establishment some distance from the host institute in order to guard against catastrophe.
A second general point to make is that, while a package such as this one may be useful for performing partial quality control in addition to making tidal analysis, it can serve only as a complement to general programming skills. A variety of problems always arise with data (e.g. datum offset changes, timing errors, calibration corrections) which require a user to be adaptable in providing the best quality data sets for analysis. No package can provide a complete set of ready-to-use programs which will take care of all possible complications with data, and which will enable low-level programming to be eliminated. (If it becomes evident that several users require similar ready-to-use additions to this package, we shall of course try to provide them in future versions). We include with this disk a few examples of simple FORTRAN programs from which users can develop their own.
timesh.for reads a TASK-2000 format file (e.g. dataeg) and adjusts the times of the records by a number of hours input from the keyboard. This can be used, for example, to correct errors in the clock in the tide gauge data-logger and/or to shift the time zone of the data from local time to GMT. The program prompts for input and output file names.
adjust.for reads a TASK-2000 format file and adds a fixed amount to the sea level values.
daydif.for computes the differences between daily mean values from two stations which might be nearby. The resulting file of daily-differences can then be inspected with TASKPLOT. (This technique, called ‘buddy checking’, is very simple and yet very powerful in spotting small datum shifts and spikes in sea level records. Similar buddy check programs can be written to perform checks on monthly or annual mean values. A user should make maximum use of such checks to ensure ongoing data quality.  Other tests would include: Are the tidal constants for this data set similar to previous ones from this station, thereby guarding against timing and calibration errors; Is the seasonal cycle of sea level for this year similar to that for previous years? etc. Quality control procedures employed by several tide gauge groups can be found described in the report of the IOC/GLOSS-IAPSO workshop on quality control of sea level data held in October 1992, copies available from IOC/UNESCO, 7 Place de Fontenoy, Paris).
adjustd.for adds a fixed amount to values in a daily mean value file.
monthly.for computes monthly mean values from values in a daily mean value file.
toga.for converts a data file of hourly values in University of Hawaii (TOGA) processing or archiving formats into TASK-2000 format.

Supplementary Notes
Suitable Data Epochs
The package has software components which should work adequately with data from any epoch (e.g. the TASKPLOT plotting module). However, TIRA and MARIE have been restricted to work only with data and predictions from 1801 onwards. There are two reasons for this. First, while we have checked that the parameterisations of astronomical arguments employed in the code are adequate for most tidal applications within this period (see below), we would not wish to encourage their use for tidal work at even earlier epochs, for which more sophisticated treatment of the arguments is necessary. Second, the code is not adapted to  accommodate the calendar changes which took place in different countries at different times (e.g. mid-eighteenth century in the UK). Other tidal prediction software exists at the POL Applications Group which has been specially adapted for historical research. The software is not offered for exchange. However, enquiries into its use may be sent to the above address.
Parameterisations of Astronomical Arguments and ‘Time’
TASK-2000 uses parameterisations of each of the terms (s, h, p, N, pprime) which make up the astronomical arguments of tidal constituents. These parameterisations are essentially those described in the publications of Doodson and Warburg (1941) and Doodson (1954), which in turn go back to Brown (see Cartwright, D.E. 1985.  Tidal prediction and modern time scales. International Hydrographic Review, LXII(1), 127-138). The parameterisations provide the values of each of the arguments at zero hours on the day of the tidal observation. They read:
s = 277.0247+129.38481*IY  +13.17639*DL
 	h = 280.1895-  0.23872*IY + 0.98565*DL
 	p = 334.3853+ 40.66249*IY  + 0.11140*DL
 	N = 259.1568- 19.32818*IY  - 0.05295*DL
pprime = 281.2209 + 0.017192*IY
where	s	 =	the Moon's mean longitude
h	=	the Sun's mean longitude
p	=	longitude of Moon's perigee
N	=	longitude of the Moon's ascending node
pprime	=	longitude of Sun's perigee
and where IY (an integer) is year number relative to 1900 e.g. IY = 1 for 1901	or -1 for 1899
and DL (also an integer) can be written IL + IDAY - 1
where IL is the number of leap years from 1900 (which was not a leap year) up to the start of year IY i.e.
IL = (IY-1)/4 in FORTRAN
and IDAY is the day number in the year in question e.g. for 12 January 1905 then DL = 12. For years less than 1900 then one can compute
IL = IABS(IY)/4  and
DL = -IL + IDAY - 1 in FORTRAN.
A tidalist will recall that a constituent can then be expressed, aside from nodal factors, essentially as
H cos (t + V - G)
where H is the amplitude of the constituent, G the phase lag (assumed Greenwich phase lags for this discussion),  its angular speed and V the astronomical argument composed of the combinations of s, h, p, N and pprime. The time ‘t’ which multiplies  is the time elapsed since the zero hours on the day in question.
A question arises as to whether these parameterisations are adequate for the period 1801-2099 for which TASK is intended as some authors’ parameterisations employ quadratics in time and/or are expressed relative to epoch-2000 rather than 1900. The answer is ‘yes’. We have tested alternative expressions for s, h etc. about epoch-2000 and found negligible difference (i.e. order 0.01 degrees) compared to those obtained using the above expressions.
Also, what is the effect of ‘leap seconds’ in the value of ‘t’ for ‘time’ as used within TIRA and MARIE? Cartwright (1985) shows that ‘t’ used for ‘t’ should always be a close approximation of UTC/GMT (again assuming we are working with the Greenwich time zone, other time zones result in simple phase shifts). However, as UTC contains leap seconds which result in offsets of up to a minute during the twentieth century compared to ‘Emphemeris Time’, if one just uses one version of ‘time’ (i.e. UTC/GMT) for the period 1801-2099, will there be a possibility of bias introduced into computed harmonic constants from a misunderstanding of which ‘time’ to use?
The answer is essentially ‘no’ for the period of interest. Consider the speed of s (approximately 13 degrees per day). A misunderstanding of ‘time’ of the order of a minute (which is approximately the integrated number of leap seconds from 1900 to the present) would result in s being altered by approximately 0.01 degrees. Consequently, although most tidal constituents will have astronomical arguments described by combinations of multiples of the basic s, h etc. parameters,  any errors due to the use of different time bases will not be major ones.
(Note that, in earlier versions of the TASK package, pprime was set to a constant value of 282.2 degrees. Also small corrections have been made to the astronomical arguments for PI1 and PSI1 which will be of only minor interest.)
Difference of Sa Phase Lags in Different Packages
Users should note that different tidal analysis packages have different conventions for the annual tidal harmonic Sa (and possibly some other tidal constituents, albeit small ones). In TASK, and in other tidal analysis packages at POL, the astronomical argument of the annual component is given by ‘h’ rather than by ‘h-pprime’ which is the convention of the Foreman (1977) software used in, for example, the package of Pat Caldwell from the University of Hawaii.
The reason for the use of ‘h’ is described in Table 4.1 of David Pugh's 1987 book (Pugh, D.T. 1987. Tides, surges and mean sea-level: a handbook for engineers and scientists. Wiley, Chichester, 472pp.). The point is that in most locations the gravitational part of Sa, for which the ‘Doodson numbers’ are (0 0 1 0 0 -1) and for which therefore the astronomical argument will be ‘h - pprime’, will be much smaller than the ‘radiational’ annual component, for which Doodson numbers of (0 0 1 0 0 0) and astronomical argument of ‘h’ are more logical over a limited period of time for which pprime (speed of solar perigee) can be considered constant. (The argument for the semiannual component Ssa is ‘2h’ anyway in all packages).
For example, if a phase lag of zero is obtained for Sa from TASK, it means that the observed annual cycle peaks around the spring equinox. A zero phase lag for Sa obtained from the Foreman software would correspond to an annual cycle maximum around the start of the year.
This different convention of astronomical argument for Sa is of no importance if the same package is used both for tidal data analysis and tidal predictions. However, if a different package is used for analysis and predictions, then the user should be aware of the possible errors which will be introduced at annual period. Furthermore, if harmonic constants are obtained by tidal analysis and submitted to a data centre (e.g. that of the International Hydrographic Bureau), then care should be taken to state exactly which convention has been used for Sa.
TIRA and MARIE ‘Features’
•	There is a feature of TIRA such that the program will abort if the last record of the input data file is a ‘bad data’ record (i.e. channel 2 flag is 1). The solution is to edit the input the input file such that the last record is a good data record (i.e. channel 2 flag is 0).
•	MARIE will object if the tidal constituents in the marie.ctl input file are not ordered in terms of an increasing index number of the frequencies of the ‘ZZ array’ in the program data statements.
•	TIRA and MARIE are set up to read files called tira.ctl and marie.ctl (lower case) because most of our work is within a Unix environment which uses lower case file names. The code will also work without modification under DOS, as DOS will find the .ctl files anyway. However, if the operating system you are using has case-sensitive file naming, you should ensure that the .ctl files have lower case names. 
•	The versions of TIRA and MARIE used in this package are written in single precision FORTRAN. In some analyses, numerical precision problems have been experienced when using many tidal constituents (e.g. in areas of large tidal amplitudes with many shallow water terms). In that case, advice on converting to double precision versions of the programs may be obtained from Ian Vassie. However, the standard sets of harmonic constants included in the example tira.ctl files function satisfactorily in single precision and should be adequate for the data quality control purposes for which this package is intended.
FILTER ‘Features’
FILTER uses direct access files for temporary work space. Some computers (e.g. Silicon Graphics workstations) define record length in terms of full words, others (e.g. Sun workstations or DOS computers) define record length in bytes. The record length used by FILTER has to be set to 4 or 16 respectively. FILTER reads this value from the first line of the file filter.dat which can simply be edited to the appropriate value for the computer.
FTP Notes
If you have obtained these files via ftp, and if problems are experienced with some of them, first check that you have transferred ASCII and BINARY files from the /asc and /bin directories respectively using the appropriate ftp file transfer options.