CACHE94: SOFTWARE Messages: 23 Entries..

xstrip version in sun4/ needs update 
 

AIR sensor removed from dailyplots: 
 
 Psyc.config.S was modified to remove the AIR 
sensor from daily plots starting on day 222. 
 

More changes for dailyplots: 
 
 Tony wanted co2 to be correlated to 
the atik sonic instead of solent. So 
sonic.config.S in sfun/CACHE94 was changed. 
This file was also changed to include 
"c.pvm.10m.walk". 
 

Synch problem in fun.plot.prep 
 
fun.plot.prep(c("co2.licor.10m.walk","u.atik.10m.walk"),1994,228) 
start 231930 
end   232000 
data are getting synched to 10Hz 
 
results in missing line segments in the co2.licor signal, instead of 
expected data fragmentation of u.atik signal. 
 

Data Error in fast228200000 after 23:19  
 
 Tried data for co2.licor.10m.walk 
 
fun.plot.prep stops displaying data after that time. 
prep stops with a segmentation fault. 
data_dump does ok. 
 

corrupted marigold.covar 
 
We got another bad timetag  which advanced the time in marigold.covar 
(but not solentfssp.covar!?) to j=233.  Since emacs kept on acting 
strange when I tried to edit this file, I just used "sed" to change 
j=233 to j=232.  Note that this left a few bad entries with s=00.0000? 
in the data file, which (presumably) will be used instead of the good 
entries for this time period, but I'm not going to worry about this 
in the field. 
 
