1/6/06
	parse_t.f90 : Actually, there are 4 versions of this code,
		      parse_[tuw2].f90, for each variable of interest.

		      What this code does is take the ASCII data file
		      (from format.f90 I guess) and split it up into
		      <ntim> data files, each containing 1 timestep
		      of the data.  It contains the full plain of data.

		      The reason for this was to make it easier to plot
		      in IDL, but it may be a wiser/better course to simply
		      deal w/ the time steps in IDL.  This will at least
		      save some space and bookkeeping in the directory tree.

	format.f90 : This code converts the non-ASCII triple output to
		     ASCII since it's easier for me to deal with that way.

		     YOU MUST "iditarod>setenv F_UFMTENDIAN big" otherwise
		     you'll get garbage.

		     Upon further inspection, it looks as though parse_t.f90
		     was absorbed into format.f90.  May want to create another
		     code that leave all the data in 1 file.

		     The old version of format.f90 created a file,
		     reordered_[tuw2].dat which was the input to parse_t.f90.
		     It was obviously done away with.

		     Note that part of what format.f90 does is join the 
		     n processor files from triple.  That's useful.

		     Currently, format.f90 only handles variables described
	  	     by 1 character ('t', 'u', '2') and will likely bomb
		     on a multi-char variable like 'kx'.

		     Even if you eliminate the multiple file output for each
		     timestep, you need to retain the tfile.f90 subroutine
		     in order to open the processor files.