FLATLAND96: Site base Messages, 16 Entries..

bkfiles run for 2 Jul 96 through 10 Jul 96.

This backup writes aster raw_data, sysbackups,
pam ppf and pam netcdf files to tape.

/usr/local/adm/backup/backup.flatland run on 11 July 1996.

This probably does not need to be run more
than every two weeks or so, since the sysbackup
files are written to the aster archive tape during
a bkfiles.

During yesterday's bkfiles and backup.flatland,
the Exabyte was agonizingly slow. Does this mean
that it needs to be cleaned?

There are several plots which combine several variables (weather, energy 
balance) which die with "length not a multiple..." errors and exit dplot.
This happens when "Plotting Recent" while the netcdf files are being updated.
We could spend a lot of time modifying the plot codes, but in the meantime
there are two workarounds:
1. Don't make these plots at these times (easy to know because the RASS also
goes off at the ppf->netcdf update times!)
2. Use "Plot" rather than "Plot Recent".
Running the plots manually (not window-driven) avoids having to clean up
the dead windows when this occurs.

A new version of tklog was installed.

Old version is in:      /home/aster/apps/tklog/tklog.save.16jun96

Modifications relate to HTML generation:
        - site # grouping added.
        - both ascending and descending message ordering available.
        - all chronological messages are now contained in the
          'contents' file, not just the message titles.
        - index button added to return to top of a file, where
          the header contents for that file are located so that
          it's a bit faster than scrolling (provided the browser
          is accessing the files locally).

I found that the temperature coefficient for the CS615 needed to
be multiplied by 100 in fun.qsoil.plot.  I have made this correction
and changed this routine to plot only the corrected data if CS615=T.
This is now the default in fun.soil.pam.

The temperature correction now appears to eliminate the diurnal cycle
in the soil moisture at the lower soil moisture values found at sites 1
and 2 (10-20% by volume).  It is insufficient at the 30% soil moisture
being measured at site 3.

High OVC to south, clear to north - a front is expected today.
Winds SW @ ~4 m/s - Steve S. has a headwind biking in (again!)

The phone company just disconnected the line we have been calling to connect
to the network.  (net66 says that Ameritech messed up in the process of 
changing to a centrex system).  Anyway, we have been switched to a new
number: 344-5876, so I updated /etc/dp/dp.conf.  I couldn't figure out a
graceful way to stopdp (I thought there was a command by this name, but I
couldn't find it), so I "kill -9"'ed the process and restarted it using
/etc/dpctl.  This appeared to work.  net66 said that they also changed us
off of the latest modems "...tech" and onto a Motorola one.  I noticed
that we are now back on at 21600 baud.

I hope the line is stable from now on...

It has become apparent that we want a command to look at recent data from the
stations.  Steve S. told me about the "last" command, which works on stout
but not here (even when using the ppf= option).  As a temporary cludge, I
have created the aliases in the aster account: "last1", "last2", and "last3" 
which run the "last" command on stout for each pam station.  This serves our
need for the moment.

Version 2.9 of TKLOG is now installed.

Graphics image files are now included in the HTML file generation.

GIF is the preferred format.  TKLOG will attempt to convert non-gif
images into gif for the html stuff to save space, load time, compatibility,
etc.   Multiple images per message are possible in Matt's graphics handlers,
and also for the html.

I've connected the S+ legend locator function to my fun.array.minmax routine,
which I think will speed up multiple day plotting.

I've changed the atik calibration routine to have the default ambient pressure 
entered as a parameter in prep.config.  I've set this to 990mb for FLATLAND.

I just "make"d prep, covar, xcockpit, and xstrip and restarted covar on
cosmos.

Gordon: I tried another way to do this at first, but the variable
"p_baro_share" was being written to by some routine which I couldn't
find, so I just overwrote the value in sonic_atik.  You may want to
look at this further.

Rebooted ASTER after fouling up the cosmos data collection.
Documentation on ASTER operations is sparse.  Sun system administration
documentation is not here.  Splus documentation not here either.

GPS readings for the base station and station 1 were taken yesterday but had to
be repeated today due to faulty programing on the base station receiver.
thought I had it set up to take 24 hrs of data through 18:30 today, but when
I went to download, I found only 10 min from yesterday just before the program 
was to begin! readings must be concurrent so station 1 was repeated also and
it looks like everything was successful.
quality control checks are not possible yet due to the PC being minus a
math coprocessor. I will check with UNAVCO tommorrow to see if anything else
can be done.
GPS antenna height was transfered to pam station through the use of the
transit.


center of lens of transit is 19 cm above choke ring ( the altitude that the GPS
data will provide to us ). the height of the transfer via transit to the pam
station #1 was 73 cm above the pressure port, and 205.8 cm above the bottom of
the electronics box.
therefore, GPS derived altitude is 186.8 cm above bottom of box and 54 cm above
pressure port.
(by the way, a measurement was taken from the choke ring to the surface and from
the surface to the bottom of the electronics box, as an alternate method of 
transfering antenna height to the pam station, and it was off by a whopping
4.6 cm! seems like the transit is a lot of effort when the GPS accuracy is
only good to within a half a meter!)

GPS readings for the base station and Pam 1-3, and both ISS trailers are
now completed, along with quality checks.
results are as follows:

GPS antenna height was transfered to pam station through the use of the
transit.


PamIII station 1:

	Gps derived altitude - 186.8 cm = height of elctronic box bottom
	Gps derived altitude - 54.0 cm = height of external pressure port

PamIII station 2:

	Gps derived altitude - 158.0 cm = height of electronic box bottom
	Gps derived altitude - 28.0 cm = height of external pressure port

PamIII station 3:

	Gps derived altitude - 40.6 cm = height of electronics box bottom
	Gps derived altitude + 91.6 cm = height of external pressure port

Monticello ISS (ISS #1)

	Gps derived altitude - 24.0 cm = height of port on pressure sensor
	Gps derived altitude + 59.0 cm = height of external pressure port

Senica ISS (ISS #3)

	Gps derived altitude - 5.0 cm = height of port on pressure sensor
	Gps derived altitude + 38.4 cm = height of extrnal pressure port
	Gps derived altitude - 62.2 cm = height of balloon launching platform

all measurements were also done using a simple tape measure as opposed to the
transit, and the worst case error was found to be 13.0 cm, best case error
was 2.9 cm, and avg. was 7.1 cm.
	not bad for an accuarcy of +- 50 cm from Gps

	the actual Gps antenna heights will be processed from the data in
Boulder with the apropriate software provided by UNAVCO.
Quality checks were completed in the Pam base for all the data, and all
surveys looked quite good.