I restarted covar_marigold for this change (just to ensure that editing 
an open file wasn't causing the emacs problems).  I also made a copy 
of the unmodified file as marigold.covar.first. 
 

Analytic Applications IR hygrometer installed 
 
I've spent the day adding the ir_AA_1 calibration routine and all of 
its associated configuration files to connect this instrument to our 
data system.  The files I've changed are: 
ir_AA_1.c 
calib/Makefile.cpp 
calib/calib_defs.h 
sio_converters 
sio_msg_formats 
channel_config 
archive_config 
prep.config 
prep.config.raw 
did.config 
idraw/ops1 
create_cdl.csh 
cov2netcdf.csh 
covar_cosmos.csh 
 
After mucking around with all these files, I re"make"d prep, xstrip, 
xcockpit, and covar. 
 
We mounted the sensor at 7.5m on the flux tower.  (Actually, it 
is closer to 7.6m [2.4m down from Tony's 10m mark on the tower]  
to utilize a rung for support.) 
We rebooted cosmos to have the changes take effect. 
 
I am archiving the "raw" output from this sensor, which has all of 
the internal parameters used to measure humidity, but only sending 
the derived humidity, internal temperature, and reference (signal 
strength).  It should be possible to write another calibration 
routine which uses the raw data if necessary (e.g., a different 
calibration is needed). 
 
Now I get to think about daily_S_plots for this sensor. 
 
BOY, THIS IS A LOT OF WORK!  WE NEED AN EASIER WAY TO ADD SENSORS! 
 

Tex and Latex 
 
These don't appear to be installed on aster? 
 

Splus TRUNC_AUDIT 
 
I got an error something like:  
truncating to most recent 100000 characters, 
truncating produced only 95xxx characters 
file not truncated. 
 
I've never seen this before.  I just deleted .Audit to prevent 
S from screaming at us all the time. 
 

'bkfiles' script modified 
 
The 'bkfiles' script was changed to combine functionality 
with the bkfiles_kill script. 
 
Bkfiles will now query the operator (if any) to go into 
and purge all existing files in the  raw_data/backup 
directory tree and then proceed with the copy and tape 
archive as usual. 
 
Bkfiles_kill is no longer needed but can still be run 
as usual. 
This allows an operator greater flexibility to retain 
'yesterdays' data files for further examination without 
copying it into the save tree (which obviously can still 
be done if longer retention of specific files is desired). 
 
For CACHE, anticipated capacity of /data is about 5-days 
worth of data, therefore, retaining more than 4-days in 
the backup tree is a very bad idea. 
 

Don't use did aliases? 
 
prep bug. 
 
We just found that prep does not resample to evenly-spaced 
times (using r=xx) if aliases are used in did.config.  I.e: 
chanA.peter	290 
t.licor		290 
caused prep to not resample chanA.peter data.  This showed 
up when fun.plot.prep gave "all missing data" when requesting 
chanA.peter alone.  (If multiple channels were requested, 
all were synchronized.) 
 
 

 
Also discovered that swap space was all used up. 
Found an Splus session which seemed to be  
using a bunch of space; it had a message about 
not being able to allocated dynamic message. 
When I killed the Splus session, 40 MB swap 
space returned to the system. 
 
It looks like the daily plots ran into the 
same problem, since tey are not running 
and have not finished. I will restart them 
by hand. 
 
 

System Backup 
 
Done this morning! 
 

Delayed entry - xfssp devours swap space! 
 
Yesterday afternoon, Charlie discovered xfssp had 
grown to gargantuan proportions, and aster had very 
little swap space left. Killing the hog process, 
which had been up for several hours, 
brought things back to normal. 
 
 

t.AA.7.5.flux spikes fixed! 
 
The negative going spikes we have been seeing 
were caused by an incorrect calib function, 
which was occasionally parsing random '-' signs, 
and assigning them to the temperature reading. 
I changed this today, and restarted covars and 
cockpits. Looks good now. 
 

xfssp definitely has a big memory leak 
 
I have been running xfssp and watching its memory usage. 
It has grown from about 600K at start to consume 5Meg of 
swap space in about 0.5 hour. 
I will suggest it should not be left running for long periods 
of time. 
 

For some reason the cosmos covar was not 
running from 0257. Perhaps I forgot to start
it after the cosmos reboot? I ran it
in post processing mode "covar_cosmos 300 246";
it claimed that it was updating the cdf file.

Restarted it for realtime mode around 1600.

Just added jd display capability to tklog. Will
make it a lot easier to relate to the daily plots.

The weekly system backup is on Aster Backup tape # 1

Now that the two krypton hygrometers are broken,
we want to calculate latent heat flux from the AA
instrument. This means that we need w.atik.10m.flux -
h2o.AA.7.5m.flux correlation.

I have modified cosmos_covar to calculate this
quantity. It is showing up in covar.cosmos,
in a variance group with dids of 202:400:401:402.

I have added variance group "-v w.atik.10m.flux:h2o.AA.7.5m.flux"
to cov2netcdf.csh. This causes cov2netcdf to croak when
processing archive files, since for some reason the AA data is 
going into separate archive files. It would not
help for it to make it any further, though, since:

I tried to add h2o.AA.7.5m.flux to a covariance group containing
w.atik.10m.flux in the obscure create_cdl.csh script. For some reason,
it generates broken cdl, which ncgen then chokes on. I had
to abandon this attempt.

In any event, the realtime covars are putting the correlations
into cosmos.covar. We just can't get them into the cdf files.

It turns out that create_cdl does not want to let you mix variables that 
do not share common suffixes. It seems to have something to do
with the npts varaibles in the cdf files. If the AA instrument were
named h20.AA.10m.flux, I guess that it would work.

I have put everything back to the way
it was originally, I think. The upshot
of it all is that I am unable to make 
the 7.5m moisture flux available for
plotting!

It turned out that just having an
unexpected covariance group in the covar output
(w.atik.10m.flux:h2o.AA.7.5m.flux) really
fouled things up. cov2netcdf, when it found
this group in the covar output, but not in
the netcdf file, would burp and just stop
filling the netcdf file. This caused the
covar netcdf to loose about half of it's
variables. (Recall from comment 277 that I was
forbidden from correlating two dids with different
suffixes).

So.... I had to take out the covariance specification
from covar_cosmos. I used grep to find offending
entries in covar.cosmos, and then built a sed script
to remove them (emacs is ungracious about editing an 11MB file,
and vi, well...it just dies, violently). 

But this was not enough! For some reason, I had to run
covar_cosmos in a post processing mode, which apparently produced a
different cdf file than running cov2netcdf directly.
So I had to run covar_cosmos for 248 and 249.

I have noticed that the data plot sometimes overwrites the
field label and/or the scale numbers.
Suggest that the labels be a different color, and be refreshed
more often.

Removed references to non-existent 4m and 6m props from fun.prop.config,
and changed prop indexing in prop.config and sonic.config.  These two
wind sensors showed up on the dailyplots for JD 251-253 only.  Why were
they put back into prop.config???