CHATS: software Messages: 8 Entries..

Modified configs.xml for the new low, wide position (per logbook 291).
2m/3m 1.72m spacing. V.azimuth not altered yet.

I finally got around to making this configuration ops5.  I've renamed the
configs simply high.xml, mid.xml, and low.xml, referring to the heights of
the horizontal array and config.xml simply points to them in turn.

I've assumed that the times that specify the ops periods are in GMT.

Changed config to ops4 for sonic spacing of 1.72 m and height of 10 m

I used Gordon's instructions, logbook entry 59, to start new config for
the horizontal array at 2.5 m.  Will rerun covars.

3/30: I forgot to edit Vazimuth.q as described in logbook #54

Gordon's instructions for chaningin the config, e.g. when changing the 
heights of the horizontal array:

cd config

create the new xml, for example:

cp ops1.xml ops2.xml

edit ops2.xml, changing the heights of the sensors for
  There are a bunch of them.

Also change the heights in the section
.  There are
a bazillion of them (pays to have quick vi hands, or
you can do global changes with this vi command:

1116,1348s/9.6m/4.9m/g

where you figure out the line number range by looking at
the info line in vi.

Then you're done editing, check for syntax errors:

ck_xml ops2.xml

It will either report an error, or a long list of sensors and variables
names if things are OK.

edit configs.xml. Add an entry for the new config.  Here are the
entries for ops1 and ops2. The times are in UTC. Note
that the times cannot overlap.  Update the end
time of the previous ops.

  
    

  
  

To check the configs:

proj_configs -l configs.xml

Assuming the new operations period has started (the begin
time has passed) then shut down dsm_server:

ps -ef | fgrep dsm_server
kill -HUP pid

Then edit $ISFF/scripts/run_server.sh
to change the xml file (when I get the
time I can make that step unnecessary).

Then run it

$ISFF/scripts/run_server.sh

Then run statsproc:

$ISFF/scripts/run_statsproc.sh

Also edit Vazimuth.q as described in Entry #54.

With new array heights, it is necessary to edit dat.Vazimuth in the file
chats.q in directory /usr/local/isff/projects/CHATS/ISFF/S:

Need to increase variables aa1 and aa2 by 18 for every new pair of
array heights.  Note '36'  corresponding to 2 array heights x 18 sonics.
Note that these might be other than exactly 180 if we had measured them.

    aa1 = rep(180,36) + 90
    aa2 = rep(180,36) + 90

Also need to increase the array name vector:

    an = c("1b.9.6m.ha","2b.9.6m.ha","3b.9.6m.ha","4b.9.6m.ha","5b.9.6m.ha",
    "6b.9.6m.ha","7b.9.6m.ha","8b.9.6m.ha","9b.9.6m.ha",
    "1t.10.6m.ha","2t.10.6m.ha","3t.10.6m.ha","4t.10.6m.ha","5t.10.6m.ha",
    "6t.10.6m.ha","7t.10.6m.ha","8t.10.6m.ha","9t.10.6m.ha",
    "1b.4.9m.ha","2b.4.9m.ha","3b.4.9m.ha","4b.4.9m.ha","5b.4.9m.ha",
    "6b.4.9m.ha","7b.4.9m.ha","8b.4.9m.ha","9b.4.9m.ha",
    "1t.5.9m.ha","2t.5.9m.ha","3t.5.9m.ha","4t.5.9m.ha","5t.5.9m.ha",
    "6t.5.9m.ha","7t.5.9m.ha","8t.5.9m.ha","9t.5.9m.ha")

Gordon wrote:

Doing dpar(robust=T) gets around the problem
of dat("w'h2o'"). Is that good enough for gov't work?

It is failing in dat.Scorr (which is a complicated
mess), trying to conform dat("heights.sonic") to
w'h2o'.  Not sure why...

Fixed logbook problem:

Gordon wrote:

Converting the logbook to html is failing here, complaining
about an entry that doesn't have a date.

Could you exit logbook and re-enter?

If you get an error then you may have to fix

$ISFF/projects/CHATS/ISFFlogbook/tklog.log by hand editing.

(Make a backup of it first).

I see this empty entry at the end. Perhaps it is causing the
problem:

50
{author {}} {type {}} {site {}} {title {}} {graphics {}} {text {
}}

I'd nuke that entry if restarting doesn't fix it.  Make sure
you keep the "end" record.