>From: "James R. Frysinger" <address@hidden>
>Organization: College of Charleston
>Keywords: 200111061842.fA6Igt112242 LDM binary install
Jim,
>Logged on remotely as frysingj and saw you were on as ldm; tried 'talk'
>to no avail.
At the time you saw this, I was probably in the process of logging off
from home and heading into work (for a meeting, groan).
>I saw (via 'who') that apparently two of my remote connections to ldm
>on Dec 06 had failed to close out; killed them manually. I wonder if
>this might have led to the strange behavior, though I doubt it would.
This would not have been a problem.
>From address@hidden Tue Dec 11 10:46:52 2001
>I see you folks are hard at it, straightening out my mess.
Let's just say that I was putting the icing on the cake :-) All-in-all
things weren't so bad, but some tweaking was in order. I will detail
what I did, and why I did it below.
>I'm at home
>today grading papers and otherwise bored to death. (G.W. Bush has the
>downtown are tied up with his visit to The Citadel.)
Better you than me :-)
>If'n you need to call me to do some root type things that can be done
>remotely, or whatever, I'm at .....
OK, thanks. I think that everything is moving along nicely now. The
LDM is merrily grabbing data and the ldm-mcidas and XCD decoders are
decoding like crazy. Your disk is getting populated with data, and
I removed a bunch of data files that were the results of the default
pqact.conf FILE action that comes with a new LDM install. I have since
commented out that action and freed up on the order of 8 GB of disk
space that was being used by that data.
OK, so here is what I have done:
-- as user 'ldm' --
1) corrected a typo in the 'xcd_run DDS' action in pqact.conf. The
action previously read:
DDPLUS|IDS ^." PIPE
decoders/xcd_run DDS
HRS ^.* PIPE
decoders/xcd_run HRS
it should read (and now does):
DDPLUS|IDS ^.* PIPE
decoders/xcd_run DDS
HRS ^.* PIPE
decoders/xcd_run HRS
This typo was preventing POINT source data decoding by XCD.
2) modified all ~ldm/etc/pqact.conf entries to specify directory/decoder
as the decoder to run. As I mentioned in a previous email, this
is important for folks (like you) who will be running ldmfail from
cron.
3) modified ~ldm/etc/ldmd.conf to:
a) include the full pathname for xcd_run in its exec line:
exec "/export/home/ldm/decoders/xcd_run MONITOR"
this was needed for the same reason as 2)
b) added request of FSL2 data from atm.geo.nsf.gov. The FSL2
data is the FSL wind profiler data. This is not as useful
for East Coast folks such as yourself as it is for sites
in the middle of the country, but I figured you might want
to look at the data anyway.
c) modified the request lines for UNIDATA so as to make switching
the feed host easier:
request UNIDATA ".*"
pluto.met.fsu.edu
# cirp.met.utah.edu
to change the feed from pluto to cirp, you only have to comment
out one line and comment the other:
request UNIDATA ".*"
# pluto.met.fsu.edu
cirp.met.utah.edu
d) added a request for the NMC3 feed (aka FNEXRAD) from atm.geo.nsf.gov.
This feed contains NEXRAD floater sites and several regional
composite base level reflectivities in grib format. This
product is especially useful in GEMPAK and will be in McIDAS as
soon as I figure out how to decoded it with the XCD grib decoder.
I will add the pqact.conf actions needed to deal with this data
later today. The request will need to get updated to FNEXRAD
after atm.geo.nsf.gov's LDM gets upgraded to 5.1.4.
e) I setup the request line for NLDN lightning data from SUNY Albany.
You need to send an email to Dr. David Knight <address@hidden>
(with CC to address@hidden) requesting that they allow
weather.cofc.edu to request an NLDN feed. Your LDM is currently
requesting the data from SUNYA, but it is being denied access
by their LDM server, so you need to send David a request for
a feed.
f) I removed allow lines for NLDN data for pluto.met.fsu.edu and
cirp.met.utah.edu. NLDN data can NOT be relayed by Unidata IDD
sites. All NLDN feeds are point-to-point from SUNY Albany to
the university desiring the data. Also (I noted this before),
the NLDN data and/or depcitions of that data (GIFs (tm), JPEG,
etc.) may _never_ be posted on a web page that can be viewed
from any site not on the individual university's campus. Breaking
this restriction will result in immediate, and permanent loss
of the data.
g) allow ANY from your upstream feed hosts
h) modified ~ldm/etc ldmd.pluto.met.fsu.edu and ldmd.cirp.met.utah.edu
to:
o startup '/export/home/ldm/decoders/xcd_run MONITOR'
o request UNIDATA from the appropriate host
o request FSL2|NMC3 from atm.geo.nsf.gov
o only request NLDN from striker.atmos.albany.edu
o allow ANY for your upstream feed sites
These mods should make things work correctly when ldmfail changes
the host you are feeding UNIDATA from.
4) edited ~ldm/decoders/mcscour.sh to keep 3 days of McIDAS POINT data
onlne. This was set to 2 days.
5) stopped and restarted the LDM numerous times to test out all of the
changes made
6) added a cron entry that rotates the ADDE server log file, SERVER
(SERVER.2 -> SERVER.3; SERVER.1 -> SERVER.2; SERVER -> SERVER.1;
and a new SERVER gets created). This log file is rotated once a week.
7) annotated 'ldm's crontab entries (so it is easy to read what the
entries are all about (crontab -l)
<as user 'mcidas'>
1) modified ~mcidas/.mcenv to set the environment variable ADDE_LOGGING.
Added a REDIRECTion for SERVER* to /export/home/mcdata/ldm/logs.
SERVER will be the file in which ADDE requests are logged. SERVER
will be "rotated" by an 'ldm' cron entry (see 6) above). Once
the logging gets rolling, you can use the McIDAS ADDEINFO command
to review ADDE use. Use the HELP ADDEINFO sequence from a McIDAS
session running as 'mcidas' for information on what you can list
out with this command.
2) edited .cshrc and moved things around a bit (no major changes). Added
an alias for 'lt' which is a long, time oriented list whose output
is piped into 'more'. Use:
lt /export/home/mcdata
3) turned on generation of GOES East/West composite imagery:
cd ~mcidas/workdata
route.k REL C
Turned on generation of GOES and topography composite imagery:
route.k REL N
The composite products are being created. The are accessible
as are the other images ingested from the Unidata-Wisconsin feed
(LDM feed type MCIDAS which is part of the UNIDATA feed) in the
ADDE dataset RTIMAGES:
imglist.k RTIMAGES/GEW-IR.ALL
Image file directory listing for:RTIMAGES/GEW-IR
Pos Satellite/ Date Time Center Band(s)
sensor Lat Lon
--- ------------- ------------ -------- ---- ---- ------------
1 G-8 IMG 11 DEC 01345 11:15:00 26 100 4
2 G-8 IMG 11 DEC 01345 12:15:00 26 100 4
3 G-8 IMG 11 DEC 01345 13:15:00 26 100 4
4 G-8 IMG 11 DEC 01345 14:15:00 26 100 4
5 G-8 IMG 11 DEC 01345 15:15:00 26 100 4
6 G-8 IMG 11 DEC 01345 16:15:00 26 100 4
7 G-8 IMG 11 DEC 01345 17:15:00 26 100 4
8 G-10 IMG 11 DEC 01345 18:00:00 26 100 4
9 G-10 IMG 11 DEC 01345 19:00:00 26 100 4
10 G-8 IMG 11 DEC 01345 10:15:00 26 100 4
imglist.k: done
Finally, I logged on as you and snooped in the .cshrc file looking for
typos, etc.
1) I moved the definition of path down below the block that defines McIDAS
stuff (not a biggie; just part of me being anal).
2) set DISPLAY back to my machine at Unidata (after setting my xhost to
allow the connection), and then started a McIDAS session:
mcidas config
Selected auto start of MCGUI and save settings to defaults file. The
latter setting caused ~frysingj/.mcidasrc to be created. I also set
up defaults for starting a session with 600x800 windows instead of
the default 480x640. I find that the larger display windows are much
more pleasing.
Exercised the MCGUI and found that things appear to be working reasonably
well. I plotted:
meteorogram
latest GOES-East VIS image
surface plot of temperatures over South Carolina
overlaid surface T plot with contours of surface pressure
overlaid surface T and pressure map with fronts from the same time
All of these displays were created using data that weather had received
over the IDD and decoded with ldm-mcidas and McIDAS-XCD decoders.
So, I can verify that the following are working correctly:
o LDM/IDD
o ldm-mcidas decoders
o McIDAS-XCD decoders
o ADDE remote server
While it may seem like a I did a lot, the total amount of time needed
to make the mods was on the order of a half hour. The thing that takes
the most time when doing something like this is documenting what was done
so that the end user (you) will have a record of what was changed and
why.
OK, so back to one of the problems you were having yesterday. When
you tried to start a McIDAS session, you got a warning about not being
able to allocate colors. This is caused by your system running X in
8-bit mode AND there already being applications running (maybe even
CDE itself) that are using most of the available colors. If you are
not running Netscape or other applications and you still get this
problem, you will need to modify your CDE environment to use less
colors.
When you get a chance, could you logon from work and try running McIDAS
as yourself? You can now bring up McIDAS with the MCGUI automatically
by simply running:
mcidas
This was made possible by the 'mcidas config' settings referenced to
above.
Ciao...
Tom
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.